From report at bugs.python.org  Thu Dec  1 00:43:38 2016
From: report at bugs.python.org (wim glenn)
Date: Thu, 01 Dec 2016 05:43:38 +0000
Subject: [issue28848] Add CopyingMock to mock.py
Message-ID: <1480571018.23.0.434543002887.issue28848@psf.upfronthosting.co.za>


New submission from wim glenn:

Would people be interested to consider adding the CopyingMock example shown in the documentation section "coping with mutable arguments" into the mock module?

https://docs.python.org/3/library/unittest.mock-examples.html#coping-with-mutable-arguments 

It seems like a useful and simple enough feature to add.

----------
components: Library (Lib)
messages: 282136
nosy: wim.glenn
priority: normal
severity: normal
status: open
title: Add CopyingMock to mock.py
versions: Python 3.7

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

From report at bugs.python.org  Thu Dec  1 00:59:15 2016
From: report at bugs.python.org (wim glenn)
Date: Thu, 01 Dec 2016 05:59:15 +0000
Subject: [issue28848] Add CopyingMock to mock.py
In-Reply-To: <1480571018.23.0.434543002887.issue28848@psf.upfronthosting.co.za>
Message-ID: <1480571955.12.0.693605926958.issue28848@psf.upfronthosting.co.za>


wim glenn added the comment:

Here's a first attempt at a patch.  

If it doesn't go into Lib finally, I'll just put up a CopyingMock on pypi instead.  But it seemed like the kind of feature which should just be in mock directly rather than 3rd party, preferably.

----------
keywords: +patch
Added file: http://bugs.python.org/file45715/copying_mock.diff

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

From report at bugs.python.org  Thu Dec  1 02:21:23 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 01 Dec 2016 07:21:23 +0000
Subject: [issue28728] test_host_resolution in test_socket fails
In-Reply-To: <1479407743.41.0.909577209709.issue28728@psf.upfronthosting.co.za>
Message-ID: <1480576883.2.0.923397246015.issue28728@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Ohh, sorry.

> I was wondering if there was a separate way to detect the troublesome ISP environment.

How could you differentiate the failure between ISP environment caused and function behaved wrongly? Successfully resolve an invalid ip address doesn't mean you can successfully resolve a bogus domain.

I think this case should be rare. Maybe we can just fail the test and warn the user this failure is not 100% caused by function's misbehaviour, just like test_bad_address.

----------
Added file: http://bugs.python.org/file45716/test_host_resolution-v2.patch

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

From report at bugs.python.org  Thu Dec  1 02:40:13 2016
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 01 Dec 2016 07:40:13 +0000
Subject: [issue27647] Update Windows build to Tcl/Tk 8.6.6
In-Reply-To: <1480492894.95.0.734204087595.issue27647@psf.upfronthosting.co.za>
Message-ID: <1480578010.1655751.804717193.489CED65@webmail.messagingengine.com>


Benjamin Peterson added the comment:

I don't mind if it gets updated.

On Wed, Nov 30, 2016, at 00:01, Serhiy Storchaka wrote:
> 
> Serhiy Storchaka added the comment:
> 
> Why not? 8.5.15 is 3 years old. There were 4 bugfix releases since it.
> 
> ----------
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue27647>
> _______________________________________

----------

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

From report at bugs.python.org  Thu Dec  1 03:06:07 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 01 Dec 2016 08:06:07 +0000
Subject: [issue28849] do not define sys.implementation._multiarch on Android
Message-ID: <1480579567.9.0.848858013461.issue28849@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

Android is not a multiarch system and the unix build system can cross compile non-multiarch systems as well as multiarch systems.  This is a follow up of the decisions implemented in issue 28046 and the patch fixes also an oversight made in this issue in Makefile.pre.in.

Also tested with the patch in issue 28833 that implements cross compilation of third-party extension modules.
Please run autoconf after installing the patch.

----------
assignee: xdegaye
components: Cross-Build
files: android_multiarch.patch
keywords: patch
messages: 282140
nosy: Alex.Willmer, Chi Hsuan Yen, doko, haypo, ned.deily, xdegaye, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: do not define sys.implementation._multiarch on Android
type: behavior
versions: Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45717/android_multiarch.patch

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

From report at bugs.python.org  Thu Dec  1 03:06:54 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Thu, 01 Dec 2016 08:06:54 +0000
Subject: [issue28833] cross compilation of third-party extension modules
In-Reply-To: <1480431100.4.0.611325572748.issue28833@psf.upfronthosting.co.za>
Message-ID: <1480579614.84.0.475443802856.issue28833@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

Well, cross compiling extension modules already works fine...

$ _PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata_m_linux_aarch64-linux-android PYTHONHOME=~/Projects/python3-android/build/21-aarch64-linux-android-4.9/usr python3.7 setup.py build_ext
running build_ext
building 'xx' extension
creating build
creating build/temp.linux-x86_64-3.7
/opt/android-ndk/toolchains/llvm/prebuilt/linux-x86_64/bin/clang -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -target aarch64-none-linux-android -gcc-toolchain /opt/android-ndk/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64 --sysroot=/opt/android-ndk/platforms/android-21/arch-arm64/usr -fPIE -fno-integrated-as -target aarch64-none-linux-android -gcc-toolchain /opt/android-ndk/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64 --sysroot=/opt/android-ndk/platforms/android-21/arch-arm64/usr -fPIE -fno-integrated-as -fPIC -I/home/yen/Projects/python3-android/build/21-aarch64-linux-android-4.9/usr/include/python3.7m -c xxmodule.c -o build/temp.linux-x86_64-3.7/xxmodule.o
creating build/lib.linux-x86_64-3.7
/opt/android-ndk/toolchains/llvm/prebuilt/linux-x86_64/bin/clang -shared -target aarch64-none-linux-android -gcc-toolchain /opt/android-ndk/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64 --sysroot=/opt/android-ndk/platforms/android-21/arch-arm64/usr -pie -L/home/yen/Projects/python3-android/build/21-aarch64-linux-android-4.9/usr/lib -target aarch64-none-linux-android -gcc-toolchain /opt/android-ndk/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64 --sysroot=/opt/android-ndk/platforms/android-21/arch-arm64/usr -pie -L/home/yen/Projects/python3-android/build/21-aarch64-linux-android-4.9/usr/lib build/temp.linux-x86_64-3.7/xxmodule.o -o build/lib.linux-x86_64-3.7/xx.cpython-37m-aarch64-linux-android.so
clang: warning: argument unused during compilation: '-pie'
clang: warning: argument unused during compilation: '-pie'

And it's running fine, too:

$ adb push build/lib.linux-x86_64-3.7/xx.cpython-37m-aarch64-linux-android.so /data/local/tmp
[100%] /data/local/tmp/xx.cpython-37m-aarch64-linux-android.so

$ adb shell
shell at ASUS_Z00E_2:/ $ cd /data/local/tmp
shell at ASUS_Z00E_2:/data/local/tmp $ . ./python3/tools/env.sh
shell at ASUS_Z00E_2:/data/local/tmp $ python3.7m
Python 3.7.0a0 (default:3d660ed2a60e+, Nov 23 2016, 20:22:14) 
[GCC 4.2.1 Compatible Android Clang 3.8.256229 ] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import xx
>>> xx
<module 'xx' from '/data/local/tmp/xx.cpython-37m-aarch64-linux-android.so'>
>>>

Here's my xxmodule.c:

#include "Python.h"

PyDoc_STRVAR(module_doc,
"This is a template module just for instruction.");

static struct PyModuleDef xxmodule = {
    PyModuleDef_HEAD_INIT,
    "xx",
    module_doc,
    0,
    NULL,
    NULL,
    NULL,
    NULL,
    NULL
};

PyMODINIT_FUNC
PyInit_xx(void)
{
    return PyModuleDef_Init(&xxmodule);
}

And setup.py:

from distutils.core import setup, Extension

module1 = Extension('xx',
                    sources=['xxmodule.c'])

setup(name='PackageName',
      version='1.0',
      description='This is a demo package',
      ext_modules=[module1])

Both the host and target Python are built from a6e59a2e880e

There's a little bug in the built filename: build/lib.linux-x86_64-3.7/xx.cpython-37m-aarch64-linux-android.so, which should be build/lib.linux-aarch64-3.7/xx.cpython-37m-aarch64-linux-android.so.

Also, I guess there may be quirks if NDK or the cross-built CPython is at different locations than built-time configurations. Those issues can be left to the future.

----------

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

From report at bugs.python.org  Thu Dec  1 03:11:45 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Dec 2016 08:11:45 +0000
Subject: [issue28740] Add sys.getandroidapilevel()
In-Reply-To: <1479504395.69.0.761590307394.issue28740@psf.upfronthosting.co.za>
Message-ID: <1480579905.01.0.177086537285.issue28740@psf.upfronthosting.co.za>


STINNER Victor added the comment:

getandroidapilevel-3.patch: Updated version of getandroidapilevel.patch: replace "runtime" with "build time" in the doc :-) Remove also "version > 0" check in support/__init__.py.

About the version > 0 check: would it make sense to add the check in configure.ac? I guess that it was Xavier who wrote the test in support/__init__.py?

----------
Added file: http://bugs.python.org/file45718/getandroidapilevel-3.patch

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

From report at bugs.python.org  Thu Dec  1 03:16:37 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Dec 2016 08:16:37 +0000
Subject: [issue28740] Add sys.getandroidapilevel()
In-Reply-To: <1479504395.69.0.761590307394.issue28740@psf.upfronthosting.co.za>
Message-ID: <1480580197.86.0.425550220336.issue28740@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I suggest to start to add sys.getandroidapilevel(), and then discuss how to expose (or not) the runtime version.

Reminder: The first step is to have a working Python on Android. I opened this issue to fix the issue #28596. Getting the runtime version is a new Android-specific version, it can be done later.

----------

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

From report at bugs.python.org  Thu Dec  1 03:23:33 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 01 Dec 2016 08:23:33 +0000
Subject: [issue28833] cross compilation of third-party extension modules
In-Reply-To: <1480431100.4.0.611325572748.issue28833@psf.upfronthosting.co.za>
Message-ID: <1480580613.81.0.960063674788.issue28833@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

$ _PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata_m_linux_aarch64-linux-android PYTHONHOME=~/Projects/python3-android/build/21-aarch64-linux-android-4.9/usr python3.7 setup.py build_ext
>

Variables prefixed by an underscore such as '_PYTHON_SYSCONFIGDATA_NAME' are private, please do not use them, they may be changed or removed at any time.

----------

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

From report at bugs.python.org  Thu Dec  1 03:27:45 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 01 Dec 2016 08:27:45 +0000
Subject: [issue11145] '%o' % user-defined instance
In-Reply-To: <1297104394.76.0.0164852469273.issue11145@psf.upfronthosting.co.za>
Message-ID: <20161201082742.12692.70987.306AA538@psf.io>


Roundup Robot added the comment:

New changeset adb296e4bcaa by Serhiy Storchaka in branch '2.7':
Issue #11145: Fixed miscellaneous issues with C-style formatting of types
https://hg.python.org/cpython/rev/adb296e4bcaa

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

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

From report at bugs.python.org  Thu Dec  1 03:46:26 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 01 Dec 2016 08:46:26 +0000
Subject: [issue28838] Uniformize argument names of "call" functions (C API)
In-Reply-To: <1480504437.73.0.907175245586.issue28838@psf.upfronthosting.co.za>
Message-ID: <1480581986.09.0.297136317183.issue28838@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> * Callable object: callable, o, callable_object => func

The original names better describes the argument type in functions like PyObject_Call(). It works not just with functions, but with arbitrary callables. For example it is used with type objects for creating instances.

> * Method name: name or nameid => method

The parameter is not a *method object*, but a method *name*. You have to pass an object and a method names to call a method.

> Serhiy: Can you please elaborate "Other changes looks not well justified too."?

Renaming obj to arg0 looks questionable to me. I would rather rename func to method (this is a true unbound method, not method name as in PyObject_CallMethod()).

It would be better to uniformize parameter names in the documentation (and perhaps in headers) and left sources untouched unless we rewrite particular functions. Otherwise it looks as code churn. It would be nice to formalize naming rules in PEP 7.

See also issue18697.

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

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

From report at bugs.python.org  Thu Dec  1 03:46:35 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Thu, 01 Dec 2016 08:46:35 +0000
Subject: [issue28833] cross compilation of third-party extension modules
In-Reply-To: <1480431100.4.0.611325572748.issue28833@psf.upfronthosting.co.za>
Message-ID: <1480581995.9.0.913147009052.issue28833@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

I know. I guess it can be determined without manually specifying but haven't investigated into details. Maybe some patches are necessary.

----------

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

From report at bugs.python.org  Thu Dec  1 03:47:56 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 01 Dec 2016 08:47:56 +0000
Subject: [issue11145] '%o' % user-defined instance
In-Reply-To: <1297104394.76.0.0164852469273.issue11145@psf.upfronthosting.co.za>
Message-ID: <1480582076.45.0.290900641791.issue11145@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Dec  1 03:54:43 2016
From: report at bugs.python.org (Shai Berger)
Date: Thu, 01 Dec 2016 08:54:43 +0000
Subject: [issue27286] str object got multiple values for keyword argument
In-Reply-To: <1465551431.42.0.267871198404.issue27286@psf.upfronthosting.co.za>
Message-ID: <1480582483.43.0.205245057236.issue27286@psf.upfronthosting.co.za>


Shai Berger added the comment:

Following the last comment, and just as clarification for anyone else running into this and thinking like me: The bumped code is not included in v3.5.2, and v3.5.3 hasn't been released yet. Should it be undone?

No, because the bump which was encountered by John Ehresman on Debian Testing has also made it into Ubuntu 16.04LTS. Undoing it, at this point, is liable to bring even worse breakage than the original change caused.

http://changelogs.ubuntu.com/changelogs/pool/main/p/python3.5/python3.5_3.5.2-2ubuntu0~16.04.1/changelog

----------
nosy: +shai

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

From report at bugs.python.org  Thu Dec  1 03:56:12 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Thu, 01 Dec 2016 08:56:12 +0000
Subject: [issue28849] do not define sys.implementation._multiarch on Android
In-Reply-To: <1480579567.9.0.848858013461.issue28849@psf.upfronthosting.co.za>
Message-ID: <1480582572.07.0.0894799045509.issue28849@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

Actually all UNIX-like platforms now have non-empty sys.implementation._multiarch now (msg273875). An idea is renaming it to something like target_architecture to make things clearer. It will be a triplet on all system, whether cross-built or not.

----------

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

From report at bugs.python.org  Thu Dec  1 03:58:17 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Thu, 01 Dec 2016 08:58:17 +0000
Subject: [issue28740] Add sys.getandroidapilevel()
In-Reply-To: <1479504395.69.0.761590307394.issue28740@psf.upfronthosting.co.za>
Message-ID: <1480582697.25.0.538719414493.issue28740@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

How about renaming sys.implementation._multiarch to sys.implementation.target_architecture and make it public? sys.androidapilevel() sounds too specific to me.

----------

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

From report at bugs.python.org  Thu Dec  1 04:10:37 2016
From: report at bugs.python.org (piotr.sk)
Date: Thu, 01 Dec 2016 09:10:37 +0000
Subject: [issue28840] IDLE not handling long lines correctly
In-Reply-To: <1480514700.66.0.957548851102.issue28840@psf.upfronthosting.co.za>
Message-ID: <1480583437.96.0.432687309716.issue28840@psf.upfronthosting.co.za>


piotr.sk added the comment:

Thank you for explanation of the background problem. Updating documentation as you mention is a good next step.

Thanks as well for the proposed solution of splitting the input string, but as long as it is just a display issue, this is not needed for test strings. 

On the other side, given tkinter limitations of displaying lines longer than 2728 characters, I propose following solution for IDLE:
If line to display is longer than 2728 characters (or whatever limit you set, let?s call it X), by default replace it with a line of X-3 initial characters followed by ?...? (internally, just for displaying purposes ;-)). As long as the current cursor position is not beyond X-3 column (99.99% of time working with the script), display the truncated line.  

This will avoid confusion, as users will not see ?empty?/?strange? lines browsing through the code and if someone really wants to manually edit character after the X-3 column, the display will be adapted accordingly.

Let me know what you think about it.

----------

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

From report at bugs.python.org  Thu Dec  1 04:14:42 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 01 Dec 2016 09:14:42 +0000
Subject: [issue28839] _PyFunction_FastCallDict(): replace PyTuple_New() with
 PyMem_Malloc()
In-Reply-To: <1480505567.26.0.13388381207.issue28839@psf.upfronthosting.co.za>
Message-ID: <1480583682.75.0.524471702602.issue28839@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I agree with Josh, PyTuple_New() can be faster than PyMem_Malloc() due to tuple free list. small_stack increases C stack consumption even for calls without keyword arguments. This is serious problem since we can't control stack overflow.

----------

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

From report at bugs.python.org  Thu Dec  1 04:28:49 2016
From: report at bugs.python.org (Julien Palard)
Date: Thu, 01 Dec 2016 09:28:49 +0000
Subject: [issue26483] docs unclear on difference between str.isdigit() and
 str.isdecimal()
In-Reply-To: <1457121897.81.0.495681677897.issue26483@psf.upfronthosting.co.za>
Message-ID: <1480584529.39.0.0628025544175.issue26483@psf.upfronthosting.co.za>


Julien Palard added the comment:

?digits which do not form decimal radix forms?

> ?forming a form? seems a long way of saying very little. The difference seems a bit vague

> I gather that digits not in the Unicode ?decimal digit? category are often (always?) still decimal digits

I expected them not to, but they often are representative of a base 10 value:

>>> import sys
>>> import unicodedata
>>> chars = ''.join(map(chr, range(sys.maxunicode+1)))
>>> decimals = ''.join(filter(str.isdecimal, chars))
>>> digits = ''.join(filter(str.isdigit, chars))
>>> non_decimal_digits = set(digits) - set(decimals)
>>> from collections import Counter
>>> Counter([unicodedata.digit(char) for char in non_decimal_digits])
Counter({1: 15, 2: 14, 3: 14, 4: 14, 5: 13, 6: 13, 7: 13, 8: 13, 9: 13, 0: 6})

But, note that there's one more in the range [1,4], it's the [Kharosthi](https://en.wikipedia.org/wiki/Kharosthi) numbers, they do not use base 10 but a notation reminiscent of Roman numerals.

So here, clearly, all digits are not an notation for a base 10 value.
 
> but primarily used for a symbolic or typographical meaning more than in a plain number, e.g. superscripts, subscripts and other fonts, added circles and other decorations.

Which also can't be used to form a base 10 number.

So here is another proposition for isdecimal, probably more human friendly:

    Return true if all characters in the string are decimal
    characters and there is at least one character, false
    otherwise. Decimal characters are those that can be used to form
    numbers in base 10, e.g. U+0660, ARABIC-INDIC DIGIT
    ZERO. Formally a decimal character is a character in the Unicode
    General Category "Nd".

And here is another proposition for isdigit, probably friendlier too:

    Return true if all characters in the string are digits and there is at least one
    character, false otherwise.  Digits include decimal characters and digits that need
    special handling, such as the compatibility superscript digits.
    This covers digits which cannot be used to form numbers in base 10, like the Kharosthi numbers.
    Formally, a digit is a character that has the property value
    Numeric_Type=Digit or Numeric_Type=Decimal.

----------

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

From report at bugs.python.org  Thu Dec  1 05:05:27 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Dec 2016 10:05:27 +0000
Subject: [issue28839] _PyFunction_FastCallDict(): replace PyTuple_New() with
 PyMem_Malloc()
In-Reply-To: <1480505567.26.0.13388381207.issue28839@psf.upfronthosting.co.za>
Message-ID: <1480586727.92.0.388079084075.issue28839@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Patch version: fix the "if (0)" to use the small stack allocated on the C stack.

----------
Added file: http://bugs.python.org/file45719/fastcalldict-3.patch

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

From report at bugs.python.org  Thu Dec  1 05:40:47 2016
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 01 Dec 2016 10:40:47 +0000
Subject: [issue28833] cross compilation of third-party extension modules
In-Reply-To: <1480431100.4.0.611325572748.issue28833@psf.upfronthosting.co.za>
Message-ID: <1480588847.83.0.485047796937.issue28833@psf.upfronthosting.co.za>


Matthias Klose added the comment:

again, I don't think relying on a specific target path for a cross target is a good idea. and now deciding that the last possibility to use a target id to identify is better is internal doesn't make it better.  I'd appreciate if we could sit together where your work will lead to, and see how we accomplish everybody's goals.

----------

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

From report at bugs.python.org  Thu Dec  1 05:49:43 2016
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 01 Dec 2016 10:49:43 +0000
Subject: [issue28849] do not define sys.implementation._multiarch on Android
In-Reply-To: <1480579567.9.0.848858013461.issue28849@psf.upfronthosting.co.za>
Message-ID: <1480589383.59.0.248893831896.issue28849@psf.upfronthosting.co.za>


Matthias Klose added the comment:

> An idea is renaming it to something like target_architecture
> to make things clearer

Yes, that was my intent, and I think it is the right solution. using $(MACHDEP)_$(MULTIARCH) in the sysconfigdata name and probably in other places was not a good idea (introduced by the platdir removal).

There's no reason why this target_architecture could be used by any unix like platform.

----------

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

From report at bugs.python.org  Thu Dec  1 05:57:22 2016
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 01 Dec 2016 10:57:22 +0000
Subject: [issue28833] cross compilation of third-party extension modules
In-Reply-To: <1480431100.4.0.611325572748.issue28833@psf.upfronthosting.co.za>
Message-ID: <1480589842.08.0.311956468837.issue28833@psf.upfronthosting.co.za>


Matthias Klose added the comment:

> Hum, you still need to provide the native python interpreter
> with the _path_ to the <target>-python-config executable that
> can be anywhere on the file system

No, it's found in the same path. No contradiction.

> So I suggest we start with this patch as it works for:

Please do not.

> Then we can later extend the semantics of XBUILD_PYTHON_DIR

Again, I think that's the wrong way to go rely on any path as the primary id for the target, then "extending" on it makes it worse.

----------

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

From report at bugs.python.org  Thu Dec  1 06:29:04 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 01 Dec 2016 11:29:04 +0000
Subject: [issue28847] dumbdbm should not commit if in read mode
In-Reply-To: <1480564427.92.0.600594500998.issue28847@psf.upfronthosting.co.za>
Message-ID: <1480591744.51.0.942777527828.issue28847@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Do you have concrete example when not ignoring an OSError in _update causes an issue? This is needed for writing tests.

----------
components: +Library (Lib)
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Thu Dec  1 06:45:23 2016
From: report at bugs.python.org (=?utf-8?q?Michael_En=C3=9Flin?=)
Date: Thu, 01 Dec 2016 11:45:23 +0000
Subject: [issue28850] Regression in Python 3: Subclassing PrettyPrinter.format
 doesn't work anymore
Message-ID: <1480592723.97.0.369129599105.issue28850@psf.upfronthosting.co.za>


New submission from Michael En?lin:

This issue was previously addressed and fixed here:

http://bugs.python.org/issue1351692

When subclassing PrettyPrinter, overriding the format() method should allow users to define custom pretty-printers.

However, for objects whose repr is short, format() is not called for the individual members.

Example code that reproduces the issue is as follows:


import pprint
import sys

pprint.pprint(sys.version_info)

class MyPrettyPrinter(pprint.PrettyPrinter):
    def format(self, object, context, maxlevels, level):
        if isinstance(object, int):
            return hex(object), True, False
        else:
            return pprint.PrettyPrinter.format(self, object, context, maxlevels, level)

MyPrettyPrinter().pprint(10)
MyPrettyPrinter().pprint([10])


When run with different versions of Python:


sys.version_info(major=2, minor=7, micro=11, releaselevel='final', serial=0)
0xa
[0xa]

(3, 0, 1, 'final', 0)
0xa
[10]

sys.version_info(major=3, minor=2, micro=5, releaselevel='final', serial=0)
0xa
[10]

sys.version_info(major=3, minor=4, micro=4, releaselevel='final', serial=0)
0xa
[10]

sys.version_info(major=3, minor=6, micro=0, releaselevel='beta', serial=4)
0xa
[10]

You'll notice that the regression exists in all versions >= 3.0,
even though the commit that fixed the issue is still in the log (2008-01-20):
https://hg.python.org/cpython/log/3.0/Lib/pprint.py

I have not had the time to look at the source of the issue or provide a fix; I might do so tonight.

----------
components: Library (Lib)
messages: 282159
nosy: anthonybaxter, doerwalter, georg.brandl, gvanrossum, markhirota, mic_e, rhettinger
priority: normal
severity: normal
status: open
title: Regression in Python 3: Subclassing PrettyPrinter.format doesn't work anymore
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/issue28850>
_______________________________________

From report at bugs.python.org  Thu Dec  1 07:06:04 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 01 Dec 2016 12:06:04 +0000
Subject: [issue17490] Improve ast.literal_eval test suite coverage
In-Reply-To: <1363746875.32.0.0832947039866.issue17490@psf.upfronthosting.co.za>
Message-ID: <1480593964.74.0.65180079661.issue17490@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I agreed with Raymond, the current version of the code looks clearer.

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

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

From report at bugs.python.org  Thu Dec  1 07:07:32 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Dec 2016 12:07:32 +0000
Subject: [issue28839] _PyFunction_FastCallDict(): replace PyTuple_New() with
 PyMem_Malloc()
In-Reply-To: <1480505567.26.0.13388381207.issue28839@psf.upfronthosting.co.za>
Message-ID: <1480594052.03.0.202766779194.issue28839@psf.upfronthosting.co.za>


STINNER Victor added the comment:

bench_fastcalldict.py: hardcore microbenchmark on _PyFunction_FastCallDict(). Pass keyword arguments to the tp_init slot of a Python constructor. Result for 1, 5 and 10 keyword arguments:

kw1: Median +- std dev: [ref] 329 ns +- 21 ns -> [patch] 306 ns +- 17 ns: 1.07x faster (-7%)
kw5: Median +- std dev: [ref] 508 ns +- 22 ns -> [patch] 481 ns +- 25 ns: 1.05x faster (-5%)
kw10: Median +- std dev: [ref] 829 ns +- 45 ns -> [patch] 805 ns +- 39 ns: 1.03x faster (-3%)

As expected, the difference is small, but it's faster :-) Indirect benefit is that the garbage collector should be less stressed :-) (tuples are tracked by the GC.)

Note: Using a simple printf() in the C code, I noticed that it is not uncommon that _PyFunction_FastCallDict() is called with an empty dictionary for keyword arguments. Without the patch, an empty tuple was created. With my patch, "unpack" the empty dictionary costs nothing.

----------
Added file: http://bugs.python.org/file45720/bench_fastcalldict.py

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

From report at bugs.python.org  Thu Dec  1 07:07:44 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Dec 2016 12:07:44 +0000
Subject: [issue28839] _PyFunction_FastCallDict(): replace PyTuple_New() with
 PyMem_Malloc()
In-Reply-To: <1480505567.26.0.13388381207.issue28839@psf.upfronthosting.co.za>
Message-ID: <1480594064.22.0.156818790768.issue28839@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


Removed file: http://bugs.python.org/file45720/bench_fastcalldict.py

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

From report at bugs.python.org  Thu Dec  1 07:08:28 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Dec 2016 12:08:28 +0000
Subject: [issue28839] _PyFunction_FastCallDict(): replace PyTuple_New() with
 PyMem_Malloc()
In-Reply-To: <1480505567.26.0.13388381207.issue28839@psf.upfronthosting.co.za>
Message-ID: <1480594108.29.0.159093438041.issue28839@psf.upfronthosting.co.za>


STINNER Victor added the comment:

(Oops, I attached the wrong benchmark script. It's now fixed.)

----------
Added file: http://bugs.python.org/file45721/bench_fastcalldict.py

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

From report at bugs.python.org  Thu Dec  1 07:11:20 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 01 Dec 2016 12:11:20 +0000
Subject: [issue28755] Rework syntax highlighing in howto/clinic.rst
In-Reply-To: <1479679317.44.0.842687607942.issue28755@psf.upfronthosting.co.za>
Message-ID: <1480594279.99.0.0109355344676.issue28755@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> (Ned asked for only release-critical changes to go into 3.6 at the moment.)

Except the documentation changes.

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

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

From report at bugs.python.org  Thu Dec  1 07:21:42 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 01 Dec 2016 12:21:42 +0000
Subject: [issue17490] Improve ast.literal_eval test suite coverage
In-Reply-To: <1363746875.32.0.0832947039866.issue17490@psf.upfronthosting.co.za>
Message-ID: <1480594902.07.0.663008362837.issue17490@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Right, the only reason this is still open is because I thought the extra test cases might be interesting in their own right (just not interesting enough to sit down and apply).

----------

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

From report at bugs.python.org  Thu Dec  1 07:22:49 2016
From: report at bugs.python.org (Xavier Combelle)
Date: Thu, 01 Dec 2016 12:22:49 +0000
Subject: [issue26363] __builtins__ propagation is misleading described in exec
 and eval documentation
In-Reply-To: <1455532935.35.0.388834921119.issue26363@psf.upfronthosting.co.za>
Message-ID: <1480594969.57.0.912906072492.issue26363@psf.upfronthosting.co.za>


Xavier Combelle added the comment:

Hi Julien,

You are fully right that it is the builtin module dictionnary which is inserted in eval or exec context.

However, if a "__builtins__" entry is passed to eval or exec, this builtin module dictionnary is modified hence the following work: 

>>> d={"tata":"tata"}
>>> print(eval("tata",{'__builtins__':d}))
tata

----------

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

From report at bugs.python.org  Thu Dec  1 07:23:05 2016
From: report at bugs.python.org (Jonathan Ng)
Date: Thu, 01 Dec 2016 12:23:05 +0000
Subject: [issue28847] dumbdbm should not commit if in read mode
In-Reply-To: <1480564427.92.0.600594500998.issue28847@psf.upfronthosting.co.za>
Message-ID: <1480594985.41.0.695269027337.issue28847@psf.upfronthosting.co.za>


Jonathan Ng added the comment:

I'm not sure how to create an OSError.

But perhaps something like this:

'''
from dbm import dumb
import os

db = dumb.open('temp', flag='n')
db['foo'] = 'bar'
db.close()

db = dumb.open('temp', flag='r')
print(len(db.keys()))
db.close

os.rename('temp.dir', 'temp_.dir') # simulates OSError
db = dumb.open('temp', flag='r')
os.rename('temp_.dir', 'temp.dir')
db.close()

db = dumb.open('temp', flag='r')
assert len(db.keys()) > 0
'''

----------

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

From report at bugs.python.org  Thu Dec  1 07:41:51 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 01 Dec 2016 12:41:51 +0000
Subject: [issue28847] dumbdbm should not commit if in read mode
In-Reply-To: <1480564427.92.0.600594500998.issue28847@psf.upfronthosting.co.za>
Message-ID: <1480596110.99.0.836686386846.issue28847@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This example is too artificial.

But there is a real issue: opening read-only files in read mode. Currently this causes a PermissionError on closing.

For backward compatibility flags 'r' and 'w' are ignored. I.e. opening with 'r' and 'w' creates a file if it is not existing, and opening with 'r' allows modifying the database. Since 3.6 this emits deprecation warnings (issue21708). In future versions this will be an error.

Proposed patch makes two changes:

1. The index file no longer written if the database was not modified. This increases performance and adds a support of read-only files.

2. A deprecation warning is raised when the index file is absent in 'r' and 'w' modes. In future versions this will be an error.

May be the first change can be backported.

----------
keywords: +patch
stage:  -> patch review
type: behavior -> enhancement
versions: +Python 3.7
Added file: http://bugs.python.org/file45722/dbm_dumb_readonly.patch

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

From report at bugs.python.org  Thu Dec  1 07:44:29 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Dec 2016 12:44:29 +0000
Subject: [issue28839] _PyFunction_FastCallDict(): replace PyTuple_New() with
 PyMem_Malloc()
In-Reply-To: <1480505567.26.0.13388381207.issue28839@psf.upfronthosting.co.za>
Message-ID: <1480596269.28.0.642033841859.issue28839@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Note: Using a simple printf() in the C code, I noticed that it is not uncommon that _PyFunction_FastCallDict() is called with an empty dictionary for keyword arguments.

Simplified Python example where _PyFunction_FastCallDict() is called with an empty dictionary:
---
def f2():
    pass

def wrapper(func, *args, **kw):
    # CALL_FUNCTION_EX: func(**{}) calls PyObject_Call() with kwargs={} which
    # calls _PyFunction_FastCallDict()
    func(*args, **kw)

def f():
    # CALL_FUNCTION: calling wrapper calls fast_function() which calls
    # _PyEval_EvalCodeWithName() which creates an empty dictionary for kw
    wrapper(f2)

f()
---

But on this specific case, the speedup is *very* small: 3 nanoseconds :-)

./python -m perf timeit -s 'kw={}' -s 'def func(): pass' --duplicate=1000 'func(**kw)'
(...)
Median +- std dev: [ref] 108 ns +- 4 ns -> [patch] 105 ns +- 5 ns: 1.02x faster (-2%)

----------

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

From report at bugs.python.org  Thu Dec  1 07:47:26 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Dec 2016 12:47:26 +0000
Subject: [issue28839] _PyFunction_FastCallDict(): replace PyTuple_New() with
 PyMem_Malloc()
In-Reply-To: <1480505567.26.0.13388381207.issue28839@psf.upfronthosting.co.za>
Message-ID: <1480596446.47.0.662049270613.issue28839@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Serhiy: "small_stack increases C stack consumption even for calls without keyword arguments. This is serious problem since we can't control stack overflow."

This problem is not new and is worked around by Py_EnterRecursiveCall() macro which counts the depth of the Python stack.

I didn't notice any stack overflow crash with my patch. We can reduce the "small_stack" size later if needed.

----------

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

From report at bugs.python.org  Thu Dec  1 07:48:37 2016
From: report at bugs.python.org (Jonathan Ng)
Date: Thu, 01 Dec 2016 12:48:37 +0000
Subject: [issue28847] dumbdbm should not commit if in read mode
In-Reply-To: <1480596110.99.0.836686386846.issue28847@psf.upfronthosting.co.za>
Message-ID: <CAEadZoOogJ72eqKgU9QSX1JKk+Dt+N4vc_QyZr20VxiAzFOXRw@mail.gmail.com>


Jonathan Ng added the comment:

#1 makes sense to be backported.

On Thu, Dec 1, 2016 at 8:41 PM, Serhiy Storchaka <report at bugs.python.org>
wrote:

>
> Serhiy Storchaka added the comment:
>
> This example is too artificial.
>
> But there is a real issue: opening read-only files in read mode. Currently
> this causes a PermissionError on closing.
>
> For backward compatibility flags 'r' and 'w' are ignored. I.e. opening
> with 'r' and 'w' creates a file if it is not existing, and opening with 'r'
> allows modifying the database. Since 3.6 this emits deprecation warnings
> (issue21708). In future versions this will be an error.
>
> Proposed patch makes two changes:
>
> 1. The index file no longer written if the database was not modified. This
> increases performance and adds a support of read-only files.
>
> 2. A deprecation warning is raised when the index file is absent in 'r'
> and 'w' modes. In future versions this will be an error.
>
> May be the first change can be backported.
>
> ----------
> keywords: +patch
> stage:  -> patch review
> type: behavior -> enhancement
> versions: +Python 3.7
> Added file: http://bugs.python.org/file45722/dbm_dumb_readonly.patch
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue28847>
> _______________________________________
>

----------

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

From report at bugs.python.org  Thu Dec  1 08:00:10 2016
From: report at bugs.python.org (fiete)
Date: Thu, 01 Dec 2016 13:00:10 +0000
Subject: [issue28699] Imap from ThreadPool behaves unexpectedly
In-Reply-To: <1479234139.82.0.483433491582.issue28699@psf.upfronthosting.co.za>
Message-ID: <1480597210.36.0.545700315512.issue28699@psf.upfronthosting.co.za>


fiete added the comment:

Since the only thing I know about the multiprocessing internals is what I just read in the source code trying to debug my imap_unordered call, I'll add the following example, not knowing whether this is already covered by everything you have until now.


import multiprocessing.pool

def gen():
    raise Exception('generator exception')
    yield 1
    yield 2

for i in range(3):
    with multiprocessing.pool.ThreadPool(3) as pool:
        try:
            print(list(pool.imap_unordered(lambda x: x*2, gen())))
        except Exception as e:
            print(e)


This only prints 'generator exception' once for the first iteration. For the following iterations imap_unordered returns an empty list. This is the case for both Pool and ThreadPool.

----------
nosy: +fiete

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

From report at bugs.python.org  Thu Dec  1 08:04:36 2016
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 01 Dec 2016 13:04:36 +0000
Subject: [issue28638] Creating namedtuple is too slow to be used in common
 stdlib (e.g. functools)
In-Reply-To: <1478578044.23.0.961493371476.issue28638@psf.upfronthosting.co.za>
Message-ID: <1480597476.92.0.404603034665.issue28638@psf.upfronthosting.co.za>


INADA Naoki added the comment:

(reopen the issue to discuss about using Argument Clinic)

----------
resolution: rejected -> 
status: closed -> open

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

From report at bugs.python.org  Thu Dec  1 08:20:28 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 01 Dec 2016 13:20:28 +0000
Subject: [issue20438] inspect: Deprecate getfullargspec?
In-Reply-To: <1391014813.06.0.594760406572.issue20438@psf.upfronthosting.co.za>
Message-ID: <1480598428.31.0.916500207974.issue20438@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Noting for the record, as the general way of querying an unbound method for the name of the first parameter and adding it to the bound arguments:

    def add_instance_arg(callable, bound_args):
        try:
            self = callable.__self__
            func = callable.__func__
        except AttributeError:
            return # Not a bound method
        unbound_sig = inspect.signature(func)
        for name in unbound_sig.parameters:
            bound_args.arguments[name] = self
            break

>>> method = C().method
>>> sig = inspect.signature(method)
>>> sig
<Signature (arg)>
>>> args = sig.bind(1)
>>> args
<BoundArguments (arg=1)>
>>> add_instance_arg(method, args)
>>> args
<BoundArguments (arg=1, self=<__main__.C object at 0x7f07ab719668>)>

----------

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

From report at bugs.python.org  Thu Dec  1 08:22:34 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 01 Dec 2016 13:22:34 +0000
Subject: [issue27172] Undeprecate inspect.getfullargspec()
In-Reply-To: <1464767888.9.0.788649321892.issue27172@psf.upfronthosting.co.za>
Message-ID: <1480598553.99.0.11367166802.issue27172@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Updated patch adding What's New and NEWS entries, and addressing Martin's review comments (mostly by accepting his suggestions).

I ended up leaving `inspect.getcallargs()` deprecated, and instead added a comment to issue 20438 noting how to achieve the bound args -> unbound args conversion in a general way: http://bugs.python.org/issue20438#msg282173

----------
Added file: http://bugs.python.org/file45723/issue27172_undeprecate_getfullargspec_v2.diff

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

From report at bugs.python.org  Thu Dec  1 08:25:12 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Dec 2016 13:25:12 +0000
Subject: [issue28839] _PyFunction_FastCallDict(): replace PyTuple_New() with
 PyMem_Malloc()
In-Reply-To: <1480505567.26.0.13388381207.issue28839@psf.upfronthosting.co.za>
Message-ID: <1480598712.1.0.951821794739.issue28839@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> I agree with Josh, PyTuple_New() can be faster than PyMem_Malloc() due to tuple free list.

According to benchmarks, PyTuple_New() is slower than PyMem_Malloc(). It's not surprising for me, using a tuple object requires extra work:

* Track and then untrack the object from the garbage collector
* Destructor uses Py_TRASHCAN_SAFE_BEGIN/Py_TRASHCAN_SAFE_END macros
* Some additional indirectons

When I started working on "fastcall", I was surprised that not creating tuples has a *significant* (positive) effect on performance. It seems to be between 5% and 45% faster. Obviously, it depends on the speed of the function body. The speedup is higher for faster functions, like fast functions implemented in C.

----------

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

From report at bugs.python.org  Thu Dec  1 08:31:53 2016
From: report at bugs.python.org (=?utf-8?q?Micha=C5=82_Bultrowicz?=)
Date: Thu, 01 Dec 2016 13:31:53 +0000
Subject: [issue28733] Show how to use mock_open in modules other that __main__
In-Reply-To: <1479475072.8.0.338397997846.issue28733@psf.upfronthosting.co.za>
Message-ID: <1480599113.14.0.864216214642.issue28733@psf.upfronthosting.co.za>


Micha? Bultrowicz added the comment:

One more update - I had the problem, because I was using monkeypatch.setattr() from Pytest, and assumed that it will work the same as patch(). This assumption turned out to be wrong.

----------

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

From report at bugs.python.org  Thu Dec  1 09:05:35 2016
From: report at bugs.python.org (Francesco Grondona)
Date: Thu, 01 Dec 2016 14:05:35 +0000
Subject: [issue28851] namedtuples field_names sequence preferred
Message-ID: <1480601135.13.0.00871251418973.issue28851@psf.upfronthosting.co.za>


New submission from Francesco Grondona:

A change by mhettinger in the doc of Python 2 years ago implicitely stated a sequence of strings as preferred way to provide 'field_names' to a namedtuple:

https://github.com/python/cpython/commit/7be6326e09f2062315f995a18ab54baedfd0c0ff

Same change should be integrated in Python 3, I see no reason to prefer the single string version.

----------
assignee: docs at python
components: Documentation
messages: 282177
nosy: docs at python, peentoon
priority: normal
severity: normal
status: open
title: namedtuples field_names sequence preferred
type: enhancement
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Thu Dec  1 09:09:42 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 01 Dec 2016 14:09:42 +0000
Subject: [issue28638] Creating namedtuple is too slow to be used in common
 stdlib (e.g. functools)
In-Reply-To: <1478578044.23.0.961493371476.issue28638@psf.upfronthosting.co.za>
Message-ID: <1480601382.07.0.194739716686.issue28638@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Argument Clinic is not needed, since we can use Makefile.

----------
Added file: http://bugs.python.org/file45724/functools-CacheInfo-Makefile.patch

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

From report at bugs.python.org  Thu Dec  1 09:09:50 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 01 Dec 2016 14:09:50 +0000
Subject: [issue23507] Tuple creation is too slow
In-Reply-To: <1424765312.55.0.269687406134.issue23507@psf.upfronthosting.co.za>
Message-ID: <20161201140943.42091.3386.4BFEF906@psf.io>


Roundup Robot added the comment:

New changeset b9c9691c72c5 by Victor Stinner in branch 'default':
Replace PyObject_CallFunctionObjArgs() with fastcall
https://hg.python.org/cpython/rev/b9c9691c72c5

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

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

From report at bugs.python.org  Thu Dec  1 09:12:01 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 01 Dec 2016 14:12:01 +0000
Subject: [issue23507] Tuple creation is too slow
In-Reply-To: <1424765312.55.0.269687406134.issue23507@psf.upfronthosting.co.za>
Message-ID: <1480601521.49.0.749949329561.issue23507@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think it would be better to optimize PyObject_CallFunctionObjArgs().

----------

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

From report at bugs.python.org  Thu Dec  1 09:13:31 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 01 Dec 2016 14:13:31 +0000
Subject: [issue28851] namedtuples field_names sequence preferred
In-Reply-To: <1480601135.13.0.00871251418973.issue28851@psf.upfronthosting.co.za>
Message-ID: <1480601611.05.0.377357412661.issue28851@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> rhettinger
nosy: +rhettinger

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

From report at bugs.python.org  Thu Dec  1 09:27:48 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 01 Dec 2016 14:27:48 +0000
Subject: [issue28839] _PyFunction_FastCallDict(): replace PyTuple_New() with
 PyMem_Malloc()
In-Reply-To: <1480505567.26.0.13388381207.issue28839@psf.upfronthosting.co.za>
Message-ID: <1480602468.72.0.914831871416.issue28839@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The problem with C stack overflow is not new, but your patch may make it worse (I don't know if it actually make it worse). Py_EnterRecursiveCall() is used for limiting Python stack. It can't prevent C stack overflow.

----------

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

From report at bugs.python.org  Thu Dec  1 09:30:38 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 01 Dec 2016 14:30:38 +0000
Subject: [issue28638] Creating namedtuple is too slow to be used in common
 stdlib (e.g. functools)
In-Reply-To: <1478578044.23.0.961493371476.issue28638@psf.upfronthosting.co.za>
Message-ID: <1480602638.42.0.0748948364986.issue28638@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

The concern with using the "generate a private module that can be cached" approach is that it doesn't generalise well - any time you want to micro-optimise a new module that way, you have to add a custom Makefile rule.

By contrast, Argument Clinic is a general purpose tool - adopting it for micro-optimisation in another file would just be a matter of adding that file to the list of files that trigger a clinic run. functools.py would be somewhat notable as the first Python file we do that for, but it isn't a novel concept overall.

That leads into my main comment on the AC patch: the files that are explicitly listed as triggering a new clinic run should be factored out into a named variable and that list commented accordingly.

----------

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

From report at bugs.python.org  Thu Dec  1 10:17:53 2016
From: report at bugs.python.org (Michael Hughes)
Date: Thu, 01 Dec 2016 15:17:53 +0000
Subject: [issue10444] A mechanism is needed to override waiting for Python
 threads to finish
In-Reply-To: <1480543090.05.0.358368178106.issue10444@psf.upfronthosting.co.za>
Message-ID: <B247D57B-3D07-48D2-80F9-73C45ED2A2E7@gmail.com>


Michael Hughes added the comment:

Given that this is from five years ago, and I've moved on, I honestly can't say I care too deeply about this.

My use case was for handling threads:
* created by inexperienced python programmers that don't know about daemons
* using third party python scripts that it would be easier not to edit

I feel that my proposed change handles that in a reasonable way, and doesn't complicate the interface for threads terribly. Most users can completely ignore the new method I proposed, and it won't affect them. For those going to look for it, it'll be there.

But again, I'm not even working in Python and no one else has chimed in on this in five years. Does it matter anymore?

- Michael

> On Nov 30, 2016, at 1:58 PM, Julien Palard <report at bugs.python.org> wrote:
> 
> 
> Julien Palard added the comment:
> 
> If nobody has nothing to add on this issue, I think it just should be closed.
> 
> ----------
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue10444>
> _______________________________________

----------

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

From report at bugs.python.org  Thu Dec  1 10:19:28 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Dec 2016 15:19:28 +0000
Subject: [issue28835] Change in behavior when overriding warnings.showwarning
 and with catch_warnings(record=True)
In-Reply-To: <1480465767.99.0.401403947818.issue28835@psf.upfronthosting.co.za>
Message-ID: <1480605568.69.0.934417561642.issue28835@psf.upfronthosting.co.za>


STINNER Victor added the comment:

It seems like a regression of Python 3.6, probably introduced by myself with add addition of warnings._showwarningmsg() and the source parameter.

----------
nosy: +haypo, ned.deily
priority: normal -> release blocker

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

From report at bugs.python.org  Thu Dec  1 10:21:23 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Thu, 01 Dec 2016 15:21:23 +0000
Subject: [issue10444] A mechanism is needed to override waiting for Python
 threads to finish
In-Reply-To: <1290002661.34.0.535369286873.issue10444@psf.upfronthosting.co.za>
Message-ID: <1480605683.37.0.99593250906.issue10444@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

Let's just close this.

----------
nosy: +ebarry
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Thu Dec  1 10:38:27 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 01 Dec 2016 15:38:27 +0000
Subject: [issue23507] Tuple creation is too slow
In-Reply-To: <1424765312.55.0.269687406134.issue23507@psf.upfronthosting.co.za>
Message-ID: <1480606707.55.0.0962840340023.issue23507@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is an example that shows increased stack consumption.

With old code it counts to 74700, with the patch it counts only to 65400.

Please revert your changes.

----------
Added file: http://bugs.python.org/file45725/stack_overflow.py

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

From report at bugs.python.org  Thu Dec  1 10:39:41 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Dec 2016 15:39:41 +0000
Subject: [issue23507] Tuple creation is too slow
In-Reply-To: <1424765312.55.0.269687406134.issue23507@psf.upfronthosting.co.za>
Message-ID: <1480606781.84.0.855538874697.issue23507@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I rewrote bench_builtins.py to use my new perf module.

Python 3.7 is between 1.27x and 1.42x faster than Python 3.6, but sorted(list) is slower. I don't know why sorted(list) is slower. It doesn't use a key function, and so should not be impacted by FASTCALL changes made since Python 3.6.

Benchmark results of Python 3.7 (include latest FASTCALL patches) compared to Python 3.5 (no FASTCALL):

filter(lambda x: x, range(1000)): Median +- std dev: [3.5] 126 us +- 7 us -> [3.7] 94.6 us +- 4.8 us: 1.34x faster (-25%)
map(lambda x, y: x+y, range(1000), range(1000)): Median +- std dev: [3.5] 163 us +- 10 us -> [3.7] 115 us +- 7 us: 1.42x faster (-30%)
map(lambda x: x, range(1000)): Median +- std dev: [3.5] 115 us +- 6 us -> [3.7] 90.9 us +- 5.4 us: 1.27x faster (-21%)
sorted(list): Median +- std dev: [3.5] 17.5 us +- 1.0 us -> [3.7] 19.7 us +- 1.1 us: 1.12x slower (+12%)
sorted(list, key=lambda x: x): Median +- std dev: [3.5] 122 us +- 10 us -> [3.7] 91.8 us +- 5.7 us: 1.33x faster (-25%)

Note: you need the development version of perf to run the script (future version 0.9.2).

----------
Added file: http://bugs.python.org/file45726/bench_builtins.py

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

From report at bugs.python.org  Thu Dec  1 10:49:13 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Dec 2016 15:49:13 +0000
Subject: [issue23507] Tuple creation is too slow
In-Reply-To: <1424765312.55.0.269687406134.issue23507@psf.upfronthosting.co.za>
Message-ID: <1480607353.09.0.732226109095.issue23507@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Serhiy: "I don't propose to commit this complicated patch, but these results can be used as a guide to the optimization of tuple creating. It is surprising to me that this patch has any effect at all."

A new "fast call" calling convention was added to Python 3.6 to avoid the creation of temporary tuples to pass function arguments. Benchmarks confirm that Python 3.7 is faster than Python 3.5 of functions that Serhiy suggested to optimize. I confirm that I was also surprised that fast call has a significant effect on performance!

Fast calls don't require complex code like reuse_argtuples_3.patch which requires to check carefully the reference counter. In the past, a similar optimization on property_descr_get() introduced complex bugs: see issue #24276 and issue #26811. Fast calls don't use such issues.

The implementation of fast calls is currently incomplete: tp_new, tp_init and tp_call slots still require a tuple and a dict for positional and keyword arguments. I'm working on an enhancement for Python 3.7 to support also fast calls for these slots. In the meanwhile, callbacks using tp_call don't benefit yet on fast calls.

That's why I had to keep the tuple/refcount optimization in property_descr_get(), to not introduce a performance regression.

I consider that this issue can now be closed as "fixed".

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

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

From report at bugs.python.org  Thu Dec  1 11:00:53 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 01 Dec 2016 16:00:53 +0000
Subject: [issue28740] Add sys.getandroidapilevel()
In-Reply-To: <1479504395.69.0.761590307394.issue28740@psf.upfronthosting.co.za>
Message-ID: <1480608053.19.0.289546553688.issue28740@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

> How about renaming sys.implementation._multiarch to sys.implementation.target_architecture and make it public? sys.androidapilevel() sounds too specific to me.

Please do not hijack this issue. The removal of sys.implementation._multiarch for Android is discussed in issue 28849 not here.

----------

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

From report at bugs.python.org  Thu Dec  1 11:02:20 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 01 Dec 2016 16:02:20 +0000
Subject: [issue23507] Tuple creation is too slow
In-Reply-To: <1424765312.55.0.269687406134.issue23507@psf.upfronthosting.co.za>
Message-ID: <1480608140.1.0.161718806269.issue23507@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Victor, your changes introduced a regression.

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

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

From report at bugs.python.org  Thu Dec  1 11:03:23 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Dec 2016 16:03:23 +0000
Subject: [issue28839] _PyFunction_FastCallDict(): replace PyTuple_New() with
 PyMem_Malloc()
In-Reply-To: <1480505567.26.0.13388381207.issue28839@psf.upfronthosting.co.za>
Message-ID: <1480608203.88.0.348152644193.issue28839@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I pushed th echange b9c9691c72c5 to replace PyObject_CallFunctionObjArgs() with _PyObject_CallNoArg() or _PyObject_CallArg1(). These functions are simpler and don't allocate
memory on the C stack.

I made similar to PyObject_CallFunctionObjArgs() in Python 3.6 to this issue: don't create a tuple but a small stack allocated on the C stack or allocate heap memory to pass a C array of PyObject* to _PyObject_FastCall().

Currently, PyObject_CallFunctionObjArgs() uses a small stack for up to 5 positional arguments: it allocates 40 bytes on the C stack.

Serhiy Storchaka: "The problem with C stack overflow is not new, but your patch may make it worse (I don't know if it actually make it worse)."

I consider that 80 bytes is small enough for a C stack. As I wrote, we can reduce this "small stack" in the future if somone reports issues.


"Py_EnterRecursiveCall() is used for limiting Python stack. It can't prevent C stack overflow."

I know that the protection is not perfect. It's an heuristic.

I don't even know if it counts Python builtin functions, or only pure Python functions.


But I'm not sure that I understood your comment: do you suggest to use a tuple and reject this issue? To reduce the size of the small stack? Or to only allocate memory on the heap memory?

If the issue is the memory allocated on the C stack, maybe we can use a free list for "stacks" (C array of PyObject*), as done for tuples? I'm not sure that a free list for PyMem_Malloc()/PyMem_Free() is useful, since it uses our efficient pymalloc.

----------

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

From report at bugs.python.org  Thu Dec  1 11:10:46 2016
From: report at bugs.python.org (Wolfgang Maier)
Date: Thu, 01 Dec 2016 16:10:46 +0000
Subject: [issue18971] calendar
In-Reply-To: <1378651735.34.0.106872134579.issue18971@psf.upfronthosting.co.za>
Message-ID: <1480608646.65.0.608921736407.issue18971@psf.upfronthosting.co.za>


Changes by Wolfgang Maier <wolfgang.maier at biologie.uni-freiburg.de>:


----------
title: Use argparse in the profile/cProfile modules -> calendar

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

From report at bugs.python.org  Thu Dec  1 11:11:57 2016
From: report at bugs.python.org (Wolfgang Maier)
Date: Thu, 01 Dec 2016 16:11:57 +0000
Subject: [issue18971] Use argparse in the profile/cProfile modules
In-Reply-To: <1378651735.34.0.106872134579.issue18971@psf.upfronthosting.co.za>
Message-ID: <1480608717.79.0.451708935198.issue18971@psf.upfronthosting.co.za>


Wolfgang Maier added the comment:

oops, typing in wrong window. Very sorry.

----------
nosy: +wolma
title: calendar -> Use argparse in the profile/cProfile modules

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

From report at bugs.python.org  Thu Dec  1 11:15:35 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 01 Dec 2016 16:15:35 +0000
Subject: [issue28740] Add sys.getandroidapilevel()
In-Reply-To: <1479504395.69.0.761590307394.issue28740@psf.upfronthosting.co.za>
Message-ID: <1480608935.06.0.354426792085.issue28740@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

@Chi Hsuan Yen
And please, let us not waste any more time on lost battles, this suggestion of using sys.implementation has already been rejected at issue 27442 (see msg269748) as you must know since you were involved in the discussion there.

----------

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

From report at bugs.python.org  Thu Dec  1 11:21:27 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Dec 2016 16:21:27 +0000
Subject: [issue28852] sorted(range(1000)) is slower in Python 3.7 compared to
 Python 3.5
Message-ID: <1480609287.7.0.199610846669.issue28852@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Follow-up of my comment http://bugs.python.org/issue23507#msg282187 :

"sorted(list): Median +- std dev: [3.5] 17.5 us +- 1.0 us -> [3.7] 19.7 us +- 1.1 us: 1.12x slower (+12%)"

"(...) sorted(list) is slower. I don't know why sorted(list) is slower. It doesn't use a key function, and so should not be impacted by FASTCALL changes made since Python 3.6."

----------
messages: 282194
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: sorted(range(1000)) is slower in Python 3.7 compared to Python 3.5
type: performance
versions: Python 3.7

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

From report at bugs.python.org  Thu Dec  1 11:23:31 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Dec 2016 16:23:31 +0000
Subject: [issue23507] Tuple creation is too slow
In-Reply-To: <1424765312.55.0.269687406134.issue23507@psf.upfronthosting.co.za>
Message-ID: <1480609411.67.0.0802499238727.issue23507@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Serhiy Storchaka: "Victor, your changes introduced a regression."

I suppose that you are refering to sorted(list) which seems to be slower. Do you have a specific change in mind? As I wrote, it doesn't use a key function, and so should not be impacted by my work on fast calls. I opened a new issue #28852 to track this performance regression.

----------

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

From report at bugs.python.org  Thu Dec  1 11:32:13 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 01 Dec 2016 16:32:13 +0000
Subject: [issue28852] sorted(range(1000)) is slower in Python 3.7 compared to
 Python 3.5
In-Reply-To: <1480609287.7.0.199610846669.issue28852@psf.upfronthosting.co.za>
Message-ID: <1480609933.76.0.994700875579.issue28852@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Benchmark:

   ./python -m perf timeit -s 'x=list(range(1000))' 'sorted(x)'

Python 3.6 and 3.7 compared to Python 3.5:

   $ python3 -m perf compare_to 3.5.json.gz 3.6.json.gz 3.7.json.gz
   Median +- std dev: [3.5] 18.4 us +- 0.9 us -> [3.6] 20.5 us +- 0.9 us: 1.11x slower (+11%)
   Median +- std dev: [3.5] 18.4 us +- 0.9 us -> [3.7] 19.8 us +- 1.1 us: 1.08x slower (+8%)

I compiled Python with "./configure && make". The benchmark should be run again using LTO+PGO compilation to get more reliable benchmark results.

It seems like the benchmark is not very stable even with system tune (python3 -m perf system tune, isolcpus and rcu_nocbs in the Linux command line). I ran the benchmark 3 times using --append to concatenate all runs to get enough samples.

Histograms:

$ python3 -m perf hist 3.5.json.gz 3.6.json.gz 3.7.json.gz 
[ 3.5.json ]
15.0 us:  1 #
15.2 us:  0 |
15.5 us:  3 ###
15.7 us:  4 ####
16.0 us:  7 #######
16.2 us:  5 #####
16.5 us: 16 ################
16.7 us:  4 ####
17.0 us:  8 ########
17.2 us: 10 ##########
17.4 us:  7 #######
17.7 us:  5 #####
17.9 us:  5 #####
18.2 us: 23 ########################
18.4 us: 77 ###############################################################################
18.7 us:  5 #####
18.9 us:  0 |
19.2 us:  0 |
19.4 us:  0 |
19.7 us:  0 |
19.9 us:  0 |
20.1 us:  0 |
20.4 us:  0 |
20.6 us:  0 |
20.9 us:  0 |
21.1 us:  0 |

[ 3.6.json ]
15.0 us:  0 |
15.2 us:  0 |
15.5 us:  0 |
15.7 us:  0 |
16.0 us:  0 |
16.2 us:  0 |
16.5 us:  0 |
16.7 us:  0 |
17.0 us:  0 |
17.2 us:  0 |
17.4 us:  2 ###
17.7 us:  2 ###
17.9 us:  3 #####
18.2 us:  4 #######
18.4 us:  3 #####
18.7 us:  7 ############
18.9 us:  5 ########
19.2 us:  8 #############
19.4 us:  6 ##########
19.7 us:  7 ############
19.9 us:  9 ###############
20.1 us: 24 ########################################
20.4 us: 16 ###########################
20.6 us: 47 ###############################################################################
20.9 us: 27 #############################################
21.1 us: 10 #################

[ 3.7.json ]
15.0 us:  0 |
15.2 us:  0 |
15.5 us:  0 |
15.7 us:  0 |
16.0 us:  0 |
16.2 us:  1 ##
16.5 us:  0 |
16.7 us:  2 ###
17.0 us:  4 ######
17.2 us:  6 #########
17.4 us:  4 ######
17.7 us: 11 #################
17.9 us: 10 ################
18.2 us: 14 ######################
18.4 us: 10 ################
18.7 us:  5 ########
18.9 us:  3 #####
19.2 us: 10 ################
19.4 us:  6 #########
19.7 us: 13 #####################
19.9 us: 50 ###############################################################################
20.1 us: 10 ################
20.4 us: 19 ##############################
20.6 us:  2 ###
20.9 us:  0 |
21.1 us:  0 |

----------
Added file: http://bugs.python.org/file45727/3.5.json.gz

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

From report at bugs.python.org  Thu Dec  1 11:34:42 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 01 Dec 2016 16:34:42 +0000
Subject: [issue28851] namedtuples field_names sequence preferred
In-Reply-To: <1480601135.13.0.00871251418973.issue28851@psf.upfronthosting.co.za>
Message-ID: <1480610082.23.0.498975028945.issue28851@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Thanks for the reminder.  I'll make the doc updates after 3.6 is released (we're trying to not make any changes at all right now).

----------
resolution:  -> later
versions:  -Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu Dec  1 11:38:05 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 01 Dec 2016 16:38:05 +0000
Subject: [issue28843] asyncio.Task implemented in C loses __traceback__ for
 exceptions
In-Reply-To: <1480531493.68.0.0437538826486.issue28843@psf.upfronthosting.co.za>
Message-ID: <20161201163801.101115.65206.DC044CB1@psf.io>


Roundup Robot added the comment:

New changeset c9f68150cf90 by Yury Selivanov in branch '3.6':
Issue #28843: Fix asyncio C Task to handle exceptions __traceback__.
https://hg.python.org/cpython/rev/c9f68150cf90

New changeset a21a8943c59e by Yury Selivanov in branch 'default':
Merge 3.6 (issue #28843)
https://hg.python.org/cpython/rev/a21a8943c59e

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

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

From report at bugs.python.org  Thu Dec  1 11:38:39 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 01 Dec 2016 16:38:39 +0000
Subject: [issue28843] asyncio.Task implemented in C loses __traceback__ for
 exceptions
In-Reply-To: <1480531493.68.0.0437538826486.issue28843@psf.upfronthosting.co.za>
Message-ID: <1480610319.37.0.402203016989.issue28843@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Thanks for reviewing the patch, Inada-san. Closing the issue.

----------
priority: release blocker -> normal
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type:  -> behavior

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

From report at bugs.python.org  Thu Dec  1 11:51:09 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 01 Dec 2016 16:51:09 +0000
Subject: [issue28850] Regression in Python 3: Subclassing PrettyPrinter.format
 doesn't work anymore
In-Reply-To: <1480592723.97.0.369129599105.issue28850@psf.upfronthosting.co.za>
Message-ID: <1480611069.75.0.14991398148.issue28850@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
nosy:  -gvanrossum

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

From report at bugs.python.org  Thu Dec  1 11:54:37 2016
From: report at bugs.python.org (Marco Buttu)
Date: Thu, 01 Dec 2016 16:54:37 +0000
Subject: [issue28853] locals() and free variables
Message-ID: <1480611277.06.0.950152525221.issue28853@psf.upfronthosting.co.za>


New submission from Marco Buttu:

The locals() documentation [1] says that "Free variables are returned by locals() when it is called in function blocks". A free variable inside a function has a global scope, and in fact it is not returned by locals()::

>>> x = 33
>>> def foo():
...     print(x)
...     print(locals())
... 
>>> foo()
33
{}

Maybe "function blocks" here means "closure"? Does the doc mean this?

>>> def foo():
...     x = 33
...     def moo():
...         print(x)
...         print(locals())
...     return moo
... 
>>> moo = foo()
>>> moo()
33
{'x': 33}

In that case, I think it is better to write "closures" instead of 
"function blocks".


[1] https://docs.python.org/3/library/functions.html#locals

----------
assignee: docs at python
components: Documentation
messages: 282200
nosy: docs at python, marco.buttu
priority: normal
severity: normal
status: open
title: locals() and free variables
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Thu Dec  1 12:13:03 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Thu, 01 Dec 2016 17:13:03 +0000
Subject: [issue28740] Add sys.getandroidapilevel()
In-Reply-To: <1479504395.69.0.761590307394.issue28740@psf.upfronthosting.co.za>
Message-ID: <1480612383.19.0.720075243191.issue28740@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

Sorry for mixing different issues and proposing bad alternatives.

My last hope is that someone looks into lemburg's msg281253:

"I don't think the sys module is the right place to put the API, since it doesn't have anything to do with the Python system internals."

----------

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

From report at bugs.python.org  Thu Dec  1 12:50:03 2016
From: report at bugs.python.org (Eric N. Vander Weele)
Date: Thu, 01 Dec 2016 17:50:03 +0000
Subject: [issue28852] sorted(range(1000)) is slower in Python 3.7 compared to
 Python 3.5
In-Reply-To: <1480609287.7.0.199610846669.issue28852@psf.upfronthosting.co.za>
Message-ID: <1480614603.8.0.308414381081.issue28852@psf.upfronthosting.co.za>


Changes by Eric N. Vander Weele <ericvw at gmail.com>:


----------
nosy: +ericvw

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

From report at bugs.python.org  Thu Dec  1 15:22:40 2016
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 01 Dec 2016 20:22:40 +0000
Subject: [issue28854] FIPS mode causes dead-lock in ssl module
Message-ID: <1480623760.67.0.622140819943.issue28854@psf.upfronthosting.co.za>


New submission from Christian Heimes:

Python's ssl module is dead-locking when OpenSSL is running in FIPS mode. I first noticed it with pip. The issue is also reproducible with Python's test suite.

$ sudo touch /etc/system-fips

$ OPENSSL_FORCE_FIPS_MODE=1 ./python -m test.regrtest -v test_ssl
== CPython 2.7.12+ (2.7:adb296e4bcaa, Dec 1 2016, 21:14:20) [GCC 6.2.1 20160916 (Red Hat 6.2.1-2)]
==   Linux-4.8.8-200.fc24.x86_64-x86_64-with-fedora-24-Twenty_Four little-endian
==   /home/heimes/dev/python/2.7/build/test_python_29991
Testing with flags: sys.flags(debug=0, py3k_warning=0, division_warning=0, division_new=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, tabcheck=0, verbose=0, unicode=0, bytes_warning=0, hash_randomization=0)
[1/1] test_ssl
test_ssl: testing with 'OpenSSL 1.0.2j-fips  26 Sep 2016' (1, 0, 2, 10, 15)
          under Linux ('Fedora', '24', 'Twenty Four')
          HAS_SNI = True
          OP_ALL = 0x800003ff
          OP_NO_TLSv1_1 = 0x10000000
test__create_stdlib_context (test.test_ssl.ContextTests) ... ok
test__https_verify_certificates (test.test_ssl.ContextTests) ... ok
test__https_verify_envvar (test.test_ssl.ContextTests) ... ok
test_cert_store_stats (test.test_ssl.ContextTests) ... ok
test_check_hostname (test.test_ssl.ContextTests) ... ok
test_ciphers (test.test_ssl.ContextTests) ... ok
test_constructor (test.test_ssl.ContextTests) ... ERROR
test_create_default_context (test.test_ssl.ContextTests) ... ok
test_get_ca_certs (test.test_ssl.ContextTests) ... ok
test_load_cert_chain (test.test_ssl.ContextTests) ... ERROR
test_load_default_certs (test.test_ssl.ContextTests) ... ok
test_load_default_certs_env (test.test_ssl.ContextTests) ... ok
test_load_default_certs_env_windows (test.test_ssl.ContextTests) ... skipped 'Windows specific'
test_load_dh_params (test.test_ssl.ContextTests) ... ok
test_load_verify_cadata (test.test_ssl.ContextTests) ... ok
test_load_verify_locations (test.test_ssl.ContextTests) ... ok
test_options (test.test_ssl.ContextTests) ... ok
test_protocol (test.test_ssl.ContextTests) ... ERROR
test_session_stats (test.test_ssl.ContextTests) ... ERROR
test_set_default_verify_paths (test.test_ssl.ContextTests) ... ok
test_set_ecdh_curve (test.test_ssl.ContextTests) ... 


(gdb) bt
#0  0x00007f0d9f8470c7 in do_futex_wait.constprop () from /lib64/libpthread.so.0
#1  0x00007f0d9f847174 in __new_sem_wait_slow.constprop.0 () from /lib64/libpthread.so.0
#2  0x00007f0d9f84721a in sem_wait@@GLIBC_2.2.5 () from /lib64/libpthread.so.0
#3  0x000000000051e013 in PyThread_acquire_lock (lock=0x27433a0, waitflag=1) at Python/thread_pthread.h:324
#4  0x00007f0d937b0dce in _ssl_thread_locking_function (mode=5, n=18, file=0x7f0d96e417ac "fips_drbg_rand.c", line=124)
    at /home/heimes/dev/python/2.7/Modules/_ssl.c:4000
#5  0x00007f0d96df1d7e in fips_drbg_status () from /lib64/libcrypto.so.10
#6  0x00007f0d96d75b0e in drbg_rand_add () from /lib64/libcrypto.so.10
#7  0x00007f0d96d76645 in RAND_poll () from /lib64/libcrypto.so.10
#8  0x00007f0d96d75237 in ssleay_rand_bytes () from /lib64/libcrypto.so.10
#9  0x00007f0d96d75c33 in drbg_get_entropy () from /lib64/libcrypto.so.10
#10 0x00007f0d96df10c8 in fips_get_entropy () from /lib64/libcrypto.so.10
#11 0x00007f0d96df1226 in drbg_reseed () from /lib64/libcrypto.so.10
#12 0x00007f0d96d75bb8 in drbg_rand_seed () from /lib64/libcrypto.so.10
#13 0x00007f0d96d5da84 in ECDSA_sign_ex () from /lib64/libcrypto.so.10
#14 0x00007f0d96d5db00 in ECDSA_sign () from /lib64/libcrypto.so.10
#15 0x00007f0d96d3bc10 in pkey_ec_sign () from /lib64/libcrypto.so.10
#16 0x00007f0d96d81359 in EVP_SignFinal () from /lib64/libcrypto.so.10
#17 0x00007f0d96def373 in fips_pkey_signature_test () from /lib64/libcrypto.so.10
#18 0x00007f0d96d38fe0 in EC_KEY_generate_key () from /lib64/libcrypto.so.10
#19 0x00007f0d970d7d7c in ssl3_ctx_ctrl () from /lib64/libssl.so.10
#20 0x00007f0d937af934 in set_ecdh_curve (self=0x7f0d92a23f78, name='prime256v1') at /home/heimes/dev/python/2.7/Modules/_ssl.c:3110
#21 0x00000000004d8acc in call_function (pp_stack=0x7ffcc0334730, oparg=1) at Python/ceval.c:4340
#22 0x00000000004d37a9 in PyEval_EvalFrameEx (
    f=Frame 0x7f0d929bf460, for file /home/heimes/dev/python/2.7/Lib/test/test_ssl.py, line 1023, in test_set_ecdh_curve (self=<ContextTests(_resultForDoCleanups=<TextTestResult(_original_stdout=<file at remote 0x7f0d9fc281c0>, dots=False, skipped=[(<ContextTests(_resultForDoCleanups=<...>, _type_equality_funcs={<type at remote 0x7fae40>: 'assertMultiLineEqual', <type at remote 0x7f4cc0>: 'assertTupleEqual', <type at remote 0x7f0ee0>: 'assertSetEqual', <type at remote 0x7ebf80>: 'assertListEqual', <type at remote 0x7edd80>: 'assertDictEqual', <type at remote 0x7f09e0>: 'assertSetEqual'}, _testMethodDoc=None, _testMethodName='test_load_default_certs_env_windows', _cleanups=[]) at remote 0x7f0d92a80ae0>, 'Windows specific')], _mirrorOutput=False, stream=<_WritelnDecorator(stream=<file at remote 0x7f0d9fc281c0>) at remote 0x7f0d93747450>, testsRun=21, buffer=False, _original_stderr=<file at remote 0x7f0d9fc28280>, showAll=True, _stdout_buffer=None, _stderr_buffer=None, _moduleSetUpFailed=False, expectedFailures=[], er...(truncated), throwflag=0)
    at Python/ceval.c:2989


Python 3's test suite is dead locking in a different test:

#0  0x00007f2be93dc0c7 in do_futex_wait.constprop () from /lib64/libpthread.so.0
#1  0x00007f2be93dc174 in __new_sem_wait_slow.constprop.0 () from /lib64/libpthread.so.0
#2  0x00007f2be93dc21a in sem_wait@@GLIBC_2.2.5 () from /lib64/libpthread.so.0
#3  0x0000000000433e5c in PyThread_acquire_lock_timed (lock=0x17c0b40, microseconds=-1, intr_flag=intr_flag at entry=0)
    at Python/thread_pthread.h:352
#4  0x0000000000433f5e in PyThread_acquire_lock (lock=<optimized out>, waitflag=waitflag at entry=1) at Python/thread_pthread.h:556
#5  0x00007f2be0870945 in _ssl_thread_locking_function (mode=<optimized out>, n=<optimized out>, file=<optimized out>, 
    line=<optimized out>) at /home/heimes/dev/python/cpython/Modules/_ssl.c:5069
#6  0x00007f2be02f4d7e in fips_drbg_status () from /lib64/libcrypto.so.10
#7  0x00007f2be0278b0e in drbg_rand_add () from /lib64/libcrypto.so.10
#8  0x00007f2be0279645 in RAND_poll () from /lib64/libcrypto.so.10
#9  0x00007f2be0278237 in ssleay_rand_bytes () from /lib64/libcrypto.so.10
#10 0x00007f2be0278c33 in drbg_get_entropy () from /lib64/libcrypto.so.10
#11 0x00007f2be02f40c8 in fips_get_entropy () from /lib64/libcrypto.so.10
#12 0x00007f2be02f4226 in drbg_reseed () from /lib64/libcrypto.so.10
#13 0x00007f2be0278b39 in drbg_rand_add () from /lib64/libcrypto.so.10
#14 0x00007f2be0868870 in _ssl_RAND_add_impl (module=module at entry=<module at remote 0x7f2be0aa1a58>, view=view at entry=0x7ffd106c1420, 
    entropy=75) at /home/heimes/dev/python/cpython/Modules/_ssl.c:4499
#15 0x00007f2be08688f2 in _ssl_RAND_add (module=<module at remote 0x7f2be0aa1a58>, args=<optimized out>)
    at /home/heimes/dev/python/cpython/Modules/clinic/_ssl.c.h:861
#16 0x00000000004984d3 in _PyCFunction_FastCallDict (
    func_obj=func_obj at entry=<built-in method RAND_add of module object at remote 0x7f2be0aa1a58>, args=args at entry=0x18d54b8, 
    nargs=nargs at entry=2, kwargs=kwargs at entry=0x0) at Objects/methodobject.c:234
#17 0x000000000049872a in _PyCFunction_FastCallKeywords (
    func=func at entry=<built-in method RAND_add of module object at remote 0x7f2be0aa1a58>, stack=stack at entry=0x18d54b8, 
    nargs=nargs at entry=2, kwnames=kwnames at entry=0x0) at Objects/methodobject.c:295
#18 0x000000000052ad5b in call_function (pp_stack=pp_stack at entry=0x7ffd106c15d8, oparg=oparg at entry=2, kwnames=kwnames at entry=0x0)
    at Python/ceval.c:4735

----------
assignee: christian.heimes
components: SSL
messages: 282202
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: FIPS mode causes dead-lock in ssl module
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Thu Dec  1 15:29:10 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 01 Dec 2016 20:29:10 +0000
Subject: [issue28740] Add sys.getandroidapilevel()
In-Reply-To: <1479504395.69.0.761590307394.issue28740@psf.upfronthosting.co.za>
Message-ID: <1480624150.57.0.32992038774.issue28740@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

> getandroidapilevel-3.patch: Updated version of getandroidapilevel.patch: replace "runtime" with "build time" in the doc :-) Remove also "version > 0" check in support/__init__.py.

LGTM

> About the version > 0 check: would it make sense to add the check in configure.ac? I guess that it was Xavier who wrote the test in support/__init__.py?

The version > 0 check was done because sysconfig.get_config_var() returns 0 when a variable is found as '#undef' in pyconfig.h.  As a reference, the list of the existing API levels with their corresponding Android versions and names:

  Android Version      Released        API Level  Name
  Android 7.1          October 2016    25         Nougat
  Android 7.0          August 2016     24         Nougat
  Android 6.0          August 2015     23         Marshmallow
  Android 5.1          March 2015      22         Lollipop
  Android 5.0          November 2014   21         Lollipop
  Android 4.4W         June 2014       20         Kitkat Watch
  Android 4.4          October 2013    19         Kitkat
  Android 4.3          July 2013       18         Jelly Bean
  Android 4.2-4.2.2    November 2012   17         Jelly Bean
  Android 4.1-4.1.1    June 2012       16         Jelly Bean
  Android 4.0.3-4.0.4  December 2011   15         Ice Cream Sandwich
  Android 4.0-4.0.2    October 2011    14         Ice Cream Sandwich
  Android 3.2          June 2011       13         Honeycomb
  Android 3.1.x        May 2011        12         Honeycomb
  Android 3.0.x        February 2011   11         Honeycomb
  Android 2.3.3-2.3.4  February 2011   10         Gingerbread
  Android 2.3-2.3.2    November 2010   9          Gingerbread
  Android 2.2.x        June 2010       8          Froyo
  Android 2.1.x        January 2010    7          Eclair
  Android 2.0.1        December 2009   6          Eclair
  Android 2.0          November 2009   5          Eclair
  Android 1.6          September 2009  4          Donut
  Android 1.5          May 2009        3          Cupcake
  Android 1.1          February 2009   2          Base
  Android 1.0          October 2008    1          Base

> I suggest to start to add sys.getandroidapilevel(), and then discuss how to expose (or not) the runtime version.

Agreed and thanks for the patch Victor :)

----------
components: +Interpreter Core
stage:  -> patch review

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

From report at bugs.python.org  Thu Dec  1 15:42:50 2016
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 01 Dec 2016 20:42:50 +0000
Subject: [issue28854] FIPS mode causes dead-lock in ssl module
In-Reply-To: <1480623760.67.0.622140819943.issue28854@psf.upfronthosting.co.za>
Message-ID: <1480624970.96.0.635955848042.issue28854@psf.upfronthosting.co.za>


Christian Heimes added the comment:

It's a dead lock in OpenSSL. :(

    if (n == CRYPTO_LOCK_RAND) {
        fprintf(stderr, "%s%s %i %s:%i\n",
                (mode & CRYPTO_READ) ? "R" : "W",
                (mode & CRYPTO_LOCK) ? "L" : "U",
                n, file, line);
    }

test_random (test.test_ssl.BasicSocketTests) ... RLCK 18 fips_drbg_rand.c:124
RUNL 18 fips_drbg_rand.c:126

 RAND_status is 1 (sufficient randomness)
WLCK 18 fips_drbg_rand.c:80
WUNL 18 fips_drbg_rand.c:109
WLCK 18 fips_drbg_rand.c:80
WUNL 18 fips_drbg_rand.c:109
WLCK 18 md_rand.c:230
WUNL 18 md_rand.c:262
WLCK 18 md_rand.c:311
WUNL 18 md_rand.c:324
RLCK 18 fips_drbg_rand.c:124
RUNL 18 fips_drbg_rand.c:126
WLCK 18 rand_lib.c:240
RLCK 18 fips_drbg_rand.c:124

----------

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

From report at bugs.python.org  Thu Dec  1 15:45:44 2016
From: report at bugs.python.org (Alex Gaynor)
Date: Thu, 01 Dec 2016 20:45:44 +0000
Subject: [issue28854] FIPS mode causes dead-lock in ssl module
In-Reply-To: <1480623760.67.0.622140819943.issue28854@psf.upfronthosting.co.za>
Message-ID: <1480625144.47.0.364107924257.issue28854@psf.upfronthosting.co.za>


Changes by Alex Gaynor <alex.gaynor at gmail.com>:


----------
nosy: +alex, dstufft, janssen

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

From report at bugs.python.org  Thu Dec  1 15:53:16 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 01 Dec 2016 20:53:16 +0000
Subject: [issue28840] IDLE not handling long lines correctly
In-Reply-To: <1480514700.66.0.957548851102.issue28840@psf.upfronthosting.co.za>
Message-ID: <1480625596.46.0.708795104896.issue28840@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Currently, the code displayed is the code saved and run when requested.  Your idea would require that IDLE keep a 'true' copy of the code separate from the 'display' copy in the Text widget, with the two being kept in sync except in special situations such as super long lines.  This would be an error prone process.  It would require either having two text widgets, one displayed, one not, kept nearly in sync, or writing a Python equivalent of the non-display part of the text widget.  Or the true copy could be a virtual copy represented by the edits required to restore the true copy from the display copy.  Any of these would be tedious, error prone, and would make editing slower. I rejected the idea of making tabs visible with a special character for the same reason.

I looked at the tk Text doc to see if the line length limitation is mentioned.  It is not that I could find ('2' occurs in the text, but no longer digit string).  It might be Windows-specific.  It is possible that there should be a new issue opened on the tcl/tk tracker, but more info should be collected first, to test on other OSes and directly with tcl/tk.  I have more pressing issues to work on ;-).

While looking, I read the entry on peer text widgets, which allow multiple views of the *same* underlying text data.  A peer can be restricted to a subset of lines but not part of a line or lines.  (There can also be different default fonts and insert cursor positions.)

----------

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

From report at bugs.python.org  Thu Dec  1 16:06:55 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 01 Dec 2016 21:06:55 +0000
Subject: [issue28840] IDLE: Document tk's long line display limitation
In-Reply-To: <1480514700.66.0.957548851102.issue28840@psf.upfronthosting.co.za>
Message-ID: <1480626415.57.0.282427675765.issue28840@psf.upfronthosting.co.za>


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


----------
stage:  -> test needed
title: IDLE not handling long lines correctly -> IDLE: Document tk's long line display limitation
versions: +Python 2.7, Python 3.6, Python 3.7

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

From report at bugs.python.org  Thu Dec  1 16:17:10 2016
From: report at bugs.python.org (Julien Palard)
Date: Thu, 01 Dec 2016 21:17:10 +0000
Subject: [issue26363] __builtins__ propagation is misleading described in exec
 and eval documentation
In-Reply-To: <1455532935.35.0.388834921119.issue26363@psf.upfronthosting.co.za>
Message-ID: <1480627030.03.0.0756236860852.issue26363@psf.upfronthosting.co.za>


Julien Palard added the comment:

So, is there still an inconsistency in the documentation?

----------

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

From report at bugs.python.org  Thu Dec  1 16:52:27 2016
From: report at bugs.python.org (Lisa Roach)
Date: Thu, 01 Dec 2016 21:52:27 +0000
Subject: [issue27779] Sync-up docstrings in C version of the the decimal module
In-Reply-To: <1471375735.77.0.977501297817.issue27779@psf.upfronthosting.co.za>
Message-ID: <1480629147.12.0.37949529545.issue27779@psf.upfronthosting.co.za>


Lisa Roach added the comment:

This (should) be the patch with the python docstrings copied over to the C version.

----------
Added file: http://bugs.python.org/file45728/docstrings.patch

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

From report at bugs.python.org  Thu Dec  1 17:48:23 2016
From: report at bugs.python.org (Xavier Combelle)
Date: Thu, 01 Dec 2016 22:48:23 +0000
Subject: [issue26363] __builtins__ propagation is misleading described in exec
 and eval documentation
In-Reply-To: <1455532935.35.0.388834921119.issue26363@psf.upfronthosting.co.za>
Message-ID: <1480632503.39.0.616485056751.issue26363@psf.upfronthosting.co.za>


Xavier Combelle added the comment:

not an inconsisties but in the eval documentaion nothing specify that the builtins propagate between levels updates

----------

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

From report at bugs.python.org  Thu Dec  1 18:02:21 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 01 Dec 2016 23:02:21 +0000
Subject: [issue2771] Test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1480633341.55.0.415472685736.issue2771@psf.upfronthosting.co.za>


Ezio Melotti added the comment:

Testing that the link to PR 46 works.
Pull Request 46 should also be a link.
PullRequest 46 too.
Generally you should just use PR46.

----------

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

From report at bugs.python.org  Thu Dec  1 19:15:04 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 02 Dec 2016 00:15:04 +0000
Subject: [issue28740] Add sys.getandroidapilevel()
In-Reply-To: <1479504395.69.0.761590307394.issue28740@psf.upfronthosting.co.za>
Message-ID: <20161202001500.25162.58424.5D8A9F03@psf.io>


Roundup Robot added the comment:

New changeset be70d64bbf88 by Victor Stinner in branch 'default':
Add sys.getandroidapilevel()
https://hg.python.org/cpython/rev/be70d64bbf88

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

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

From report at bugs.python.org  Thu Dec  1 19:26:28 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Dec 2016 00:26:28 +0000
Subject: [issue28740] Add sys.getandroidapilevel()
In-Reply-To: <1479504395.69.0.761590307394.issue28740@psf.upfronthosting.co.za>
Message-ID: <1480638388.61.0.722183156346.issue28740@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> The version > 0 check was done because sysconfig.get_config_var() returns 0 when a variable is found as '#undef' in pyconfig.h.

Oh right, I see. In this case, we don't need to have a special case in sys.getandroidapilevel().

I pushed getandroidapilevel-3.patch with a change: I added a small unit test. It checks that level > 0. I hesitated to also check for a maximum, but I'm not sure that it makes sense.

Xavier: can please double test that sys.getandroidapilevel() works on Android? If it's the case, we can move on the issue #28596 :-)

----------

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

From report at bugs.python.org  Thu Dec  1 19:38:43 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Dec 2016 00:38:43 +0000
Subject: [issue28855] Compiler warnings in _PyObject_CallArg1()
Message-ID: <1480639123.61.0.549454845371.issue28855@psf.upfronthosting.co.za>


New submission from STINNER Victor:

_PyObject_CallArg1() is the following macro:
---
#define _PyObject_CallArg1(func, arg) \
    _PyObject_FastCall((func), &(arg), 1)
---

It works well in most cases, but my change 8f258245c391 or change b9c9691c72c5 added compiler warnings, because an argument which is not directly a PyObject* type is passed as "arg".

I tried to cast in the caller: _PyObject_CallArg1(func, (PyObject*)arg), but sadly it doesn't work :-( I get a compiler error.

Another option is to cast after "&" in the macro:
---
 #define _PyObject_CallArg1(func, arg) \
-    _PyObject_FastCall((func), &(arg), 1)
+    _PyObject_FastCall((func), (PyObject **)&(arg), 1)
---

This option may hide real bugs, so I dislike it.

A better option is to stop using ugly C macros and use a modern static inline function: see attached static_inline.patch. This patch casts to PyObject* before calling _PyObject_CallArg1() to fix warnings.

The question is if compilers are able to emit efficient code for static inline functions using "&" on an argument. I wrote the macro to implement the "&" optimization: convert a PyObject* to a stack of arguments: C array of PyObject* objects.

----------
files: static_inline.patch
keywords: patch
messages: 282212
nosy: benjamin.peterson, haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Compiler warnings in _PyObject_CallArg1()
versions: Python 3.7
Added file: http://bugs.python.org/file45729/static_inline.patch

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

From report at bugs.python.org  Thu Dec  1 21:01:35 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Dec 2016 02:01:35 +0000
Subject: [issue28852] sorted(range(1000)) is slower in Python 3.7 compared to
 Python 3.5
In-Reply-To: <1480609287.7.0.199610846669.issue28852@psf.upfronthosting.co.za>
Message-ID: <1480644095.43.0.0716408307774.issue28852@psf.upfronthosting.co.za>


STINNER Victor added the comment:

On my laptop, the revision introducing the performance regression is:
---
changeset:   101858:5a62d682636e
user:        Brett Cannon <brett at python.org>
date:        Fri Jun 10 14:37:21 2016 -0700
files:       Doc/library/os.rst Lib/test/test_os.py Misc/NEWS Modules/posixmodule.c
description:
Issue #27186: Add os.PathLike support to DirEntry

Initial patch thanks to Jelle Zijlstra.
---

This change is unrelated to sorted(list). It looks more like a "random performance" caused by code placement:

* https://haypo.github.io/analysis-python-performance-issue.html
* https://haypo.github.io/journey-to-stable-benchmark-deadcode.html

According to perf record/perf report, the benchmark spends most of its time in PyObject_RichCompareBool() and long_richcompare():

Overhead  Command  Shared Object       Symbol
  41,98%  python   python              [.] PyObject_RichCompareBool
  35,36%  python   python              [.] long_richcompare
   8,52%  python   python              [.] listsort
   6,29%  python   python              [.] listextend
   5,31%  python   python              [.] list_dealloc

So I guess that the exact code placement of these two functions has a "signifiant" impact on performance. "Significant":

* rev b0be24a2f16c (fast): Median +- std dev: 15.0 us +- 0.1 us
* rev 5a62d682636e (slow): Median +- std dev: 16.3 us +- 0.0 us

The revision 5a62d682636e makes sorted(list) 9% slower.

--

Enabling PGO on compilation should help to get a more reliable code placement, and so more stable performances.

I suggest to close this issue as NOTABUG: ./configure --with-pgo should already fix this issue.

----------

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

From report at bugs.python.org  Thu Dec  1 21:02:51 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Dec 2016 02:02:51 +0000
Subject: [issue23507] Tuple creation is too slow
In-Reply-To: <1424765312.55.0.269687406134.issue23507@psf.upfronthosting.co.za>
Message-ID: <1480644171.0.0.828176728531.issue23507@psf.upfronthosting.co.za>


STINNER Victor added the comment:

>  I opened a new issue #28852 to track this performance regression.

So can I close again this issue?

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

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

From report at bugs.python.org  Thu Dec  1 21:30:44 2016
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 02 Dec 2016 02:30:44 +0000
Subject: [issue28856] %b format for bytes does not support objects that follow
 the buffer protocol
Message-ID: <1480645844.32.0.506545914898.issue28856@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky:

Python 3.7.0a0 (default:be70d64bbf88, Dec  1 2016, 21:21:25)
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.42.1)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from array import array
>>> a = array('B', [1, 2])
>>> b'%b' % a
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: %b requires bytes, or an object that implements __bytes__, not 'array.array'
>>> m = memoryview(a)
>>> b'%b' % m
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: %b requires bytes, or an object that implements __bytes__, not 'memoryview'

Accorfing to documentation [1] objects that follow the buffer protocol should be supported.  Both array.array and memoryview follow the buffer protocol.

[1]: https://docs.python.org/3/library/stdtypes.html#printf-style-bytes-formatting


See also issue 20284 and PEP 461.

----------
messages: 282215
nosy: belopolsky
priority: normal
severity: normal
stage: test needed
status: open
title: %b format for bytes does not support objects that follow the buffer protocol
type: behavior

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

From report at bugs.python.org  Thu Dec  1 21:54:26 2016
From: report at bugs.python.org (Aaron Hill)
Date: Fri, 02 Dec 2016 02:54:26 +0000
Subject: [issue23224] LZMADecompressor object is only initialized in __init__
In-Reply-To: <1421024308.33.0.868171678499.issue23224@psf.upfronthosting.co.za>
Message-ID: <1480647266.8.0.564223514806.issue23224@psf.upfronthosting.co.za>


Aaron Hill added the comment:

I've upload a patch which should address the issue in both the lzma and bz2 modules.

----------
keywords: +patch
nosy: +Aaron1011
Added file: http://bugs.python.org/file45730/fix-lzma-bz2-segfaults.patch

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

From report at bugs.python.org  Fri Dec  2 00:32:37 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 02 Dec 2016 05:32:37 +0000
Subject: [issue23507] Tuple creation is too slow
In-Reply-To: <1424765312.55.0.269687406134.issue23507@psf.upfronthosting.co.za>
Message-ID: <1480656757.59.0.984306137725.issue23507@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

No, I'm referring to the crashing. The code that worked before your changes now are crashing. Please revert your changes and find a way to optimize a function calling without increasing stack consumption.

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

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

From report at bugs.python.org  Fri Dec  2 00:41:51 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 02 Dec 2016 05:41:51 +0000
Subject: [issue28847] dumbdbm should not commit if in read mode
In-Reply-To: <1480564427.92.0.600594500998.issue28847@psf.upfronthosting.co.za>
Message-ID: <1480657311.0.0.277056093531.issue28847@psf.upfronthosting.co.za>


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


----------
assignee:  -> serhiy.storchaka
versions: +Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri Dec  2 00:59:08 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 02 Dec 2016 05:59:08 +0000
Subject: [issue28847] dumbdbm should not commit if in read mode
In-Reply-To: <1480564427.92.0.600594500998.issue28847@psf.upfronthosting.co.za>
Message-ID: <20161202055905.28040.67132.255BD627@psf.io>


Roundup Robot added the comment:

New changeset 0516f54491cb by Serhiy Storchaka in branch '2.7':
Issue #28847: dubmdbm no longer writes the index file in when it is not
https://hg.python.org/cpython/rev/0516f54491cb

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

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

From report at bugs.python.org  Fri Dec  2 01:00:47 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 02 Dec 2016 06:00:47 +0000
Subject: [issue28847] dumbdbm should not commit if in read mode
In-Reply-To: <1480564427.92.0.600594500998.issue28847@psf.upfronthosting.co.za>
Message-ID: <1480658447.97.0.280634703389.issue28847@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The first part is committed in 2.7. I'll commit it in 3.5-3.7 after releasing 3.6.0.

----------
versions:  -Python 2.7

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

From report at bugs.python.org  Fri Dec  2 01:01:42 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 02 Dec 2016 06:01:42 +0000
Subject: [issue28855] Compiler warnings in _PyObject_CallArg1()
In-Reply-To: <1480639123.61.0.549454845371.issue28855@psf.upfronthosting.co.za>
Message-ID: <20161202060138.93520.11906.196C45F2@psf.io>


Roundup Robot added the comment:

New changeset 96245d4af0ca by Benjamin Peterson in branch 'default':
fix _PyObject_CallArg1 compiler warnings (closes #28855)
https://hg.python.org/cpython/rev/96245d4af0ca

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

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

From report at bugs.python.org  Fri Dec  2 01:03:08 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 02 Dec 2016 06:03:08 +0000
Subject: [issue26861] shutil.copyfile() doesn't close the opened files
In-Reply-To: <1461678435.64.0.223785102956.issue26861@psf.upfronthosting.co.za>
Message-ID: <1480658588.79.0.648463342455.issue26861@psf.upfronthosting.co.za>


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


----------
status: open -> pending

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

From report at bugs.python.org  Fri Dec  2 01:08:34 2016
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 02 Dec 2016 06:08:34 +0000
Subject: [issue28855] Compiler warnings in _PyObject_CallArg1()
In-Reply-To: <1480639123.61.0.549454845371.issue28855@psf.upfronthosting.co.za>
Message-ID: <1480658914.18.0.38254093858.issue28855@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

It doesn't seem like the question is whether to use inline functions but whether to force all callers to cast. Your original code would work if you added all the casts in your static_inline.patch patch.

----------

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

From report at bugs.python.org  Fri Dec  2 01:24:14 2016
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 02 Dec 2016 06:24:14 +0000
Subject: [issue28855] Compiler warnings in _PyObject_CallArg1()
In-Reply-To: <1480639123.61.0.549454845371.issue28855@psf.upfronthosting.co.za>
Message-ID: <1480659854.96.0.987131801214.issue28855@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

(Sorry, I noticed and landed a fix before completely reading the issue.)

----------

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

From report at bugs.python.org  Fri Dec  2 01:42:52 2016
From: report at bugs.python.org (Nagarjuna Arigapudi)
Date: Fri, 02 Dec 2016 06:42:52 +0000
Subject: [issue28857] SyncManager and Main Process fail to communicate after
 reboot or stoping with Ctrl - C
Message-ID: <1480660972.34.0.757124295552.issue28857@psf.upfronthosting.co.za>


New submission from Nagarjuna Arigapudi:

"SyncManager" and "Main Process" and main process look at different directories and fail to communicate, causing shutdown of all process, immediately after start of program. This behavior is seen in both 2.7 and 3.5. The logging of 2.7 is more clear, It tells the file  name it is looking for.

Extract of Program:

manager = Manager()
lst1 = manager.list([[]]*V1)  
lst2 = manager.list(range(v2)) 
lst3 = manager.list([0]*V3)         
lst4 = manager.list([0]*V3) 
lst5 = manager.list([0]*V3)  
initializeData(lst1,lst2,lst3,lst4,lst5)
procs = []
for indx in range(noOfProcs):
    procs.append(Process(target=workerProc, args=(lst1,lst2,lst3,lst4,lst5)))
    procs[indx].start()

bContinueWorking = True
while (bContinueWorking):
    logger.debug("Main thread about to sleep")   
    time.sleep(300)
    globLOCK.acquire()
    if(not lst1):
        bContinueWorking = False
    try:
        doPickle(lst1)
    except Exception, ep:
        logger.error("failed to pickle" +str(ep))
    finally:
        globLOCK.release()

________________________________________________________
The program works well. but if the program is terminated, it will not start back. rebooting or cleaning temporary files does not fix the issue.

below is log when it fails. ( beneath the log is other log where it runs successfully)

FAIL LOG
[DEBUG/MainProcess] Star of Application
[DEBUG/MainProcess] created semlock with handle 139965318860800
[DEBUG/MainProcess] created semlock with handle 139965318856704
[DEBUG/MainProcess] created semlock with handle 139965318852608
[DEBUG/MainProcess] created semlock with handle 139965318848512
[DEBUG/MainProcess] created semlock with handle 139965318844416
[DEBUG/MainProcess] created semlock with handle 139965318840320
[INFO/SyncManager-1] child process calling self.run()

***[INFO/SyncManager-1] created temp directory /tmp/pymp-xTqdkd***

[DEBUG/MainProcess] requesting creation of a shared 'list' object
[INFO/SyncManager-1] manager serving at '/tmp/pymp-xTqdkd/listener-eDG1yJ'
[DEBUG/SyncManager-1] 'list' callable returned object with id '7f4c34316f80'
[DEBUG/MainProcess] INCREF '7f4c34316f80'
[DEBUG/MainProcess] requesting creation of a shared 'list' object
[DEBUG/SyncManager-1] 'list' callable returned object with id '7f4c3432a758'
[DEBUG/MainProcess] INCREF '7f4c3432a758'
[DEBUG/MainProcess] requesting creation of a shared 'list' object
[DEBUG/SyncManager-1] 'list' callable returned object with id '7f4c3432a7a0'
[DEBUG/MainProcess] INCREF '7f4c3432a7a0'
[DEBUG/MainProcess] requesting creation of a shared 'list' object
[DEBUG/SyncManager-1] 'list' callable returned object with id '7f4c3432a7e8'
[DEBUG/MainProcess] INCREF '7f4c3432a7e8'
[DEBUG/MainProcess] requesting creation of a shared 'list' object
[DEBUG/SyncManager-1] 'list' callable returned object with id '7f4c3432a830'
[DEBUG/MainProcess] INCREF '7f4c3432a830'
[DEBUG/MainProcess] thread 'MainThread' does not own a connection
[DEBUG/MainProcess] making connection to manager
[DEBUG/SyncManager-1] starting server thread to service 'MainProcess'

***[DEBUG/MainProcess] failed to connect to address /tmp/pymp-LOMHoT/listener-EbLeup***

[Errno 2] No such file or directory
Initialization failed Exiting
[INFO/MainProcess] process shutting down


SUCCESS LOG

[DEBUG/MainProcess] Star of Application
[DEBUG/MainProcess] created semlock with handle 139830888992768
[DEBUG/MainProcess] created semlock with handle 139830888988672
[DEBUG/MainProcess] created semlock with handle 139830888984576
[DEBUG/MainProcess] created semlock with handle 139830888980480
[DEBUG/MainProcess] created semlock with handle 139830888976384
[DEBUG/MainProcess] created semlock with handle 139830888972288
[INFO/SyncManager-1] child process calling self.run()
[INFO/SyncManager-1] created temp directory /tmp/pymp-UiHuij
[DEBUG/MainProcess] requesting creation of a shared 'list' object
[INFO/SyncManager-1] manager serving at '/tmp/pymp-UiHuij/listener-lS7hf5'
[DEBUG/SyncManager-1] 'list' callable returned object with id '7f2ce78c6f80'
[DEBUG/MainProcess] INCREF '7f2ce78c6f80'
[DEBUG/MainProcess] requesting creation of a shared 'list' object
[DEBUG/SyncManager-1] 'list' callable returned object with id '7f2ce78da758'
[DEBUG/MainProcess] INCREF '7f2ce78da758'
[DEBUG/MainProcess] requesting creation of a shared 'list' object
[DEBUG/SyncManager-1] 'list' callable returned object with id '7f2ce78da7a0'
[DEBUG/MainProcess] INCREF '7f2ce78da7a0'
[DEBUG/MainProcess] requesting creation of a shared 'list' object
[DEBUG/SyncManager-1] 'list' callable returned object with id '7f2ce78da7e8'
[DEBUG/MainProcess] INCREF '7f2ce78da7e8'
[DEBUG/MainProcess] requesting creation of a shared 'list' object
[DEBUG/SyncManager-1] 'list' callable returned object with id '7f2ce78da830'
[DEBUG/MainProcess] INCREF '7f2ce78da830'
[DEBUG/MainProcess] thread 'MainThread' does not own a connection
[DEBUG/MainProcess] making connection to manager
[DEBUG/SyncManager-1] starting server thread to service 'MainProcess'
[DEBUG/MainProcess] Main thread about to sleep
[DEBUG/Process-7] INCREF '7f2ce78c6f80'
[DEBUG/Process-6] INCREF '7f2ce78c6f80'
[DEBUG/Process-5] INCREF '7f2ce78c6f80'
[DEBUG/Process-4] INCREF '7f2ce78c6f80'
[DEBUG/Process-3] INCREF '7f2ce78c6f80'
[DEBUG/Process-2] INCREF '7f2ce78c6f80'
[DEBUG/Process-6] INCREF '7f2ce78da758'
[DEBUG/Process-7] INCREF '7f2ce78da758'
[DEBUG/Process-5] INCREF '7f2ce78da758'
[DEBUG/Process-4] INCREF '7f2ce78da758'
[DEBUG/Process-3] INCREF '7f2ce78da758'
[DEBUG/Process-2] INCREF '7f2ce78da758'
[DEBUG/Process-6] INCREF '7f2ce78da7a0'
[DEBUG/Process-7] INCREF '7f2ce78da7a0'
[DEBUG/Process-5] INCREF '7f2ce78da7a0'
[DEBUG/Process-4] INCREF '7f2ce78da7a0'
[DEBUG/Process-3] INCREF '7f2ce78da7a0'
[DEBUG/Process-2] INCREF '7f2ce78da7a0'
[DEBUG/Process-6] INCREF '7f2ce78da7e8'
[DEBUG/Process-7] INCREF '7f2ce78da7e8'
[DEBUG/Process-5] INCREF '7f2ce78da7e8'
[DEBUG/Process-4] INCREF '7f2ce78da7e8'
[DEBUG/Process-3] INCREF '7f2ce78da7e8'
[DEBUG/Process-2] INCREF '7f2ce78da7e8'
[DEBUG/Process-6] INCREF '7f2ce78da830'
[INFO/Process-6] child process calling self.run()
[DEBUG/Process-6] thread 'MainThread' does not own a connection
[DEBUG/Process-6] making connection to manager
[DEBUG/Process-7] INCREF '7f2ce78da830'
[INFO/Process-7] child process calling self.run()

----------
components: Extension Modules, Interpreter Core
messages: 282223
nosy: Nagarjuna Arigapudi
priority: normal
severity: normal
status: open
title: SyncManager and Main Process fail to communicate after reboot or stoping with Ctrl - C
type: crash
versions: Python 2.7, Python 3.5

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

From report at bugs.python.org  Fri Dec  2 01:43:06 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 02 Dec 2016 06:43:06 +0000
Subject: [issue5322] Python 2.6 object.__new__ argument calling autodetection
 faulty
In-Reply-To: <1235075665.37.0.301694124748.issue5322@psf.upfronthosting.co.za>
Message-ID: <20161202064303.93520.32475.F1B40909@psf.io>


Roundup Robot added the comment:

New changeset a37cc3d926ec by Serhiy Storchaka in branch '2.7':
Issue #5322: Fixed setting __new__ to a PyCFunction inside Python code.
https://hg.python.org/cpython/rev/a37cc3d926ec

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

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

From report at bugs.python.org  Fri Dec  2 01:44:36 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 02 Dec 2016 06:44:36 +0000
Subject: [issue5322] Python 2.6 object.__new__ argument calling autodetection
 faulty
In-Reply-To: <1235075665.37.0.301694124748.issue5322@psf.upfronthosting.co.za>
Message-ID: <1480661076.14.0.875680273851.issue5322@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Will commit to 3.5-3.7 after releasing 3.6.0.

----------
versions:  -Python 2.7

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

From report at bugs.python.org  Fri Dec  2 02:04:08 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 02 Dec 2016 07:04:08 +0000
Subject: [issue28856] %b format for bytes does not support objects that follow
 the buffer protocol
In-Reply-To: <1480645844.32.0.506545914898.issue28856@psf.upfronthosting.co.za>
Message-ID: <1480662248.22.0.527185984301.issue28856@psf.upfronthosting.co.za>


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


----------
nosy: +ethan.furman, serhiy.storchaka

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

From report at bugs.python.org  Fri Dec  2 02:41:41 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 02 Dec 2016 07:41:41 +0000
Subject: [issue28740] Add sys.getandroidapilevel()
In-Reply-To: <1479504395.69.0.761590307394.issue28740@psf.upfronthosting.co.za>
Message-ID: <1480664501.74.0.243667085398.issue28740@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Here is the output of getandroidapilevel(), a verbose run of test_sys and a run of the test suite on the Android x86 emulator API 21. All the results are as expected, the failed tests are the usual ones, BTW all of the failed tests have either a patch ready to be commited as soon as the 3.6.1 branch is created, or have a patch ready, pending a review.

root at generic_x86:/data/data/org.bitbucket.pyona # python
Python 3.7.0a0 (default:96245d4af0ca+, Dec  2 2016, 07:59:12)
[GCC 4.2.1 Compatible Android Clang 3.8.256229 ] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.getandroidapilevel()
21
>>>

=======================================
root at generic_x86:/data/data/org.bitbucket.pyona # python -m test -v test_sys
...
test_getandroidapilevel (test.test_sys.SysModuleTest) ... ok
...
Ran 45 tests in 2.567s

OK (skipped=3)
1 test OK.

Total duration: 3 sec
Tests result: SUCCESS

=======================================
root at generic_x86:/data/data/org.bitbucket.pyona # python -m test
...
358 tests OK.

8 tests failed:
    test_asyncio test_cmd_line test_pathlib test_pwd test_site
    test_socket test_tarfile test_warnings

38 tests skipped:
    test_asdl_parser test_concurrent_futures test_crypt test_curses
    test_dbm_gnu test_dbm_ndbm test_devpoll test_gdb test_grp
    test_idle test_kqueue test_lzma test_msilib
    test_multiprocessing_fork test_multiprocessing_forkserver
    test_multiprocessing_main_handling test_multiprocessing_spawn
    test_nis test_ossaudiodev test_smtpnet test_socketserver test_spwd
    test_startfile test_tcl test_timeout test_tix test_tk
    test_ttk_guionly test_ttk_textonly test_turtle test_urllib2net
    test_urllibnet test_wait3 test_winconsoleio test_winreg
    test_winsound test_xmlrpc_net test_zipfile64

Total duration: 20 min 31 sec
Tests result: FAILURE

----------

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

From report at bugs.python.org  Fri Dec  2 02:46:03 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Dec 2016 07:46:03 +0000
Subject: [issue28740] Add sys.getandroidapilevel()
In-Reply-To: <1479504395.69.0.761590307394.issue28740@psf.upfronthosting.co.za>
Message-ID: <1480664763.17.0.474486214047.issue28740@psf.upfronthosting.co.za>


STINNER Victor added the comment:

@Xavier: Cool, thanks for checking :-) I don't have access to an Android platform yet.

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

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

From report at bugs.python.org  Fri Dec  2 02:54:27 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Dec 2016 07:54:27 +0000
Subject: [issue28858] Fastcall uses more C stack
Message-ID: <1480665267.65.0.416366810047.issue28858@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Serhiy Storchaka reported that Python 3.6 crashs earlier than Python 3.5 on calling json.dumps() when sys.setrecursionlimit() is increased.

I tested the script he wrote. Results on Python built in release mode:

Python 3.7:

...
58100 116204
Segmentation fault (core dumped)

Python 3.6:

...
74800 149604
Segmentation fault (core dumped)

Python 3.5:

...
74700 149404
Segmentation fault (core dumped)

Oh, it seems like Python 3.7 does crash earlier.

But to be clear, it's hard to control the usage of the C stack.

----------
files: stack_overflow.py
messages: 282228
nosy: haypo
priority: normal
severity: normal
status: open
title: Fastcall uses more C stack
versions: Python 3.7
Added file: http://bugs.python.org/file45731/stack_overflow.py

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

From report at bugs.python.org  Fri Dec  2 02:54:42 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Dec 2016 07:54:42 +0000
Subject: [issue23507] Tuple creation is too slow
In-Reply-To: <1424765312.55.0.269687406134.issue23507@psf.upfronthosting.co.za>
Message-ID: <1480665282.45.0.665499162814.issue23507@psf.upfronthosting.co.za>


STINNER Victor added the comment:

haypo: "status: open -> closed"

Oops, it's a mistake, sorry. I only wanted to ask the question, not to close the issue.

Serhiy Storchaka: "No, I'm referring to the crashing. The code that worked before your changes now are crashing."

Sorry, I didn't notice that you attached a script! I opened the issue #28858.

----------

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

From report at bugs.python.org  Fri Dec  2 02:59:18 2016
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 02 Dec 2016 07:59:18 +0000
Subject: [issue28855] Compiler warnings in _PyObject_CallArg1()
In-Reply-To: <1480639123.61.0.549454845371.issue28855@psf.upfronthosting.co.za>
Message-ID: <1480665558.73.0.167690355574.issue28855@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

I also think forcing callers to cast is fine. Most of our APIs require PyObject *.

----------

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

From report at bugs.python.org  Fri Dec  2 03:40:08 2016
From: report at bugs.python.org (Mark Harris)
Date: Fri, 02 Dec 2016 08:40:08 +0000
Subject: [issue28781] On Installation of 3.5 Python get error message
In-Reply-To: <1479918351.94.0.34425443448.issue28781@psf.upfronthosting.co.za>
Message-ID: <1480668008.4.0.828751709407.issue28781@psf.upfronthosting.co.za>


Mark Harris added the comment:

Hi All,

Just wanted to check if there is any progress on the below? I understand it's a bit of a mess, however I use python in my day job(this is on my work pc) so any help getting it sorted would be great.

Thanks again,

Mark

----------

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

From report at bugs.python.org  Fri Dec  2 04:10:05 2016
From: report at bugs.python.org (Vukasin Felbab)
Date: Fri, 02 Dec 2016 09:10:05 +0000
Subject: [issue26861] shutil.copyfile() doesn't close the opened files
In-Reply-To: <1461678435.64.0.223785102956.issue26861@psf.upfronthosting.co.za>
Message-ID: <1480669805.17.0.13386613258.issue26861@psf.upfronthosting.co.za>


Vukasin Felbab added the comment:

Okay, so the problem is that I have a command library instance which is containing a connection to a server and functions can be called to execute some queries. As I pass this instance as a parameter in a recursive chain, after a while the open files limit is reached, I got it a few times an error on file opening. It is sure that I don't leave connections and open files before calling the next recursion, only thing this command library has the connection open. Additionally, when I store the instance in a global variable and call it from there then there are no IO errors. So, it means that the python is not giving parameters by reference, but by value? Because according to the Python, if I pass a mutable object as an argument, an if I use that for querying and passing the same instance to the next recursion level it should work fine, because in this case it should pass by reference, but it is not obviously, it passes by value, the connections remain open and the io limit is reached.

----------
status: pending -> open

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

From report at bugs.python.org  Fri Dec  2 04:39:57 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 02 Dec 2016 09:39:57 +0000
Subject: [issue28850] Regression in Python 3: Subclassing PrettyPrinter.format
 doesn't work anymore
In-Reply-To: <1480592723.97.0.369129599105.issue28850@psf.upfronthosting.co.za>
Message-ID: <1480671597.75.0.273270578219.issue28850@psf.upfronthosting.co.za>


Changes by Xiang Zhang <angwerzx at 126.com>:


----------
nosy: +xiang.zhang
stage:  -> needs patch
versions: +Python 3.7 -Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Dec  2 05:23:55 2016
From: report at bugs.python.org (Michael Felt)
Date: Fri, 02 Dec 2016 10:23:55 +0000
Subject: [issue27435] ctypes library loading and AIX - also for 2.7.X (and
 later)
In-Reply-To: <1467383699.63.0.495142233463.issue27435@psf.upfronthosting.co.za>
Message-ID: <1480674235.4.0.795737784902.issue27435@psf.upfronthosting.co.za>


Michael Felt added the comment:

Considering that python-2.7.13 is posed for a release - I ask again, considering that python-2.7.12 (and I expect a few earlier ones) can load "AIX" .a type shared libraries - if you know how to supply the name - 

that my patch be included in python-2.7.13.

michael at x071:[/data/prj/python]-2.7.12.0/Lib/ctypes/util.py                    <
--- python-2.7.12/Lib/ctypes/util.py    2016-06-25 21:49:30 +0000
+++ python-2.7.12.0/Lib/ctypes/util.py  2016-12-02 10:12:01 +0000
@@ -262,6 +262,10 @@
             print cdll.LoadLibrary("libcrypto.dylib")
             print cdll.LoadLibrary("libSystem.dylib")
             print cdll.LoadLibrary("System.framework/System")
+        if sys.platform == "aix5":
+            from ctypes import CDLL
+            RTLD_MEMBER =  0x00040000
+            print CDLL("libc.a(shr_64.o)", RTLD_MEMBER)
         else:
             print cdll.LoadLibrary("libm.so")
             print cdll.LoadLibrary("libcrypt.so")

And the result is:

root at x064:[/data/prj/python/python-2.7.12.0/Lib/ctypes]../../python util.py
None
None
None
<CDLL 'libc.a(shr_64.o)', handle e at 70000000013ae10>

In, other words, as is, find_library() will always return None for standard libraries (will only return a value if "root" has extracted and renamed a shared library member as a file) - while, if you know the magic that find_library cannot return - you can load such a library.

IMVHO (in my Very humble opinion) - a bug that has been too long unnoticed - but can be repaired.

There is no additional ability being added - it is already there. Just making it more accessible and legible for python programmers on AIX.

If the patch-code needs more cleanup, improvement, etc. - fine. But do not lock out an easy interface to such a basic function.

regards,
Michael

----------

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

From report at bugs.python.org  Fri Dec  2 05:35:13 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 02 Dec 2016 10:35:13 +0000
Subject: [issue27172] Undeprecate inspect.getfullargspec()
In-Reply-To: <1464767888.9.0.788649321892.issue27172@psf.upfronthosting.co.za>
Message-ID: <20161202103510.30584.51408.984A4589@psf.io>


Roundup Robot added the comment:

New changeset 14c2d93ffcb3 by Nick Coghlan in branch '3.6':
Issue #27172: Undeprecate inspect.getfullargspec()
https://hg.python.org/cpython/rev/14c2d93ffcb3

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

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

From report at bugs.python.org  Fri Dec  2 05:38:10 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 02 Dec 2016 10:38:10 +0000
Subject: [issue27172] Undeprecate inspect.getfullargspec()
In-Reply-To: <1464767888.9.0.788649321892.issue27172@psf.upfronthosting.co.za>
Message-ID: <1480675090.3.0.352927661416.issue27172@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I've pushed the change for 3.6.0rc1 based on Yury and Martin's review, but wasn't able to forward merge it to default due to merge conflicts on Misc/NEWS that I wasn't sure how to resolve.

----------
priority: release blocker -> deferred blocker
stage: needs patch -> commit review
versions:  -Python 3.6

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

From report at bugs.python.org  Fri Dec  2 06:20:51 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 02 Dec 2016 11:20:51 +0000
Subject: [issue28856] %b format for bytes does not support objects that follow
 the buffer protocol
In-Reply-To: <1480645844.32.0.506545914898.issue28856@psf.upfronthosting.co.za>
Message-ID: <1480677651.38.0.324897112273.issue28856@psf.upfronthosting.co.za>


Changes by Xiang Zhang <angwerzx at 126.com>:


----------
nosy: +xiang.zhang

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

From report at bugs.python.org  Fri Dec  2 06:32:02 2016
From: report at bugs.python.org (Marco Buttu)
Date: Fri, 02 Dec 2016 11:32:02 +0000
Subject: [issue28853] locals() and free variables
In-Reply-To: <1480611277.06.0.950152525221.issue28853@psf.upfronthosting.co.za>
Message-ID: <1480678322.22.0.562226953352.issue28853@psf.upfronthosting.co.za>


Marco Buttu added the comment:

In addition, also if here "function blocks" means nested function, the sentence "Free variables are returned by locals() when it is called in function blocks" I think is wrong. It is true only in case of free variables belonging to the local enclosing scope. For instance, in the following case ``x`` is free in ``moo()``, but it is not in ``locals()``::

>>> x = 10
>>> def foo():
...     def moo():
...         print(x)
...         print(locals())
...     return moo
... 
>>> moo = foo()
>>> moo()
10
{}

I attach a patch with a new description and an example.

PS. Is the rst rendered by Sphinx? In that case, why we are not using the doctest Sphinx extension to test the code examples?

----------
keywords: +patch
Added file: http://bugs.python.org/file45732/locals_func.patch

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

From report at bugs.python.org  Fri Dec  2 06:35:37 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Dec 2016 11:35:37 +0000
Subject: [issue28855] Compiler warnings in _PyObject_CallArg1()
In-Reply-To: <1480665558.73.0.167690355574.issue28855@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwauhi9iGRPvqU2jsPXJxf5nn_B1w0O=44=1W=Teo+wisQ@mail.gmail.com>


STINNER Victor added the comment:

No problem, thanks for the fix Benjamin!

----------

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

From report at bugs.python.org  Fri Dec  2 08:52:24 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Fri, 02 Dec 2016 13:52:24 +0000
Subject: [issue26861] shutil.copyfile() doesn't close the opened files
In-Reply-To: <1461678435.64.0.223785102956.issue26861@psf.upfronthosting.co.za>
Message-ID: <1480686744.17.0.0085587641715.issue26861@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

You're going to need to provide a real repro; your description is effectively useless. For the record, Python is not precisely pass by reference (it's roughly equivalent to passing a pointer in C, binding the local name to the same pointer, so if you reassign the local name, you lose the reference, but otherwise it behaves like pass-by-reference).

Are you sure the command library doesn't open new connections as needed? In a recursive call scenario, if it goes deep enough, even if it clean up with the recursive call eventually returns, you could still hit the open files limit.

The problem is not copyfile, even if you happen to see copyfile in the traceback. You've got too many open files, and copyfile is the straw that broke the camel's back, but unless you're running 1000 threads doing copyfile simultaneously, it's not responsible for the excess open file handles.

But this is all speculation; the only thing I'm confident of is that copyfile isn't ultimately responsible. We have no idea what's wrong, so you need to provide some sort of minimal repro that exhibits the problem.

----------

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

From report at bugs.python.org  Fri Dec  2 09:21:40 2016
From: report at bugs.python.org (Julien Palard)
Date: Fri, 02 Dec 2016 14:21:40 +0000
Subject: [issue28853] locals() and free variables
In-Reply-To: <1480611277.06.0.950152525221.issue28853@psf.upfronthosting.co.za>
Message-ID: <1480688500.79.0.818214035028.issue28853@psf.upfronthosting.co.za>


Julien Palard added the comment:

Hi, thanks for reporting,

Variables are defined in python docs? by:

> If a name is bound in a block, it is a local variable of that block, unless declared as nonlocal or global. If a name is bound at the module level, it is a global variable. (The variables of the module code block are local and global.) If a variable is used in a code block but not defined there, it is a free variable.

According to this definition, global variables used in a code block are free variable, is this intentional? I think so, but can't be sure, maybe someone is seeing this as "globals are NOT free variables", in this case, this definition should probably be enhanced.

If I'm right, maybe we should just change "Free variables are returned"? to "Non-global free variables are returned"??

----------
nosy: +mdk

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

From report at bugs.python.org  Fri Dec  2 09:34:52 2016
From: report at bugs.python.org (Tim Graham)
Date: Fri, 02 Dec 2016 14:34:52 +0000
Subject: [issue23722] During metaclass.__init__,
 super() of the constructed class does not work
In-Reply-To: <1426859061.43.0.510286082444.issue23722@psf.upfronthosting.co.za>
Message-ID: <1480689292.18.0.351167592748.issue23722@psf.upfronthosting.co.za>


Tim Graham added the comment:

Hi, this causes a regression in Django and I'm not sure if Django or cpython is at fault. For a simple model that uses super() rather than super(Model self) in save():

from django.db import models

class Model(models.Model):
    def save(self, *args, **kwargs):
        super().save(*args, **kwargs)

>>> Model().save()
Traceback (most recent call last):
  File "/home/tim/code/mysite/model/tests.py", line 8, in test
    Model().save()
  File "/home/tim/code/mysite/model/models.py", line 5, in save
    super().save(*args, **kwargs)
RuntimeError: super(): empty __class__ cell


django.db.models.Model does some things with metaclasses which is likely related to the root cause:
https://github.com/django/django/blob/6d1394182d8c4c02598e0cf47f42a5e86706411f/django/db/models/base.py

If someone could provide guidance about what the issue might be, I'm happy to provide more details or to debug this further.

Thank you!

----------
nosy: +Tim.Graham

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

From report at bugs.python.org  Fri Dec  2 09:39:20 2016
From: report at bugs.python.org (Christoph Reiter)
Date: Fri, 02 Dec 2016 14:39:20 +0000
Subject: [issue28859] os.path.mount sometimes raises FileNotFoundError on
 Windows
Message-ID: <1480689560.28.0.129916928722.issue28859@psf.upfronthosting.co.za>


New submission from Christoph Reiter:

It returns True for drives which don't exist and raises for paths starting with drives which don't exist.

>>> os.path.exists("C:\\")
True
>>> os.path.ismount("C:\\")
True
>>> os.path.ismount("C:\\doesnotexist")
False
>>> os.path.exists("F:\\")
False
>>> os.path.ismount("F:\\")
True
>>> os.path.ismount("F:\\doesnotexist")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Users\lazka\AppData\Local\Programs\Python\Python35\lib\ntpath.py", line 290, in ismount
    return path.rstrip(seps) == _getvolumepathname(path).rstrip(seps)
FileNotFoundError: [WinError 2] The system cannot find the file specified: 'F:\\doesnotexist'

----------
components: Windows
messages: 282241
nosy: lazka, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: os.path.mount sometimes raises FileNotFoundError on Windows
versions: Python 3.5

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

From report at bugs.python.org  Fri Dec  2 09:58:04 2016
From: report at bugs.python.org (Marco Buttu)
Date: Fri, 02 Dec 2016 14:58:04 +0000
Subject: [issue28853] locals() and free variables
In-Reply-To: <1480611277.06.0.950152525221.issue28853@psf.upfronthosting.co.za>
Message-ID: <1480690684.15.0.0711340398368.issue28853@psf.upfronthosting.co.za>


Marco Buttu added the comment:

Yes, it is the same. "Free variables belonging to the enclosing local namespaces" are "non-global free variables". In order for the reader to better contextualize the sentence, I think it is worth keeping the code example in the patch.

----------

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

From report at bugs.python.org  Fri Dec  2 10:08:19 2016
From: report at bugs.python.org (R. David Murray)
Date: Fri, 02 Dec 2016 15:08:19 +0000
Subject: [issue28857] SyncManager and Main Process fail to communicate after
 reboot or stoping with Ctrl - C
In-Reply-To: <1480660972.34.0.757124295552.issue28857@psf.upfronthosting.co.za>
Message-ID: <1480691299.33.0.911035134326.issue28857@psf.upfronthosting.co.za>


R. David Murray added the comment:

There doesn't appear to be enough information here to determine what part of Python you are trying to report a bug in.  It reads more like you are asking for help debugging your program :)

Maybe you could ask for help on the python-list mailing list to help you formulate a clearer bug report.

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

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

From report at bugs.python.org  Fri Dec  2 10:17:07 2016
From: report at bugs.python.org (R. David Murray)
Date: Fri, 02 Dec 2016 15:17:07 +0000
Subject: [issue28853] locals() and free variables
In-Reply-To: <1480611277.06.0.950152525221.issue28853@psf.upfronthosting.co.za>
Message-ID: <1480691827.15.0.579466383562.issue28853@psf.upfronthosting.co.za>


R. David Murray added the comment:

To answer the parenthetical question (I haven't looked at the doc issue itself), we don't doctest the examples because most of them were written before sphinx grew a doctest extension, so a lot of them don't pass for reasons that have nothing to do with code validity.  Issues and patches for making the doctests pass are welcome, and we have applied a number of them.  There is a lot of work to do before we could add running doctest to our doc buildbot, though.

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

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

From report at bugs.python.org  Fri Dec  2 10:44:03 2016
From: report at bugs.python.org (Steve Dower)
Date: Fri, 02 Dec 2016 15:44:03 +0000
Subject: [issue28781] On Installation of 3.5 Python get error message
In-Reply-To: <1479918351.94.0.34425443448.issue28781@psf.upfronthosting.co.za>
Message-ID: <1480693443.85.0.613807263995.issue28781@psf.upfronthosting.co.za>


Steve Dower added the comment:

Sorry, I got caught up in work stuff yesterday and didn't get a chance to go through these. I'll try and find time today.

----------

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

From report at bugs.python.org  Fri Dec  2 10:46:44 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 02 Dec 2016 15:46:44 +0000
Subject: [issue23722] During metaclass.__init__,
 super() of the constructed class does not work
In-Reply-To: <1426859061.43.0.510286082444.issue23722@psf.upfronthosting.co.za>
Message-ID: <1480693604.39.0.260860774044.issue23722@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

This step here is likely to be causing you problems:

https://github.com/django/django/blob/6d1394182d8c4c02598e0cf47f42a5e86706411f/django/db/models/base.py#L90

Because the original class namespace isn't being passed up to type.__new__, it isn't seeing the `__classcell__` reference it needs in order to populate the automatic reference correctly. Copying that over the same way you're already copying `__module__` should get things working again with 3.6.0b4.

However, given that we have a least one in-the-wild example of this causing problems, I think the right thing to do on the CPython side is to restore the old behaviour where the cell reference is returned from the class creation closure, but issue a deprecation warning if it hasn't already been set by type.__new__.

We're also going to need to document `__classcell__`, as we didn't account for the type-subclass-passing-a-different-namespace-to-the-parent-method scenario when initially deciding we could treat it as a hidden implementation detail.

----------
nosy: +larry
priority: normal -> release blocker
resolution: fixed -> 
stage: resolved -> needs patch
status: closed -> open

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

From report at bugs.python.org  Fri Dec  2 11:10:15 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 02 Dec 2016 16:10:15 +0000
Subject: [issue28858] Fastcall uses more C stack
In-Reply-To: <1480665267.65.0.416366810047.issue28858@psf.upfronthosting.co.za>
Message-ID: <1480695015.62.0.0439223890982.issue28858@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oh, I didn't understand that the regression was introduced by the revision b9c9691c72c5. The purpose of this revision was to *reduce* the memory usage of the C stack!?

It seems like _PyObject_CallArg1() uses more stack memory than PyObject_CallFunctionObjArgs(). PyObject_CallFunctionObjArgs() allocates 4O bytes (5*sizeof(PyObject*)) on the stack.

At least, I can say that when the crash occurs, _PyObject_FastCallDict() is not the gdb backtrace.

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

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

From report at bugs.python.org  Fri Dec  2 11:12:29 2016
From: report at bugs.python.org (Tim Graham)
Date: Fri, 02 Dec 2016 16:12:29 +0000
Subject: [issue23722] During metaclass.__init__,
 super() of the constructed class does not work
In-Reply-To: <1426859061.43.0.510286082444.issue23722@psf.upfronthosting.co.za>
Message-ID: <1480695149.46.0.168726015222.issue23722@psf.upfronthosting.co.za>


Tim Graham added the comment:

Thanks Nick. Your suggestion does fix the issue for Django: https://github.com/django/django/pull/7653.

----------

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

From report at bugs.python.org  Fri Dec  2 11:13:06 2016
From: report at bugs.python.org (Wolfgang Maier)
Date: Fri, 02 Dec 2016 16:13:06 +0000
Subject: [issue28859] os.path.mount sometimes raises FileNotFoundError on
 Windows
In-Reply-To: <1480689560.28.0.129916928722.issue28859@psf.upfronthosting.co.za>
Message-ID: <1480695186.23.0.268322903212.issue28859@psf.upfronthosting.co.za>


Changes by Wolfgang Maier <wolfgang.maier at biologie.uni-freiburg.de>:


----------
nosy: +wolma

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

From report at bugs.python.org  Fri Dec  2 11:17:19 2016
From: report at bugs.python.org (Mark Harris)
Date: Fri, 02 Dec 2016 16:17:19 +0000
Subject: [issue28781] On Installation of 3.5 Python get error message
In-Reply-To: <1479918351.94.0.34425443448.issue28781@psf.upfronthosting.co.za>
Message-ID: <1480695439.47.0.0793333735277.issue28781@psf.upfronthosting.co.za>


Mark Harris added the comment:

No worries Steve, I've managed to fix it.

I uninstalled, went through regedit & removed all mentions of python. I then installed python 2.7, installed 3.4 afterwards, uninstalled python 2.7 and for some reason that worked, it is working correctly now!

Thanks for all your help,

Mark

----------

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

From report at bugs.python.org  Fri Dec  2 12:48:42 2016
From: report at bugs.python.org (Mariatta Wijaya)
Date: Fri, 02 Dec 2016 17:48:42 +0000
Subject: [issue28794] inspect.isasyncgen and inspect.isasyncgenfunction aren't
 documented
In-Reply-To: <1480025404.72.0.713291262903.issue28794@psf.upfronthosting.co.za>
Message-ID: <1480700922.01.0.908727379735.issue28794@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

Can anyone review this please? :)

Thanks.

----------

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

From report at bugs.python.org  Fri Dec  2 12:54:21 2016
From: report at bugs.python.org (Steve Dower)
Date: Fri, 02 Dec 2016 17:54:21 +0000
Subject: [issue28781] On Installation of 3.5 Python get error message
In-Reply-To: <1479918351.94.0.34425443448.issue28781@psf.upfronthosting.co.za>
Message-ID: <1480701261.93.0.458848071893.issue28781@psf.upfronthosting.co.za>


Steve Dower added the comment:

> installed 3.4 afterwards

Did you mean 3.5 here? If you're going to change versions, I'd at least suggest grabbing the 3.6 beta - it's *much* better than 3.4, and we've had very little trouble with the most recent version (RC is coming in a week or two).

----------

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

From report at bugs.python.org  Fri Dec  2 14:53:47 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 02 Dec 2016 19:53:47 +0000
Subject: [issue28858] Fastcall uses more C stack
In-Reply-To: <1480665267.65.0.416366810047.issue28858@psf.upfronthosting.co.za>
Message-ID: <1480708427.22.0.16927716067.issue28858@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Yes, that is why I asked you to revert your changes.

In additional, they introduced compiler warnings.

----------

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

From report at bugs.python.org  Fri Dec  2 14:56:17 2016
From: report at bugs.python.org (Rohit Jamuar)
Date: Fri, 02 Dec 2016 19:56:17 +0000
Subject: [issue26876] Extend MSVCCompiler class to respect environment
 variables
In-Reply-To: <1461866719.82.0.2605655084.issue26876@psf.upfronthosting.co.za>
Message-ID: <1480708577.22.0.303251007804.issue26876@psf.upfronthosting.co.za>


Rohit Jamuar added the comment:

Bump! The changes, that Steve was asking for, have been incorporated. If something was missed, please inform. Otherwise, could this be merged?

----------

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

From report at bugs.python.org  Fri Dec  2 15:07:54 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 02 Dec 2016 20:07:54 +0000
Subject: [issue23224] LZMADecompressor object is only initialized in __init__
In-Reply-To: <1421024308.33.0.868171678499.issue23224@psf.upfronthosting.co.za>
Message-ID: <1480709274.9.0.619507095829.issue23224@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is not the only issue. Calling __init__ multiple times causes leaking locks, bz2/lzma internal buffers, etc.

It looks to me that the most straightforward way is using __new__ instead of __init__.

----------
versions: +Python 3.6, Python 3.7 -Python 3.4

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

From report at bugs.python.org  Fri Dec  2 15:19:55 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 02 Dec 2016 20:19:55 +0000
Subject: [issue28853] locals() and free variables
In-Reply-To: <1480611277.06.0.950152525221.issue28853@psf.upfronthosting.co.za>
Message-ID: <1480709995.95.0.234089529598.issue28853@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

FWIW the definition of free variables can be found in the Language Reference at section 4.2.1. "Binding of names" [1].
The list of the free variables of a user defined function can be accessed through the __closure__ function attribute, a tuple. The function attributes are listed in the Language Reference
at section 3.2. "The standard type hierarchy" [2]. In the example given at msg282236, the value of x would be printed by the statement:
    print(moo.__closure__[0].cell_contents)

[1]https://docs.python.org/3/reference/executionmodel.html#naming-and-binding
[2] https://docs.python.org/3/reference/datamodel.html#the-standard-type-hierarchy

----------
nosy: +xdegaye

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

From report at bugs.python.org  Fri Dec  2 16:15:32 2016
From: report at bugs.python.org (Ned Deily)
Date: Fri, 02 Dec 2016 21:15:32 +0000
Subject: [issue27172] Undeprecate inspect.getfullargspec()
In-Reply-To: <1464767888.9.0.788649321892.issue27172@psf.upfronthosting.co.za>
Message-ID: <1480713332.61.0.0234849895692.issue27172@psf.upfronthosting.co.za>


Ned Deily added the comment:

It looks like Serhiy took care of the merge to default in dd4c420b8e66.

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

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

From report at bugs.python.org  Fri Dec  2 16:23:29 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 02 Dec 2016 21:23:29 +0000
Subject: [issue19795] Formatting of True/False/None in docs
In-Reply-To: <1385457525.93.0.980812903017.issue19795@psf.upfronthosting.co.za>
Message-ID: <1480713809.44.0.715156916066.issue19795@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Dec  2 16:34:54 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 02 Dec 2016 21:34:54 +0000
Subject: [issue21818] cookielib documentation references Cookie module,
 not cookielib.Cookie class
In-Reply-To: <1403306887.99.0.626699628104.issue21818@psf.upfronthosting.co.za>
Message-ID: <20161202213451.28343.69107.7BB5A7AF@psf.io>


Roundup Robot added the comment:

New changeset 5b40d81e8883 by Serhiy Storchaka in branch '2.7':
Issue #21818: Fixed references to classes that have names matching with module
https://hg.python.org/cpython/rev/5b40d81e8883

New changeset d64e37b9204e by Serhiy Storchaka in branch '3.5':
Issue #21818: Fixed references to classes that have names matching with module
https://hg.python.org/cpython/rev/d64e37b9204e

New changeset 62c9a89a2103 by Serhiy Storchaka in branch '3.6':
Issue #21818: Fixed references to classes that have names matching with module
https://hg.python.org/cpython/rev/62c9a89a2103

New changeset c642c597d05c by Serhiy Storchaka in branch 'default':
Issue #21818: Fixed references to classes that have names matching with module
https://hg.python.org/cpython/rev/c642c597d05c

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

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

From report at bugs.python.org  Fri Dec  2 17:25:52 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 02 Dec 2016 22:25:52 +0000
Subject: [issue28859] os.path.ismount sometimes raises FileNotFoundError on
 Windows
In-Reply-To: <1480689560.28.0.129916928722.issue28859@psf.upfronthosting.co.za>
Message-ID: <1480717552.68.0.567882789001.issue28859@psf.upfronthosting.co.za>


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


----------
title: os.path.mount sometimes raises FileNotFoundError on Windows -> os.path.ismount sometimes raises FileNotFoundError on Windows

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

From report at bugs.python.org  Fri Dec  2 17:28:32 2016
From: report at bugs.python.org (Marco Buttu)
Date: Fri, 02 Dec 2016 22:28:32 +0000
Subject: [issue28860] Fixed all the doctest failures in
 Doc/library/configparser.rst
Message-ID: <1480717712.23.0.651677304063.issue28860@psf.upfronthosting.co.za>


New submission from Marco Buttu:

With Python 3.7.0a0  and sphinx-build 1.4.9, this was the result before applying the patch:

Doctest summary
===============
   80 tests
    8 failures in tests
    0 failures in setup code
    0 failures in cleanup code
build finished with problems, 139 warnings.

After applaying the patch there are 0 failures in 84 tests. All the doctests also pass with Python 3.6 and 3.5. I skipped three tests (doctest: +SKIP) because their output is random (iterating over dictionary keys).

----------
assignee: docs at python
components: Documentation
files: configparser.patch
keywords: patch
messages: 282258
nosy: docs at python, marco.buttu
priority: normal
severity: normal
status: open
title: Fixed all the doctest failures in Doc/library/configparser.rst
type: enhancement
versions: Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45733/configparser.patch

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

From report at bugs.python.org  Fri Dec  2 18:40:09 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 02 Dec 2016 23:40:09 +0000
Subject: [issue28808] Make PyUnicode_CompareWithASCIIString() never failing
In-Reply-To: <1480175314.71.0.35688135657.issue28808@psf.upfronthosting.co.za>
Message-ID: <1480722009.2.0.570961860037.issue28808@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Updated patch addresses some Victor's comments. But I disagree that this bugfix needs a versionchanged directive.

----------
Added file: http://bugs.python.org/file45734/PyUnicode_CompareWithASCIIString-no-errors-2.patch

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

From report at bugs.python.org  Fri Dec  2 20:21:49 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 03 Dec 2016 01:21:49 +0000
Subject: [issue28853] locals() and free variables
In-Reply-To: <1480611277.06.0.950152525221.issue28853@psf.upfronthosting.co.za>
Message-ID: <1480728109.12.0.845406162886.issue28853@psf.upfronthosting.co.za>


Martin Panter added the comment:

Marco, your patch removes the description for class blocks. Is that your intent, or just an accident? See r53954.

My understanding is ?function block? is there to distinguish these three modes:

def foo():
    # Function block
    print(locals())

class Bar:
    # Class block
    print(locals())

# Module level
print(locals())

There are patches proposed at Issue 17546 which also address this reference to ?free variables?. Perhaps you could provide feedback on them?

Also see Issue 26683 and Issue 12165, about what free variables, locals, nonlocals, non-globals, etc can mean to different people.

----------
nosy: +martin.panter
stage:  -> patch review
versions:  -Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri Dec  2 20:35:30 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 03 Dec 2016 01:35:30 +0000
Subject: [issue28829] Tkinter messagebox cx_freeze Python 3.4
In-Reply-To: <1480406378.43.0.92141568421.issue28829@psf.upfronthosting.co.za>
Message-ID: <1480728930.96.0.52115103066.issue28829@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

You code is buggy and will not run in Python because it does import messagebox.  Add

from tkinter import messagebox

If you only tested with IDLE before freezing, you might have missed the bug in your program because of a bug in IDLE, now fixed in 2.7 and 3.5+.

----------
nosy: +terry.reedy
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri Dec  2 20:44:38 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 03 Dec 2016 01:44:38 +0000
Subject: [issue28853] locals() and free variables
In-Reply-To: <1480611277.06.0.950152525221.issue28853@psf.upfronthosting.co.za>
Message-ID: <1480729478.76.0.175547790182.issue28853@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Dec  2 20:44:47 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 03 Dec 2016 01:44:47 +0000
Subject: [issue28852] sorted(range(1000)) is slower in Python 3.7 than in 3.5
In-Reply-To: <1480609287.7.0.199610846669.issue28852@psf.upfronthosting.co.za>
Message-ID: <1480729487.98.0.215325110392.issue28852@psf.upfronthosting.co.za>


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


----------
title: sorted(range(1000)) is slower in Python 3.7 compared to Python 3.5 -> sorted(range(1000)) is slower in Python 3.7 than in 3.5

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

From report at bugs.python.org  Fri Dec  2 21:32:54 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 03 Dec 2016 02:32:54 +0000
Subject: [issue22057] The doc say all globals are copied on eval(),
 but only __builtins__ is copied
In-Reply-To: <1406210389.95.0.0796853252426.issue22057@psf.upfronthosting.co.za>
Message-ID: <1480732374.83.0.427453121989.issue22057@psf.upfronthosting.co.za>


Martin Panter added the comment:

?the current mapping of '__builtins__' is copied into *globals* ?

That sounds like we insert each individual builtin name, i.e. globals.update(builtins_mapping). But my understanding is that it is the __builtins__ global variable that is affected:

globals["__builtins__"] = builtins_mapping

What about borrowing the wording from exec():

If the *globals* dictionary is present and lacks ?__builtins__?, a reference to the current mapping of ?__builtins__? is inserted under that key . . .

See also Issue 26363, which also covers this problem.

----------
nosy: +martin.panter
stage: needs patch -> patch review
versions: +Python 3.6, Python 3.7 -Python 3.4

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

From report at bugs.python.org  Fri Dec  2 22:06:47 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 03 Dec 2016 03:06:47 +0000
Subject: [issue26363] __builtins__ propagation is misleading described in exec
 and eval documentation
In-Reply-To: <1455532935.35.0.388834921119.issue26363@psf.upfronthosting.co.za>
Message-ID: <1480734407.95.0.552462409411.issue26363@psf.upfronthosting.co.za>


Martin Panter added the comment:

Xavier, you are welcome to propose your own version of the text, or build on Julien?s. See also Issue 22057, about copying all globals vs builtins.

----------
nosy: +martin.panter
stage:  -> patch review
versions: +Python 2.7, Python 3.6, Python 3.7

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

From report at bugs.python.org  Fri Dec  2 23:04:17 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 03 Dec 2016 04:04:17 +0000
Subject: [issue28847] dumbdbm should not commit if in read mode
In-Reply-To: <1480564427.92.0.600594500998.issue28847@psf.upfronthosting.co.za>
Message-ID: <1480737857.43.0.644689922583.issue28847@psf.upfronthosting.co.za>


Martin Panter added the comment:

Serhiy: The Windows buildbots are having trouble removing read-only files. Maybe restore the write mode for the end of the test, or fix support.rmtree()? See <https://docs.python.org/3/library/shutil.html#rmtree-example>.

----------
nosy: +martin.panter

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

From report at bugs.python.org  Fri Dec  2 23:05:14 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 03 Dec 2016 04:05:14 +0000
Subject: [issue28847] dumbdbm should not commit if in read mode
In-Reply-To: <1480564427.92.0.600594500998.issue28847@psf.upfronthosting.co.za>
Message-ID: <20161203040510.21262.56137.60763720@psf.io>


Roundup Robot added the comment:

New changeset dc7c86de9e13 by Martin Panter in branch '2.7':
Issue #28847: Fix spelling
https://hg.python.org/cpython/rev/dc7c86de9e13

----------

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

From report at bugs.python.org  Fri Dec  2 23:12:56 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 03 Dec 2016 04:12:56 +0000
Subject: [issue28847] dumbdbm should not commit if in read mode
In-Reply-To: <1480564427.92.0.600594500998.issue28847@psf.upfronthosting.co.za>
Message-ID: <1480738376.88.0.148676883749.issue28847@psf.upfronthosting.co.za>


Martin Panter added the comment:

http://buildbot.python.org/all/builders/AMD64%20Windows8%202.7/builds/9/steps/test/logs/stdio
======================================================================
ERROR: test_readonly_files (test.test_dumbdbm.DumbDBMTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\buildarea\2.7.bolen-windows8\build\lib\test\test_dumbdbm.py", line 190, in test_readonly_files
    test_support.rmtree(dir)
  File "D:\buildarea\2.7.bolen-windows8\build\lib\test\test_support.py", line 289, in rmtree
    _rmtree(path)
  File "D:\buildarea\2.7.bolen-windows8\build\lib\test\test_support.py", line 245, in _rmtree
    _waitfor(_rmtree_inner, path, waitall=True)
  File "D:\buildarea\2.7.bolen-windows8\build\lib\test\test_support.py", line 199, in _waitfor
    func(pathname)
  File "D:\buildarea\2.7.bolen-windows8\build\lib\test\test_support.py", line 244, in _rmtree_inner
    _force_run(path, os.unlink, fullname)
  File "D:\buildarea\2.7.bolen-windows8\build\lib\test\test_support.py", line 194, in _force_run
    return func(*args)
WindowsError: [Error 5] Access is denied: '@test_3796_tmp\\db.dat'

----------------------------------------------------------------------
'test_dumbdbm' left behind directory '@test_3796_tmp'
. . .
test test_dumbdbm crashed -- <type 'exceptions.WindowsError'>: [Error 5] Access is denied: '@test_3796_tmp\\db.dat'
Traceback (most recent call last):
  File "D:\buildarea\2.7.bolen-windows8\build\PCbuild\..\Lib\test\regrtest.py", line 948, in runtest_inner
    test_time = time.time() - start_time
  File "D:\buildarea\2.7.bolen-windows8\build\PCbuild\..\Lib\test\regrtest.py", line 899, in __exit__
    restore(original)
  File "D:\buildarea\2.7.bolen-windows8\build\PCbuild\..\Lib\test\regrtest.py", line 876, in restore_files
    test_support.rmtree(fn)
. . .
'test_dumbdbm' left behind directory '@test_3796_tmp' and it couldn't be removed: [Error 5] Access is denied: '@test_3796_tmp\\db.dat'
Traceback (most recent call last):
  File "D:\buildarea\2.7.bolen-windows8\build\PCbuild\..\Lib\test\regrtest.py", line 1679, in <module>
    main()
  File "D:\buildarea\2.7.bolen-windows8\build\lib\contextlib.py", line 35, in __exit__
    self.gen.throw(type, value, traceback)
  File "D:\buildarea\2.7.bolen-windows8\build\lib\test\test_support.py", line 765, in temp_cwd
    rmtree(name)

----------

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

From report at bugs.python.org  Fri Dec  2 23:44:05 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 03 Dec 2016 04:44:05 +0000
Subject: [issue17546] Document the circumstances where the locals() dict get
 updated
In-Reply-To: <1364232011.36.0.2936348393.issue17546@psf.upfronthosting.co.za>
Message-ID: <1480740245.55.0.648855494693.issue17546@psf.upfronthosting.co.za>


Martin Panter added the comment:

Some minor tweaks to my earlier patch:
* list comprehension ? comprehension
* time it is called ? time of the call

----------
versions: +Python 3.6, Python 3.7 -Python 3.3, Python 3.4
Added file: http://bugs.python.org/file45735/locals_doc.04.patch

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

From report at bugs.python.org  Fri Dec  2 23:44:16 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 03 Dec 2016 04:44:16 +0000
Subject: [issue27172] Undeprecate inspect.getfullargspec()
In-Reply-To: <1464767888.9.0.788649321892.issue27172@psf.upfronthosting.co.za>
Message-ID: <1480740256.8.0.59572014953.issue27172@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Thank you Serhiy!

That leaves this just as a pending update for 3.5.3 to bring it into line with 3.6.0.

I've reverted the stage to "needs patch" and removed the patch keyword, as the 3.5 patch will be slightly different:

- using 3.5.3 in the versionchanged notice
- adjusting the 3.5 What's New to change the list of deprecated inspect module APIs

----------
stage: commit review -> needs patch
versions:  -Python 3.7

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

From report at bugs.python.org  Sat Dec  3 00:58:18 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 03 Dec 2016 05:58:18 +0000
Subject: [issue28847] dumbdbm should not commit if in read mode
In-Reply-To: <1480564427.92.0.600594500998.issue28847@psf.upfronthosting.co.za>
Message-ID: <20161203055815.21122.20216.09277E1E@psf.io>


Roundup Robot added the comment:

New changeset cb4a892e9b66 by Serhiy Storchaka in branch '2.7':
Try to fix test.test_support.rmtree() on Windows for fixing issue28847 tests.
https://hg.python.org/cpython/rev/cb4a892e9b66

----------

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

From report at bugs.python.org  Sat Dec  3 01:45:19 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 03 Dec 2016 06:45:19 +0000
Subject: [issue23722] During metaclass.__init__,
 super() of the constructed class does not work
In-Reply-To: <1426859061.43.0.510286082444.issue23722@psf.upfronthosting.co.za>
Message-ID: <1480747519.13.0.0589364758026.issue23722@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Attached patch is some new test cases for an approach that I figured out *won't work*.

The problem I hit is that "__classcell__" is only injected into the class body execution namespace when there is at least one method implementation that needs it. In any other case, including when constructing types dynamically, it's entirely legitimate for it to be missing.

The attached draft test cases explored the idea of requiring that `__classcell__` be set to `None` to affirmatively indicate that it wasn't needed, but that would be a *major* compatibility break for dynamic type creation.

I haven't given up on providing that eager warning though - it should be possible to emit it in __build_class__ based on PyCell_GET returning NULL (as that should reliably indicate that type.__new__ never got access to the compiler provided cell object)

----------
Added file: http://bugs.python.org/file45736/issue23722_enhanced_classcell_tests.diff

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

From report at bugs.python.org  Sat Dec  3 01:59:23 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 03 Dec 2016 06:59:23 +0000
Subject: [issue28847] dumbdbm should not commit if in read mode
In-Reply-To: <1480564427.92.0.600594500998.issue28847@psf.upfronthosting.co.za>
Message-ID: <1480748363.71.0.028161308228.issue28847@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thanks Martin for pointing on this. Now buildbots are green.

----------

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

From report at bugs.python.org  Sat Dec  3 02:15:15 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 03 Dec 2016 07:15:15 +0000
Subject: [issue28440] ensurepip and pip install failures on macOS Sierra with
 non-system Python 2.7.x
In-Reply-To: <1476450540.6.0.486887198503.issue28440@psf.upfronthosting.co.za>
Message-ID: <20161203071512.30481.82956.B4A7C747@psf.io>


Roundup Robot added the comment:

New changeset a8a342b3fbc7 by Ned Deily in branch '2.7':
Issue #28440: No longer add /Library/Python/site-packages, the Apple-supplied
https://hg.python.org/cpython/rev/a8a342b3fbc7

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

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

From report at bugs.python.org  Sat Dec  3 02:15:15 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 03 Dec 2016 07:15:15 +0000
Subject: [issue4865] system wide site-packages dir not used on Mac OS X
In-Reply-To: <1231332662.33.0.831675111419.issue4865@psf.upfronthosting.co.za>
Message-ID: <20161203071512.30481.56592.ADCCC49F@psf.io>


Roundup Robot added the comment:

New changeset a8a342b3fbc7 by Ned Deily in branch '2.7':
Issue #28440: No longer add /Library/Python/site-packages, the Apple-supplied
https://hg.python.org/cpython/rev/a8a342b3fbc7

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

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

From report at bugs.python.org  Sat Dec  3 02:19:00 2016
From: report at bugs.python.org (Parviz Karimli)
Date: Sat, 03 Dec 2016 07:19:00 +0000
Subject: [issue28829] Tkinter messagebox cx_freeze Python 3.4
In-Reply-To: <1480728930.96.0.52115103066.issue28829@psf.upfronthosting.co.za>
Message-ID: <CAP0QrKJZig0wi7nc29SAj+53BQv65aKb0bqTt3=8fWPhhbfHrg@mail.gmail.com>


Parviz Karimli added the comment:

Thanks, mr. Reedy for your response! I have already solved the issue.
Actually I had encountered this before and figured out the problem, but
unfortunately forgot when I encountered it again. I should have deleted
this issue from Python Bug community, but I thought it was not online since
I needed to complete some kind of form before it published on the site...
My bad!

On Sat, Dec 3, 2016 at 5:35 AM, Terry J. Reedy <report at bugs.python.org>
wrote:

>
> Terry J. Reedy added the comment:
>
> You code is buggy and will not run in Python because it does import
> messagebox.  Add
>
> from tkinter import messagebox
>
> If you only tested with IDLE before freezing, you might have missed the
> bug in your program because of a bug in IDLE, now fixed in 2.7 and 3.5+.
>
> ----------
> nosy: +terry.reedy
> resolution:  -> not a bug
> stage:  -> resolved
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue28829>
> _______________________________________
>

----------

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

From report at bugs.python.org  Sat Dec  3 02:21:14 2016
From: report at bugs.python.org (Ned Deily)
Date: Sat, 03 Dec 2016 07:21:14 +0000
Subject: [issue28440] ensurepip and pip install failures on macOS Sierra with
 non-system Python 2.7.x
In-Reply-To: <1476450540.6.0.486887198503.issue28440@psf.upfronthosting.co.za>
Message-ID: <1480749674.56.0.66002691889.issue28440@psf.upfronthosting.co.za>


Ned Deily added the comment:

I've pushed the change to revert Issue4865 for the 2.7 branch for release with 2.7.13.  I am leaving this open to push similar changes for 3.x branches in anticipation of Apple someday supplying system Python 3.x.  It would also be good to see if the post-install script that runs ensurepip can be made to fail more noisily.

----------
priority: release blocker -> 
versions: +Python 3.6, Python 3.7

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

From report at bugs.python.org  Sat Dec  3 02:23:22 2016
From: report at bugs.python.org (Ned Deily)
Date: Sat, 03 Dec 2016 07:23:22 +0000
Subject: [issue4865] system wide site-packages dir not used on Mac OS X
In-Reply-To: <1231332662.33.0.831675111419.issue4865@psf.upfronthosting.co.za>
Message-ID: <1480749802.47.0.0397413518354.issue4865@psf.upfronthosting.co.za>


Ned Deily added the comment:

Update: this change has been reverted in Python 2.7.13.  See Issue #28440 for details.

----------
nosy: +ned.deily
stage:  -> resolved

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

From report at bugs.python.org  Sat Dec  3 04:57:57 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 03 Dec 2016 09:57:57 +0000
Subject: [issue27647] Update Windows build to Tcl/Tk 8.6.6
In-Reply-To: <1469737194.88.0.144648917966.issue27647@psf.upfronthosting.co.za>
Message-ID: <1480759077.93.0.980508983503.issue27647@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Proposed patch updates Tcl/Tk versions to 8.5.19 and Tix version to 8.4.3.6 in Python 2.7 on Windows and Mac OS X. But needed to update http://svn.python.org/projects/external/ . Is there special script or instruction?

----------
keywords: +patch
Added file: http://bugs.python.org/file45737/update-tk-2.7.patch

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

From report at bugs.python.org  Sat Dec  3 05:04:48 2016
From: report at bugs.python.org (INADA Naoki)
Date: Sat, 03 Dec 2016 10:04:48 +0000
Subject: [issue28638] Creating namedtuple is too slow to be used in common
 stdlib (e.g. functools)
In-Reply-To: <1478578044.23.0.961493371476.issue28638@psf.upfronthosting.co.za>
Message-ID: <1480759488.15.0.492755989934.issue28638@psf.upfronthosting.co.za>


INADA Naoki added the comment:

> That leads into my main comment on the AC patch: the files that are explicitly listed as triggering a new clinic run should be factored out into a named variable and that list commented accordingly.

done.

----------
Added file: http://bugs.python.org/file45738/namedtuple-clinic3.patch

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

From report at bugs.python.org  Sat Dec  3 05:37:53 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 03 Dec 2016 10:37:53 +0000
Subject: [issue28638] Creating namedtuple is too slow to be used in common
 stdlib (e.g. functools)
In-Reply-To: <1478578044.23.0.961493371476.issue28638@psf.upfronthosting.co.za>
Message-ID: <1480761473.55.0.203580428786.issue28638@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Argument Clinic is used just for running the generating code and inlining the result. This is the simplest part of Argument Clinic and using it looks an overhead. Argument Clinic has other disadvantages:

* In any case you need a rule in Makefile, otherwise the generated code can became outdated.

* Generated code depends not just on the generator code, but on the code of the collections module.

* Even tiny change in the generating code, namedtuple implementation or Argument Clinic code could need regenerating generated code with different checksums.

My second idea, more general solution, was making namedtuple itself using external caching. This would add a benefit for all users of namedtuple without changing a user code or with minimal changes.

namedtuple itself can save a bytecode and a source in files (like Java creates additional .class files for internal classes) and use a bytecode if it is not outdated. Generalized import machinery could be used for supporting generated code in a sync.

----------

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

From report at bugs.python.org  Sat Dec  3 05:57:22 2016
From: report at bugs.python.org (Edward K. Ream)
Date: Sat, 03 Dec 2016 10:57:22 +0000
Subject: [issue25778] winreg.EnumValue does not truncate strings correctly
In-Reply-To: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za>
Message-ID: <1480762642.69.0.0173285654325.issue25778@psf.upfronthosting.co.za>


Edward K. Ream added the comment:

The last message on this thread was in January, and this item is Open. According to Pep 478, 3.5.2 final was released Sunday, June 26, 2016.

How is this issue not a release blocker?

Why does there appear to be no urgency in fixing this bug?

This bug bites for 64-bit versions of Python 3. When it bit, it caused Leo to crash during startup. When it bit, it was reason to recommend Python 2 over Python 3.

I have just released an ugly workaround in Leo. So now Leo itself can start up, but there is no guarantee that user plugins and scripts will work.

Imo, no future version of Python 3 should go out the door until this bug is fixed, for sure, and for all time. If you want people to use Python 3, it can NOT have this kind of bug in it.

----------
nosy: +Edward.K..Ream

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

From report at bugs.python.org  Sat Dec  3 06:56:04 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNC60YHQuNC8INCb0YPQutC+0Y/QvdC+0LI=?=)
Date: Sat, 03 Dec 2016 11:56:04 +0000
Subject: [issue27305] Crash with "pip list --outdated" on Windows 10 with
 Python 2.7.12rc1
In-Reply-To: <1465820074.65.0.989290191732.issue27305@psf.upfronthosting.co.za>
Message-ID: <1480766164.81.0.292738672648.issue27305@psf.upfronthosting.co.za>


?????? ???????? added the comment:

I still got the same issue with 2.7.12 x64 release version from https://www.python.org/downloads/release/python-2712/

----------
nosy: +?????? ????????

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

From report at bugs.python.org  Sat Dec  3 07:25:03 2016
From: report at bugs.python.org (Marco Buttu)
Date: Sat, 03 Dec 2016 12:25:03 +0000
Subject: [issue28853] locals() and free variables
In-Reply-To: <1480611277.06.0.950152525221.issue28853@psf.upfronthosting.co.za>
Message-ID: <1480767903.47.0.496704743578.issue28853@psf.upfronthosting.co.za>


Marco Buttu added the comment:

Martin, I removed the class blocks by accident. In any case, I reject the patch by myself, because to me the definition of "free variable" is not clear. 
The documentation [1] says: "If a variable is used in a code block but not defined there, it is a free variable." According to this description,  it seems to me that ``x`` is free both in ``foo()`` and in ``moo()``:


>>> def foo():
...     print(x)
...     def moo():
...         print(x)
...     return moo


But actually for the code object it is not:


>>> foo.__code__.co_freevars
()
>>> moo.__code__.co_freevars
('x',)


Thank you for your feedback, I will continue the discussion in issue 26683.

[1] https://docs.python.org/3/reference/executionmodel.html#naming-and-binding

----------

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

From report at bugs.python.org  Sat Dec  3 07:37:58 2016
From: report at bugs.python.org (Marco Buttu)
Date: Sat, 03 Dec 2016 12:37:58 +0000
Subject: [issue28853] locals() and free variables
In-Reply-To: <1480611277.06.0.950152525221.issue28853@psf.upfronthosting.co.za>
Message-ID: <1480768678.31.0.859966638335.issue28853@psf.upfronthosting.co.za>


Marco Buttu added the comment:

Sorry, in the last example, for the code object ``x`` is not free both in ``foo()`` and ``moo()``, but this does not affect the conclusion.

----------

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

From report at bugs.python.org  Sat Dec  3 08:56:18 2016
From: report at bugs.python.org (Marco Buttu)
Date: Sat, 03 Dec 2016 13:56:18 +0000
Subject: [issue26683] Questionable terminology for describing what locals()
 does
In-Reply-To: <1459474292.87.0.515226107717.issue26683@psf.upfronthosting.co.za>
Message-ID: <1480773378.94.0.43794987954.issue26683@psf.upfronthosting.co.za>


Marco Buttu added the comment:

The documentation [1] says: "If a variable is used in a code block but not defined there, it is a free variable." According to this description,  it seems to me that the variable ``x`` is free in ``foo()``::

  >>> def foo():
  ...     print(x)

But actually for the code object it is not::

  >>> foo.__code__.co_freevars
  ()

The meaning of free variable used for the code object is consistent with the ``locals()`` documentation [2]: "Free variables are returned by locals() when it is called in function blocks". In fact, in the following code ``x` is not a free variable for ``locals()``::

  >>> def foo():
  ...     print(x)
  ...     print(locals())
  ... 
  >>> x = 3
  >>> foo()
  3
  {}

So, I thing there is an inconsistency between the definition of "free variable" given in [1] and the meaning of "free variable" both in the code object and in the ``locals()`` documentation [2]. 
But if we change the definition of "free variable" according to the meaning of both the code object and ``locals()``, I am afraid we go in the wrong direction, because I suspect for most people the proper definition of free variable is the one given in [1]. Also for Wikipedia [3]: "In computer programming, the term free variable refers to variables used in a function that are neither local variables nor parameters of that function.".

Instead, if we keep or remove the definition of "free variable" given in [1], I agree with Terry to change the ``locals()`` documentation, writing that "``locals()`` includes also the locals of the surrounding function contexts, even though they are called 'nonlocal' within the nested function.". Maybe it is also worth adding a shell example, to better clarify. 

So, at the end, to me the ideal solution would be to keep in [1] the current definition of "free variable", to change the ``locals()`` documentation according to Terry suggestion, and to change the behavior of ``code.co_freevars`` (maybe not only this) in order to fit the definition.


[1] https://docs.python.org/3/reference/executionmodel.html#naming-and-binding
[2] https://docs.python.org/3/library/functions.html#locals
[3] https://en.wikipedia.org/wiki/Free_variables_and_bound_variables

----------
nosy: +marco.buttu

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

From report at bugs.python.org  Sat Dec  3 09:50:44 2016
From: report at bugs.python.org (R. David Murray)
Date: Sat, 03 Dec 2016 14:50:44 +0000
Subject: [issue25778] winreg.EnumValue does not truncate strings correctly
In-Reply-To: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za>
Message-ID: <1480776644.53.0.537266497357.issue25778@psf.upfronthosting.co.za>


R. David Murray added the comment:

Looks like it fell off everyone's radar.    It is now also too late in the 3.6 release cycle: it isn't "release critical" in the sense of being a breaking regression from 3.5, so it is not likely to get in.

Keep in mind that this is a distributed, mostly volunteer community.  Clearly no one else thought it was a release blocker, but you have presented a case for making it so.  I haven't evaluated that case; I'm leaving that to the windows devs.  Having your input a few weeks ago would have made it more likely to get in to 3.6, regardless of whether or not anyone else thought it was a release blocker.

And please check back after the 3.6 release, and advocate for getting it in to the next release of both 3.5 and 3.6.

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

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

From report at bugs.python.org  Sat Dec  3 10:05:57 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 03 Dec 2016 15:05:57 +0000
Subject: [issue28849] do not define sys.implementation._multiarch on Android
In-Reply-To: <1480579567.9.0.848858013461.issue28849@psf.upfronthosting.co.za>
Message-ID: <1480777557.22.0.513298290549.issue28849@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

The change made by the patch in Makefile.pre.in handles the removing of the dangling underscore in the patch of issue 28833, it is not needed.
android_multiarch_2.patch is simpler: the change in Makefile.pre.in has been removed and test_triplet_in_ext_suffix is now skipped when sys.implementation does not have the _multiarch attribute instead of only for android as previously.

----------
Added file: http://bugs.python.org/file45739/android_multiarch_2.patch

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

From report at bugs.python.org  Sat Dec  3 10:11:04 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 03 Dec 2016 15:11:04 +0000
Subject: [issue28849] do not define sys.implementation._multiarch on Android
In-Reply-To: <1480579567.9.0.848858013461.issue28849@psf.upfronthosting.co.za>
Message-ID: <1480777864.95.0.791347110205.issue28849@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

The MULTIARCH triplet:
  * is used by the build system in the suffix of the name of the _sysconfigdata private module, it may have any value (including being empty) when the platform is non-multiarch - for example cross-compiling for an Android emulator with the 'foo-bar-foobar' MULTIARCH triplet works just fine (without the patch)
  * is not used by the interpreter
  * the Python user may not use it (sys.implementation_multiarch is private)
  * is not used in the standard library, except by the sysconfig modules to get the name of the _sysconfigdata module (and it may be empty)
  * is not needed any more to cross-compile non-multiarch platforms (even without the patch) since issue 28046, where platform-specific directories have been removed

On Android the MULTIARCH triplet adds the burden of having to maintain the list of Android processors and abis in configure.ac through a set of complex conditionals (see below [1]) whose correctness is uncertain and not verified. This is useless and removed since it is not needed anymore.

[1] The Android set of conditionals in configure.ac:

#if defined(__ANDROID__)
# if defined(__x86_64__) && defined(__LP64__)
        x86_64-linux-android
# elif defined(__i386__)
        i686-linux-android
# elif defined(__aarch64__) && defined(__AARCH64EL__)
#  if defined(__ILP32__)
        aarch64_ilp32-linux-android
#  else
        aarch64-linux-android
#  endif
# elif defined(__ARM_EABI__) && defined(__ARMEL__)
        arm-linux-androideabi
# elif defined(__mips_hard_float) && defined(_MIPSEL)
#  if _MIPS_SIM == _ABIO32
        mipsel-linux-android
#  elif _MIPS_SIM == _ABI64
        mips64el-linux-android
#  else
#   error unknown platform triplet
#  endif
# else
#   error unknown platform triplet
# endif

----------

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

From report at bugs.python.org  Sat Dec  3 10:44:06 2016
From: report at bugs.python.org (Julien Palard)
Date: Sat, 03 Dec 2016 15:44:06 +0000
Subject: [issue28853] locals() and free variables
In-Reply-To: <1480611277.06.0.950152525221.issue28853@psf.upfronthosting.co.za>
Message-ID: <1480779846.36.0.287929362624.issue28853@psf.upfronthosting.co.za>


Julien Palard added the comment:

Should this issue be closed so?

----------

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

From report at bugs.python.org  Sat Dec  3 11:42:30 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 03 Dec 2016 16:42:30 +0000
Subject: [issue28596] on Android _bootlocale on startup relies on too many
 library modules
In-Reply-To: <1478166520.26.0.975749703987.issue28596@psf.upfronthosting.co.za>
Message-ID: <1480783350.87.0.959707768252.issue28596@psf.upfronthosting.co.za>


Changes by Xavier de Gaye <xdegaye at gmail.com>:


----------
assignee:  -> xdegaye
stage: needs patch -> patch review
type: behavior -> performance
versions:  -Python 3.6

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

From report at bugs.python.org  Sat Dec  3 12:04:39 2016
From: report at bugs.python.org (Ned Deily)
Date: Sat, 03 Dec 2016 17:04:39 +0000
Subject: [issue27647] Update Windows build to Tcl/Tk 8.6.6
In-Reply-To: <1469737194.88.0.144648917966.issue27647@psf.upfronthosting.co.za>
Message-ID: <1480784679.6.0.833451268122.issue27647@psf.upfronthosting.co.za>


Ned Deily added the comment:

Please don't change Mac/BuildScript.  The code there to build Tcl and Tk is currently not used.

----------
nosy: +ned.deily

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

From report at bugs.python.org  Sat Dec  3 13:07:06 2016
From: report at bugs.python.org (Marco Buttu)
Date: Sat, 03 Dec 2016 18:07:06 +0000
Subject: [issue28853] locals() and free variables
In-Reply-To: <1480611277.06.0.950152525221.issue28853@psf.upfronthosting.co.za>
Message-ID: <1480788426.65.0.132501178398.issue28853@psf.upfronthosting.co.za>


Marco Buttu added the comment:

I close it because the meaning of "free variable" is not clear. We are discussing about it in issue 26683.

----------
resolution:  -> postponed
status: open -> closed

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

From report at bugs.python.org  Sat Dec  3 13:50:40 2016
From: report at bugs.python.org (=?utf-8?b?RMSBdmlz?=)
Date: Sat, 03 Dec 2016 18:50:40 +0000
Subject: [issue6135] subprocess seems to use local encoding and give no choice
In-Reply-To: <1243494524.57.0.870766192683.issue6135@psf.upfronthosting.co.za>
Message-ID: <1480791040.38.0.386418377585.issue6135@psf.upfronthosting.co.za>


D?vis added the comment:

Still can't specify encoding for getstatusoutput and getoutput. Also it uses wrong encoding by default, most of time it will be console's codepage instead of ANSI codepage which is used now.

----------
nosy: +davispuh

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

From report at bugs.python.org  Sat Dec  3 13:58:02 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 03 Dec 2016 18:58:02 +0000
Subject: [issue28860] Fixed all the doctest failures in
 Doc/library/configparser.rst
In-Reply-To: <1480717712.23.0.651677304063.issue28860@psf.upfronthosting.co.za>
Message-ID: <1480791482.38.0.903057324116.issue28860@psf.upfronthosting.co.za>


Brett Cannon added the comment:

For the iteration of dictionary keys, can you pass the keys through sorted() to have a deterministic order?

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

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

From report at bugs.python.org  Sat Dec  3 14:04:03 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 03 Dec 2016 19:04:03 +0000
Subject: [issue27870] Left shift of zero allocates memory
In-Reply-To: <1472238743.62.0.87785770674.issue27870@psf.upfronthosting.co.za>
Message-ID: <20161203190400.29377.64789.E19192D7@psf.io>


Roundup Robot added the comment:

New changeset 2b190bfd9ab4 by Benjamin Peterson in branch '2.7':
fix refleak in the shift-by-zero case (#27870)
https://hg.python.org/cpython/rev/2b190bfd9ab4

----------

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

From report at bugs.python.org  Sat Dec  3 14:19:37 2016
From: report at bugs.python.org (=?utf-8?b?RMSBdmlz?=)
Date: Sat, 03 Dec 2016 19:19:37 +0000
Subject: [issue6135] subprocess seems to use local encoding and give no choice
In-Reply-To: <1243494524.57.0.870766192683.issue6135@psf.upfronthosting.co.za>
Message-ID: <1480792777.88.0.442238826143.issue6135@psf.upfronthosting.co.za>


D?vis added the comment:

And looks like only way to specify console's codepage is with
`encoding=os.device_encoding(2)` which will have to be used for 99% of cases. I don't see other way...

----------

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

From report at bugs.python.org  Sat Dec  3 14:30:14 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 03 Dec 2016 19:30:14 +0000
Subject: [issue25455] Some repr implementations don't check for
 self-referential structures
In-Reply-To: <1445455038.6.0.824380060049.issue25455@psf.upfronthosting.co.za>
Message-ID: <20161203193011.28558.33033.DF80F507@psf.io>


Roundup Robot added the comment:

New changeset ea1edf1bf362 by Benjamin Peterson in branch '2.7':
when you enter repr, you must leave, too (#25455)
https://hg.python.org/cpython/rev/ea1edf1bf362

----------

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

From report at bugs.python.org  Sat Dec  3 14:34:46 2016
From: report at bugs.python.org (John Helour)
Date: Sat, 03 Dec 2016 19:34:46 +0000
Subject: [issue24339] iso6937 encoding missing
In-Reply-To: <1433078403.47.0.568019085367.issue24339@psf.upfronthosting.co.za>
Message-ID: <1480793686.56.0.817809483629.issue24339@psf.upfronthosting.co.za>


Changes by John Helour <helourx at gmail.com>:


Removed file: http://bugs.python.org/file45708/iso6937.py

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

From report at bugs.python.org  Sat Dec  3 14:36:10 2016
From: report at bugs.python.org (John Helour)
Date: Sat, 03 Dec 2016 19:36:10 +0000
Subject: [issue24339] iso6937 encoding missing
In-Reply-To: <1433078403.47.0.568019085367.issue24339@psf.upfronthosting.co.za>
Message-ID: <1480793770.26.0.880900696211.issue24339@psf.upfronthosting.co.za>


Changes by John Helour <helourx at gmail.com>:


Added file: http://bugs.python.org/file45740/iso6937.py

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

From report at bugs.python.org  Sat Dec  3 14:37:11 2016
From: report at bugs.python.org (Steve Dower)
Date: Sat, 03 Dec 2016 19:37:11 +0000
Subject: [issue25778] winreg.EnumValue does not truncate strings correctly
In-Reply-To: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za>
Message-ID: <1480793831.95.0.178206667066.issue25778@psf.upfronthosting.co.za>


Steve Dower added the comment:

This looks like it was my fault - I said I'd commit the patches and then never got back to it.

I've assigned the issue to me so it doesn't fall off my radar again (though if someone else wants to do it first they're welcome to). But at this stage I suspect it's best not to change 3.6.0.

----------
assignee:  -> steve.dower
versions: +Python 3.7

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

From report at bugs.python.org  Sat Dec  3 14:40:44 2016
From: report at bugs.python.org (Marco Buttu)
Date: Sat, 03 Dec 2016 19:40:44 +0000
Subject: [issue28860] Fixed all the doctest failures in
 Doc/library/configparser.rst
In-Reply-To: <1480717712.23.0.651677304063.issue28860@psf.upfronthosting.co.za>
Message-ID: <1480794044.7.0.994536178086.issue28860@psf.upfronthosting.co.za>


Marco Buttu added the comment:

I usually keep the code examples focused, because I think extra code added just in order to have more tests can get the example less clear. But of course, there is an important downside :/ So, if your policy and goal is to have a better coverage of the code examples, here is another patch that uses sorted().

Thank you very much for your time :-)

----------
Added file: http://bugs.python.org/file45741/configparser2nd.patch

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

From report at bugs.python.org  Sat Dec  3 14:47:19 2016
From: report at bugs.python.org (Steve Dower)
Date: Sat, 03 Dec 2016 19:47:19 +0000
Subject: [issue6135] subprocess seems to use local encoding and give no choice
In-Reply-To: <1243494524.57.0.870766192683.issue6135@psf.upfronthosting.co.za>
Message-ID: <1480794439.82.0.906189100836.issue6135@psf.upfronthosting.co.za>


Steve Dower added the comment:

> looks like only way to specify console's codepage is with
`encoding=os.device_encoding(2)` which will have to be used for 99% of cases

That's true, but it only applies when the subprocess is using the same call (GetConsoleCP) to determine what encoding to use to write to something *other* than the console, which is incorrect. The defaults in this cause ought to be ACP, but it depends entirely on the target application and there is no good "99%" default.

To see this demonstrated, check the difference between these two commands (with 3.5 or earlier):

python -c "import sys; print(sys.stdin.encoding)"
python -c "import sys; print(sys.stdin.encoding)" < textfile.txt

When stdin is redirected, the default encoding is not the console encoding (unless it happens to match your ACP). And ACP is not the correct encoding for a file anyway - it just happens to be the default for TextIOWrapper - so to do it properly you need to detect that it's not a console (sys.stdin.isatty()) and then use the raw stream rather than the default wrapper. (Or you specify that your program requires ACP files, or that PYTHONIOENCODING should be set, or that it requires any other encoding and you explicitly switch to that one.)

In short, character encoding is hard, and the only way to get it right is for the developer to be aware of it. No good defaults exist.

----------

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

From report at bugs.python.org  Sat Dec  3 14:49:08 2016
From: report at bugs.python.org (Steve Dower)
Date: Sat, 03 Dec 2016 19:49:08 +0000
Subject: [issue27305] Crash with "pip list --outdated" on Windows 10 with
 Python 2.7.12rc1
In-Reply-To: <1465820074.65.0.989290191732.issue27305@psf.upfronthosting.co.za>
Message-ID: <1480794548.7.0.639706290601.issue27305@psf.upfronthosting.co.za>


Steve Dower added the comment:

It works for me. Can you confirm your operating system, and add the full output from running these commands:

>>> print sys.version
>>> from urllib2 import urlopen
>>> urlopen('http://www.google.co.uk')
>>> urlopen('https://www.google.co.uk')

----------

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

From report at bugs.python.org  Sat Dec  3 14:56:12 2016
From: report at bugs.python.org (Edward K. Ream)
Date: Sat, 03 Dec 2016 19:56:12 +0000
Subject: [issue25778] winreg.EnumValue does not truncate strings correctly
In-Reply-To: <1480793831.95.0.178206667066.issue25778@psf.upfronthosting.co.za>
Message-ID: <CAMF8tS1P6D6VOseKCiqOvuWy=cRqp+bgpAOKqdfFkx_+0g0Fig@mail.gmail.com>


Edward K. Ream added the comment:

On Sat, Dec 3, 2016 at 1:37 PM, Steve Dower <report at bugs.python.org> wrote:

?Thanks, Steve and David, for your replies. Getting this issue fixed
eventually will do.? Glad to hear it was a mistake, and not policy ;-)

EKR

----------

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

From report at bugs.python.org  Sat Dec  3 15:01:38 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 03 Dec 2016 20:01:38 +0000
Subject: [issue21147] sqlite3 doesn't complain if the request contains a null
 character
In-Reply-To: <1396544845.43.0.82545828662.issue21147@psf.upfronthosting.co.za>
Message-ID: <20161203200135.21414.54618.C3F41627@psf.io>


Roundup Robot added the comment:

New changeset e358aaf9563f by Benjamin Peterson in branch '2.7':
fix refleak in null-containing error case (#21147)
https://hg.python.org/cpython/rev/e358aaf9563f

----------

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

From report at bugs.python.org  Sat Dec  3 15:13:14 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 03 Dec 2016 20:13:14 +0000
Subject: [issue28846] Add a ProviderKey to the installer bundle
In-Reply-To: <1480550258.58.0.874105613934.issue28846@psf.upfronthosting.co.za>
Message-ID: <20161203201311.93035.36266.6BF8E379@psf.io>


Roundup Robot added the comment:

New changeset 68530c0a1487 by Steve Dower in branch '3.5':
Issue #28846: Various installer fixes
https://hg.python.org/cpython/rev/68530c0a1487

New changeset 5171bd86a36f by Steve Dower in branch '3.6':
Issue #28846: Various installer fixes
https://hg.python.org/cpython/rev/5171bd86a36f

New changeset 014f52fe1da1 by Steve Dower in branch 'default':
Issue #28846: Various installer fixes
https://hg.python.org/cpython/rev/014f52fe1da1

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

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

From report at bugs.python.org  Sat Dec  3 15:15:04 2016
From: report at bugs.python.org (Steve Dower)
Date: Sat, 03 Dec 2016 20:15:04 +0000
Subject: [issue28846] Add a ProviderKey to the installer bundle
In-Reply-To: <1480550258.58.0.874105613934.issue28846@psf.upfronthosting.co.za>
Message-ID: <1480796104.23.0.679861400353.issue28846@psf.upfronthosting.co.za>


Steve Dower added the comment:

This bloated into a couple of extra build/installer fixes, including *finally* fixing the sys._mercurial bug (I hope). I can also now merge fairly cleanly between 3.5 and 3.6 again, so I'm happy for a while :)

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

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

From report at bugs.python.org  Sat Dec  3 15:48:45 2016
From: report at bugs.python.org (YoSTEALTH)
Date: Sat, 03 Dec 2016 20:48:45 +0000
Subject: [issue28861] Type Hints Syntax
Message-ID: <1480798125.09.0.140898215567.issue28861@psf.upfronthosting.co.za>


New submission from YoSTEALTH:

Type Hints Syntax
-----------------

Goal: Is to make it easy to read function/methods arguments, yet keep the new and cool Type Hints.

For example this is a code from one of my function. Its getting to that point of what the heck is going on here?

def find_replace(string: str, find: (str, dict, list, tuple, set), replace: (str, list, tuple, set)='') -> str:
    pass

I know it can be rewritten as:

T = (str, dict, list, tuple, set)
def find_replace(string: str, find: T, replace: T='') -> str:
    pass

But when you start using variable to represent another variables type... maybe we are losing the plot here!

What if we could have both? Readability and type reference, what if it could be written as:

def find_replace(string, find, replace):
    targ str, *(str, dict, list, tuple, set) -> str
    # code here ...

targ = type argument (like *args and **kwargs)

Calling a "targ" like we call "global" but to represent types.

Simple Examples:

def Redirect(url='', code=301):
    targ (str, int) -> None


Just think about it...

----------
messages: 282304
nosy: YoSTEALTH
priority: normal
severity: normal
status: open
title: Type Hints Syntax
type: enhancement

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

From report at bugs.python.org  Sat Dec  3 16:32:18 2016
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 03 Dec 2016 21:32:18 +0000
Subject: [issue28862] test_import.py leaks on 2.7
Message-ID: <1480800738.41.0.861957002748.issue28862@psf.upfronthosting.co.za>


New submission from Benjamin Peterson:

It looks like the test if not the fix for #15578 reveals a reference leak somewhere in the import system:

$ ./python Lib/test/regrtest.py -R :: test_import
[1/1] test_import
beginning 9 repetitions
123456789
.........
test_import leaked [1, 1, 1, 1] references, sum=4
Warning -- sys.path was modified by test_import
1 test failed:
    test_import
[57131 refs]

----------
messages: 282305
nosy: benjamin.peterson, eric.snow
priority: normal
severity: normal
status: open
title: test_import.py leaks on 2.7
versions: Python 2.7

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

From report at bugs.python.org  Sat Dec  3 16:45:09 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 03 Dec 2016 21:45:09 +0000
Subject: [issue28862] test_import.py leaks on 2.7
In-Reply-To: <1480800738.41.0.861957002748.issue28862@psf.upfronthosting.co.za>
Message-ID: <1480801509.05.0.622541334335.issue28862@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Following patch fixes a warning. I didn't run the test in debug mode, but suppose that the leak also is fixed.

----------
keywords: +patch
nosy: +serhiy.storchaka
stage:  -> patch review
Added file: http://bugs.python.org/file45742/test_import-leak-2.7.patch

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

From report at bugs.python.org  Sat Dec  3 16:48:05 2016
From: report at bugs.python.org (Marco Buttu)
Date: Sat, 03 Dec 2016 21:48:05 +0000
Subject: [issue28863] Doc/includes/*.py files and doctests
Message-ID: <1480801685.13.0.102040139052.issue28863@psf.upfronthosting.co.za>


New submission from Marco Buttu:

In the Doc/includes directory, some of the *.py file names have a dash character. For instance: Doc/includes/tzinfo-examples.py. I am trying to make all of the code examples pass the doctests, and I usually need to import from these files some code. Importing from these modules also allow us to test them, and I think that is important because their code is included in the documentation.

There are two problems:

1) I can not directly import them, because of the - character, so I have to use __import__('file-name') and write other ugly tricks. I can import them in the setuptests, so the reader will not see these imports, but it is still ugly, and in addition the code examples will be not complete, and the reader will not be able to try the code

2) the dash in the file names is un-pythonic. As the PEP 0008 says, the preferred way is to use underscores: "Modules should have short, all-lowercase names. Underscores can be used in the module name if it improves readability."

In conclusion, I propose to change the Doc/includes/*.py file names, replacing the dash character with an underscore. If you agree, I will do it step by step: I will change each file name only when I will work with the related documentation and code examples. 

PS. To include these files in the code examples, I also need to add the Doc/includes directory to the sys.path (in conf.py).

----------
assignee: docs at python
components: Documentation
messages: 282307
nosy: docs at python, marco.buttu
priority: normal
severity: normal
status: open
title: Doc/includes/*.py files and doctests
type: enhancement
versions: Python 3.7

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

From report at bugs.python.org  Sat Dec  3 18:08:28 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 03 Dec 2016 23:08:28 +0000
Subject: [issue28754] Argument Clinic for bisect.bisect_left
In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za>
Message-ID: <1480806508.79.0.841126709584.issue28754@psf.upfronthosting.co.za>


Martin Panter added the comment:

Fair enough, I don?t really mind if it is (lo=0, hi=None). I think I have only used bisect with both defaults anyway.

----------

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

From report at bugs.python.org  Sat Dec  3 18:15:24 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 03 Dec 2016 23:15:24 +0000
Subject: [issue27200] make doctest in CPython has failures
In-Reply-To: <1464988408.0.0.840317371896.issue27200@psf.upfronthosting.co.za>
Message-ID: <1480806924.88.0.368070707043.issue27200@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

#28860 has a patch for configparser.  Jelle, if you have more patches for some of the items listed above, please upload them so Marco can focus on the others.

----------
dependencies: +Fixed all the doctest failures in Doc/library/configparser.rst
nosy: +terry.reedy

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

From report at bugs.python.org  Sat Dec  3 18:19:33 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 03 Dec 2016 23:19:33 +0000
Subject: [issue27200] make doctest in CPython has failures
In-Reply-To: <1464988408.0.0.840317371896.issue27200@psf.upfronthosting.co.za>
Message-ID: <1480807173.98.0.389381517158.issue27200@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

#10225, still open, has a old 3.2 patch that might be useful.  If it is not, it should be closed.  Note that Raymond does not like the patch for the sorting help doc.

----------

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

From report at bugs.python.org  Sat Dec  3 18:26:19 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 03 Dec 2016 23:26:19 +0000
Subject: [issue28860] Fixed all the doctest failures in
 Doc/library/configparser.rst
In-Reply-To: <1480717712.23.0.651677304063.issue28860@psf.upfronthosting.co.za>
Message-ID: <1480807579.44.0.667772954081.issue28860@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Marco, thank you for adding more energy to improving the docs. #27200 is the master issue for fixing failing doc doctests.  The goal is to be able to have a buildbot run 'make doctest' or the Windows equivalent and expect success.

For this issue, I mildly agree with Brett.  Adding sorted is something a user might do.  But I am curious what policy Zack followed for the other 9 patches.

----------
nosy: +terry.reedy, zach.ware

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

From report at bugs.python.org  Sat Dec  3 18:27:48 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 03 Dec 2016 23:27:48 +0000
Subject: [issue28860] Fixed all the doctest failures in
 Doc/library/configparser.rst
In-Reply-To: <1480717712.23.0.651677304063.issue28860@psf.upfronthosting.co.za>
Message-ID: <1480807668.32.0.902443042494.issue28860@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

For some reason, not obvious to me, these patches cannot be reviewed on Rietveld.

----------

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

From report at bugs.python.org  Sat Dec  3 20:40:01 2016
From: report at bugs.python.org (YoSTEALTH)
Date: Sun, 04 Dec 2016 01:40:01 +0000
Subject: [issue28861] Type Hints Syntax
In-Reply-To: <1480798125.09.0.140898215567.issue28861@psf.upfronthosting.co.za>
Message-ID: <1480815601.06.0.405295586244.issue28861@psf.upfronthosting.co.za>


YoSTEALTH added the comment:

I was told to post this in python-ideas and also i totally missed the most important part (type aliases) in my example (rushed it)

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

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

From report at bugs.python.org  Sat Dec  3 22:36:35 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 04 Dec 2016 03:36:35 +0000
Subject: [issue28864] Add devnull file-like object
Message-ID: <1480822595.87.0.853337900572.issue28864@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Uses cases are the same as /dev/null:

with redirect_stderr(io.DevNull()):
    some_func_using_stdout_and_stderr()

----------
messages: 282314
nosy: ncoghlan, pitrou, rhettinger
priority: low
severity: normal
status: open
title: Add devnull file-like object
type: enhancement
versions: Python 3.7

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

From report at bugs.python.org  Sun Dec  4 00:30:32 2016
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 04 Dec 2016 05:30:32 +0000
Subject: [issue28860] Fixed all the doctest failures in
 Doc/library/configparser.rst
In-Reply-To: <1480717712.23.0.651677304063.issue28860@psf.upfronthosting.co.za>
Message-ID: <1480829432.41.0.321999910155.issue28860@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Indeed, thank you Marco for continuing this work!

The patches that I committed [1] were mostly done by Jelle Zijlstra.  There were not many tests that had dict ordering issues; but it looks like we used sorted() rather than list() in a few places.  I think using sorted() here is fine as well (though for the third one, I'd recommend turning the list comprehension into a generator expression argument to sorted, rather than sticking sorted() in the middle of the listcomp).

As far as why these patches are not compatible with Rietveld, they appear to have been generated by `diff` between two discrete files rather than by `hg diff` or `git diff`, and Reitveld can't find the files as named to be able to apply the patch.


[1] Viewable in aggregate here: https://hg.python.org/cpython/rev/769355e031:d0302d8ecbc1

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

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

From report at bugs.python.org  Sun Dec  4 01:13:35 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 04 Dec 2016 06:13:35 +0000
Subject: [issue28864] Add devnull file-like object
In-Reply-To: <1480822595.87.0.853337900572.issue28864@psf.upfronthosting.co.za>
Message-ID: <1480832015.14.0.105521522391.issue28864@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

If you need true file object, with name, fileno() etc, you can use open(os.devnull, 'w'). If the simple file-like object is enough, it is just few lines:

    class NullWriter:
        def write(self, s): pass

io.StringIO() works in most cases well too.

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

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

From report at bugs.python.org  Sun Dec  4 01:47:54 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 04 Dec 2016 06:47:54 +0000
Subject: [issue23722] During metaclass.__init__,
 super() of the constructed class does not work
In-Reply-To: <1426859061.43.0.510286082444.issue23722@psf.upfronthosting.co.za>
Message-ID: <1480834074.15.0.65363246825.issue23722@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

This latest patch restores the behaviour where a reference to the class cell is returned from the class-defining closure.

That restoration allows __build_class__ to implement a sanity check that ensures that the class referenced from the cell is the one that was just defined, and complain if they don't match.

To give metaclasses like the Django one a chance to adjust, not setting it at all is just a deprecation warning for 3.6, while setting it incorrectly is a TypeError.

----------
stage: needs patch -> commit review
versions: +Python 3.6, Python 3.7 -Python 3.5
Added file: http://bugs.python.org/file45743/issue23722_classcell_reference_validation.diff

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

From report at bugs.python.org  Sun Dec  4 01:49:25 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 04 Dec 2016 06:49:25 +0000
Subject: [issue23722] During metaclass.__init__,
 super() of the constructed class does not work
In-Reply-To: <1426859061.43.0.510286082444.issue23722@psf.upfronthosting.co.za>
Message-ID: <1480834165.02.0.547643600175.issue23722@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Reassigning to Ned for now, pending finding another commit reviewer.

----------
assignee: ncoghlan -> ned.deily

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

From report at bugs.python.org  Sun Dec  4 01:51:20 2016
From: report at bugs.python.org (Nagarjuna Arigapudi)
Date: Sun, 04 Dec 2016 06:51:20 +0000
Subject: [issue28857] SyncManager and Main Process fail to communicate after
 reboot or stoping with Ctrl - C
In-Reply-To: <1480660972.34.0.757124295552.issue28857@psf.upfronthosting.co.za>
Message-ID: <1480834280.13.0.0858969515081.issue28857@psf.upfronthosting.co.za>


Nagarjuna Arigapudi added the comment:

I  added logs just to provide additional info. The problem is one of the process uses " /tmp/pymp-xTqdkd" for communication and other uses "/tmp/pymp-LOMHoT/listener-EbLeup". because of mismatch porcesse could communicate and multiprocess application shuts down, with message "process shutting down". The files/directories (temporary files in tmp) are not user defined, they are generated by Python.

This behavior is seen only after a running application is sent  (Ctrl C) or the server is rebooted while application is running. In Simple terms non-clean shutdown of application make application not runnable, because synchronization of multiprocess gets corrupted, rebooting or clearing /tmp does not fix the issue. 

Relevent Logs (both SyncManager-1 and MainProcess) is python code ( in multiprocessing package/module).


[INFO/SyncManager-1] created temp directory /tmp/pymp-xTqdkd

[DEBUG/MainProcess] failed to connect to address /tmp/pymp-LOMHoT/listener-EbLeup


This results in File not found error, and application shuts down.
The code in multiprocessing should be using same directory for communication.

Thanks

----------

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

From report at bugs.python.org  Sun Dec  4 01:52:20 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 04 Dec 2016 06:52:20 +0000
Subject: [issue23722] During metaclass.__init__,
 super() of the constructed class does not work
In-Reply-To: <1426859061.43.0.510286082444.issue23722@psf.upfronthosting.co.za>
Message-ID: <1480834340.19.0.357459080208.issue23722@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

In the meantime, I'll try to work out a suitable documentation patch.

----------

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

From report at bugs.python.org  Sun Dec  4 02:13:13 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 04 Dec 2016 07:13:13 +0000
Subject: [issue28797] Modifying class __dict__ inside __set_name__
In-Reply-To: <1480042109.13.0.341330811366.issue28797@psf.upfronthosting.co.za>
Message-ID: <1480835593.85.0.727679425345.issue28797@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Regarding the docs suggestion above, I need to make some other docs changes for issue 23722, so I'll roll that update in with those.

Given that, I think we can mark this issue as resolved.

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

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

From report at bugs.python.org  Sun Dec  4 02:17:13 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 04 Dec 2016 07:17:13 +0000
Subject: [issue28862] test_import.py leaks on 2.7
In-Reply-To: <1480800738.41.0.861957002748.issue28862@psf.upfronthosting.co.za>
Message-ID: <20161204071710.28700.46052.C28F38CF@psf.io>


Roundup Robot added the comment:

New changeset 6e9939e1f933 by Benjamin Peterson in branch '2.7':
simplify cleanup of test_replace_parent_in_sys_modules (closes #28862)
https://hg.python.org/cpython/rev/6e9939e1f933

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

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

From report at bugs.python.org  Sun Dec  4 02:19:00 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Sun, 04 Dec 2016 07:19:00 +0000
Subject: [issue23722] During metaclass.__init__,
 super() of the constructed class does not work
In-Reply-To: <1426859061.43.0.510286082444.issue23722@psf.upfronthosting.co.za>
Message-ID: <1480835940.39.0.343414269865.issue23722@psf.upfronthosting.co.za>


Changes by Emanuel Barry <barry at dadadata.net>:


----------
nosy: +ebarry

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

From report at bugs.python.org  Sun Dec  4 02:28:21 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 04 Dec 2016 07:28:21 +0000
Subject: [issue23722] During metaclass.__init__,
 super() of the constructed class does not work
In-Reply-To: <1426859061.43.0.510286082444.issue23722@psf.upfronthosting.co.za>
Message-ID: <1480836501.75.0.530181334414.issue23722@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Attached patch covers the proposed documentation updates.

----------
Added file: http://bugs.python.org/file45744/issue23722_documentation_updates.diff

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

From report at bugs.python.org  Sun Dec  4 03:49:27 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 04 Dec 2016 08:49:27 +0000
Subject: [issue23722] During metaclass.__init__,
 super() of the constructed class does not work
In-Reply-To: <1426859061.43.0.510286082444.issue23722@psf.upfronthosting.co.za>
Message-ID: <1480841367.89.0.251534543563.issue23722@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I should have made my comments a bit clearer as to which patches they were referring to. The ones submitted for inclusion in 3.6.0rc1 are:

* issue23722_classcell_reference_validation.diff (the compatibility fix)
* issue23722_documentation_updates.diff (the related docs updates)

----------

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

From report at bugs.python.org  Sun Dec  4 04:23:17 2016
From: report at bugs.python.org (Marco Buttu)
Date: Sun, 04 Dec 2016 09:23:17 +0000
Subject: [issue28860] Fixed all the doctest failures in
 Doc/library/configparser.rst
In-Reply-To: <1480717712.23.0.651677304063.issue28860@psf.upfronthosting.co.za>
Message-ID: <1480843397.91.0.356463782433.issue28860@psf.upfronthosting.co.za>


Marco Buttu added the comment:

Here is a 3rd patch. I used a generator expression argument to ``sorted()``, as recommend by Zachary. Thank you very much for all your suggestions

----------
Added file: http://bugs.python.org/file45745/configparser3rd.patch

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

From report at bugs.python.org  Sun Dec  4 05:07:52 2016
From: report at bugs.python.org (Marco Buttu)
Date: Sun, 04 Dec 2016 10:07:52 +0000
Subject: [issue28863] Doc/includes/*.py files and doctests
In-Reply-To: <1480801685.13.0.102040139052.issue28863@psf.upfronthosting.co.za>
Message-ID: <1480846072.92.0.0386562199821.issue28863@psf.upfronthosting.co.za>


Marco Buttu added the comment:

Here is the patch for the Sphinx conf.py file.

----------
keywords: +patch
Added file: http://bugs.python.org/file45746/conf.py.patch

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

From report at bugs.python.org  Sun Dec  4 05:25:25 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 04 Dec 2016 10:25:25 +0000
Subject: [issue24329] __qualname__ and __slots__
In-Reply-To: <1432930157.09.0.507147768187.issue24329@psf.upfronthosting.co.za>
Message-ID: <1480847125.41.0.572084517668.issue24329@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Nick, could you please look at the patch? Especially at the part about __classcell__.

----------
nosy: +ncoghlan

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

From report at bugs.python.org  Sun Dec  4 05:26:01 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 04 Dec 2016 10:26:01 +0000
Subject: [issue23722] During metaclass.__init__,
 super() of the constructed class does not work
In-Reply-To: <1426859061.43.0.510286082444.issue23722@psf.upfronthosting.co.za>
Message-ID: <1480847161.61.0.355422648467.issue23722@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Added comments on Rietveld.

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

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

From report at bugs.python.org  Sun Dec  4 05:42:25 2016
From: report at bugs.python.org (Julien Palard)
Date: Sun, 04 Dec 2016 10:42:25 +0000
Subject: [issue28692] gettext: deprecate selecting plural form by fractional
 numbers
In-Reply-To: <1479148679.54.0.229445108959.issue28692@psf.upfronthosting.co.za>
Message-ID: <1480848145.95.0.2473286983.issue28692@psf.upfronthosting.co.za>


Julien Palard added the comment:

> But gettext formulas are not purposed to support non-integer values and can return incorrect result

Looks like the cast to integer is done *before* giving the value to the C gettext expression.

> For example (in Ukrainian)

As long as gettext expression don't support non-integer values, there exist *no* way to support two languages where plural form differ for non-integer value. Typically if a language A consider 1.5 to be singular and another language B consider 1.5 to be plural, the only place in the code that can make the difference IS in the C plural expression which don't support non-integer values.

Rouding the value before giving it to ngettext only fixes the issue for the lang of the current developer, as for other languages, translators won't be able to change the rounding properties.

But should we bet that in most, any, or all languages, 1.5 is considered plural? I think so, according to wikipedia?: "Plural of nouns typically denote a quantity other than the default quantity represented by a noun, which is generally one."

So, I think that a better fix than warning for non-integer values may be to round them using math.ceil instead of round. This way we avoid developpers to drop round() everywhere to fix the warning the wrong way, leaving the same bug you're having in Ukrainian.

?: https://en.wikipedia.org/wiki/Plural

----------

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

From report at bugs.python.org  Sun Dec  4 05:53:43 2016
From: report at bugs.python.org (Marco Buttu)
Date: Sun, 04 Dec 2016 10:53:43 +0000
Subject: [issue27200] make doctest in CPython has failures
In-Reply-To: <1464988408.0.0.840317371896.issue27200@psf.upfronthosting.co.za>
Message-ID: <1480848823.99.0.540966385129.issue27200@psf.upfronthosting.co.za>


Marco Buttu added the comment:

Here is a patch that makes all Doc/library/datetime.rst doctests pass. The tests only pass with Python 3.6 and 3.7 (the optional ``timespec`` argument of ``datetime.isoformat()`` has been introduced in Python 3.6).

To apply the patch you should agree with issue 28863. In particular, to make the patch effective, as explained in issue 28863, you should:

* apply the Doc/conf.py patch of issue 28863.
* rename Doc/includes/tzinfo-examples.py to Doc/includes/tzinfo_examples.py

About the Raymond disappointment expressed in #10225, I see two ways to make both Raymond happy and the code examples tested. For the examples included from Doc/includes, using the ``literalinclude`` Sphinx directive, we can just add the Doc/includes path in Doc/conf.py (see issue 28863). At this point we can import them in the shell code examples (or in the ``setupcode``). In the datetime.rst.patch in attachment, I make use of this solution. Another option, for short snippets of code, not included from Doc/includes, is to use the ``testcode`` Sphinx directive.

----------
keywords: +patch
nosy: +marco.buttu
Added file: http://bugs.python.org/file45747/datetime.rst.patch

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

From report at bugs.python.org  Sun Dec  4 06:54:52 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 04 Dec 2016 11:54:52 +0000
Subject: [issue28692] gettext: deprecate selecting plural form by fractional
 numbers
In-Reply-To: <1479148679.54.0.229445108959.issue28692@psf.upfronthosting.co.za>
Message-ID: <1480852492.57.0.0623263999387.issue28692@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

round() was used because it is the simplest way to convert fractional numbers to integers that doesn't involve strings-to-integer converting (as in int()). Perhaps math.trunc() looks a little more appropriate. math.ceil() returns a float in 2.7 and is limited by float range. But "1.678 second" don't look more correct than "1.678 seconds". My point is that gettext ability of selecting plural form shouldn't be used for fractional numbers. It seems to me that a fractional number should be formatted with the same form independently from it's value (it can be different from plural forms for integer numbers). Proposed patch adds a deprecating warning for encouraging users to rewrite their code for formatting fractional numbers.

----------

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

From report at bugs.python.org  Sun Dec  4 07:00:57 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 04 Dec 2016 12:00:57 +0000
Subject: [issue24329] __qualname__ and __slots__
In-Reply-To: <1432930157.09.0.507147768187.issue24329@psf.upfronthosting.co.za>
Message-ID: <1480852857.71.0.0229535277647.issue24329@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

"__classcell__" in __slots__ doesn't really make sense, as unlike __qualname__ (which turns into a real class level attribute and can be useful to override on instances), it's only a transient entry in a class definition namespace - types.__new__ pops it automatically so it doesn't get turned into an attribute.

However, consistency is a good thing, so allowing it seems reasonable.

Regarding the specifics, the pending patch on issue 23722 makes it a TypeError to ever set __classcell__ to anything other than a real cell object.

----------

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

From report at bugs.python.org  Sun Dec  4 07:04:05 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 04 Dec 2016 12:04:05 +0000
Subject: [issue24329] __qualname__ and __slots__
In-Reply-To: <1432930157.09.0.507147768187.issue24329@psf.upfronthosting.co.za>
Message-ID: <1480853045.5.0.130905312982.issue24329@psf.upfronthosting.co.za>


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


----------
dependencies: +During metaclass.__init__, super() of the constructed class does not work

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

From report at bugs.python.org  Sun Dec  4 07:14:37 2016
From: report at bugs.python.org (Mikhail)
Date: Sun, 04 Dec 2016 12:14:37 +0000
Subject: [issue28865] [MinGW32-x64]-PyList_Check PyDict_Check does not work
Message-ID: <1480853677.86.0.114330805471.issue28865@psf.upfronthosting.co.za>


New submission from Mikhail:

Windows 10 x64
Python 3.4, 3.5, Anaconda3 4.2  - x64
SWIG 3.0.8, 3.0.10
MinGW32/64  - TDM-GCC-64 5.1.0-2, x86_64-5.3.0-win32-sjlj-rt_v4-rev0, x86_64-6.2.0-win32-sjlj-rt_v5-rev1  

The code in C compiles fine, there are no warnings. But then, in the finished module, do not work C-API functions such as:

PyList_Check
PyDict_Check
PyDict_Next

PyObject *result = PyList_New(1);
printf("%i \n", PyList_Check(result));

Check always returns zero, even if the object is created in the previous line.
But PyMapping_Check works fine

----------
components: Build, Distutils, Windows
messages: 282333
nosy: dstufft, eric.araujo, mifik, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: [MinGW32-x64]-PyList_Check PyDict_Check does not work
type: resource usage
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun Dec  4 07:40:33 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 04 Dec 2016 12:40:33 +0000
Subject: [issue28865] [MinGW32-x64]-PyList_Check PyDict_Check does not work
In-Reply-To: <1480853677.86.0.114330805471.issue28865@psf.upfronthosting.co.za>
Message-ID: <1480855233.78.0.271093539398.issue28865@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could you please provide a complete C file that is compiled?

Output also PyType_GetFlags(Py_TYPE(result)). And check that result is not NULL.

----------
nosy: +serhiy.storchaka
versions:  -Python 3.4

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

From report at bugs.python.org  Sun Dec  4 07:43:29 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 04 Dec 2016 12:43:29 +0000
Subject: [issue23722] During metaclass.__init__,
 super() of the constructed class does not work
In-Reply-To: <1426859061.43.0.510286082444.issue23722@psf.upfronthosting.co.za>
Message-ID: <1480855409.73.0.665231833036.issue23722@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Updated patch for Serhiy's review comments: issue23722_classcell_reference_validation_v2.diff

- avoids a spurious deprecation warning for metaclasses that don't return a type() instance at all
- avoids even the appearance of a refleak in the __build_class__ fallback code
- integrates the documentation into the main patch

----------
Added file: http://bugs.python.org/file45748/issue23722_classcell_reference_validation_v2.diff

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

From report at bugs.python.org  Sun Dec  4 07:56:50 2016
From: report at bugs.python.org (John Helour)
Date: Sun, 04 Dec 2016 12:56:50 +0000
Subject: [issue24339] iso6937 encoding missing
In-Reply-To: <1433078403.47.0.568019085367.issue24339@psf.upfronthosting.co.za>
Message-ID: <1480856210.61.0.184436873288.issue24339@psf.upfronthosting.co.za>


Changes by John Helour <helourx at gmail.com>:


Added file: http://bugs.python.org/file45749/check_iso6937.py

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

From report at bugs.python.org  Sun Dec  4 07:57:08 2016
From: report at bugs.python.org (John Helour)
Date: Sun, 04 Dec 2016 12:57:08 +0000
Subject: [issue24339] iso6937 encoding missing
In-Reply-To: <1433078403.47.0.568019085367.issue24339@psf.upfronthosting.co.za>
Message-ID: <1480856228.01.0.85766055455.issue24339@psf.upfronthosting.co.za>


Changes by John Helour <helourx at gmail.com>:


Removed file: http://bugs.python.org/file45740/iso6937.py

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

From report at bugs.python.org  Sun Dec  4 07:59:05 2016
From: report at bugs.python.org (John Helour)
Date: Sun, 04 Dec 2016 12:59:05 +0000
Subject: [issue24339] iso6937 encoding missing
In-Reply-To: <1433078403.47.0.568019085367.issue24339@psf.upfronthosting.co.za>
Message-ID: <1480856345.2.0.266426746824.issue24339@psf.upfronthosting.co.za>


Changes by John Helour <helourx at gmail.com>:


Added file: http://bugs.python.org/file45750/iso6937.py

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

From report at bugs.python.org  Sun Dec  4 08:00:21 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 04 Dec 2016 13:00:21 +0000
Subject: [issue23722] During metaclass.__init__,
 super() of the constructed class does not work
In-Reply-To: <1426859061.43.0.510286082444.issue23722@psf.upfronthosting.co.za>
Message-ID: <1480856421.4.0.753501757372.issue23722@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Assuming there are no further comments overnight, I'll go ahead and commit this tomorrow (after doing a local refleak hunting run).

----------

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

From report at bugs.python.org  Sun Dec  4 08:14:14 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 04 Dec 2016 13:14:14 +0000
Subject: [issue23722] During metaclass.__init__,
 super() of the constructed class does not work
In-Reply-To: <1426859061.43.0.510286082444.issue23722@psf.upfronthosting.co.za>
Message-ID: <1480857254.92.0.726607743271.issue23722@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Added two more style comments. And please take note of my comments to issue23722_documentation_updates.diff. Nothing critical, but would be nice to add more cross-references in the documentation.

----------

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

From report at bugs.python.org  Sun Dec  4 08:15:09 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 04 Dec 2016 13:15:09 +0000
Subject: [issue24339] iso6937 encoding missing
In-Reply-To: <1433078403.47.0.568019085367.issue24339@psf.upfronthosting.co.za>
Message-ID: <1480857309.15.0.290519807886.issue24339@psf.upfronthosting.co.za>


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


----------
assignee:  -> serhiy.storchaka
priority: normal -> low

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

From report at bugs.python.org  Sun Dec  4 08:17:35 2016
From: report at bugs.python.org (John Helour)
Date: Sun, 04 Dec 2016 13:17:35 +0000
Subject: [issue24339] iso6937 encoding missing
In-Reply-To: <1433078403.47.0.568019085367.issue24339@psf.upfronthosting.co.za>
Message-ID: <1480857455.59.0.360544353136.issue24339@psf.upfronthosting.co.za>


John Helour added the comment:

Performance issue resolved, more info on error added.

I've checked encoding and decoding on a two UTF-8 ~3MiB txt files. Except the first BOM mark (May I ignore it?) all seems work OK.

----------

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

From report at bugs.python.org  Sun Dec  4 08:35:00 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Sun, 04 Dec 2016 13:35:00 +0000
Subject: [issue28596] on Android _bootlocale on startup relies on too many
 library modules
In-Reply-To: <1478166520.26.0.975749703987.issue28596@psf.upfronthosting.co.za>
Message-ID: <1480858500.88.0.737455531064.issue28596@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

Patch version 3, using sys.getandroidapilevel()

----------
Added file: http://bugs.python.org/file45751/android-locale-utf8.patch

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

From report at bugs.python.org  Sun Dec  4 09:12:03 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNC60YHQuNC8INCb0YPQutC+0Y/QvdC+0LI=?=)
Date: Sun, 04 Dec 2016 14:12:03 +0000
Subject: [issue27305] Crash with "pip list --outdated" on Windows 10 with
 Python 2.7.12rc1
In-Reply-To: <1465820074.65.0.989290191732.issue27305@psf.upfronthosting.co.za>
Message-ID: <1480860723.63.0.138425095804.issue27305@psf.upfronthosting.co.za>


?????? ???????? added the comment:

>>> import sys
>>> print sys.version
2.7.12 (v2.7.12:d33e0cf91556, Jun 27 2016, 15:24:40) [MSC v.1500 64 bit (AMD64)]
>>> from urllib2 import urlopen
>>> urlopen('http://www.google.co.uk')

Traceback (most recent call last):
  File "<pyshell#2>", line 1, in <module>
    urlopen('http://www.google.co.uk')
  File "C:\Python27x64\lib\urllib2.py", line 154, in urlopen
    return opener.open(url, data, timeout)
  File "C:\Python27x64\lib\urllib2.py", line 435, in open
    response = meth(req, response)
  File "C:\Python27x64\lib\urllib2.py", line 548, in http_response
    'http', request, response, code, msg, hdrs)
  File "C:\Python27x64\lib\urllib2.py", line 467, in error
    result = self._call_chain(*args)
  File "C:\Python27x64\lib\urllib2.py", line 407, in _call_chain
    result = func(*args)
  File "C:\Python27x64\lib\urllib2.py", line 654, in http_error_302
    return self.parent.open(new, timeout=req.timeout)
  File "C:\Python27x64\lib\urllib2.py", line 435, in open
    response = meth(req, response)
  File "C:\Python27x64\lib\urllib2.py", line 548, in http_response
    'http', request, response, code, msg, hdrs)
  File "C:\Python27x64\lib\urllib2.py", line 473, in error
    return self._call_chain(*args)
  File "C:\Python27x64\lib\urllib2.py", line 407, in _call_chain
    result = func(*args)
  File "C:\Python27x64\lib\urllib2.py", line 556, in http_error_default
    raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
HTTPError: HTTP Error 503: Service Unavailable
>>> urlopen('https://www.google.co.uk')

=============================== RESTART: Shell ===============================

----------

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

From report at bugs.python.org  Sun Dec  4 09:23:09 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNC60YHQuNC8INCb0YPQutC+0Y/QvdC+0LI=?=)
Date: Sun, 04 Dec 2016 14:23:09 +0000
Subject: [issue27305] Crash with "pip list --outdated" on Windows 10 with
 Python 2.7.12rc1
In-Reply-To: <1465820074.65.0.989290191732.issue27305@psf.upfronthosting.co.za>
Message-ID: <1480861389.17.0.569035277323.issue27305@psf.upfronthosting.co.za>


?????? ???????? added the comment:

>>> import platform
>>> platform.platform()
'Windows-10-10.0.14393'

----------

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

From report at bugs.python.org  Sun Dec  4 09:31:10 2016
From: report at bugs.python.org (Julien Palard)
Date: Sun, 04 Dec 2016 14:31:10 +0000
Subject: [issue28692] gettext: deprecate selecting plural form by fractional
 numbers
In-Reply-To: <1479148679.54.0.229445108959.issue28692@psf.upfronthosting.co.za>
Message-ID: <1480861870.78.0.312882718272.issue28692@psf.upfronthosting.co.za>


Julien Palard added the comment:

> It seems to me that a fractional number should be formatted with the same form independently from it's value

Ok, so 1.000 seconds, ok, LGTM.

Should we mention something explicit about it? Not sure how to write it down, but I still fear that everyone's reaction will be "Oh can't give a float? Let my put a round() in my call" and stay with the same plural bug as before.

Maybe replace

> Plural value must be an integer

by

> Should not use ngettext with floating point, consider an invariant form.

?

----------

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

From report at bugs.python.org  Sun Dec  4 09:33:09 2016
From: report at bugs.python.org (Steve Dower)
Date: Sun, 04 Dec 2016 14:33:09 +0000
Subject: [issue27305] Crash with "pip list --outdated" on Windows 10 with
 Python 2.7.12rc1
In-Reply-To: <1465820074.65.0.989290191732.issue27305@psf.upfronthosting.co.za>
Message-ID: <1480861989.52.0.729805197055.issue27305@psf.upfronthosting.co.za>


Steve Dower added the comment:

Since it's not crashing, it is different from this issue. You should open a new bug.

----------

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

From report at bugs.python.org  Sun Dec  4 09:35:45 2016
From: report at bugs.python.org (sjpalt)
Date: Sun, 04 Dec 2016 14:35:45 +0000
Subject: [issue28866] Unexpected behavior resulting from mro() and __setattr__
 in interactive mode
Message-ID: <1480862145.72.0.468660451957.issue28866@psf.upfronthosting.co.za>


New submission from sjpalt:

I ran into a strange bug while experimenting with metaclasses that implement a custom mro() method. It only seems to occur in interactive mode, either returning completely unrelated values or causing a segfault. Python 2 appears unaffected. I have been able to reproduce this with the following code:

# $ python -i weird.py
# >>> proxy.x
# 52011448
# >>> proxy.x
# 6160
# ...

class Foo:
    pass

class Meta(type):
    def mro(cls):
        return (cls, Foo, object)

    def __setattr__(cls, name, value):
        setattr(Foo, name, value)

proxy = Meta('FooProxy', (), {})

proxy.x = 300
proxy.x  # don't omit
proxy.x = 0

----------
components: Interpreter Core
files: weird.py
messages: 282344
nosy: sjpalt
priority: normal
severity: normal
status: open
title: Unexpected behavior resulting from mro() and __setattr__ in interactive mode
type: crash
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file45752/weird.py

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

From report at bugs.python.org  Sun Dec  4 10:00:05 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 04 Dec 2016 15:00:05 +0000
Subject: [issue28866] Unexpected behavior resulting from mro() and __setattr__
 in interactive mode
In-Reply-To: <1480862145.72.0.468660451957.issue28866@psf.upfronthosting.co.za>
Message-ID: <1480863605.76.0.328622702289.issue28866@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Python 2 is affected if make Foo a new style class.

----------
nosy: +serhiy.storchaka
priority: normal -> high
versions: +Python 3.6, Python 3.7 -Python 3.4

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

From report at bugs.python.org  Sun Dec  4 10:11:02 2016
From: report at bugs.python.org (Julien Palard)
Date: Sun, 04 Dec 2016 15:11:02 +0000
Subject: [issue28707] add 'directory' option to the http.server module
In-Reply-To: <1479249109.08.0.530385659795.issue28707@psf.upfronthosting.co.za>
Message-ID: <1480864262.8.0.138863144015.issue28707@psf.upfronthosting.co.za>


Julien Palard added the comment:

@Victor you're right, I forgot that partial can also apply keyword arguments. Here is a new patch.

----------
Added file: http://bugs.python.org/file45753/issue28707.diff

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

From report at bugs.python.org  Sun Dec  4 10:18:58 2016
From: report at bugs.python.org (Mikhail)
Date: Sun, 04 Dec 2016 15:18:58 +0000
Subject: [issue28865] [MinGW32-x64]-PyList_Check PyDict_Check does not work
In-Reply-To: <1480853677.86.0.114330805471.issue28865@psf.upfronthosting.co.za>
Message-ID: <1480864738.67.0.0731250687911.issue28865@psf.upfronthosting.co.za>


Mikhail added the comment:

Project included.


building output in the console:

running build_ext
building '_PyAPITests' extension
swigging PyAPITests.i to PyAPITests_wrap.c
z:\PortableApps\MyApps\Dev\SWIGWin\swigwin-3.0.10\swig.exe -python -py3 -o PyAPITests_wrap.c PyAPITests.i
z:\PortableApps\MyApps\Dev\mingw64\x86_64-6.2.0-win32-sjlj-rt_v5-rev1\mingw64\bin\gcc.exe -mdll -O -Wall -IZ:\PortableApps\MyApps\Dev\Python\Anaconda3\include -IZ:\PortableApps\MyApps\Dev\Python\Anaconda3\include -c PyAPITests_wrap.c -o build\temp.win-amd64-3.5\Release\pyapitests_wrap.o -std=c99
z:\PortableApps\MyApps\Dev\mingw64\x86_64-6.2.0-win32-sjlj-rt_v5-rev1\mingw64\bin\gcc.exe -mdll -O -Wall -IZ:\PortableApps\MyApps\Dev\Python\Anaconda3\include -IZ:\PortableApps\MyApps\Dev\Python\Anaconda3\include -c PyAPITests.c -o build\temp.win-amd64-3.5\Release\pyapitests.o -std=c99
writing build\temp.win-amd64-3.5\Release\_PyAPITests.cp35-win_amd64.def
z:\PortableApps\MyApps\Dev\mingw64\x86_64-6.2.0-win32-sjlj-rt_v5-rev1\mingw64\bin\gcc.exe -shared -s build\temp.win-amd64-3.5\Release\pyapitests_wrap.o build\temp.win-amd64-3.5\Release\pyapitests.o build\temp.win-amd64-3.5\Release\_PyAPITests.cp35-win_amd64.def -LZ:\PortableApps\MyApps\Dev\Python\Anaconda3\libs -LZ:\PortableApps\MyApps\Dev\Python\Anaconda3\PCbuild\amd64 -lpython35 -lvcruntime140 -o Z:\Projects\AI\PyAPITests\_PyAPITests.cp35-win_amd64.pyd


main output:

Start
TestIteration: 0 
tp_name for List: list 
tp_name for Dict: dict 
PyType_GetFlags for List: 34362368 
PyType_GetFlags for Dict: 537678848 
PyList_Size: 0 
PyDict_Size: 0 
PyMapping_Check for List: 1 
PyMapping_Check for Dict: 1 
PyList_Check: 0 
PyDict_Check: 0 
Iterators test for Dict:

End iterators test.
-----------------
TestIteration: 1 
tp_name for List: list 
tp_name for Dict: dict 
PyType_GetFlags for List: 34362368 
PyType_GetFlags for Dict: 537678848 
PyList_Size: 1 
PyDict_Size: 1 
PyMapping_Check for List: 1 
PyMapping_Check for Dict: 1 
PyList_Check: 0 
PyDict_Check: 0 
Iterators test for Dict:

End iterators test.
-----------------
TestIteration: 2 
tp_name for List: list 
tp_name for Dict: dict 
PyType_GetFlags for List: 34362368 
PyType_GetFlags for Dict: 537678848 
PyList_Size: 2 
PyDict_Size: 2 
PyMapping_Check for List: 1 
PyMapping_Check for Dict: 1 
PyList_Check: 0 
PyDict_Check: 0 
Iterators test for Dict:

End iterators test.
-----------------
ReturnedResult: 3
End

----------
Added file: http://bugs.python.org/file45754/PyAPITests.zip

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

From report at bugs.python.org  Sun Dec  4 10:21:03 2016
From: report at bugs.python.org (Julien Palard)
Date: Sun, 04 Dec 2016 15:21:03 +0000
Subject: [issue28724] Add method send_io, recv_io to the socket module.
In-Reply-To: <1479395133.65.0.0720889900419.issue28724@psf.upfronthosting.co.za>
Message-ID: <1480864863.68.0.00135048431796.issue28724@psf.upfronthosting.co.za>


Julien Palard added the comment:

Unless somebody don't think so, I think this should go as a pypi module before going to the socket module, so this issue should probably be closed.

----------

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

From report at bugs.python.org  Sun Dec  4 10:40:23 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Sun, 04 Dec 2016 15:40:23 +0000
Subject: [issue28866] Unexpected behavior resulting from mro() and __setattr__
 in interactive mode
In-Reply-To: <1480862145.72.0.468660451957.issue28866@psf.upfronthosting.co.za>
Message-ID: <1480866023.57.0.632129537726.issue28866@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

Additionally, trying to access an attribute before assigning it will result in an AttributeError on all subsequent accesses (even if set).

I didn't manage to get a segfault, however.

----------
nosy: +ebarry

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

From report at bugs.python.org  Sun Dec  4 10:45:33 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 04 Dec 2016 15:45:33 +0000
Subject: [issue28866] Unexpected behavior resulting from mro() and __setattr__
 in interactive mode
In-Reply-To: <1480862145.72.0.468660451957.issue28866@psf.upfronthosting.co.za>
Message-ID: <1480866333.95.0.216474449537.issue28866@psf.upfronthosting.co.za>


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


----------
versions: +Python 2.7

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

From report at bugs.python.org  Sun Dec  4 11:11:20 2016
From: report at bugs.python.org (Julien Palard)
Date: Sun, 04 Dec 2016 16:11:20 +0000
Subject: [issue28754] Argument Clinic for bisect.bisect_left
In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za>
Message-ID: <1480867880.07.0.0818257680149.issue28754@psf.upfronthosting.co.za>


Julien Palard added the comment:

Hi Martin,

Historically (lo=0, hi=None) was the implementation (in Python), until the C implementation, which used (lo=0, hi=-1). As my implementation allows for -1 and None, I don't think I'm breaking something.

----------

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

From report at bugs.python.org  Sun Dec  4 11:49:29 2016
From: report at bugs.python.org (Julien Palard)
Date: Sun, 04 Dec 2016 16:49:29 +0000
Subject: [issue24339] iso6937 encoding missing
In-Reply-To: <1433078403.47.0.568019085367.issue24339@psf.upfronthosting.co.za>
Message-ID: <1480870169.9.0.0600813416491.issue24339@psf.upfronthosting.co.za>


Julien Palard added the comment:

LGTM, for me it's time to release it as a package on pypi to check the adoption rate and see it it's worth adding it in Python and maybe close this issue.

----------

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

From report at bugs.python.org  Sun Dec  4 12:07:50 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 04 Dec 2016 17:07:50 +0000
Subject: [issue23722] During metaclass.__init__,
 super() of the constructed class does not work
In-Reply-To: <1426859061.43.0.510286082444.issue23722@psf.upfronthosting.co.za>
Message-ID: <1480871270.6.0.533399313969.issue23722@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
nosy:  -gvanrossum

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

From report at bugs.python.org  Sun Dec  4 12:47:27 2016
From: report at bugs.python.org (Jon Dufresne)
Date: Sun, 04 Dec 2016 17:47:27 +0000
Subject: [issue28867] NamedTemporaryFile does not generate a ResourceWarning
 for unclosed files (unlike TemporaryFile)
Message-ID: <1480873647.39.0.877280517926.issue28867@psf.upfronthosting.co.za>


New submission from Jon Dufresne:

When using unittest, I'll frequently enable -Wall to help catch code smells and potential bugs.

One feature of this, I'm told when files aren't explicitly closed with an error like: "ResourceWarning: unclosed file <...>". I've noticed this warning is generated for an unclosed tempfile.TemporaryFile (good), but not for an unclosed tempfile.NamedTemporaryFile (possible bug).

I've verified this on Python 3.5 and 3.6.

Example test:

```
import tempfile
import unittest


class MyTest(unittest.TestCase):
    def test_temporary_file(self):
        tempfile.TemporaryFile()

    def test_named_temporary_file(self):
        tempfile.NamedTemporaryFile()
```

Actual output:

```
$ Python-3.6.0b4/python --version
Python 3.6.0b4
$ Python-3.6.0b4/python -Wall -m unittest -v test
test_named_temporary_file (test.MyTest) ... ok
test_temporary_file (test.MyTest) ... /home/jon/test.py:7: ResourceWarning: unclosed file <_io.BufferedRandom name=3>
  tempfile.TemporaryFile()
ok

----------------------------------------------------------------------
Ran 2 tests in 0.004s

OK

```

Expected:

I expect both tests to generate a ResourceWarning, as neither test explicitly closes the file.

----------
components: Library (Lib)
messages: 282352
nosy: jdufresne
priority: normal
severity: normal
status: open
title: NamedTemporaryFile does not generate a ResourceWarning for unclosed files (unlike TemporaryFile)
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Sun Dec  4 12:59:12 2016
From: report at bugs.python.org (Julien Palard)
Date: Sun, 04 Dec 2016 17:59:12 +0000
Subject: [issue28866] Unexpected behavior resulting from mro() and __setattr__
 in interactive mode
In-Reply-To: <1480862145.72.0.468660451957.issue28866@psf.upfronthosting.co.za>
Message-ID: <1480874352.19.0.0820696450314.issue28866@psf.upfronthosting.co.za>


Julien Palard added the comment:

FWIW, in _PyType_Lookup I see the "300" PyLong being cached, and later, just before the segfault, I see its address getting out of the cache (a cache hit) but it's no longer a PyLong, it's scrambled, so we're getting a real pointer with scrambled values on the line:

    attribute = _PyType_Lookup(type, name);

segfaulting two lines later in:

    descrgetfunc local_get = Py_TYPE(attribute)->tp_descr_get

When I write scrambled value I mean: 

    (gdb) p *attribute                                                                                                         
    $21 = {_ob_next = 0xdbdbdbdbdbdbdbdb, _ob_prev = 0xdbdbdbdbdbdbdbdb, ob_refcnt = -2604246222170760229, ob_type = 0xdbdbdbd\
    bdbdbdbdb}                                                                                                                 

To debug interactive session in GDB I used:

    r -i weird.py < stdin

with "proxy.x" in the stdin file.

----------
nosy: +mdk

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

From report at bugs.python.org  Sun Dec  4 13:19:38 2016
From: report at bugs.python.org (Mikhail)
Date: Sun, 04 Dec 2016 18:19:38 +0000
Subject: [issue28865] [MinGW32-x64]-PyList_Check PyDict_Check does not work
In-Reply-To: <1480853677.86.0.114330805471.issue28865@psf.upfronthosting.co.za>
Message-ID: <1480875578.51.0.847015192118.issue28865@psf.upfronthosting.co.za>


Changes by Mikhail <smirmik at gmail.com>:


Removed file: http://bugs.python.org/file45754/PyAPITests.zip

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

From report at bugs.python.org  Sun Dec  4 13:24:58 2016
From: report at bugs.python.org (Mikhail)
Date: Sun, 04 Dec 2016 18:24:58 +0000
Subject: [issue28865] [MinGW32-x64]-PyList_Check PyDict_Check does not work
In-Reply-To: <1480853677.86.0.114330805471.issue28865@psf.upfronthosting.co.za>
Message-ID: <1480875898.78.0.777707395387.issue28865@psf.upfronthosting.co.za>


Mikhail added the comment:

I made a small correction to the project. But the essence has not changed.


With Microsoft Visual C++ Build Tools everything is fine. But I would like to use the GCC.

----------
Added file: http://bugs.python.org/file45755/PyAPITests.zip

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

From report at bugs.python.org  Sun Dec  4 13:49:41 2016
From: report at bugs.python.org (SilentGhost)
Date: Sun, 04 Dec 2016 18:49:41 +0000
Subject: [issue28867] NamedTemporaryFile does not generate a ResourceWarning
 for unclosed files (unlike TemporaryFile)
In-Reply-To: <1480873647.39.0.877280517926.issue28867@psf.upfronthosting.co.za>
Message-ID: <1480877381.51.0.0964548292643.issue28867@psf.upfronthosting.co.za>


SilentGhost added the comment:

Looking at the code it seems NamedTemporaryFile is closed on destruction of the object, so there is no need for ResourceWarning, because the file descriptor is not leaking.

You also don't need to involve unittest here. Just running python with -Wall would generate a warning if there is a need for one.

----------
nosy: +SilentGhost

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

From report at bugs.python.org  Sun Dec  4 14:22:01 2016
From: report at bugs.python.org (Steve Dower)
Date: Sun, 04 Dec 2016 19:22:01 +0000
Subject: [issue28865] [MinGW32-x64]-PyList_Check PyDict_Check does not work
In-Reply-To: <1480853677.86.0.114330805471.issue28865@psf.upfronthosting.co.za>
Message-ID: <1480879321.35.0.734131829189.issue28865@psf.upfronthosting.co.za>


Steve Dower added the comment:

Is this the fork of MinGW specially for Python? I didn't think it supported 3.5 yet, because of the different CRT.

Also, I can't easily tell right now, but if you're using the libpython35.a that's included with the regular install, you might want to regenerate it. Nobody could agree on what tools should be used to generate it, so I picked one fairly blind and it may not be compatible with your tools (really it should just be regenerated if you want to rely on it, rather than shipping one, but that's where we're currently at).

----------

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

From report at bugs.python.org  Sun Dec  4 15:12:33 2016
From: report at bugs.python.org (R. David Murray)
Date: Sun, 04 Dec 2016 20:12:33 +0000
Subject: [issue25591] refactor imaplib tests
In-Reply-To: <1447107407.81.0.130095933409.issue25591@psf.upfronthosting.co.za>
Message-ID: <1480882353.38.0.937991584298.issue25591@psf.upfronthosting.co.za>


R. David Murray added the comment:

Revised patch LGTM.  Once 3.6 is out the door I'll commit it, though you may need to remind me.

----------
stage: patch review -> commit review
versions: +Python 3.7 -Python 3.6

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

From report at bugs.python.org  Sun Dec  4 15:13:27 2016
From: report at bugs.python.org (R. David Murray)
Date: Sun, 04 Dec 2016 20:13:27 +0000
Subject: [issue25591] refactor imaplib tests
In-Reply-To: <1447107407.81.0.130095933409.issue25591@psf.upfronthosting.co.za>
Message-ID: <1480882407.94.0.163493459236.issue25591@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


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

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

From report at bugs.python.org  Sun Dec  4 15:23:18 2016
From: report at bugs.python.org (R. David Murray)
Date: Sun, 04 Dec 2016 20:23:18 +0000
Subject: [issue28864] Add devnull file-like object
In-Reply-To: <1480822595.87.0.853337900572.issue28864@psf.upfronthosting.co.za>
Message-ID: <1480882998.34.0.828506417206.issue28864@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yes, in my mind open(os.devnull) is the "obvious way" to do this.

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

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

From report at bugs.python.org  Sun Dec  4 15:31:03 2016
From: report at bugs.python.org (R. David Murray)
Date: Sun, 04 Dec 2016 20:31:03 +0000
Subject: [issue28857] SyncManager and Main Process fail to communicate after
 reboot or stoping with Ctrl - C
In-Reply-To: <1480660972.34.0.757124295552.issue28857@psf.upfronthosting.co.za>
Message-ID: <1480883463.53.0.00725382434088.issue28857@psf.upfronthosting.co.za>


R. David Murray added the comment:

Hmm.  I wasn't aware that multiprocessing used anything other than semaphores (ie: not files in /tmp). Clearly my knowledge is not enough to understand this problem, I'll leave it to the multiprocessing experts.

----------
nosy: +davin

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

From report at bugs.python.org  Sun Dec  4 15:45:28 2016
From: report at bugs.python.org (R. David Murray)
Date: Sun, 04 Dec 2016 20:45:28 +0000
Subject: [issue28867] NamedTemporaryFile does not generate a ResourceWarning
 for unclosed files (unlike TemporaryFile)
In-Reply-To: <1480873647.39.0.877280517926.issue28867@psf.upfronthosting.co.za>
Message-ID: <1480884328.71.0.729887204007.issue28867@psf.upfronthosting.co.za>


R. David Murray added the comment:

The point of ResourceWarning it tell you when you are depending on destructors for cleanup, so this does look like a bug.

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

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

From report at bugs.python.org  Sun Dec  4 15:58:50 2016
From: report at bugs.python.org (rm)
Date: Sun, 04 Dec 2016 20:58:50 +0000
Subject: [issue28868] Python advertising BeOpen.com domain
Message-ID: <1480885130.58.0.883426761296.issue28868@psf.upfronthosting.co.za>


New submission from rm:

There is BeOpen attribution in __builtins__() call, that may confuse users and generate some traffic to unrelated domain.

For example:

>>> import smtplib
>>> smtplib.__builtins__
<...>
Copyright (c) 2000 BeOpen.com.
All Rights Reserved.
<...>

but beopen.com resolves to domain hosting stub page. May be this string should be changed to just BeOpen, or removed altogether.

----------
assignee: docs at python
components: Documentation
messages: 282361
nosy: cvs-src, docs at python
priority: normal
severity: normal
status: open
title: Python advertising BeOpen.com domain
versions: Python 3.5

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

From report at bugs.python.org  Sun Dec  4 16:03:07 2016
From: report at bugs.python.org (SilentGhost)
Date: Sun, 04 Dec 2016 21:03:07 +0000
Subject: [issue28868] Python advertising BeOpen.com domain
In-Reply-To: <1480885130.58.0.883426761296.issue28868@psf.upfronthosting.co.za>
Message-ID: <1480885387.94.0.489001743425.issue28868@psf.upfronthosting.co.za>


SilentGhost added the comment:

It's part of the copyright notice, just removing it is probably not an option.

----------
nosy: +SilentGhost

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

From report at bugs.python.org  Sun Dec  4 16:09:34 2016
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sun, 04 Dec 2016 21:09:34 +0000
Subject: [issue28869] __module__ attribute is not set correctly for a class
 created by direct metaclass call
Message-ID: <1480885774.84.0.670239959771.issue28869@psf.upfronthosting.co.za>


New submission from Ivan Levkivskyi:

__module__ attribute is set differently depending on whether a metaclass is explicitly called or invoked in a class statement:

>>> A = ABCMeta('A', (), {})
>>> A.__module__
'abc'
>>> class B(metaclass=ABCMeta): ...
... 
>>> B.__module__
'__main__'

Documentation on data model says that "__module__ is the module name in which the class was defined", so that the second behaviour seems right, while the first behaviour seems wrong to me.

----------
components: Interpreter Core
messages: 282363
nosy: levkivskyi
priority: normal
severity: normal
status: open
title: __module__ attribute is not set correctly for a class created by direct metaclass call
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun Dec  4 16:10:38 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Sun, 04 Dec 2016 21:10:38 +0000
Subject: [issue28868] Python advertising BeOpen.com domain
In-Reply-To: <1480885130.58.0.883426761296.issue28868@psf.upfronthosting.co.za>
Message-ID: <1480885838.4.0.379854659953.issue28868@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

Part of the copyright notice, as SilentGhost mentioned. This can't be removed.

----------
nosy: +ebarry
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Sun Dec  4 16:10:40 2016
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sun, 04 Dec 2016 21:10:40 +0000
Subject: [issue28869] __module__ attribute is not set correctly for a class
 created by direct metaclass call
In-Reply-To: <1480885774.84.0.670239959771.issue28869@psf.upfronthosting.co.za>
Message-ID: <1480885840.64.0.591569910937.issue28869@psf.upfronthosting.co.za>


Changes by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
type:  -> behavior

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

From report at bugs.python.org  Sun Dec  4 16:12:01 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Sun, 04 Dec 2016 21:12:01 +0000
Subject: [issue28869] __module__ attribute is not set correctly for a class
 created by direct metaclass call
In-Reply-To: <1480885774.84.0.670239959771.issue28869@psf.upfronthosting.co.za>
Message-ID: <1480885921.29.0.352788728695.issue28869@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

As a matter of fact, A.__module__ in this case is abc.ABCMeta.__module__. A class body creates a __module__ key, while a direct metaclass call does not.

----------
nosy: +ebarry

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

From report at bugs.python.org  Sun Dec  4 16:12:17 2016
From: report at bugs.python.org (SilentGhost)
Date: Sun, 04 Dec 2016 21:12:17 +0000
Subject: [issue28867] NamedTemporaryFile does not generate a ResourceWarning
 for unclosed files (unlike TemporaryFile)
In-Reply-To: <1480873647.39.0.877280517926.issue28867@psf.upfronthosting.co.za>
Message-ID: <1480885937.87.0.737787527942.issue28867@psf.upfronthosting.co.za>


SilentGhost added the comment:

> The point of ResourceWarning it tell you when you are depending on destructors for cleanup
But there is an explicit call in __del__ to .close(), it's looks like intended behaviour and is ultimately the difference that Jon was seeing between NamedTemporaryFile and TemporaryFile.

----------

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

From report at bugs.python.org  Sun Dec  4 16:21:24 2016
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sun, 04 Dec 2016 21:21:24 +0000
Subject: [issue28869] __module__ attribute is not set correctly for a class
 created by direct metaclass call
In-Reply-To: <1480885774.84.0.670239959771.issue28869@psf.upfronthosting.co.za>
Message-ID: <1480886484.03.0.0502280655401.issue28869@psf.upfronthosting.co.za>


Ivan Levkivskyi added the comment:

> As a matter of fact, A.__module__ in this case is abc.ABCMeta.__module__. A class body creates a __module__ key, while a direct metaclass call does not.

But

>>> A = ABCMeta('A', (), {})
>>> ABCMeta.__module__ = 'hi'
>>> A.__module__
'abc'
>>> ABCMeta.__module__
'hi'

This means that the __module__ is copied from metaclass (also A.__dict__ actually contains '__module__' key, checked in 3.6).

----------

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

From report at bugs.python.org  Sun Dec  4 16:34:53 2016
From: report at bugs.python.org (Julien Palard)
Date: Sun, 04 Dec 2016 21:34:53 +0000
Subject: [issue28866] Unexpected behavior resulting from mro() and __setattr__
 in interactive mode
In-Reply-To: <1480862145.72.0.468660451957.issue28866@psf.upfronthosting.co.za>
Message-ID: <1480887293.39.0.620942131127.issue28866@psf.upfronthosting.co.za>


Julien Palard added the comment:

I'm able to reproduce the segmentation fault outside the interactive mode, see attached file.

----------
Added file: http://bugs.python.org/file45756/weird_without_interactive.py

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

From report at bugs.python.org  Sun Dec  4 16:37:46 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Sun, 04 Dec 2016 21:37:46 +0000
Subject: [issue28869] __module__ attribute is not set correctly for a class
 created by direct metaclass call
In-Reply-To: <1480885774.84.0.670239959771.issue28869@psf.upfronthosting.co.za>
Message-ID: <1480887466.39.0.0482353261217.issue28869@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

Oh, nicely spotted! Apparently I was wrong, and it does create a key; defaulting to __name__.

About the original issue, I don't think it's easily possible to fix, sadly.

----------

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

From report at bugs.python.org  Sun Dec  4 17:00:17 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 04 Dec 2016 22:00:17 +0000
Subject: [issue28858] Fastcall uses more C stack
In-Reply-To: <1480665267.65.0.416366810047.issue28858@psf.upfronthosting.co.za>
Message-ID: <20161204220014.21590.39199.BB730D53@psf.io>


Roundup Robot added the comment:

New changeset d35fc6e58a70 by Victor Stinner in branch 'default':
Backed out changeset b9c9691c72c5
https://hg.python.org/cpython/rev/d35fc6e58a70

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

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

From report at bugs.python.org  Sun Dec  4 17:13:53 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 04 Dec 2016 22:13:53 +0000
Subject: [issue28858] Fastcall uses more C stack
In-Reply-To: <1480665267.65.0.416366810047.issue28858@psf.upfronthosting.co.za>
Message-ID: <1480889633.85.0.624745673359.issue28858@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Serhiy Storchaka reported that Python 3.6 crashs earlier than Python 3.5 on calling json.dumps() when sys.setrecursionlimit() is increased.

Reference: http://bugs.python.org/issue23507#msg282190 (issue #23507).


Serhiy Storchaka: "Yes, that is why I asked you to revert your changes."

Sorry, I misunderstood your comments. So yes, my change b9c9691c72c5 introduced a regression. Sorry, I didn't have time before now to revert my  change. I just pushed the change d35fc6e58a70 which reverts b9c9691c72c5.

The question is how replacing PyObject_CallFunctionObjArgs() with _PyObject_CallArg1() increases the usage of the C stack. I wrote my change to reduce the usage of the C stack.

PyObject_CallFunctionObjArgs() allocates 5 "PyObject *", so 40 bytes, on the C stack. Maybe using _PyObject_CallArg1() increases the usage of C stack in the *caller*.


> In additional, they introduced compiler warnings.

This one was fixed by Benjamin Peterson in the issue #28855 (change 96245d4af0ca).

----------

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

From report at bugs.python.org  Sun Dec  4 17:29:53 2016
From: report at bugs.python.org (R. David Murray)
Date: Sun, 04 Dec 2016 22:29:53 +0000
Subject: [issue28867] NamedTemporaryFile does not generate a ResourceWarning
 for unclosed files (unlike TemporaryFile)
In-Reply-To: <1480873647.39.0.877280517926.issue28867@psf.upfronthosting.co.za>
Message-ID: <1480890593.22.0.160249198908.issue28867@psf.upfronthosting.co.za>


R. David Murray added the comment:

__del__ is a destructor.  If the file is open when it is called, it should emit a ResourceWarning.

----------

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

From report at bugs.python.org  Sun Dec  4 17:49:30 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 04 Dec 2016 22:49:30 +0000
Subject: [issue28858] Fastcall uses more C stack
In-Reply-To: <1480665267.65.0.416366810047.issue28858@psf.upfronthosting.co.za>
Message-ID: <1480891770.48.0.954492206729.issue28858@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thanks Victor.

Following script includes several examples of achieving a stack overflow (most are real world examples or can be used in real world examples). It measures maximal deep for every type of recursion.

----------
Added file: http://bugs.python.org/file45757/stack_overflow.py

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

From report at bugs.python.org  Sun Dec  4 17:50:13 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 04 Dec 2016 22:50:13 +0000
Subject: [issue28870] Refactor PyObject_CallFunctionObjArgs() and like
Message-ID: <1480891813.94.0.54795440575.issue28870@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Following patch I wrote in attempt to decrease a stack consumption of PyObject_CallFunctionObjArgs(), PyObject_CallMethodObjArgs() and _PyObject_CallMethodIdObjArgs(). But it doesn't affect a stack consumption. I still didn't measured what performance effect it has. Seems it makes a code a little cleaner.

----------
components: Interpreter Core
files: PyObject_CallFunctionObjArgs.patch
keywords: patch
messages: 282374
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Refactor PyObject_CallFunctionObjArgs() and like
type: enhancement
versions: Python 3.7
Added file: http://bugs.python.org/file45758/PyObject_CallFunctionObjArgs.patch

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

From report at bugs.python.org  Sun Dec  4 17:51:04 2016
From: report at bugs.python.org (Julien Palard)
Date: Sun, 04 Dec 2016 22:51:04 +0000
Subject: [issue28866] Unexpected behavior resulting from mro() and __setattr__
 in interactive mode
In-Reply-To: <1480862145.72.0.468660451957.issue28866@psf.upfronthosting.co.za>
Message-ID: <1480891864.43.0.245529650919.issue28866@psf.upfronthosting.co.za>


Julien Palard added the comment:

Problem looks mainly due to the __setattr__ done on a different type than the getattr, and the cache of PyType_Lookup:

 - type_setattro will be called with Foo, "x", and the value to set
 - type_getattro will be called with FooProxy, "x"

The timeline (with my weird_without_interactive.py) is:

 - type_setattro is called on Foo for attr "x" with the instance of Bar
 - type_getattro is called on FooProxy for attr "x" (the `proxy.x` line)
     During this type_getattro, the instance of Bar is cached in PyType_Lookup for (FooProxy, "x")
 - type_setattro is called on Foo for attr "x" with the value 0
     During this call, insertdict will legitimately call DECREF on the Bar instance, which is deleted
 - type_getattro is called on FooProxy with attr "x" for the print()
     During this call, PyType_Lookup will cache hit for (FooProxy, x) with the old reference to the instance of Bar

----------

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

From report at bugs.python.org  Sun Dec  4 18:03:24 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 04 Dec 2016 23:03:24 +0000
Subject: [issue28871] Destructor of ElementTree.Element is recursive
Message-ID: <1480892604.34.0.360751620771.issue28871@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The Element class in the xml.etree.ElementTree module is a collection. It can contain other Element's. But unlike to common Python collections (list, dict, etc) and pure Python classes, C implementation of Element doesn't support unlimited recursion. As result, destroying very deep Element tree can cause stack overflow. Example:

import xml.etree.cElementTree as ElementTree
y = x = ElementTree.Element('x')
for i in range(200000): y = ElementTree.SubElement(y, 'x')

del x

----------
components: Extension Modules
messages: 282376
nosy: eli.bendersky, scoder, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Destructor of ElementTree.Element is recursive
type: crash
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Sun Dec  4 18:11:19 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 04 Dec 2016 23:11:19 +0000
Subject: [issue28858] Fastcall uses more C stack
In-Reply-To: <1480665267.65.0.416366810047.issue28858@psf.upfronthosting.co.za>
Message-ID: <1480893079.06.0.747517062557.issue28858@psf.upfronthosting.co.za>


STINNER Victor added the comment:

When I wrote the _PyObject_CallArg1(), it looks as a cool hack:

#define _PyObject_CallArg1(func, arg) \
    _PyObject_FastCall((func), (PyObject **)&(arg), 1)

It hacks the declaration of an explicit "stack" like:

   PyObject *stack[1];
   stack[0] = arg;
   res = _PyObject_FastCall(func, stack, 1);

And I expected that the C compiler magically computes the memory address of the argument. But it seems like requesting the memory address of an argument allocates something on the C stack.

On x86_64, first function arguments are passed with CPU registers. Maybe requesting the memory address of an argument requires to allocate a local variable, copy the register into the variable, to get the address of the local variable?

So, I suggest to *remove* the _PyObject_CallArg1() macro, and use existing functions like PyObject_CallFunctionObjArgs().

What do you think Serhiy?

----------

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

From report at bugs.python.org  Sun Dec  4 18:15:31 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 04 Dec 2016 23:15:31 +0000
Subject: [issue28869] __module__ attribute is not set correctly for a class
 created by direct metaclass call
In-Reply-To: <1480885774.84.0.670239959771.issue28869@psf.upfronthosting.co.za>
Message-ID: <1480893331.16.0.582578212969.issue28869@psf.upfronthosting.co.za>


Steven D'Aprano added the comment:

I had a brief look at the source for ABCMeta, and it seems to me that the __module__ behaviour is coming from `type`. I'm not sure whether it can, or should, can be fixed in type, but I think that the correct behaviour for ABCMeta is to set __module__ to the caller's global "__name__", not its own.

Something like this should probably work:


class ABCMeta(type):
    def __new__(mcls, name, bases, namespace):
        if '__module__' not in namespace:
            # globals()['__name__'] gives 'abc'
            frame = inspect.currentframe()
            if frame is not None:
                # IronPython? 
                caller_globals = frame.f_back.f_globals
                namespace['__module__'] = caller_globals['__name__']
        cls = super().__new__(mcls, name, bases, namespace)
        ...

----------
nosy: +steven.daprano

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

From report at bugs.python.org  Sun Dec  4 18:30:50 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 04 Dec 2016 23:30:50 +0000
Subject: [issue28870] Refactor PyObject_CallFunctionObjArgs() and like
In-Reply-To: <1480891813.94.0.54795440575.issue28870@psf.upfronthosting.co.za>
Message-ID: <1480894250.42.0.0872289522821.issue28870@psf.upfronthosting.co.za>


STINNER Victor added the comment:

What do you think of using alloca() instead of an "PyObject *small_stack[5];" which has a fixed size?

Note: About your patch, try to avoid _PyObject_CallArg1() if you care of the usage of the C stack, see issue #28858.

----------

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

From report at bugs.python.org  Sun Dec  4 18:38:10 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 04 Dec 2016 23:38:10 +0000
Subject: [issue28870] Refactor PyObject_CallFunctionObjArgs() and like
In-Reply-To: <1480891813.94.0.54795440575.issue28870@psf.upfronthosting.co.za>
Message-ID: <1480894690.92.0.0233981812803.issue28870@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> But it doesn't affect a stack consumption.

How do you check the stack consumption of PyObject_CallFunctionObjArgs()?

----------

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

From report at bugs.python.org  Sun Dec  4 18:42:12 2016
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 04 Dec 2016 23:42:12 +0000
Subject: [issue28854] FIPS mode causes dead-lock in ssl module
In-Reply-To: <1480623760.67.0.622140819943.issue28854@psf.upfronthosting.co.za>
Message-ID: <1480894932.31.0.857506337937.issue28854@psf.upfronthosting.co.za>


Christian Heimes added the comment:

It was a downstream bug in Fedora. Tomas Mraz has fixed the issue and will release openssl-1.0.2j-3 soon, https://bugzilla.redhat.com/show_bug.cgi?id=1400922

----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Sun Dec  4 21:30:08 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 05 Dec 2016 02:30:08 +0000
Subject: [issue28864] Add devnull file-like object
In-Reply-To: <1480822595.87.0.853337900572.issue28864@psf.upfronthosting.co.za>
Message-ID: <1480905008.92.0.20368532284.issue28864@psf.upfronthosting.co.za>


Martin Panter added the comment:

If you only need the readable interface, use BytesIO or StringIO.

I once had an implementation like Serhiy?s, called dummywriter: <https://github.com/vadmium/python-lib/blob/99ec887/streams.py#L12>. To fully implement the writable file API it should also implement writable(), and write() should return the size of its argument.

Implementing this without opening a real file descriptor is slightly easier to manage (no need to worry about closing it, and no problem sharing instances or creating many copies). I don?t have a strong opinion about including it in the builtin library though, since it is pretty easy to implement the basics yourself.

I doubt anyone would need a readable and writable object, i.e. open(devnull, "r+"). On the other hand, it is occasionally useful to know how many bytes were written in total, so implementing tell() etc could be useful. (Linux?s /dev/null doesn?t work that way though; I find it always returns zero.)

----------
nosy: +martin.panter

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

From report at bugs.python.org  Sun Dec  4 22:50:10 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 05 Dec 2016 03:50:10 +0000
Subject: [issue23722] During metaclass.__init__,
 super() of the constructed class does not work
In-Reply-To: <1426859061.43.0.510286082444.issue23722@psf.upfronthosting.co.za>
Message-ID: <1480909810.43.0.182104629505.issue23722@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I've hit a problem where test_builtin and test_unittest are failing for me when refleak hunting is enabled (as in actual test failures, not just leak reports), but those also appear for me without the patch applied.

Current plan:

- ensure "./python -m test -R 3:3 -x test_builtin test_unittest" is clean both with and without the patch (perhaps also removing some other tests that are unreliable even without the patch)
- file a separate issue for the refleak hunting problem with the error tracebacks
- push the fix for the __classcell__ problems to 3.6

----------

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

From report at bugs.python.org  Mon Dec  5 00:52:58 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 05 Dec 2016 05:52:58 +0000
Subject: [issue28870] Refactor PyObject_CallFunctionObjArgs() and like
In-Reply-To: <1480891813.94.0.54795440575.issue28870@psf.upfronthosting.co.za>
Message-ID: <1480917178.12.0.704656166919.issue28870@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> What do you think of using alloca() instead of an "PyObject *small_stack[5];" which has a fixed size?

alloca() is not in POSIX.1. I afraid it would make CPython less portable.

> Note: About your patch, try to avoid _PyObject_CallArg1() if you care of the usage of the C stack, see issue #28858.

I don't understand how can I avoid it.

> How do you check the stack consumption of PyObject_CallFunctionObjArgs()?

Using a script from issue28858.

----------

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

From report at bugs.python.org  Mon Dec  5 01:06:17 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 05 Dec 2016 06:06:17 +0000
Subject: [issue28858] Fastcall uses more C stack
In-Reply-To: <1480665267.65.0.416366810047.issue28858@psf.upfronthosting.co.za>
Message-ID: <1480917977.2.0.329959927709.issue28858@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

That was my initial preference. Mainly because this doesn't add code churn.

But I don't understand how PyObject_CallFunctionObjArgs() that uses _PyObject_CallArg1() and has many local variables can consume less stack than _PyObject_CallArg1() itself.

----------

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

From report at bugs.python.org  Mon Dec  5 01:17:47 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Mon, 05 Dec 2016 06:17:47 +0000
Subject: [issue28596] on Android _bootlocale on startup relies on too many
 library modules
In-Reply-To: <1478166520.26.0.975749703987.issue28596@psf.upfronthosting.co.za>
Message-ID: <1480918667.09.0.538546650582.issue28596@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

Thanks Victor. Here's new patch, which uses hasattr

----------
Added file: http://bugs.python.org/file45759/android-locale-utf8.patch

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

From report at bugs.python.org  Mon Dec  5 01:59:36 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 05 Dec 2016 06:59:36 +0000
Subject: [issue23722] During metaclass.__init__,
 super() of the constructed class does not work
In-Reply-To: <1426859061.43.0.510286082444.issue23722@psf.upfronthosting.co.za>
Message-ID: <20161205065933.13469.59303.8BDE6816@psf.io>


Roundup Robot added the comment:

New changeset e33245800f1a by Nick Coghlan in branch '3.6':
Issue #23722: improve __classcell__ compatibility
https://hg.python.org/cpython/rev/e33245800f1a

New changeset 9e5bc3d38de8 by Nick Coghlan in branch 'default':
Merge #23722 from 3.6
https://hg.python.org/cpython/rev/9e5bc3d38de8

----------

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

From report at bugs.python.org  Mon Dec  5 02:05:09 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 05 Dec 2016 07:05:09 +0000
Subject: [issue27050] Demote run() below the high level APIs in subprocess docs
In-Reply-To: <1463548305.72.0.232219818049.issue27050@psf.upfronthosting.co.za>
Message-ID: <1480921509.23.0.10060841009.issue27050@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I've switched to using Vinay Sajip's "sarge" for my own subprocess invocation needs, which uses a similar all-in-one "run" API (albeit quite a different approach to capturing output).

Accordingly, I don't think there's anything useful to be done specifically in the context of this issue - any energy that might be spent here would likely be spent more constructively on things like making the pipe encoding easier to configure, or reducing the risk of deadlocks due to OS-level buffer size limits.

----------
resolution:  -> not a bug
status: open -> closed

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

From report at bugs.python.org  Mon Dec  5 02:08:43 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 05 Dec 2016 07:08:43 +0000
Subject: [issue28872] test_builtin failures when refleak hunting
Message-ID: <1480921723.59.0.457276441152.issue28872@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

test_builtin currently fails for me when hunting refleaks (Fedora 25):

$ ./python -m test -R 3:3 -v test_builtin

[snip]

======================================================================
FAIL: test_input_tty_non_ascii (test.test_builtin.PtyTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/ncoghlan/devel/py36/Lib/test/test_builtin.py", line 1592, in test_input_tty_non_ascii
    self.check_input_tty("prompt?", b"quux\xe9", "utf-8")
  File "/home/ncoghlan/devel/py36/Lib/test/test_builtin.py", line 1583, in check_input_tty
    self.assertEqual(input_result, expected)
AssertionError: 'quux' != 'quux\udce9'
- quux
+ quux\udce9
?     +


======================================================================
FAIL: test_input_tty_non_ascii_unicode_errors (test.test_builtin.PtyTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/ncoghlan/devel/py36/Lib/test/test_builtin.py", line 1596, in test_input_tty_non_ascii_unicode_errors
    self.check_input_tty("prompt?", b"quux\xe9", "ascii")
  File "/home/ncoghlan/devel/py36/Lib/test/test_builtin.py", line 1583, in check_input_tty
    self.assertEqual(input_result, expected)
AssertionError: 'quux' != 'quux\udce9'
- quux
+ quux\udce9
?     +


----------------------------------------------------------------------
Ran 78 tests in 0.066s

FAILED (failures=2)

----------
messages: 282389
nosy: ncoghlan, ned.deily
priority: normal
severity: normal
stage: needs patch
status: open
title: test_builtin failures when refleak hunting
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Mon Dec  5 02:10:24 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 05 Dec 2016 07:10:24 +0000
Subject: [issue28873] test_unittest failures when refleak hunting
Message-ID: <1480921824.58.0.630803385181.issue28873@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

test_unittest currently fails for me when hunting refleaks (Fedora 25):

$ ./python -m test -R 3:3 -v test_unittest

======================================================================
ERROR: test_discover_with_init_module_that_raises_SkipTest_on_import (unittest.test.test_discovery.TestDiscovery)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/ncoghlan/devel/py36/Lib/unittest/test/test_discovery.py", line 572, in test_discover_with_init_module_that_raises_SkipTest_on_import
    pickle.loads(pickle.dumps(suite, proto))
_pickle.PicklingError: Can't pickle <class 'unittest.loader.ModuleSkipped'>: attribute lookup ModuleSkipped on unittest.loader failed

======================================================================
ERROR: test_discover_with_module_that_raises_SkipTest_on_import (unittest.test.test_discovery.TestDiscovery)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/ncoghlan/devel/py36/Lib/unittest/test/test_discovery.py", line 548, in test_discover_with_module_that_raises_SkipTest_on_import
    pickle.loads(pickle.dumps(suite, proto))
_pickle.PicklingError: Can't pickle <class 'unittest.loader.ModuleSkipped'>: attribute lookup ModuleSkipped on unittest.loader failed

----------------------------------------------------------------------
Ran 715 tests in 1.898s

FAILED (errors=2, skipped=7)

----------
messages: 282390
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: test_unittest failures when refleak hunting
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Mon Dec  5 02:10:34 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 05 Dec 2016 07:10:34 +0000
Subject: [issue28873] test_unittest failures when refleak hunting
In-Reply-To: <1480921824.58.0.630803385181.issue28873@psf.upfronthosting.co.za>
Message-ID: <1480921834.23.0.78028432891.issue28873@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
nosy: +ned.deily

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

From report at bugs.python.org  Mon Dec  5 02:12:09 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 05 Dec 2016 07:12:09 +0000
Subject: [issue23722] During metaclass.__init__,
 super() of the constructed class does not work
In-Reply-To: <1426859061.43.0.510286082444.issue23722@psf.upfronthosting.co.za>
Message-ID: <1480921929.79.0.483045760353.issue23722@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Thanks for the reviews Serhiy! The patch as merged addressed both your comments on the docs (including adding several new index entries) as well as the last couple of style comments on the code changes.

I've filed separate issues for the test failures I'm seeing when refleak hunting:

* test_builtin: http://bugs.python.org/issue28872
* test_unittest: http://bugs.python.org/issue28873

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

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

From report at bugs.python.org  Mon Dec  5 02:25:08 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 05 Dec 2016 07:25:08 +0000
Subject: [issue28872] test_builtin failures when refleak hunting
In-Reply-To: <1480921723.59.0.457276441152.issue28872@psf.upfronthosting.co.za>
Message-ID: <1480922708.24.0.307771651325.issue28872@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Ned, I'm not sure if this should be a release blocker or not.

Superficially, it looks like it's just a test bug arising from running the test multiple times in the same process, but I unfortunately don't have time to investigate further today.

----------
assignee:  -> ned.deily

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

From report at bugs.python.org  Mon Dec  5 02:25:46 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 05 Dec 2016 07:25:46 +0000
Subject: [issue28873] test_unittest failures when refleak hunting
In-Reply-To: <1480921824.58.0.630803385181.issue28873@psf.upfronthosting.co.za>
Message-ID: <1480922746.7.0.254804980623.issue28873@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Ned, I'm not sure if this should be a release blocker or not.

Superficially, it looks like it's just a test bug arising from running the test multiple times in the same process, but I unfortunately don't have time to investigate further today.

----------
assignee:  -> ned.deily

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

From report at bugs.python.org  Mon Dec  5 02:32:55 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 05 Dec 2016 07:32:55 +0000
Subject: [issue28873] test_unittest failures when refleak hunting
In-Reply-To: <1480921824.58.0.630803385181.issue28873@psf.upfronthosting.co.za>
Message-ID: <1480923175.8.0.464099172453.issue28873@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is a duplicate of issue25746.

----------
nosy: +serhiy.storchaka
resolution:  -> duplicate
superseder:  -> test_unittest failure in leaks searching mode

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

From report at bugs.python.org  Mon Dec  5 02:35:23 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 05 Dec 2016 07:35:23 +0000
Subject: [issue28872] test_builtin failures when refleak hunting
In-Reply-To: <1480921723.59.0.457276441152.issue28872@psf.upfronthosting.co.za>
Message-ID: <1480923323.32.0.357553795823.issue28872@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is a duplicate of issue13886.

----------
nosy: +serhiy.storchaka
resolution:  -> duplicate
superseder:  -> readline-related test_builtin failure

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

From report at bugs.python.org  Mon Dec  5 02:41:23 2016
From: report at bugs.python.org (Whitequill Riclo)
Date: Mon, 05 Dec 2016 07:41:23 +0000
Subject: [issue28874] test_logging fails
Message-ID: <1480923682.41.0.106352881958.issue28874@psf.upfronthosting.co.za>


New submission from Whitequill Riclo:

while testing my build of cpython it hangs on test 198/404 and will not continue unless interrupted with ctrl-C.

the build is fairly sound, but I can't test anything after test 198/404 cause it gets stuck.

----------
components: Tests
files: cpython-testlogging.log
hgrepos: 364
messages: 282396
nosy: Whitequill Riclo
priority: normal
severity: normal
status: open
title: test_logging fails
versions: Python 3.7
Added file: http://bugs.python.org/file45760/cpython-testlogging.log

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

From report at bugs.python.org  Mon Dec  5 02:44:30 2016
From: report at bugs.python.org (Whitequill Riclo)
Date: Mon, 05 Dec 2016 07:44:30 +0000
Subject: [issue28875] test fails and freezes
Message-ID: <1480923867.51.0.993366895906.issue28875@psf.upfronthosting.co.za>


New submission from Whitequill Riclo:

while testing my build of cpython it hangs on test 198/404 and will not continue unless interrupted with ctrl-C.

the build is fairly sound, but I can't test anything after test 198/404 cause it gets stuck.

----------
components: Tests
files: cpython-testlogging.log
hgrepos: 365
messages: 282397
nosy: Whitequill Riclo
priority: normal
severity: normal
status: open
title: test fails and freezes
type: behavior
versions: Python 3.7
Added file: http://bugs.python.org/file45761/cpython-testlogging.log

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

From report at bugs.python.org  Mon Dec  5 02:56:26 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 05 Dec 2016 07:56:26 +0000
Subject: [issue28875] test fails and freezes
In-Reply-To: <1480923867.51.0.993366895906.issue28875@psf.upfronthosting.co.za>
Message-ID: <1480924586.97.0.961973371246.issue28875@psf.upfronthosting.co.za>


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


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> test_logging fails

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

From report at bugs.python.org  Mon Dec  5 02:57:34 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 05 Dec 2016 07:57:34 +0000
Subject: [issue28874] test_logging fails and freezes
In-Reply-To: <1480923682.41.0.106352881958.issue28874@psf.upfronthosting.co.za>
Message-ID: <1480924654.85.0.0101351747478.issue28874@psf.upfronthosting.co.za>


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


----------
title: test_logging fails -> test_logging fails and freezes
type:  -> behavior

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

From report at bugs.python.org  Mon Dec  5 03:10:43 2016
From: report at bugs.python.org (Mikhail)
Date: Mon, 05 Dec 2016 08:10:43 +0000
Subject: [issue28865] [MinGW32-x64]-PyList_Check PyDict_Check does not work
In-Reply-To: <1480853677.86.0.114330805471.issue28865@psf.upfronthosting.co.za>
Message-ID: <1480925443.65.0.962760588618.issue28865@psf.upfronthosting.co.za>


Mikhail added the comment:

SOLVED:

I found a solution. It turned out that on the Windows x64 need to use '-DMS_WIN64' compiler option.

Three days wasted.

And although no one helped me, I felt that mentally you were with me, guys. Thank you! ;)

----------
resolution:  -> not a bug
status: open -> closed

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

From report at bugs.python.org  Mon Dec  5 03:31:43 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 05 Dec 2016 08:31:43 +0000
Subject: [issue13886] readline-related test_builtin failure
In-Reply-To: <1327659819.71.0.475160045664.issue13886@psf.upfronthosting.co.za>
Message-ID: <1480926703.22.0.0591733004734.issue13886@psf.upfronthosting.co.za>


Martin Panter added the comment:

Since people keep coming upon this bug, perhaps we should inhibit push my fix without fixing that other prompt bug (now a feature change I think). Probably have to capture stderr to avoid it coming out in the test output.

----------
versions: +Python 3.7

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

From report at bugs.python.org  Mon Dec  5 03:33:50 2016
From: report at bugs.python.org (Whitequill Riclo)
Date: Mon, 05 Dec 2016 08:33:50 +0000
Subject: [issue28875] test fails and freezes
In-Reply-To: <1480923867.51.0.993366895906.issue28875@psf.upfronthosting.co.za>
Message-ID: <1480926830.45.0.343455668195.issue28875@psf.upfronthosting.co.za>


Changes by Whitequill Riclo <theguild42 at gmail.com>:


----------
hgrepos:  -365

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

From report at bugs.python.org  Mon Dec  5 03:35:36 2016
From: report at bugs.python.org (Whitequill Riclo)
Date: Mon, 05 Dec 2016 08:35:36 +0000
Subject: [issue28875] test fails and freezes
In-Reply-To: <1480923867.51.0.993366895906.issue28875@psf.upfronthosting.co.za>
Message-ID: <1480926936.2.0.448445705661.issue28875@psf.upfronthosting.co.za>


Changes by Whitequill Riclo <theguild42 at gmail.com>:


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

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

From report at bugs.python.org  Mon Dec  5 03:42:40 2016
From: report at bugs.python.org (Whitequill Riclo)
Date: Mon, 05 Dec 2016 08:42:40 +0000
Subject: [issue28875] test fails and freezes
In-Reply-To: <1480923867.51.0.993366895906.issue28875@psf.upfronthosting.co.za>
Message-ID: <1480927360.51.0.688915499832.issue28875@psf.upfronthosting.co.za>


Changes by Whitequill Riclo <theguild42 at gmail.com>:


----------
hgrepos: +366

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

From report at bugs.python.org  Mon Dec  5 03:49:29 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 05 Dec 2016 08:49:29 +0000
Subject: [issue27870] Left shift of zero allocates memory
In-Reply-To: <1472238743.62.0.87785770674.issue27870@psf.upfronthosting.co.za>
Message-ID: <1480927769.5.0.183367122588.issue27870@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Gah. Sorry about that. Thanks for the refleak fix, Benjamin.

----------

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

From report at bugs.python.org  Mon Dec  5 04:08:41 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 05 Dec 2016 09:08:41 +0000
Subject: [issue24329] __qualname__ and __slots__
In-Reply-To: <1432930157.09.0.507147768187.issue24329@psf.upfronthosting.co.za>
Message-ID: <1480928921.38.0.958163809239.issue24329@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

> However, consistency is a good thing, so allowing it seems reasonable.

The inconsistency also appears when "__classcell__" in slots with or without super().

v4 catches up with HEAD.

----------
Added file: http://bugs.python.org/file45762/slots_special-v4.patch

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

From report at bugs.python.org  Mon Dec  5 04:37:42 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 05 Dec 2016 09:37:42 +0000
Subject: [issue28876] bool of large range raises OverflowError
Message-ID: <1480930662.45.0.497603219066.issue28876@psf.upfronthosting.co.za>


New submission from Mark Dickinson:

The bool of a large range raises OverflowError:

    >>> bool(range(2**63))
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    OverflowError: Python int too large to convert to C ssize_t

This is a side-effect of len raising OverflowError, which is a general problem that's nontrivial to fix (the sq_length slot is constrained to return a ssize_t). In theory, though, it would be possible to implement nb_bool for range objects to do the right thing.

In practice, this may well not be worth fixing, though I think it's at least worth reporting.

----------
components: Interpreter Core
messages: 282402
nosy: mark.dickinson
priority: normal
severity: normal
status: open
title: bool of large range raises OverflowError
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Mon Dec  5 04:49:20 2016
From: report at bugs.python.org (Paul Doom)
Date: Mon, 05 Dec 2016 09:49:20 +0000
Subject: [issue22107] tempfile module misinterprets access denied error on
 Windows
In-Reply-To: <1406724041.52.0.0365391579019.issue22107@psf.upfronthosting.co.za>
Message-ID: <1480931360.01.0.64800983749.issue22107@psf.upfronthosting.co.za>


Paul Doom added the comment:

Can the _mkstemp_inner portion of Billy McCulloch's patch be applied? Due to a large default os.TMP_MAX value (2147483647 - seems to be the current value on Win 7/8.1/10 I have access to), the following will push  the CPU to 100% for a very long time when run under a non-elevated shell:

--
import tempfile
tempfile.TemporaryFile(dir='C:\Windows')
... wait ...
--

In _mkstemp_inner() we should be testing for the filename, not parent directory here:

        except PermissionError:
            # This exception is thrown when a directory with the chosen name
            # already exists on windows.
            if (_os.name == 'nt' and _os.path.isdir(dir) and
                _os.access(dir, _os.W_OK)):
                continue

Changing the _os.path.isdir(dir) call to _os.path.isdir(filename) is all that is needed to prevent the death loop and function correctly in cases where Windows os.access(dir, _os.W_OK) claims we have write access when we do not.

----------
nosy: +Paul Doom
type: behavior -> resource usage

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

From report at bugs.python.org  Mon Dec  5 04:52:37 2016
From: report at bugs.python.org (Masayuki Yamamoto)
Date: Mon, 05 Dec 2016 09:52:37 +0000
Subject: [issue25658] PyThread assumes pthread_key_t is an integer,
 which is against POSIX
In-Reply-To: <1447861816.88.0.632584646231.issue25658@psf.upfronthosting.co.za>
Message-ID: <1480931557.7.0.386931450079.issue25658@psf.upfronthosting.co.za>


Masayuki Yamamoto added the comment:

I wrote a patch based on msg281227's idea.  I confirmed to pass related tests (test_capi, test_threading and test_tracemalloc) on Cygwin x86 and Ubuntu 16.04 x86.

This patch adds to change CPython about:

1. Avoid compile error on Currently TLS API.
   With POSIX threads, configure script checks pthread_key_t type. And if the type is not integer, TLS API is implemented empty (do nothing or return fail).
2. Implement New TSS API based on C11 threads.
   Thread key type is changed wrapped native TLS key type by typedef instead of integer, and the key parameter on key create function is changed to calling by pointer.  Key create function doesn't support destructor because users have need to manage memory.  And this patch changes Currently TLS API to call New TSS API. Or does it need to keep implementation?
3. Move to TSS API.
   Py_DEPRECATED(3.7) is added to TLS API declaration, and Modules/_tracemalloc.c and Python/pystate.c are modified to use TSS API instead of TLS API.

----------
Added file: http://bugs.python.org/file45763/pythread-tss.patch

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

From report at bugs.python.org  Mon Dec  5 04:54:59 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 05 Dec 2016 09:54:59 +0000
Subject: [issue28876] bool of large range raises OverflowError
In-Reply-To: <1480930662.45.0.497603219066.issue28876@psf.upfronthosting.co.za>
Message-ID: <1480931699.55.0.129547404941.issue28876@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

+1 for implementing nb_bool for range objects.

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

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

From report at bugs.python.org  Mon Dec  5 04:58:40 2016
From: report at bugs.python.org (James Matthews)
Date: Mon, 05 Dec 2016 09:58:40 +0000
Subject: [issue28877] Cannot compile _ssl.o on HP-UX
Message-ID: <1480931920.31.0.868439629841.issue28877@psf.upfronthosting.co.za>


New submission from James Matthews:

Cannot build Python 2.7.12 on HP-UX due to the following error:

/opt/hp-gcc64-4.7.1/bin/gcc -pthread -shared build/temp.hp-ux-B.11.31-9000-800-2.7/root/build/Python-2.7.12/Modules/_ssl.o -L/usr/local/lib -lssl -lcrypto -o build/lib.hp-ux-B.11.31-9000-800-2.7/_ssl.sl
/usr/lib/pa20_64/dld.sl: Unsatisfied code symbol 'CRYPTO_THREADID_set_callback' in load module 'build/lib.hp-ux-B.11.31-9000-800-2.7/_ssl.sl'.
/bin/sh: 23510 Killed
gmake: *** [sharedmods] Error 137

----------
components: Build
messages: 282406
nosy: James Matthews
priority: normal
severity: normal
status: open
title: Cannot compile _ssl.o on HP-UX
versions: Python 2.7

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

From report at bugs.python.org  Mon Dec  5 04:58:46 2016
From: report at bugs.python.org (Armin Rigo)
Date: Mon, 05 Dec 2016 09:58:46 +0000
Subject: [issue28427] WeakValueDictionary next bug (with multithreading)
In-Reply-To: <1476354989.22.0.575160455599.issue28427@psf.upfronthosting.co.za>
Message-ID: <1480931926.38.0.135309757706.issue28427@psf.upfronthosting.co.za>


Armin Rigo added the comment:

issue28427-atomic.patch: is it still necessary to modify weakref.py so much, then?

What I had in mind was a C function with Python signature "del_if_equal(dict, key, value)"; the C function doesn't need to know about weakrefs and checking if they are dead.  The C function would simply call PyObject_GetItem() and PyObject_DelItem()---without releasing the GIL in the middle.

----------

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

From report at bugs.python.org  Mon Dec  5 04:59:02 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 05 Dec 2016 09:59:02 +0000
Subject: [issue28864] Add devnull file-like object
In-Reply-To: <1480822595.87.0.853337900572.issue28864@psf.upfronthosting.co.za>
Message-ID: <1480931942.21.0.0502155238423.issue28864@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I had in mind a pre-opened file like sys.stderr or sys.stdout.

----------

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

From report at bugs.python.org  Mon Dec  5 05:22:08 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 05 Dec 2016 10:22:08 +0000
Subject: [issue28427] WeakValueDictionary next bug (with multithreading)
In-Reply-To: <1476354989.22.0.575160455599.issue28427@psf.upfronthosting.co.za>
Message-ID: <1480933328.48.0.229436939002.issue28427@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Hi Armin,

> is it still necessary to modify weakref.py so much, then?

Not sure. I'll take a look again. Modifying __len__() at least is necessary, as the previous version took into account the length of _pending_removals (and could therefore return wrong results). I'm inclined to be a bit defensive here.

> The C function would simply call PyObject_GetItem() and PyObject_DelItem()---without releasing the GIL in the middle.

If you implement it like that, and the dictionary has non-trivial keys with a user-defined __hash__, then the GIL can be released at the beginning of PyObject_DelItem().

----------

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

From report at bugs.python.org  Mon Dec  5 05:22:59 2016
From: report at bugs.python.org (Erik Bray)
Date: Mon, 05 Dec 2016 10:22:59 +0000
Subject: [issue25658] PyThread assumes pthread_key_t is an integer,
 which is against POSIX
In-Reply-To: <1447861816.88.0.632584646231.issue25658@psf.upfronthosting.co.za>
Message-ID: <1480933379.24.0.910064195993.issue25658@psf.upfronthosting.co.za>


Erik Bray added the comment:

I'm still pretty happy with the previous patch, personally, since I don't need the tracemalloc module.  But it seems like that should be fixed (or if nothing else that code in _tracemalloc.c should check Py_HAVE_NATIVE_TLS too).

I like the idea of the new PyThread_tss_ API.  At first I wasn't sure because I thought you implied that it would use tss_t and related APIs from C11 which was going to be a non-starter (as CPython has only just barely started using *some* features from C99, per the recent update to PEP 7).  But I see in your patch that the naming is only inspired by C11 (and could be consistent with it if CPython ever moves toward C11 support).

I imagine this will likely require a PEP though?  I would happy to help draft one.

----------

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

From report at bugs.python.org  Mon Dec  5 05:34:58 2016
From: report at bugs.python.org (Maciej Szulik)
Date: Mon, 05 Dec 2016 10:34:58 +0000
Subject: [issue25591] refactor imaplib tests
In-Reply-To: <1447107407.81.0.130095933409.issue25591@psf.upfronthosting.co.za>
Message-ID: <1480934098.52.0.568774118986.issue25591@psf.upfronthosting.co.za>


Maciej Szulik added the comment:

Thank you David, of course I'll remind you :)

----------

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

From report at bugs.python.org  Mon Dec  5 05:47:43 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 05 Dec 2016 10:47:43 +0000
Subject: [issue28876] bool of large range raises OverflowError
In-Reply-To: <1480930662.45.0.497603219066.issue28876@psf.upfronthosting.co.za>
Message-ID: <1480934863.85.0.643784261175.issue28876@psf.upfronthosting.co.za>


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


----------
nosy: +serhiy.storchaka
stage:  -> needs patch

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

From report at bugs.python.org  Mon Dec  5 05:48:19 2016
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 05 Dec 2016 10:48:19 +0000
Subject: [issue28638] Creating namedtuple is too slow to be used in common
 stdlib (e.g. functools)
In-Reply-To: <1478578044.23.0.961493371476.issue28638@psf.upfronthosting.co.za>
Message-ID: <1480934899.88.0.552751853151.issue28638@psf.upfronthosting.co.za>


INADA Naoki added the comment:

I think external cache system introduces more complexity and startup overhead than AC.

I think functools is the only "very common" module using namedtuple, because
`functools.wraps()` is used to create decorator functions.

But if general solution for all namedtuple is necessary to make agreement,
I think C implemented namedtuple may be better.
structseq is faster than namedtuple, not only when building type, but also
using instance.


$ ./python -m perf timeit -s 'import sys; vi = sys.version_info' -- 'vi.major, vi.minor, vi.micro'
.....................
Median +- std dev: 130 ns +- 2 ns

$ ./python -m perf timeit -s 'from collections import namedtuple; VersionInfo=namedtuple("VersionInfo", "major minor micro releaselevel serial"); vi=VersionInfo(3, 7, 0, "alpha", 0)' -- 'vi.major, vi.minor, vi.micro'
.....................
Median +- std dev: 212 ns +- 4 ns

----------

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

From report at bugs.python.org  Mon Dec  5 06:06:46 2016
From: report at bugs.python.org (Julien Palard)
Date: Mon, 05 Dec 2016 11:06:46 +0000
Subject: [issue28707] add 'directory' option to the http.server module
In-Reply-To: <1479249109.08.0.530385659795.issue28707@psf.upfronthosting.co.za>
Message-ID: <1480936006.79.0.662410626454.issue28707@psf.upfronthosting.co.za>


Changes by Julien Palard <julien+python at palard.fr>:


Added file: http://bugs.python.org/file45764/issue28707.diff

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

From report at bugs.python.org  Mon Dec  5 07:00:51 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 05 Dec 2016 12:00:51 +0000
Subject: [issue28873] test_unittest failures when refleak hunting
In-Reply-To: <1480921824.58.0.630803385181.issue28873@psf.upfronthosting.co.za>
Message-ID: <1480939251.04.0.785376846565.issue28873@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
stage: needs patch -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Dec  5 07:21:23 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 05 Dec 2016 12:21:23 +0000
Subject: [issue28875] test fails and freezes
In-Reply-To: <1480923867.51.0.993366895906.issue28875@psf.upfronthosting.co.za>
Message-ID: <1480940483.62.0.177315073409.issue28875@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Please do not reopen this one. You already opened issue 28874.

----------
nosy: +berker.peksag
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Dec  5 07:27:37 2016
From: report at bugs.python.org (Akira Li)
Date: Mon, 05 Dec 2016 12:27:37 +0000
Subject: [issue28876] bool of large range raises OverflowError
In-Reply-To: <1480930662.45.0.497603219066.issue28876@psf.upfronthosting.co.za>
Message-ID: <1480940857.27.0.271840570089.issue28876@psf.upfronthosting.co.za>


Akira Li added the comment:

Here's a patch with range_bool() implementation, tests and the docs update.

I'm not sure how it should be documented. I've specified it as 
versionchanged:: 3.6

----------
keywords: +patch
nosy: +akira
Added file: http://bugs.python.org/file45765/range_bool.patch

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

From report at bugs.python.org  Mon Dec  5 07:41:30 2016
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 05 Dec 2016 12:41:30 +0000
Subject: [issue28724] Add method send_io, recv_io to the socket module.
In-Reply-To: <1479395133.65.0.0720889900419.issue28724@psf.upfronthosting.co.za>
Message-ID: <1480941690.95.0.928387471199.issue28724@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Good idea! Initially I planned to add the functions and some other helpers around AF_UNIX to Python 3.6. You can directly copy the example functions from the documentation.

https://docs.python.org/3/library/socket.html#socket.socket.sendmsg
https://docs.python.org/3/library/socket.html#socket.socket.recvmsg

Please keep the names send_fds() and recv_fds(), and pass the message like in the examples. Some protocols use the payload to signal the count of fds. Your patch is also lacking unit tests and documentation update.

----------
nosy: +christian.heimes
stage:  -> needs patch

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

From report at bugs.python.org  Mon Dec  5 07:52:20 2016
From: report at bugs.python.org (sergem)
Date: Mon, 05 Dec 2016 12:52:20 +0000
Subject: [issue28878] datetime should not be a subclass of date
Message-ID: <1480942340.78.0.750693942086.issue28878@psf.upfronthosting.co.za>


New submission from sergem:

I have Python 3.5.2.

datetime is implemented as a subclass of date
(isinstance(datetime.datetime(2015,1,1), datetime.date) == True)

I suppose that violates Liskov substitution principle:

1. datetime and date cannot be compared via "<".
2. both of these classes have "isoformat()" method. And the meaning of these methods differ.

It means one cannot pass datetime to the function that expects date.

Also one cannot say that datetime "is a" date. 

I suppose datetime must not be a subclass of date.

----------
messages: 282416
nosy: sergem
priority: normal
severity: normal
status: open
title: datetime should not be a subclass of date
versions: Python 3.5

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

From report at bugs.python.org  Mon Dec  5 08:00:48 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 05 Dec 2016 13:00:48 +0000
Subject: [issue28878] datetime should not be a subclass of date
In-Reply-To: <1480942340.78.0.750693942086.issue28878@psf.upfronthosting.co.za>
Message-ID: <1480942848.77.0.262182878548.issue28878@psf.upfronthosting.co.za>


R. David Murray added the comment:

Right or wrong, this was a concious design choice.  If you wish to argue that it should be changed, you need to address it on the python-ideas mailing list (but look for previous threads about it there and on python-dev first).

----------
nosy: +r.david.murray
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Dec  5 08:13:09 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 05 Dec 2016 13:13:09 +0000
Subject: [issue28876] bool of large range raises OverflowError
In-Reply-To: <1480930662.45.0.497603219066.issue28876@psf.upfronthosting.co.za>
Message-ID: <1480943589.85.0.750453088226.issue28876@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> I'm not sure how it should be documented.

I think a change at this level probably isn't worth documenting in the official docs; it's enough that there's a Misc/NEWS entry for it.

----------

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

From report at bugs.python.org  Mon Dec  5 08:18:12 2016
From: report at bugs.python.org (sergem)
Date: Mon, 05 Dec 2016 13:18:12 +0000
Subject: [issue28878] datetime should not be a subclass of date
In-Reply-To: <1480942340.78.0.750693942086.issue28878@psf.upfronthosting.co.za>
Message-ID: <1480943892.64.0.449946186074.issue28878@psf.upfronthosting.co.za>


sergem added the comment:

Would you be so kind to point to me to the discussion/arguments for that choice? 

Also 
http://www.gossamer-threads.com/lists/python/python/1114426

----------
resolution: not a bug -> 

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

From report at bugs.python.org  Mon Dec  5 08:36:36 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Dec 2016 13:36:36 +0000
Subject: [issue28866] Unexpected behavior resulting from mro() and __setattr__
 in interactive mode
In-Reply-To: <1480862145.72.0.468660451957.issue28866@psf.upfronthosting.co.za>
Message-ID: <1480944996.39.0.89965544257.issue28866@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

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

From report at bugs.python.org  Mon Dec  5 09:03:48 2016
From: report at bugs.python.org (Eric N. Vander Weele)
Date: Mon, 05 Dec 2016 14:03:48 +0000
Subject: [issue28845] Clean up known issues for AIX
In-Reply-To: <1480542032.97.0.55863701863.issue28845@psf.upfronthosting.co.za>
Message-ID: <1480946628.56.0.587780857837.issue28845@psf.upfronthosting.co.za>


Eric N. Vander Weele added the comment:

I have been able to test the example without a segmentation fault.

$ python3.5
Python 3.5.2 (default, Nov 17 2016, 10:45:58) [C] on aix7
Type "help", "copyright", "credits" or "license" for more information.
>>> import curses
>>> from curses import panel
>>> def mkpanel(scr):
...         win = curses.newwin(8,8,1,1)
...         pan = panel.new_panel(win)
...
>>> curses.wrapper(mkpanel)
>>>

----------

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

From report at bugs.python.org  Mon Dec  5 09:18:28 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 05 Dec 2016 14:18:28 +0000
Subject: [issue28878] datetime should not be a subclass of date
In-Reply-To: <1480942340.78.0.750693942086.issue28878@psf.upfronthosting.co.za>
Message-ID: <1480947508.07.0.594026317491.issue28878@psf.upfronthosting.co.za>


R. David Murray added the comment:

Hmm.  I thought there was a PEP, but maybe datetime was from before PEPs because I did find a PEP when I searched.  I don't have specific pointers to discussion, that's why I suggested you search first.  I'm pretty sure I remember a discussion of this some time in the past five years, but I have no idea which list it took place on.  If you don't find any relevant thread, start one.  I'm going to nosy Tim Peters and Andrew Belopolsky; they may be able to save you some time by speaking directly to the issue.

However, changing this is probably ruled out by backward compatibility concerns, regardless of anyone's (modern) opinion on the design.

----------
nosy: +belopolsky, tim.peters

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

From report at bugs.python.org  Mon Dec  5 10:27:00 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Mon, 05 Dec 2016 15:27:00 +0000
Subject: [issue28864] Add devnull file-like object
In-Reply-To: <1480822595.87.0.853337900572.issue28864@psf.upfronthosting.co.za>
Message-ID: <1480951620.76.0.324164900437.issue28864@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

Didn't pre-opened (or lazily opened) file descriptors cause headaches with os.urandom? I'm not sure I'd want my programming environment eating file descriptors "just in case", even if it might make certain tasks trivially faster after startup.

----------
nosy: +josh.r

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

From report at bugs.python.org  Mon Dec  5 10:35:37 2016
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 05 Dec 2016 15:35:37 +0000
Subject: [issue28864] Add devnull file-like object
In-Reply-To: <1480822595.87.0.853337900572.issue28864@psf.upfronthosting.co.za>
Message-ID: <1480952137.43.0.606836314856.issue28864@psf.upfronthosting.co.za>


Christian Heimes added the comment:

It can be done with some extra effort. We have to get the st_dev and st_inode from os.fstat(fd), cache them together with the fd, and verify them every time we create a new DevNull object. That way we catch both closed fd and modified fd. We might have to add a lock around the check, too.

----------
nosy: +christian.heimes

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

From report at bugs.python.org  Mon Dec  5 10:36:54 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Dec 2016 15:36:54 +0000
Subject: [issue28864] Add devnull file-like object
In-Reply-To: <1480822595.87.0.853337900572.issue28864@psf.upfronthosting.co.za>
Message-ID: <1480952214.34.0.407211579005.issue28864@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

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

From report at bugs.python.org  Mon Dec  5 10:46:12 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 05 Dec 2016 15:46:12 +0000
Subject: [issue28864] Add devnull file-like object
In-Reply-To: <1480822595.87.0.853337900572.issue28864@psf.upfronthosting.co.za>
Message-ID: <1480952772.5.0.379393331757.issue28864@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Which begs the question: what's the point? As David said, `open(os.devnull)` is a reasonably obvious way to do it. Is there a use case that it doesn't satisfy?

----------

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

From report at bugs.python.org  Mon Dec  5 10:48:15 2016
From: report at bugs.python.org (Henning von Bargen)
Date: Mon, 05 Dec 2016 15:48:15 +0000
Subject: [issue28879] smtplib RFC 5322 date header missing
Message-ID: <1480952895.22.0.418354723664.issue28879@psf.upfronthosting.co.za>


New submission from Henning von Bargen:

I'm using CPython 2.7 with the smtplib and email modules to send emails with SMTP.
Today, one of our clients complained that the email sent is not RFC 5322 compliant because the required Date header is missing. The RFC states in section 3.6.:

"The only required header fields are the origination date field and
 the originator address field(s).  All other header fields are
  syntactically optional."

Our program has been sending millions of email message this way and this is the first complaint.

I guess that the library doesn't add the header field automatically.

----------
components: Library (Lib)
messages: 282425
nosy: Henning.von.Bargen
priority: normal
severity: normal
status: open
title: smtplib RFC 5322 date header missing
versions: Python 2.7

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

From report at bugs.python.org  Mon Dec  5 11:13:21 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 05 Dec 2016 16:13:21 +0000
Subject: [issue28858] Fastcall uses more C stack
In-Reply-To: <1480665267.65.0.416366810047.issue28858@psf.upfronthosting.co.za>
Message-ID: <20161205161308.30631.15020.C3BF2427@psf.io>


Roundup Robot added the comment:

New changeset 4171cc26272c by Victor Stinner in branch 'default':
Issue #28858: Remove _PyObject_CallArg1() macro
https://hg.python.org/cpython/rev/4171cc26272c

----------

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

From report at bugs.python.org  Mon Dec  5 11:14:29 2016
From: report at bugs.python.org (Peter Waller)
Date: Mon, 05 Dec 2016 16:14:29 +0000
Subject: [issue15812] inspect.getframeinfo() cannot show first line
In-Reply-To: <1346252079.7.0.669819400342.issue15812@psf.upfronthosting.co.za>
Message-ID: <1480954469.81.0.694464736644.issue15812@psf.upfronthosting.co.za>


Peter Waller added the comment:

I have just hit this bug and independently invented the exact fix of changing the zero for a one. Any chance of getting this merged?

----------
nosy: +Peter.Waller

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

From report at bugs.python.org  Mon Dec  5 11:23:19 2016
From: report at bugs.python.org (Armin Rigo)
Date: Mon, 05 Dec 2016 16:23:19 +0000
Subject: [issue28427] WeakValueDictionary next bug (with multithreading)
In-Reply-To: <1476354989.22.0.575160455599.issue28427@psf.upfronthosting.co.za>
Message-ID: <1480954999.02.0.480038213092.issue28427@psf.upfronthosting.co.za>


Armin Rigo added the comment:

I think the issue of __len__() is a different matter.  More below.

>> The C function would simply call PyObject_GetItem() and
>> PyObject_DelItem()---without releasing the GIL in the middle.
>
> If you implement it like that, and the dictionary has non-trivial
> keys with a user-defined __hash__, then the GIL can be released
> at the beginning of PyObject_DelItem().

Right, I see your point: your version will, in any case, remove only a dead weakref as a dictionary value.  +1

Now about __len__() returning a wrong result: it is a more complicated issue, I fear.  I already patched weakref.py inside PyPy in order to pass a unit test inside CPython's test suite.  This patch is to change __len__ to look like this:

    def __len__(self):
        # PyPy change: we can't rely on len(self.data) at all, because
        # the weakref callbacks may be called at an unknown later time.
        result = 0
        for wr in self.data.values():
            result += (wr() is not None)
        return result

The problem is the delay between the death of a weakref and the actual invocation of the callback, which is systematic on PyPy but can be observed on CPython in some cases too.  It means that code like this may fail:

     if list(d) == []:
         assert len(d) == 0

because list(d) might indeed be empty, but some callbacks have not been called so far and so any simple formula in __len__() will fail to account for that.  ('issue28427-atomic.patch' does not help for that, but I might have missed a different case where it does help.)

----------

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

From report at bugs.python.org  Mon Dec  5 11:23:31 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 05 Dec 2016 16:23:31 +0000
Subject: [issue28879] smtplib RFC 5322 date header missing
In-Reply-To: <1480952895.22.0.418354723664.issue28879@psf.upfronthosting.co.za>
Message-ID: <1480955011.16.0.728307611731.issue28879@psf.upfronthosting.co.za>


R. David Murray added the comment:

That is correct.  Most SMTP gateways add the header on submission if it is missing.  At least a few other MUA programs do not automatically add the Date header, they let the SMTP server do it.  I have one person who sends me email that saw this same problem (I had my server set to reject messages without the date header), and they weren't using smtplib to send.  (I think the sender used Exchange, though I don't remember for sure.)

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

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

From report at bugs.python.org  Mon Dec  5 11:28:04 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Dec 2016 16:28:04 +0000
Subject: [issue28866] Unexpected behavior resulting from mro() and __setattr__
 in interactive mode
In-Reply-To: <1480862145.72.0.468660451957.issue28866@psf.upfronthosting.co.za>
Message-ID: <1480955284.44.0.458091424465.issue28866@psf.upfronthosting.co.za>


STINNER Victor added the comment:

If you call sys._clear_type_cache() after the setattr(), weird_without_interactive.py doesn't crash anymore.

----------

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

From report at bugs.python.org  Mon Dec  5 11:31:44 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Dec 2016 16:31:44 +0000
Subject: [issue28852] sorted(range(1000)) is slower in Python 3.7 than in 3.5
In-Reply-To: <1480609287.7.0.199610846669.issue28852@psf.upfronthosting.co.za>
Message-ID: <1480955504.12.0.00405945597267.issue28852@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> not a bug
status: open -> closed

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

From report at bugs.python.org  Mon Dec  5 11:38:17 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Dec 2016 16:38:17 +0000
Subject: [issue28838] Uniformize argument names of "call" functions (C API)
In-Reply-To: <1480504437.73.0.907175245586.issue28838@psf.upfronthosting.co.za>
Message-ID: <1480955897.25.0.718593728245.issue28838@psf.upfronthosting.co.za>


STINNER Victor added the comment:

So, what do you think of renaming argument like:

* Replace "callable_object" and "func" with "callable"
* Replace "method" with "name"
* Rename "o" to "obj" (ex: in "PyCallable_Check(PyObject *o)")

I prefer "callable_object" over "callable" because it's shorter. Some functions already use "callable" (and so others use "callable_object").


Eric: ""Isn't this just a lot of churn for not a lot of benefit? I'm all for consistency, but you'll break patches on the bug tracker and externally maintained patches."

I'm not aware of any pending patch on "call" functions like PyObject_Call. I think that I am the latest who modified these functions. I'm working on a new patch serie to add support for fast calls in tp_call. That's why I would prefer to uniformize argument names first, before rebasing my large patch.

----------

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

From report at bugs.python.org  Mon Dec  5 11:38:44 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 05 Dec 2016 16:38:44 +0000
Subject: [issue28427] WeakValueDictionary next bug (with multithreading)
In-Reply-To: <1476354989.22.0.575160455599.issue28427@psf.upfronthosting.co.za>
Message-ID: <1480955924.11.0.985119175359.issue28427@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> Now about __len__() returning a wrong result: it is a more complicated issue, I fear.  I already patched weakref.py inside PyPy in order to pass a unit test inside CPython's test suite.  This patch is to change __len__ to look like this: [...]

Thanks for the explanation. Yes, you are right on the principle. But there is also a general expectation that len() on an in-memory container is a O(1) operation, not O(n) - this change would break that expectation quite heavily.

I don't know how to fix len() without losing O(1) performance. It seems we're in a bit of a quandary on this topic. However, we can still fix the other issues.

----------

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

From report at bugs.python.org  Mon Dec  5 11:43:43 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Dec 2016 16:43:43 +0000
Subject: [issue28765] _sre.compile(): be more strict on types of indexgroup
 and groupindex
In-Reply-To: <1479743857.98.0.418828964214.issue28765@psf.upfronthosting.co.za>
Message-ID: <1480956223.03.0.43812507954.issue28765@psf.upfronthosting.co.za>


STINNER Victor added the comment:

sre-concrete-2.patch LGTM, so do you want to push it Serhiy?

----------

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

From report at bugs.python.org  Mon Dec  5 11:50:49 2016
From: report at bugs.python.org (Armin Rigo)
Date: Mon, 05 Dec 2016 16:50:49 +0000
Subject: [issue28427] WeakValueDictionary next bug (with multithreading)
In-Reply-To: <1476354989.22.0.575160455599.issue28427@psf.upfronthosting.co.za>
Message-ID: <1480956649.02.0.135399386356.issue28427@psf.upfronthosting.co.za>


Armin Rigo added the comment:

Agreed about fixing the other issues.  I'm still unclear that we need anything more than just the _remove_dead_weakref function to do that, but also, I don't see a particular problem with adding self._commit_removals() a bit everywhere.

About the O(1) expectation for len(): it's still unclear if it is better to give a precise answer or if an over-estimate is usually enough.  I can see of no reasonable use for a precise answer---e.g. code like this

    while len(d) > 0:
        do_stuff(d.popitem())

is broken anyway, because a weakref might really die between len(d) and d.popitem().  But on the other hand it makes tests behave strangely.  Maybe the correct answer is that such tests are wrong---then I'd be happy to revert the PyPy-specific change to __len__() and fix the test instead.  Or maybe weakdicts should always raise in __len__(), and instead have a method .length_upper_bound().

----------

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

From report at bugs.python.org  Mon Dec  5 11:56:58 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 05 Dec 2016 16:56:58 +0000
Subject: [issue28765] _sre.compile(): be more strict on types of indexgroup
 and groupindex
In-Reply-To: <1479743857.98.0.418828964214.issue28765@psf.upfronthosting.co.za>
Message-ID: <1480957018.12.0.938378927057.issue28765@psf.upfronthosting.co.za>


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


----------
superseder:  -> _sre.compile(): be more strict on types of indexgroup and groupindex

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

From report at bugs.python.org  Mon Dec  5 11:57:07 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 05 Dec 2016 16:57:07 +0000
Subject: [issue28765] _sre.compile(): be more strict on types of indexgroup
 and groupindex
In-Reply-To: <1479743857.98.0.418828964214.issue28765@psf.upfronthosting.co.za>
Message-ID: <1480957027.23.0.489477449647.issue28765@psf.upfronthosting.co.za>


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


----------
superseder: _sre.compile(): be more strict on types of indexgroup and groupindex -> 

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

From report at bugs.python.org  Mon Dec  5 11:57:57 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 05 Dec 2016 16:57:57 +0000
Subject: [issue28152] Clang warnings: code will never be executed
In-Reply-To: <1473860733.22.0.899787116787.issue28152@psf.upfronthosting.co.za>
Message-ID: <20161205165753.21547.54293.FB84B6EB@psf.io>


Roundup Robot added the comment:

New changeset b3f1210d098d by Victor Stinner in branch 'default':
Issue #28152: Fix -Wunreachable-code warnings on Clang
https://hg.python.org/cpython/rev/b3f1210d098d

New changeset 390fbb9c5e59 by Victor Stinner in branch 'default':
Issue #28152: Fix -Wunreachable-code warning on clang
https://hg.python.org/cpython/rev/390fbb9c5e59

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

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

From report at bugs.python.org  Mon Dec  5 12:03:13 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 05 Dec 2016 17:03:13 +0000
Subject: [issue28152] Clang warnings: code will never be executed
In-Reply-To: <1473860733.22.0.899787116787.issue28152@psf.upfronthosting.co.za>
Message-ID: <20161205170309.29039.8783.3574B358@psf.io>


Roundup Robot added the comment:

New changeset 7c7055305f69 by Victor Stinner in branch 'default':
Issue #28152: Fix -Wunreachable-code warning on clang
https://hg.python.org/cpython/rev/7c7055305f69

----------

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

From report at bugs.python.org  Mon Dec  5 12:05:19 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Dec 2016 17:05:19 +0000
Subject: [issue28152] Clang warnings: code will never be executed
In-Reply-To: <1473860733.22.0.899787116787.issue28152@psf.upfronthosting.co.za>
Message-ID: <1480957519.52.0.731793510531.issue28152@psf.upfronthosting.co.za>


STINNER Victor added the comment:

My commits fixed all warnings using clang 3.8.0 on Fedora 25.

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

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

From report at bugs.python.org  Mon Dec  5 12:07:10 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Dec 2016 17:07:10 +0000
Subject: [issue28050] test_traceback is broken by new CALL_FUNCTION* opcodes
In-Reply-To: <1473448291.52.0.407071935548.issue28050@psf.upfronthosting.co.za>
Message-ID: <1480957630.67.0.740832743575.issue28050@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oh, this issue was already fixed, thanks Serhiy :-)

changeset:   103659:51b635e81958
user:        Serhiy Storchaka <storchaka at gmail.com>
date:        Mon Sep 12 00:52:40 2016 +0300
files:       Include/abstract.h Lib/dis.py Lib/test/test_extcall.py Lib/test/test_traceback.py Objects/abstract.c Objects/methodobject.c Python/ceval.c Python/compile.c Python/importlib.h Python/imp
description:
Issue #27213: Fixed different issues with reworked CALL_FUNCTION* opcodes.

* BUILD_TUPLE_UNPACK and BUILD_MAP_UNPACK_WITH_CALL no longer generated with
  single tuple or dict.
* Restored more informative error messages for incorrect var-positional and
  var-keyword arguments.
* Removed code duplications in _PyEval_EvalCodeWithName().
* Removed redundant runtime checks and parameters in _PyStack_AsDict().
* Added a workaround and enabled previously disabled test in test_traceback.
* Removed dead code from the dis module.

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

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

From report at bugs.python.org  Mon Dec  5 12:12:20 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 05 Dec 2016 17:12:20 +0000
Subject: [issue28152] Clang warnings: code will never be executed
In-Reply-To: <1473860733.22.0.899787116787.issue28152@psf.upfronthosting.co.za>
Message-ID: <1480957940.18.0.638756566985.issue28152@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thanks Victor.

----------

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

From report at bugs.python.org  Mon Dec  5 12:19:07 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 05 Dec 2016 17:19:07 +0000
Subject: [issue28050] test_traceback is broken by new CALL_FUNCTION* opcodes
In-Reply-To: <1473448291.52.0.407071935548.issue28050@psf.upfronthosting.co.za>
Message-ID: <1480958347.93.0.871425360128.issue28050@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

It is rather worked around.

----------

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

From report at bugs.python.org  Mon Dec  5 12:27:41 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Dec 2016 17:27:41 +0000
Subject: [issue28050] test_traceback is broken by new CALL_FUNCTION* opcodes
In-Reply-To: <1480958347.93.0.871425360128.issue28050@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbhDk9CJmHtmGcpbeoSmvQ5LoDZpM+ohvCFHLXy=bFq5w@mail.gmail.com>


STINNER Victor added the comment:

Serhiy Storchaka added the comment:
> It is rather worked around.

The test pass, the change looks good to me. I don't think that it's
still worth it to keep the issue open ;-)

----------

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

From report at bugs.python.org  Mon Dec  5 12:31:15 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Dec 2016 17:31:15 +0000
Subject: [issue27829] test.regrtest: changed environment variables are not
 logged
In-Reply-To: <1471868275.54.0.211153776881.issue27829@psf.upfronthosting.co.za>
Message-ID: <1480959075.66.0.643460580888.issue27829@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


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

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

From report at bugs.python.org  Mon Dec  5 12:34:10 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Dec 2016 17:34:10 +0000
Subject: [issue27864] test_socket: unknown thread blocks forever on "AMD64
 FreeBSD 9.x 3.x"
In-Reply-To: <1472162165.25.0.11856143467.issue27864@psf.upfronthosting.co.za>
Message-ID: <1480959250.18.0.0304491622404.issue27864@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Sadly, such bug is hard to reproduce. I didn't look at buildbots recently, and I don't have access to FreeBSD 9, so I just close the issue :-/

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

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

From report at bugs.python.org  Mon Dec  5 12:34:49 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Dec 2016 17:34:49 +0000
Subject: [issue27791] test_threading: test_threads_join_2() failed with "Fatal
 Python error: Py_EndInterpreter: not the last thread"
In-Reply-To: <1471470171.51.0.873764356804.issue27791@psf.upfronthosting.co.za>
Message-ID: <1480959289.08.0.736098710514.issue27791@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Sadly, such bug is hard to reproduce. I didn't look at buildbots recently, and I don't have access to FreeBSD, so I just close the issue :-/

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

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

From report at bugs.python.org  Mon Dec  5 12:35:40 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Dec 2016 17:35:40 +0000
Subject: [issue27784] Random failure of test_TCPServer() of
 test.test_socketserver.SocketServerTest and test_handle_accept() of
 test.test_asyncore.TestAPI_UseIPv6Select on FreeBSD buildbots
In-Reply-To: <1471422222.08.0.731040607027.issue27784@psf.upfronthosting.co.za>
Message-ID: <1480959340.06.0.0951195814716.issue27784@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I didn't look at buildbots recently, and I don't have access to FreeBSD, so I just close the issue :-/

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

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

From report at bugs.python.org  Mon Dec  5 12:36:15 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Dec 2016 17:36:15 +0000
Subject: [issue27367] Windows buildbot: random timeout failure on
 test_threading
In-Reply-To: <1466584186.93.0.689178719863.issue27367@psf.upfronthosting.co.za>
Message-ID: <1480959375.07.0.283023305395.issue27367@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Such bug is random. It's hard to reproduce. I don't have access to Windows right now, so I just close the issue.

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

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

From report at bugs.python.org  Mon Dec  5 12:43:32 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Dec 2016 17:43:32 +0000
Subject: [issue26769] Python 2.7: make private file descriptors non inheritable
In-Reply-To: <1460725141.7.0.638632202912.issue26769@psf.upfronthosting.co.za>
Message-ID: <1480959811.99.0.479815688384.issue26769@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Sorry, I loose interest on this backport. The patch is large, the risk of regression is high, the goal is non-obvious. I'm not sure that such bugfix is still useful since Python 2.7 is old and developers know how to workaround Python 2.7 limitations.

The problem of non-inheritable file descriptors is that it requires to modify a lot of code, not only a few functions.

For all these reasons, I prefer to close the issue as WONTFIX.

----------
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Mon Dec  5 12:45:34 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Dec 2016 17:45:34 +0000
Subject: [issue28858] Fastcall uses more C stack
In-Reply-To: <1480665267.65.0.416366810047.issue28858@psf.upfronthosting.co.za>
Message-ID: <1480959934.46.0.527769447085.issue28858@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The changeset 4171cc26272c "Remove _PyObject_CallArg1() macro" fixed the initial bug report, so I now close the issue.

Serhiy: If you see further enhancements, please open a new issue. Your second stack_overflow.py script is interesting, but I don't see any obvious possible changes to enhance results.

Thanks Serhiy for digging into this issue ;-)

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

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

From report at bugs.python.org  Mon Dec  5 12:46:18 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Dec 2016 17:46:18 +0000
Subject: [issue26566] Failures on FreeBSD CURRENT buildbot
In-Reply-To: <1458035226.03.0.186362831064.issue26566@psf.upfronthosting.co.za>
Message-ID: <1480959978.66.0.979807368483.issue26566@psf.upfronthosting.co.za>


STINNER Victor added the comment:

This random failure is just too old, I close the issue.

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

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

From report at bugs.python.org  Mon Dec  5 13:22:00 2016
From: report at bugs.python.org (John Henning)
Date: Mon, 05 Dec 2016 18:22:00 +0000
Subject: [issue28880] range(i, j) doesn't work
Message-ID: <1480962120.7.0.536761585872.issue28880@psf.upfronthosting.co.za>


New submission from John Henning:

When attempting to use range(I, j) command in Windows 10 command prompt, the latest version of Python would simply echo what was typed.  See below:

>>> range(7)
range(0, 7)
>>> range(0, 9)
range(0, 9)
>>> range(1, 10, 3)
range(1, 10, 3)
>>>

----------
components: Regular Expressions
messages: 282449
nosy: ezio.melotti, genetics_jo, mrabarnett
priority: normal
severity: normal
status: open
title: range(i, j) doesn't work
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Mon Dec  5 13:42:56 2016
From: report at bugs.python.org (Matthew Barnett)
Date: Mon, 05 Dec 2016 18:42:56 +0000
Subject: [issue28880] range(i, j) doesn't work
In-Reply-To: <1480962120.7.0.536761585872.issue28880@psf.upfronthosting.co.za>
Message-ID: <1480963376.64.0.702295932953.issue28880@psf.upfronthosting.co.za>


Matthew Barnett added the comment:

Not a bug.

Python 2 had 'range', which returned a list, and 'xrange', which returned an xrange object which was iterable:

>>> range(7)
[0, 1, 2, 3, 4, 5, 6]
>>> xrange(7)
xrange(7)
>>> list(xrange(7))
[0, 1, 2, 3, 4, 5, 6]

In Python 3, 'range' was dropped and 'xrange' was renamed to 'range':

>>> range(7)
range(0, 7)
>>> list(range(7))
[0, 1, 2, 3, 4, 5, 6]

BTW, that's not the Windows command prompt, that's the Python prompt.

----------
components: +Interpreter Core -Regular Expressions

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

From report at bugs.python.org  Mon Dec  5 13:51:06 2016
From: report at bugs.python.org (John Henning)
Date: Mon, 05 Dec 2016 18:51:06 +0000
Subject: [issue28880] range(i, j) doesn't work
In-Reply-To: <1480962120.7.0.536761585872.issue28880@psf.upfronthosting.co.za>
Message-ID: <1480963866.63.0.475496093421.issue28880@psf.upfronthosting.co.za>


John Henning added the comment:

Right about the command prompt!  My bad.  However, the new language you provided gives me the following:

>>> list(range(9))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'list' object is not callable
>>> list(range(0, 10))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'list' object is not callable
>>> list(range(0, 10, 2))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'list' object is not callable
>>>

----------

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

From report at bugs.python.org  Mon Dec  5 13:54:01 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 05 Dec 2016 18:54:01 +0000
Subject: [issue28880] range(i, j) doesn't work
In-Reply-To: <1480962120.7.0.536761585872.issue28880@psf.upfronthosting.co.za>
Message-ID: <1480964041.28.0.0977432287646.issue28880@psf.upfronthosting.co.za>


R. David Murray added the comment:

Presumably you use 'list' as a variable name earlier in your interactive session.  Try restarting your python shell.

----------
nosy: +r.david.murray
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Dec  5 13:57:38 2016
From: report at bugs.python.org (John Henning)
Date: Mon, 05 Dec 2016 18:57:38 +0000
Subject: [issue28880] range(i, j) doesn't work
In-Reply-To: <1480962120.7.0.536761585872.issue28880@psf.upfronthosting.co.za>
Message-ID: <1480964258.94.0.564577665315.issue28880@psf.upfronthosting.co.za>


John Henning added the comment:

Ha!  Thanks!  Restarted python and now that works.  Sorry for the trouble!  Trying to teach myself python working through the python tutorial and hit this problem.

----------

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

From report at bugs.python.org  Mon Dec  5 14:04:09 2016
From: report at bugs.python.org (Vitold S)
Date: Mon, 05 Dec 2016 19:04:09 +0000
Subject: [issue28881] int no attribute 'lower'
Message-ID: <1480964649.95.0.801978620213.issue28881@psf.upfronthosting.co.za>


New submission from Vitold S:

I have MIME message and parse content. Later I walk on message headers by call for and receive follow traceback:

Traceback (most recent call last):
...
    for m in msg:  (msg is email.message.Message instance)
  File "C:\Python27\lib\email\message.py", line 294, in __getitem__
    return self.get(name)
  File "C:\Python27\lib\email\message.py", line 360, in get
    name = name.lower()
AttributeError: 'int' object has no attribute 'lower'

But with items() all work properly.

----------
components: email
messages: 282454
nosy: Vitold S, barry, r.david.murray
priority: normal
severity: normal
status: open
title: int no attribute 'lower'
versions: Python 2.7

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

From report at bugs.python.org  Mon Dec  5 14:25:58 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 05 Dec 2016 19:25:58 +0000
Subject: [issue28881] int no attribute 'lower'
In-Reply-To: <1480964649.95.0.801978620213.issue28881@psf.upfronthosting.co.za>
Message-ID: <1480965958.96.0.799392661921.issue28881@psf.upfronthosting.co.za>


R. David Murray added the comment:

It looks like your 'name' variable holds an integer, not a string giving a header name.

----------

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

From report at bugs.python.org  Mon Dec  5 14:27:09 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 05 Dec 2016 19:27:09 +0000
Subject: [issue28881] int no attribute 'lower'
In-Reply-To: <1480964649.95.0.801978620213.issue28881@psf.upfronthosting.co.za>
Message-ID: <1480966029.01.0.152254673729.issue28881@psf.upfronthosting.co.za>


R. David Murray added the comment:

Oh, I think I misread your traceback.

Can you provide the actual code you are running, please?  And probably the message you are parsing, as well.

----------

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

From report at bugs.python.org  Mon Dec  5 14:41:14 2016
From: report at bugs.python.org (Ned Deily)
Date: Mon, 05 Dec 2016 19:41:14 +0000
Subject: [issue28872] test_builtin failures when refleak hunting
In-Reply-To: <1480921723.59.0.457276441152.issue28872@psf.upfronthosting.co.za>
Message-ID: <1480966874.5.0.804592083491.issue28872@psf.upfronthosting.co.za>


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


----------
assignee: ned.deily -> 
stage: needs patch -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Dec  5 14:42:22 2016
From: report at bugs.python.org (Ned Deily)
Date: Mon, 05 Dec 2016 19:42:22 +0000
Subject: [issue28873] test_unittest failures when refleak hunting
In-Reply-To: <1480921824.58.0.630803385181.issue28873@psf.upfronthosting.co.za>
Message-ID: <1480966942.19.0.618412582944.issue28873@psf.upfronthosting.co.za>


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


----------
assignee: ned.deily -> 

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

From report at bugs.python.org  Mon Dec  5 14:43:48 2016
From: report at bugs.python.org (Ned Deily)
Date: Mon, 05 Dec 2016 19:43:48 +0000
Subject: [issue23722] During metaclass.__init__,
 super() of the constructed class does not work
In-Reply-To: <1426859061.43.0.510286082444.issue23722@psf.upfronthosting.co.za>
Message-ID: <1480967028.89.0.321924282516.issue23722@psf.upfronthosting.co.za>


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


----------
assignee: ned.deily -> 
priority: release blocker -> 

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

From report at bugs.python.org  Mon Dec  5 14:52:11 2016
From: report at bugs.python.org (Ned Deily)
Date: Mon, 05 Dec 2016 19:52:11 +0000
Subject: [issue28797] Modifying class __dict__ inside __set_name__
In-Reply-To: <1480042109.13.0.341330811366.issue28797@psf.upfronthosting.co.za>
Message-ID: <1480967531.73.0.75317715991.issue28797@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Dec  5 15:07:09 2016
From: report at bugs.python.org (Ned Deily)
Date: Mon, 05 Dec 2016 20:07:09 +0000
Subject: [issue28808] Make PyUnicode_CompareWithASCIIString() never failing
In-Reply-To: <1480175314.71.0.35688135657.issue28808@psf.upfronthosting.co.za>
Message-ID: <1480968429.88.0.938437567537.issue28808@psf.upfronthosting.co.za>


Ned Deily added the comment:

This is currently blocking 360rc1.  Victor, Serhiy, we either need to get this in now or wait until 3.6.1.  I am leaning towards pushing the latest patch for 3.6 without having a decision about 3.5 yet.

----------

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

From report at bugs.python.org  Mon Dec  5 15:10:21 2016
From: report at bugs.python.org (Ned Deily)
Date: Mon, 05 Dec 2016 20:10:21 +0000
Subject: [issue28835] Change in behavior when overriding warnings.showwarning
 and with catch_warnings(record=True)
In-Reply-To: <1480465767.99.0.401403947818.issue28835@psf.upfronthosting.co.za>
Message-ID: <1480968621.65.0.302967973576.issue28835@psf.upfronthosting.co.za>


Ned Deily added the comment:

What's the status of this issue?  It's currently blocking 360rc1.  We either need a resolution now or defer it to 3.6.1.

----------

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

From report at bugs.python.org  Mon Dec  5 15:16:44 2016
From: report at bugs.python.org (Ned Deily)
Date: Mon, 05 Dec 2016 20:16:44 +0000
Subject: [issue28089] Document TCP_NODELAY by default
Message-ID: <1480969004.54.0.512137578278.issue28089@psf.upfronthosting.co.za>


New submission from Ned Deily:

This is marked as a release blocker but, since it's just a doc change, I'm not going to hold 3.6.0 for it.  It would be nice to get it in, though.

----------
priority: release blocker -> deferred blocker

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

From report at bugs.python.org  Mon Dec  5 15:18:46 2016
From: report at bugs.python.org (Ned Deily)
Date: Mon, 05 Dec 2016 20:18:46 +0000
Subject: [issue28091] Document PEP 525
Message-ID: <1480969126.04.0.359710564403.issue28091@psf.upfronthosting.co.za>


New submission from Ned Deily:

Yuri, are you planning to do more for this for 3.6.0?  This is marked as a release blocker but, since it's just a doc change, I'm not going to hold 3.6.0 for it.

----------
priority: release blocker -> deferred blocker

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

From report at bugs.python.org  Mon Dec  5 15:19:46 2016
From: report at bugs.python.org (Ned Deily)
Date: Mon, 05 Dec 2016 20:19:46 +0000
Subject: [issue28091] Document PEP 525
In-Reply-To: <1480969126.04.0.359710564403.issue28091@psf.upfronthosting.co.za>
Message-ID: <1480969186.28.0.879526881588.issue28091@psf.upfronthosting.co.za>


Ned Deily added the comment:

Yury, are you planning to do more for this for 3.6.0?  This is marked as a release blocker but, since it's just a doc change, I'm not going to hold 3.6.0 for it.

----------

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

From report at bugs.python.org  Mon Dec  5 15:19:53 2016
From: report at bugs.python.org (Ned Deily)
Date: Mon, 05 Dec 2016 20:19:53 +0000
Subject: [issue28091] Document PEP 525
In-Reply-To: <1480969186.28.0.879526881588.issue28091@psf.upfronthosting.co.za>
Message-ID: <1480969193.03.0.411747861421.issue28091@psf.upfronthosting.co.za>


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


----------
Removed message: http://bugs.python.org/msg282460

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

From report at bugs.python.org  Mon Dec  5 15:21:26 2016
From: report at bugs.python.org (Ned Deily)
Date: Mon, 05 Dec 2016 20:21:26 +0000
Subject: [issue28090] Document PEP 530
Message-ID: <1480969286.88.0.896640535398.issue28090@psf.upfronthosting.co.za>


New submission from Ned Deily:

Yury, are you planning to do more for this for 3.6.0?  This is marked as a release blocker but, since it's just a doc change, I'm not going to hold 3.6.0 for it.

----------
priority: release blocker -> deferred blocker
versions: +Python 3.7

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

From report at bugs.python.org  Mon Dec  5 15:21:36 2016
From: report at bugs.python.org (Ned Deily)
Date: Mon, 05 Dec 2016 20:21:36 +0000
Subject: [issue28091] Document PEP 525
In-Reply-To: <1480969186.28.0.879526881588.issue28091@psf.upfronthosting.co.za>
Message-ID: <1480969296.49.0.306760010327.issue28091@psf.upfronthosting.co.za>


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


----------
versions: +Python 3.7

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

From report at bugs.python.org  Mon Dec  5 15:34:36 2016
From: report at bugs.python.org (Ned Deily)
Date: Mon, 05 Dec 2016 20:34:36 +0000
Subject: [issue28518] execute("begin immediate") throwing OperationalError
In-Reply-To: <1477307118.31.0.70785963389.issue28518@psf.upfronthosting.co.za>
Message-ID: <1480970076.56.0.530075999249.issue28518@psf.upfronthosting.co.za>


Ned Deily added the comment:

Thanks everyone for investigating this, in particular Big Stone for the reference to the SQLite project and especially Richard Hipp for once again responding quickly to issues we've brought up.  While it would be good to get this resolved soon one way or another (doc and/or code changes), it doesn't sound like it needs to be a release blocker for 3.6.0 so I'm lowering its priority.

----------
priority: release blocker -> high
stage:  -> patch review

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

From report at bugs.python.org  Mon Dec  5 15:56:22 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 05 Dec 2016 20:56:22 +0000
Subject: [issue28880] range(i, j) doesn't work
In-Reply-To: <1480962120.7.0.536761585872.issue28880@psf.upfronthosting.co.za>
Message-ID: <1480971382.59.0.343924973087.issue28880@psf.upfronthosting.co.za>


Steven D'Aprano added the comment:

Hi John, and thanks for the bug report. If only they were all as easily resolved as this one :-)

With respect, if you're just getting started with Python, you shouldn't get into the habit of hitting the bug tracker every time you find something that surprises you. If you're new to programming in general as well as Python, you might find the python tutor mailing list helpful; otherwise the main python discussion list can be helpful (although it is fairly high volume and often goes into long off-topic discussions).

https://mail.python.org/mailman/listinfo/tutor
https://mail.python.org/mailman/listinfo/python-list

----------
nosy: +steven.daprano

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

From report at bugs.python.org  Mon Dec  5 16:13:17 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 05 Dec 2016 21:13:17 +0000
Subject: [issue28881] int no attribute 'lower' iterating email.Messasge
In-Reply-To: <1480964649.95.0.801978620213.issue28881@psf.upfronthosting.co.za>
Message-ID: <1480972397.14.0.133491206562.issue28881@psf.upfronthosting.co.za>


Martin Panter added the comment:

You just need a messsage object with one or more header fields:

>>> msg = message_from_string("Name: value\r\n\r\n")
>>> for m in msg:
...     pass
... 
AttributeError: 'int' object has no attribute 'lower'

Python 2 does not implement __iter__(), so it is the default sequence iteration protocol causing this behaviour. The documentation does not mention iteration either: <https://docs.python.org/2.7/library/email.message.html#email.message.Message.__len__>. It mentions a ?mapping-like interface?, but since it explicitly lists __len__(), __contains__(), etc, and not __iter__(), I would say you should not assume iteration is supported.

Python 3 does implement Message.__iter__(), but it does not seem to be documented. The method seems to be added as a side effect of Guido removing and restoring the email package:

https://github.com/python/cpython/commit/1058618#diff-92a78c52ebc0a8908cbd06c8155f8bdb (removed without __iter__)
https://hg.python.org/cpython/file/d5f3c2f416f2/Lib/email/message.py (added back including __iter__)

----------
nosy: +martin.panter
title: int no attribute 'lower' -> int no attribute 'lower' iterating email.Messasge

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

From report at bugs.python.org  Mon Dec  5 16:13:37 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 05 Dec 2016 21:13:37 +0000
Subject: [issue28881] int no attribute 'lower' iterating email.Message
In-Reply-To: <1480964649.95.0.801978620213.issue28881@psf.upfronthosting.co.za>
Message-ID: <1480972417.74.0.753800002732.issue28881@psf.upfronthosting.co.za>


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


----------
title: int no attribute 'lower' iterating email.Messasge -> int no attribute 'lower' iterating email.Message

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

From report at bugs.python.org  Mon Dec  5 16:55:51 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Dec 2016 21:55:51 +0000
Subject: [issue28089] Document TCP_NODELAY by default
In-Reply-To: <1480969004.54.0.512137578278.issue28089@psf.upfronthosting.co.za>
Message-ID: <1480974951.89.0.198884029442.issue28089@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Yury: I don't understand your issue, can you please elaborate? Do you mean that the default value of the TCP_NODELAY changed in Python 3.6? Otherwise, why do you consider it as a release blocker?

The Python 3.6 release must be blocked by a TCP flag? Really?

----------

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

From report at bugs.python.org  Mon Dec  5 16:58:05 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Dec 2016 21:58:05 +0000
Subject: [issue28808] Make PyUnicode_CompareWithASCIIString() never failing
In-Reply-To: <1480175314.71.0.35688135657.issue28808@psf.upfronthosting.co.za>
Message-ID: <1480975085.42.0.246654127158.issue28808@psf.upfronthosting.co.za>


STINNER Victor added the comment:

PyUnicode_CompareWithASCIIString-no-errors-2.patch LGTM. Go ahead Serhiy.

----------

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

From report at bugs.python.org  Mon Dec  5 16:59:04 2016
From: report at bugs.python.org (Julien Palard)
Date: Mon, 05 Dec 2016 21:59:04 +0000
Subject: [issue28866] Unexpected behavior resulting from mro() and __setattr__
 in interactive mode
In-Reply-To: <1480862145.72.0.468660451957.issue28866@psf.upfronthosting.co.za>
Message-ID: <1480975144.64.0.390746122508.issue28866@psf.upfronthosting.co.za>


Julien Palard added the comment:

I found a way to fix it, but as I'm just discovering cpython internals, I'm not sure it's the right way, review are very welcome.

I fixed it this way because:

The bytecode generated for "proxy.x = 0" (a STORE_ATTR) will call a
PyObject_SetAttr with FooProxy which will soon execute the __setattr__ of Meta, itself calling a PyObject_SetAttr with Foo.

The actual attribute setting is done from the PyObject_SetAttr with Foo (calling in turn type_setattro, and so on), but it's already too late to invalidate the FooProxy type: we no longer have a reference on it and can't guess that FooProxy delegated __setattr__ to Foo.

So the only place when we can invalidate correctly is in the first call of PyObject_SetAttr when we know on which type the attribute will be set, and it make sense: It does not matter what a __setattr__ does and how it does it: invalidation should happen for this attribute on the current type, so invalidating here seems logic.

I did not yet took the time to measure performance loss induced with this patch.

With the patch:

./python -i weird.py
>>> proxy.x
0
>>> proxy.x
0

----------
keywords: +patch
Added file: http://bugs.python.org/file45766/issue28866.diff

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

From report at bugs.python.org  Mon Dec  5 17:02:54 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 05 Dec 2016 22:02:54 +0000
Subject: [issue28808] Make PyUnicode_CompareWithASCIIString() never failing
In-Reply-To: <1480175314.71.0.35688135657.issue28808@psf.upfronthosting.co.za>
Message-ID: <1480975374.08.0.640127379447.issue28808@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Dec  5 17:02:54 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 05 Dec 2016 22:02:54 +0000
Subject: [issue28881] int no attribute 'lower' iterating email.Message
In-Reply-To: <1480964649.95.0.801978620213.issue28881@psf.upfronthosting.co.za>
Message-ID: <1480975374.47.0.45883528074.issue28881@psf.upfronthosting.co.za>


Martin Panter added the comment:

The __iter__() method was added by Barry in <http://svn.python.org/view/sandbox/trunk/emailpkg/5_0-exp/email/message.py?r1=57344&r2=57343&pathrev=57344>:
?Added an __iter__() to email.message.Message for iterating over the message?s headers.?

On the other hand, earlier he said it was ambiguous what the behaviour should be: Issue 1017329.

----------

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

From report at bugs.python.org  Mon Dec  5 17:12:16 2016
From: report at bugs.python.org (Mariatta Wijaya)
Date: Mon, 05 Dec 2016 22:12:16 +0000
Subject: [issue28089] Document TCP_NODELAY by default
In-Reply-To: <1480969004.54.0.512137578278.issue28089@psf.upfronthosting.co.za>
Message-ID: <1480975936.6.0.590434095171.issue28089@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

The change is that TCP_NODELAY option is set by default in 3.6. It was not the case in 3.5.

----------

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

From report at bugs.python.org  Mon Dec  5 17:14:11 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Dec 2016 22:14:11 +0000
Subject: [issue28089] asyncio: Document that TCP_NODELAY is now used by default
In-Reply-To: <1480969004.54.0.512137578278.issue28089@psf.upfronthosting.co.za>
Message-ID: <1480976051.74.0.648482956236.issue28089@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
title: Document TCP_NODELAY by default -> asyncio: Document that TCP_NODELAY is now used by default

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

From report at bugs.python.org  Mon Dec  5 17:15:03 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Dec 2016 22:15:03 +0000
Subject: [issue28089] asyncio: Document that TCP_NODELAY is now used by default
In-Reply-To: <1480969004.54.0.512137578278.issue28089@psf.upfronthosting.co.za>
Message-ID: <1480976103.37.0.0627929166702.issue28089@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> The change is that TCP_NODELAY option is set by default in 3.6. It was not the case in 3.5.

Ah, it's a change in _asyncio_, ok. I missed that from the issue title, so I changed the title.

----------

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

From report at bugs.python.org  Mon Dec  5 17:15:42 2016
From: report at bugs.python.org (wim glenn)
Date: Mon, 05 Dec 2016 22:15:42 +0000
Subject: [issue28617] Why isn't "in" called a comparison operation?
In-Reply-To: <1478291760.05.0.758080389861.issue28617@psf.upfronthosting.co.za>
Message-ID: <1480976142.81.0.0184813085102.issue28617@psf.upfronthosting.co.za>


wim glenn added the comment:

1 month later.. is newpatch.diff OK to merge or any further improvements needed?  thanks

----------

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

From report at bugs.python.org  Mon Dec  5 17:20:52 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 05 Dec 2016 22:20:52 +0000
Subject: [issue28808] Make PyUnicode_CompareWithASCIIString() never failing
In-Reply-To: <1480175314.71.0.35688135657.issue28808@psf.upfronthosting.co.za>
Message-ID: <20161205222049.93632.35055.24DB9A83@psf.io>


Roundup Robot added the comment:

New changeset b431d39da67f by Serhiy Storchaka in branch '3.5':
Issue #28808: PyUnicode_CompareWithASCIIString() now never raises exceptions.
https://hg.python.org/cpython/rev/b431d39da67f

New changeset 5bdc8e1a50c8 by Serhiy Storchaka in branch '3.6':
Issue #28808: PyUnicode_CompareWithASCIIString() now never raises exceptions.
https://hg.python.org/cpython/rev/5bdc8e1a50c8

New changeset db56e39ea067 by Serhiy Storchaka in branch 'default':
Issue #28808: PyUnicode_CompareWithASCIIString() now never raises exceptions.
https://hg.python.org/cpython/rev/db56e39ea067

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

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

From report at bugs.python.org  Mon Dec  5 17:24:33 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 05 Dec 2016 22:24:33 +0000
Subject: [issue23722] During metaclass.__init__,
 super() of the constructed class does not work
In-Reply-To: <1426859061.43.0.510286082444.issue23722@psf.upfronthosting.co.za>
Message-ID: <20161205222429.21965.30124.A883083C@psf.io>


Roundup Robot added the comment:

New changeset fa4d8276d0fb by Serhiy Storchaka in branch 'default':
Fixed merge error in Misc/NEWS for issue #23722.
https://hg.python.org/cpython/rev/fa4d8276d0fb

----------

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

From report at bugs.python.org  Mon Dec  5 17:25:35 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 05 Dec 2016 22:25:35 +0000
Subject: [issue28808] Make PyUnicode_CompareWithASCIIString() never failing
In-Reply-To: <1480175314.71.0.35688135657.issue28808@psf.upfronthosting.co.za>
Message-ID: <1480976735.4.0.570043078314.issue28808@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thanks Ned and Victor.

----------
priority: release blocker -> normal
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon Dec  5 17:28:11 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Dec 2016 22:28:11 +0000
Subject: [issue28835] Change in behavior when overriding warnings.showwarning
 and with catch_warnings(record=True)
In-Reply-To: <1480465767.99.0.401403947818.issue28835@psf.upfronthosting.co.za>
Message-ID: <1480976891.5.0.52207731839.issue28835@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Ok, here is a fix.

----------
keywords: +patch
Added file: http://bugs.python.org/file45767/warnings_fix.patch

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

From report at bugs.python.org  Mon Dec  5 17:33:20 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Dec 2016 22:33:20 +0000
Subject: [issue28835] Change in behavior when overriding warnings.showwarning
 and with catch_warnings(record=True)
In-Reply-To: <1480465767.99.0.401403947818.issue28835@psf.upfronthosting.co.za>
Message-ID: <1480977200.28.0.0949014261594.issue28835@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oops, I made a mistake just before producing the patch: here is the right patch, test_warnings pass.

----------
Added file: http://bugs.python.org/file45768/warnings_fix-2.patch

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

From report at bugs.python.org  Mon Dec  5 17:34:50 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 05 Dec 2016 22:34:50 +0000
Subject: [issue28880] range(i, j) doesn't work
In-Reply-To: <1480962120.7.0.536761585872.issue28880@psf.upfronthosting.co.za>
Message-ID: <1480977290.82.0.677413583031.issue28880@psf.upfronthosting.co.za>


R. David Murray added the comment:

In case anyone else wonders, the tutorial does cover this, although its example uses ">>> print(range(10))" instead of just ">>> range(10)".

----------

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

From report at bugs.python.org  Mon Dec  5 17:37:52 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 05 Dec 2016 22:37:52 +0000
Subject: [issue28881] int no attribute 'lower' iterating email.Message
In-Reply-To: <1480964649.95.0.801978620213.issue28881@psf.upfronthosting.co.za>
Message-ID: <1480977472.56.0.212166517691.issue28881@psf.upfronthosting.co.za>


R. David Murray added the comment:

I had no memory that __iter__ wasn't implemented in python2, thanks Martin.  So, this isn't really a bug, though one could argue it should be mentioned explicitly in the 2.7 docs, since it is definitely counter-intuitive to a python programmer.

----------

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

From report at bugs.python.org  Mon Dec  5 17:40:38 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Dec 2016 22:40:38 +0000
Subject: [issue28835] Change in behavior when overriding warnings.showwarning
 and with catch_warnings(record=True)
In-Reply-To: <1480465767.99.0.401403947818.issue28835@psf.upfronthosting.co.za>
Message-ID: <1480977638.4.0.453258210191.issue28835@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Serhiy: Would you mind to review warnings_fix-2.patch? I tagged this bug as a release blocker, since it's a regression introduced in 3.6.

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

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

From report at bugs.python.org  Mon Dec  5 17:54:32 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Dec 2016 22:54:32 +0000
Subject: [issue28596] on Android _bootlocale on startup relies on too many
 library modules
In-Reply-To: <1478166520.26.0.975749703987.issue28596@psf.upfronthosting.co.za>
Message-ID: <1480978472.45.0.27701489056.issue28596@psf.upfronthosting.co.za>


STINNER Victor added the comment:

android-locale-utf8.patch LGTM, but I added minor comments on the review.

I would prefer to let Xavier merges this one, since he can test it.

----------

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

From report at bugs.python.org  Mon Dec  5 17:57:26 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 05 Dec 2016 22:57:26 +0000
Subject: [issue28838] Uniformize argument names of "call" functions (C API)
In-Reply-To: <1480504437.73.0.907175245586.issue28838@psf.upfronthosting.co.za>
Message-ID: <1480978646.89.0.618796068325.issue28838@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

I withdraw my concern. I was thinking it would affect the caller, but of course it won't. Apologies.

----------

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

From report at bugs.python.org  Mon Dec  5 17:57:28 2016
From: report at bugs.python.org (Julien Palard)
Date: Mon, 05 Dec 2016 22:57:28 +0000
Subject: [issue28835] Change in behavior when overriding warnings.showwarning
 and with catch_warnings(record=True)
In-Reply-To: <1480465767.99.0.401403947818.issue28835@psf.upfronthosting.co.za>
Message-ID: <1480978648.94.0.505870797749.issue28835@psf.upfronthosting.co.za>


Julien Palard added the comment:

Carefully reviewed, and tests are passing, issue is fixed: LGTM.

----------
nosy: +mdk

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

From report at bugs.python.org  Mon Dec  5 18:06:53 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Dec 2016 23:06:53 +0000
Subject: [issue28835] Change in behavior when overriding warnings.showwarning
 and with catch_warnings(record=True)
In-Reply-To: <1480465767.99.0.401403947818.issue28835@psf.upfronthosting.co.za>
Message-ID: <1480979213.96.0.694951555768.issue28835@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Patch version 3: fix test_warnings when running the test with python3 -Werror. Reset filters in the new unit test.

----------
Added file: http://bugs.python.org/file45769/warnings_fix-3.patch

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

From report at bugs.python.org  Mon Dec  5 18:13:53 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Dec 2016 23:13:53 +0000
Subject: [issue28866] Type cache is not correctly invalidated on a class
 defining mro()
In-Reply-To: <1480862145.72.0.468660451957.issue28866@psf.upfronthosting.co.za>
Message-ID: <1480979633.12.0.0579736002609.issue28866@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The issue is that the Meta class has a reference to the class Foo in its mro() method, but Foo is not aware of Meta. So when Foo is modified, the Foo cache is invalidated, but not Meta cache.

issue28866.diff always invalidates the cache, so it works. But it is suboptimal, IMO it defeats the whole purpose of a cache.

I never defined a mro() method. I'm not sure that it's possible to have a type cache and a mro() method?

Options:

* Disable completely the cache on classes defining mro()
* Modify "Meta" (the C code implementing the type, not the Python code) to track the version tag of each class referenced by mro(). Problem: mro() is dynamic!?
* Somehow, notify Foo that Meta has a reference to its cache, so Foo is able to invalidate Meta cache

----------
title: Unexpected behavior resulting from mro() and __setattr__ in interactive mode -> Type cache is not correctly invalidated on a class defining mro()

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

From report at bugs.python.org  Mon Dec  5 18:30:05 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 05 Dec 2016 23:30:05 +0000
Subject: [issue28866] Type cache is not correctly invalidated on a class
 defining mro()
In-Reply-To: <1480862145.72.0.468660451957.issue28866@psf.upfronthosting.co.za>
Message-ID: <1480980605.43.0.715585163766.issue28866@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> * Somehow, notify Foo that Meta has a reference to its cache, so Foo is able to invalidate Meta cache

This was implemented when the type cache was implemented in Python 2.6, but only for explicit subclasses. PyType_Modified() iterates on tp_subclasses.

PyType_Ready() updates tp_subclasses: it stores a weak reference to sub classes in each base class.

I understand that, if we want to implement this feature, type_mro_modified() should be modified to add a backward reference in each base class of the MRO. type_mro_modified() is called when a type is defined, but also when type.__bases__ is explicitly modified.

It would require to add a new slot to types, and so increase a little bit the memory usage, and slow down the creation of a type, and type.__bases__ (slow down: probably negligible, O(1) since the existing tp_subclasses uses a dict).

----------

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

From report at bugs.python.org  Mon Dec  5 19:01:37 2016
From: report at bugs.python.org (Serge Stroobandt)
Date: Tue, 06 Dec 2016 00:01:37 +0000
Subject: [issue26223] decimal.to_eng_string() does not implement engineering
 notation in all cases.
In-Reply-To: <1453922113.08.0.48679853518.issue26223@psf.upfronthosting.co.za>
Message-ID: <1480982497.15.0.365428362772.issue26223@psf.upfronthosting.co.za>


Serge Stroobandt added the comment:

Dear Keith, that is exactly how it should be! (I cross-checked with a HP calculator to make sure.)

----------

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

From report at bugs.python.org  Mon Dec  5 19:09:25 2016
From: report at bugs.python.org (Shinya Okano)
Date: Tue, 06 Dec 2016 00:09:25 +0000
Subject: [issue28724] Add method send_io, recv_io to the socket module.
In-Reply-To: <1479395133.65.0.0720889900419.issue28724@psf.upfronthosting.co.za>
Message-ID: <1480982965.2.0.284231453805.issue28724@psf.upfronthosting.co.za>


Shinya Okano added the comment:

Thanks for reviews and comments. I will work on the weekend.

----------

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

From report at bugs.python.org  Mon Dec  5 19:20:24 2016
From: report at bugs.python.org (Ned Deily)
Date: Tue, 06 Dec 2016 00:20:24 +0000
Subject: [issue27847] os.set_inheritable() looks to be broken on OpenIndiana, 
 regression of Python 3.6
In-Reply-To: <1472032643.28.0.131031350322.issue27847@psf.upfronthosting.co.za>
Message-ID: <1480983624.97.0.425224253378.issue27847@psf.upfronthosting.co.za>


Ned Deily added the comment:

Although Victor initiated some discussions on python-dev about support for OpenIndiana and other Solaris-related derivatives, I don't we ever reached a consensus, no one has proposed a solution, and currently the OpenIndiana 3.6 buildbot is not functioning well (I've pinged the owner).  I am not willing to hold 3.6.0 for a resolution.  Let's come back to this later.

https://mail.python.org/pipermail/python-dev/2016-September/146538.html

----------
priority: release blocker -> deferred blocker
versions: +Python 3.7

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

From report at bugs.python.org  Mon Dec  5 19:21:43 2016
From: report at bugs.python.org (Ned Deily)
Date: Tue, 06 Dec 2016 00:21:43 +0000
Subject: [issue27847] os.set_inheritable() looks to be broken on OpenIndiana, 
 regression of Python 3.6
In-Reply-To: <1472032643.28.0.131031350322.issue27847@psf.upfronthosting.co.za>
Message-ID: <1480983703.51.0.00465626168955.issue27847@psf.upfronthosting.co.za>


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


----------
nosy: +jcea

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

From report at bugs.python.org  Mon Dec  5 19:26:48 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 06 Dec 2016 00:26:48 +0000
Subject: [issue3687] Popen() object stdout attribute reassignment behaviour
In-Reply-To: <1219766265.83.0.904411616188.issue3687@psf.upfronthosting.co.za>
Message-ID: <1480984008.66.0.516746580636.issue3687@psf.upfronthosting.co.za>


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


----------
stage:  -> needs patch
versions: +Python 3.5, Python 3.6, Python 3.7 -Python 2.6, Python 3.1, Python 3.2

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

From report at bugs.python.org  Mon Dec  5 20:09:09 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 06 Dec 2016 01:09:09 +0000
Subject: [issue28838] Uniformize argument names of "call" functions (C API)
In-Reply-To: <1480504437.73.0.907175245586.issue28838@psf.upfronthosting.co.za>
Message-ID: <1480986549.94.0.981399549674.issue28838@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

As long as the C API docs also get updated, +1 for:

* 'o' -> 'obj'
* 'callable_object' -> 'callable'
* 'func' -> 'callable' (when the function actually accepts an arbitrary callable)
* 'method' -> 'name' (assuming 'Method' appears in the function name)

Documenting those naming conventions in PEP 7 would also still be desirable.

----------

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

From report at bugs.python.org  Mon Dec  5 20:56:50 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 06 Dec 2016 01:56:50 +0000
Subject: [issue28835] Change in behavior when overriding warnings.showwarning
 and with catch_warnings(record=True)
In-Reply-To: <1480465767.99.0.401403947818.issue28835@psf.upfronthosting.co.za>
Message-ID: <1480989410.63.0.623685798661.issue28835@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

+1 from me as well

----------
assignee:  -> haypo
nosy: +ncoghlan
stage:  -> commit review
type:  -> behavior

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

From report at bugs.python.org  Mon Dec  5 21:35:35 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 06 Dec 2016 02:35:35 +0000
Subject: [issue28835] Change in behavior when overriding warnings.showwarning
 and with catch_warnings(record=True)
In-Reply-To: <1480465767.99.0.401403947818.issue28835@psf.upfronthosting.co.za>
Message-ID: <1480991735.51.0.200683862325.issue28835@psf.upfronthosting.co.za>


Martin Panter added the comment:

The patch looks sensible to me. The fix is basically an extension to the first fixup (9c92352324e8), where Victor split _showwarnmsg_impl() out of _showwarnmsg(). Now, _showwarnmsg() is a helper for the C module to choose between the backwards-compatible showwarning() API, and the new internal _showwarnmsg_impl() function.

I left some incidental comments on Rietveld, but they are not severe release blockers. Also, is the docstring for warnings._showwarnmsg() off? It looks like you copied it from warnings.showwarning(). Best not to suggest replacing an internal function.

----------
nosy: +martin.panter

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

From report at bugs.python.org  Mon Dec  5 21:53:42 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 06 Dec 2016 02:53:42 +0000
Subject: [issue28835] Change in behavior when overriding warnings.showwarning
 and with catch_warnings(record=True)
In-Reply-To: <1480465767.99.0.401403947818.issue28835@psf.upfronthosting.co.za>
Message-ID: <1480992822.11.0.858302303004.issue28835@psf.upfronthosting.co.za>


Martin Panter added the comment:

Actually, I found a regression. Looks like you also need to cancel any showwarning() function set by the user:

>>> import warnings
>>> warnings.showwarning = print
>>> with warnings.catch_warnings(record=True) as recording:
...     warnings.warn("hi")  # Unpatched did not call print()
... 
hi <class 'UserWarning'> __main__ 2 None None
>>> recording  # Unpatched returned the warning here
[]

Also, should the documentation of catch_warnings() be amended to say that there is no longer a custom showwarning() function? The recording mechanism is now an internal detail, and not accessible by calling showwarning().

----------

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

From report at bugs.python.org  Mon Dec  5 22:17:42 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 06 Dec 2016 03:17:42 +0000
Subject: [issue28878] datetime should not be a subclass of date
In-Reply-To: <1480942340.78.0.750693942086.issue28878@psf.upfronthosting.co.za>
Message-ID: <1480994262.73.0.677224599996.issue28878@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
resolution:  -> not a bug

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

From report at bugs.python.org  Mon Dec  5 22:26:25 2016
From: report at bugs.python.org (Eric Appelt)
Date: Tue, 06 Dec 2016 03:26:25 +0000
Subject: [issue28091] Document PEP 525
In-Reply-To: <1480969186.28.0.879526881588.issue28091@psf.upfronthosting.co.za>
Message-ID: <1480994785.88.0.26090810625.issue28091@psf.upfronthosting.co.za>


Eric Appelt added the comment:

Hi, I'm a new contributor trying to get started with documentation and testing.

I have been following and testing PEP525 and PEP530 and feel familiar enough to try to work on adding this to the Python Language Reference if it would not be redundant with work already being completed. I think this makes sense to tackle along with issue 28090 as it appears that documentation of asynchronous generator expressions would necessarily refer to terminology from asynchronous generator objects. 

Specifically, for PEP525:

async generator functions would be added first in section 3.2 after coroutines.

Most of the work would be in expanding 6.2.9 (yield expressions) to discuss the asynchronous case, probably adding 6.2.9.3(4) to document the methods for asynchronous generator objects.

In section 8.8.1 I would need to remove the statement ?it is a syntax error to use yield expressions in async def coroutines?, add statement that ?yield from? is a syntax error in this context.

Finally, the new concepts should be added to the Glossary.

Then for PEP530:

Section 6.2.4 (Displays for Lists,...) needs to be updated for the grammar change that adds the optional ASYNC, i.e.:

comp_for: [ASYNC] 'for' exprlist 'in' or_test [comp_iter]

Then both sections 6.2.4 and 6.2.8  (Generator expressions) need to be expanded to include the async case.

If writing this up is not already underway, and if I?m generally on the right track for what needs to be done, I think I can have a reasonable patch for this by the end of the week. Also, please feel free to contact me if there is any other documentation/testing/test coverage work that I could help with. The new native coroutines are an area of particular interest for me.

----------
nosy: +Eric Appelt

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

From report at bugs.python.org  Mon Dec  5 22:27:33 2016
From: report at bugs.python.org (Mariatta Wijaya)
Date: Tue, 06 Dec 2016 03:27:33 +0000
Subject: [issue28089] asyncio: Document that TCP_NODELAY is now used by default
In-Reply-To: <1480969004.54.0.512137578278.issue28089@psf.upfronthosting.co.za>
Message-ID: <1480994853.76.0.0624811211883.issue28089@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

I added the following to Doc/library/asyncio-protocol.rst

.. versionchanged:: 3.6.0
   The socket option TCP_NODELAY is now set by default.

Let me know if this patch works.

----------
keywords: +patch
Added file: http://bugs.python.org/file45770/issue28089.patch

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

From report at bugs.python.org  Mon Dec  5 22:31:00 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 06 Dec 2016 03:31:00 +0000
Subject: [issue13886] readline-related test_builtin failure
In-Reply-To: <1327659819.71.0.475160045664.issue13886@psf.upfronthosting.co.za>
Message-ID: <1480995060.81.0.0562065076409.issue13886@psf.upfronthosting.co.za>


Martin Panter added the comment:

input-readline.v2.patch sets stderr=DEVNULL so that the prompt does not come out in the test log.

A disadvantage of this is that if there is a failure, any error messages, stack trace, etc is also lost. To fix this properly, we would probably have to capture stderr using a generalized communicate() loop, like I have done at the bottom of <https://hg.python.org/cpython/annotate/v3.6.0b4/Lib/test/test_readline.py#l231> (see also Issue 1260171).

----------
dependencies:  -Change input() to always prompt to stderr
Added file: http://bugs.python.org/file45771/input-readline.v2.patch

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

From report at bugs.python.org  Mon Dec  5 22:44:12 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 06 Dec 2016 03:44:12 +0000
Subject: [issue28089] asyncio: Document that TCP_NODELAY is now used by default
In-Reply-To: <1480969004.54.0.512137578278.issue28089@psf.upfronthosting.co.za>
Message-ID: <1480995852.4.0.720852442612.issue28089@psf.upfronthosting.co.za>


Berker Peksag added the comment:

+.. versionchanged:: 3.6.0

3.6.0 -> 3.6

+   The socket option TCP_NODELAY is now set by default.

TCP_NODELAY -> ``TCP_NODELAY``

----------
nosy: +berker.peksag
stage: needs patch -> patch review

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

From report at bugs.python.org  Mon Dec  5 22:49:45 2016
From: report at bugs.python.org (Mariatta Wijaya)
Date: Tue, 06 Dec 2016 03:49:45 +0000
Subject: [issue28089] asyncio: Document that TCP_NODELAY is now used by default
In-Reply-To: <1480969004.54.0.512137578278.issue28089@psf.upfronthosting.co.za>
Message-ID: <1480996185.72.0.618529436384.issue28089@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

Thanks, Berker :)
Updated.

----------
Added file: http://bugs.python.org/file45772/issue28089v2.patch

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

From report at bugs.python.org  Mon Dec  5 23:45:21 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 06 Dec 2016 04:45:21 +0000
Subject: [issue28091] Document PEP 525
In-Reply-To: <1480969186.28.0.879526881588.issue28091@psf.upfronthosting.co.za>
Message-ID: <1480999521.47.0.961076510059.issue28091@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Hi Eric, please feel free to go ahead and submit a patch, I'll review it!

----------

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

From report at bugs.python.org  Tue Dec  6 00:06:40 2016
From: report at bugs.python.org (steven Michalske)
Date: Tue, 06 Dec 2016 05:06:40 +0000
Subject: [issue28882] RFC: Slice confusing with negative strides and the 0th
 element.
Message-ID: <1481000800.36.0.0535087899648.issue28882@psf.upfronthosting.co.za>


New submission from steven Michalske:

The slicing and using inputed math is is necessary to provide a special case to make the code behave as expected.

Unless I'm missing something.  Like we can't do this, as we loose negative indexing from the end of the file?

Let's take the following example, byte swapping 32bit integers.

a = [0,1,2,3,4,5,6,7]

print([a[x] for x in [slice(y+3, y-1 if y > 1 else None, -1) for y in range(0, len(a), 4)]])
[[], [7, 7, 6, 5]]

Catching my explicit case, I changed my code to:
print([a[x] for x in [slice(y+3, y-1 if y > 1 else None, -1) for y in range(0, len(a), 4)]])
[[3, 2, 1, 0], [7, 6, 5, 4]]

Life proceeds as I am explicit, but now I have a conditional check that is slowing me down...

It appears that -1 is being considered the last element in the set.
This was surprising, as I couldn't use simple math to byte swap, I needed to pass None instead of -1

It appears PySlice_GetIndices in file cpython/Objects/sliceobject.c always 
adds length if stop < 0 regardless to start and step.

    if (r->stop == Py_None) {
        *stop = *step < 0 ? -1 : length;
    } else {
        if (!PyLong_Check(r->stop)) return -1;
        *stop = PyLong_AsSsize_t(r->stop);
        if (*stop < 0) *stop += length;   # <-- Issue here?
    }


It seems that there is some undocumented logic and behavioral decisions.

Was it explicitly decided that a negative stop and negative stride
e.g. 
In [46]: a[3:0:-1]
Out[46]: [3, 2, 1]

In [47]: a[3:-1:-1]
Out[47]: []

Not [3,2,1,0]  (My least surprising value...)

Because -1 is based on len(a).

I expected that with a positive start, and a negative stride that the -1 case would be considered include 0.

In other code...
[4:-1:-1] == [4:None:-1]
Not
[4:-1:-1] == [4:len(a)-1:-1]
Especially when len(a)-1 > start

I understand that this is behavioral, but it is confusing...

Discussion?

----------
messages: 282500
nosy: hardkrash
priority: normal
severity: normal
status: open
title: RFC: Slice confusing with negative strides and the 0th element.
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Tue Dec  6 00:16:24 2016
From: report at bugs.python.org (steven Michalske)
Date: Tue, 06 Dec 2016 05:16:24 +0000
Subject: [issue28882] RFC: Slice confusing with negative strides and the 0th
 element.
In-Reply-To: <1481000800.36.0.0535087899648.issue28882@psf.upfronthosting.co.za>
Message-ID: <1481001384.71.0.513606086297.issue28882@psf.upfronthosting.co.za>


steven Michalske added the comment:

Argh, I swear I proofread this...

print([a[x] for x in [slice(y+3, y-1, -1) for y in range(0, len(a), 4)]])
[[], [7, 7, 6, 5]]

Catching my explicit case, I changed my code to:
print([a[x] for x in [slice(y+3, y-1 if y > 1 else None, -1) for y in range(0, len(a), 4)]])
[[3, 2, 1, 0], [7, 6, 5, 4]]

Also, I could have done this...

print(list(reversed([a[x] for x in [slice(y, y-4, -1) for y in range(-1, -len(a), -4)]])))
[[3, 2, 1, 0], [7, 6, 5, 4]]
But, Yikes All those inverses!

Side Note
I wish we had partitioning in ranges/slices.

a[::4] == [0, 4]
a[::4:2] == [[0, 1], [4, 5]]
a[::4:-4] == [[3, 2, 1, 0], [7, 6, 5, 4]]

----------

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

From report at bugs.python.org  Tue Dec  6 00:47:53 2016
From: report at bugs.python.org (Suraj Deshmukh)
Date: Tue, 06 Dec 2016 05:47:53 +0000
Subject: [issue10496] Python startup should not require passwd entry
In-Reply-To: <1290398281.89.0.568058332092.issue10496@psf.upfronthosting.co.za>
Message-ID: <1481003273.1.0.0396686526341.issue10496@psf.upfronthosting.co.za>


Suraj Deshmukh added the comment:

I did not encounter this issue in fedora24 based container on docker but when I run it in openshift I see errors as:

That container has `Python 2.7.12` installed. While `flask` and `redis` python libs are installed via pip.

```
bash: /usr/local/bin/wait-for-it.sh: Permission denied
 * Running on http://0.0.0.0:5000/ (Press CTRL+C to quit)
 * Restarting with stat
 * Debugger is active!
Traceback (most recent call last):
  File "app.py", line 18, in <module>
    app.run(host="0.0.0.0", port=5000, debug=True)
  File "/usr/lib64/python2.7/site-packages/flask/app.py", line 843, in run
    run_simple(host, port, self, **options)
  File "/usr/lib/python2.7/site-packages/werkzeug/serving.py", line 633, in run_simple
    application = DebuggedApplication(application, use_evalex)
  File "/usr/lib/python2.7/site-packages/werkzeug/debug/__init__.py", line 254, in __init__
    if self.pin is None:
  File "/usr/lib/python2.7/site-packages/werkzeug/debug/__init__.py", line 264, in _get_pin
    self._pin, self._pin_cookie = get_pin_and_cookie_name(self.app)
  File "/usr/lib/python2.7/site-packages/werkzeug/debug/__init__.py", line 144, in get_pin_and_cookie_name
    username = getpass.getuser()
  File "/usr/lib64/python2.7/getpass.py", line 158, in getuser
    return pwd.getpwuid(os.getuid())[0]
KeyError: 'getpwuid(): uid not found: 1000050000'
```

----------
nosy: +surajd

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

From report at bugs.python.org  Tue Dec  6 00:54:26 2016
From: report at bugs.python.org (Graham Dumpleton)
Date: Tue, 06 Dec 2016 05:54:26 +0000
Subject: [issue10496] Python startup should not require passwd entry
In-Reply-To: <1290398281.89.0.568058332092.issue10496@psf.upfronthosting.co.za>
Message-ID: <1481003666.19.0.336185375873.issue10496@psf.upfronthosting.co.za>


Graham Dumpleton added the comment:

@surajd Why aren't you using the Python S2I builders for OpenShift?

When you run anything under OpenShift, it will assign your project a UID which any containers are forced to run under. The OpenShift containers include a mechanism using a package call nss_wrapper so that correct passwd entries are reported for the assigned UID. If your own image doesn't have a similar provision, and in general aren't designed to run as an arbitrary assigned UID, you will encounter various issues.

Read through the latter section of posts in:

* http://blog.dscpl.com.au/p/using-python-with-docker.html

for further details.

Anyway, this isn't the place to discuss OpenShift, use instead:

* https://groups.google.com/forum/#!forum/openshift

if you have questions about running Python under OpenShift.

----------

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

From report at bugs.python.org  Tue Dec  6 01:01:05 2016
From: report at bugs.python.org (Suraj Deshmukh)
Date: Tue, 06 Dec 2016 06:01:05 +0000
Subject: [issue10496] Python startup should not require passwd entry
In-Reply-To: <1290398281.89.0.568058332092.issue10496@psf.upfronthosting.co.za>
Message-ID: <1481004065.01.0.466014241842.issue10496@psf.upfronthosting.co.za>


Suraj Deshmukh added the comment:

@grahamd thanks this helps.

----------

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

From report at bugs.python.org  Tue Dec  6 02:41:22 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 06 Dec 2016 07:41:22 +0000
Subject: [issue28596] on Android _bootlocale on startup relies on too many
 library modules
In-Reply-To: <1478166520.26.0.975749703987.issue28596@psf.upfronthosting.co.za>
Message-ID: <1481010082.14.0.381921989181.issue28596@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

This is a performance issue. I will look at it shortly.

----------

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

From report at bugs.python.org  Tue Dec  6 02:50:44 2016
From: report at bugs.python.org (Akira Li)
Date: Tue, 06 Dec 2016 07:50:44 +0000
Subject: [issue28876] bool of large range raises OverflowError
In-Reply-To: <1480930662.45.0.497603219066.issue28876@psf.upfronthosting.co.za>
Message-ID: <1481010644.18.0.172839017792.issue28876@psf.upfronthosting.co.za>


Akira Li added the comment:

I've removed the documentation changes from the patch.

----------
Added file: http://bugs.python.org/file45773/range_bool-no_docs.patch

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

From report at bugs.python.org  Tue Dec  6 03:44:44 2016
From: report at bugs.python.org (Peter Eckersley)
Date: Tue, 06 Dec 2016 08:44:44 +0000
Subject: [issue28742] argparse.ArgumentDefaultsHelpFormatter sometimes
 provides inaccurate documentation of defaults, so they should be overrideable
In-Reply-To: <1479514629.23.0.218870455687.issue28742@psf.upfronthosting.co.za>
Message-ID: <1481013884.09.0.221129342137.issue28742@psf.upfronthosting.co.za>


Peter Eckersley added the comment:

OK, here's another solution following paul.j3's suggestion. I think this is much better:

https://gist.github.com/pde/817a00378d3f6ed73747dfffce323ae5

Tests & documentation included.

----------

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

From report at bugs.python.org  Tue Dec  6 04:25:36 2016
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 06 Dec 2016 09:25:36 +0000
Subject: [issue28724] Add method send_io, recv_io to the socket module.
In-Reply-To: <1479395133.65.0.0720889900419.issue28724@psf.upfronthosting.co.za>
Message-ID: <1481016336.67.0.576764401287.issue28724@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Take your time, feature freeze for 3.7 is in about 18 months from now.

----------

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

From report at bugs.python.org  Tue Dec  6 04:50:28 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 06 Dec 2016 09:50:28 +0000
Subject: [issue28835] Change in behavior when overriding warnings.showwarning
 and with catch_warnings(record=True)
In-Reply-To: <1480465767.99.0.401403947818.issue28835@psf.upfronthosting.co.za>
Message-ID: <1481017828.45.0.805708567059.issue28835@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I don't understand why test_showwarnmsg_missing was added. Why deleting warnings._showwarnmsg should be supported?

I would rename _showwarning to _showwarning_orig for accenting it's purpose. It is used only for checking if showwarning was replaced by the user.

----------

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

From report at bugs.python.org  Tue Dec  6 04:51:54 2016
From: report at bugs.python.org (Christoph Reiter)
Date: Tue, 06 Dec 2016 09:51:54 +0000
Subject: [issue27971] utf-16 decoding can't handle lone surrogates
In-Reply-To: <1473155983.16.0.820045644056.issue27971@psf.upfronthosting.co.za>
Message-ID: <1481017914.01.0.588820878332.issue27971@psf.upfronthosting.co.za>


Changes by Christoph Reiter <reiter.christoph at gmail.com>:


----------
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Tue Dec  6 05:00:40 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 06 Dec 2016 10:00:40 +0000
Subject: [issue28089] asyncio: Document that TCP_NODELAY is now used by default
In-Reply-To: <1480969004.54.0.512137578278.issue28089@psf.upfronthosting.co.za>
Message-ID: <20161206100036.22212.71133.EEC004E9@psf.io>


Roundup Robot added the comment:

New changeset 726308cfe3b5 by Victor Stinner in branch '3.6':
catch_warnings() calls showwarning() if overriden
https://hg.python.org/cpython/rev/726308cfe3b5

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

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

From report at bugs.python.org  Tue Dec  6 05:03:16 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 06 Dec 2016 10:03:16 +0000
Subject: [issue28089] asyncio: Document that TCP_NODELAY is now used by default
In-Reply-To: <1480969004.54.0.512137578278.issue28089@psf.upfronthosting.co.za>
Message-ID: <20161206100311.28672.92369.C9F94270@psf.io>


Roundup Robot added the comment:

New changeset 150d36dbe3ba by Victor Stinner in branch '3.6':
warnings: Fix the issue number
https://hg.python.org/cpython/rev/150d36dbe3ba

----------

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

From report at bugs.python.org  Tue Dec  6 05:03:16 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 06 Dec 2016 10:03:16 +0000
Subject: [issue28835] Change in behavior when overriding warnings.showwarning
 and with catch_warnings(record=True)
In-Reply-To: <1480465767.99.0.401403947818.issue28835@psf.upfronthosting.co.za>
Message-ID: <20161206100311.28672.60721.4C21C3FE@psf.io>


Roundup Robot added the comment:

New changeset 150d36dbe3ba by Victor Stinner in branch '3.6':
warnings: Fix the issue number
https://hg.python.org/cpython/rev/150d36dbe3ba

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

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

From report at bugs.python.org  Tue Dec  6 05:15:13 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 06 Dec 2016 10:15:13 +0000
Subject: [issue28835] Change in behavior when overriding warnings.showwarning
 and with catch_warnings(record=True)
In-Reply-To: <1480465767.99.0.401403947818.issue28835@psf.upfronthosting.co.za>
Message-ID: <1481019313.77.0.492692845037.issue28835@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I pushed a more complete version of my patch:

New changeset 726308cfe3b5 by Victor Stinner in branch '3.6':
catch_warnings() calls showwarning() if overriden
https://hg.python.org/cpython/rev/726308cfe3b5


I dislike pushing a different change than the reviewed change, but I was in a hurry for the Python 3.6.0 release :-/ Sorry about that.

Please double-check the pushed change!

(I used the wrong issue number, fixed in the following commit.)


The final change also fixes the bug reported by Martin:

Martin: "Actually, I found a regression. Looks like you also need to cancel any showwarning() function set by the user:"

I fixed it in catch_warnings() with these lines:

            # Reset showwarning() to the default implementation to make sure
            # that _showwarnmsg() calls _showwarnmsg_impl()
            self._module.showwarning = self._module._showwarning

It also added a new unit test for this scenario.


Serhiy Storchaka: "I don't understand why test_showwarnmsg_missing was added. Why deleting warnings._showwarnmsg should be supported?"

I don't know well the warnings module. The interactions between the C _warnings module and the Python warnings module are complex. I didn't want to break the backward compatibility, and *technically*, it is possible to delete warnings.showwarning() and warnings.warn("msg") still writes the message into stderr! So I decided to support this corner case, for the backward compatibility.

Code:
---
import warnings
warnings.warn("with showwarning")
del warnings.showwarning
warnings.warn("without showwarning")
---

Output on Python 3.5 (before my showarnmsg() changes):
---
x.py:2: UserWarning: with showwarning
  warnings.warn("with showwarning")
x.py:4: UserWarning: without showwarning
  warnings.warn("without showwarning")
---

Hum, but maybe we should decorate test_showwarnmsg_missing() with @cpython_only to announce that it's a side effect of the implementation, it's not part of the "Python specification".


Serhiy Storchaka: "I would rename _showwarning to _showwarning_orig for accenting it's purpose. It is used only for checking if showwarning was replaced by the user."

Sorry, I suck at naming things :-) Feel free to rename it (after the 3.6.0 release).


By the way, I'm still interested to make showwarnmsg() public in Python 3.7. IMO it's interesting to give access to the new source parameter to custom warning loggers. And it will allow to more easily extend warnings with new parameters (it was the whole purpose of the issue #26568).


I keep the issue open so someone can still review the pushed change.

----------

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

From report at bugs.python.org  Tue Dec  6 05:25:34 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 06 Dec 2016 10:25:34 +0000
Subject: [issue27030] Remove deprecated re features
In-Reply-To: <1463337497.02.0.81864271809.issue27030@psf.upfronthosting.co.za>
Message-ID: <1481019934.76.0.693101952856.issue27030@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch that partially reverts changes of issue27030. It allows using unknown escapes in re.sub() replacement template, but they are deprecated and will be errors in 3.7.

If this is good to you Barry, and Ned allows, it can be committed in 3.6 only.

But this could delay adding support of new escapes (like \xXX, \uXXXX, etc) in replacement templates.

----------
assignee: serhiy.storchaka -> ned.deily
priority: normal -> release blocker
resolution: fixed -> 
stage: resolved -> patch review
status: closed -> open
Added file: http://bugs.python.org/file45774/re-sub-allow-unknown-escapes.patch

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

From report at bugs.python.org  Tue Dec  6 05:38:55 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 06 Dec 2016 10:38:55 +0000
Subject: [issue28835] Change in behavior when overriding warnings.showwarning
 and with catch_warnings(record=True)
In-Reply-To: <1480465767.99.0.401403947818.issue28835@psf.upfronthosting.co.za>
Message-ID: <1481020735.41.0.64625490591.issue28835@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Julien reviewed the pushed change and asked me questions on IRC:

* "nonlocal log": this change is unrelated to the fix, I should have done that in a separated change, sorry, I cannot resist to refactoring :-) The change has no effect, it's more cosmetic to help reviewers: "log is not a local variable nor a global variable, it's a "non-local" variable".

* inner function (calling log.append) renamed from "showarnmsg()" to "showarnmsg_logger()": it's to help debugging. It's a pain when two different functions completely different have the same name, especially for the warnings where many functions are overriden at runtime. Moreover, the function is now used for _showwarnmsg_impl instead of _showwarnmsg, so I also renamed the function to avoid confusion.

----------

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

From report at bugs.python.org  Tue Dec  6 05:59:11 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 06 Dec 2016 10:59:11 +0000
Subject: [issue28835] Change in behavior when overriding warnings.showwarning
 and with catch_warnings(record=True)
In-Reply-To: <1480465767.99.0.401403947818.issue28835@psf.upfronthosting.co.za>
Message-ID: <1481021951.48.0.409510737839.issue28835@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch that cleans up the code.

----------
Added file: http://bugs.python.org/file45775/showwarning-tidy.patch

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

From report at bugs.python.org  Tue Dec  6 06:07:40 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 06 Dec 2016 11:07:40 +0000
Subject: [issue28838] Uniformize argument names of "call" functions (C API)
In-Reply-To: <1480504437.73.0.907175245586.issue28838@psf.upfronthosting.co.za>
Message-ID: <1481022460.67.0.894880095919.issue28838@psf.upfronthosting.co.za>


STINNER Victor added the comment:

rename.patch: Big patch to rename function parameters.

----------
Added file: http://bugs.python.org/file45776/rename.patch

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

From report at bugs.python.org  Tue Dec  6 06:49:47 2016
From: report at bugs.python.org (Armin Rigo)
Date: Tue, 06 Dec 2016 11:49:47 +0000
Subject: [issue28883] Python 3.5.2 crashers (from PyPy)
Message-ID: <1481024987.78.0.673131645253.issue28883@psf.upfronthosting.co.za>


New submission from Armin Rigo:

As discussed on python-dev, I am creating omnibus issues from the lists of crashers, of wrong-according-to-the-docs, and of strange-behavior-only issues that I found while developing Python 3.5.2 support for PyPy.  These occur with CPython 3.5.2 but most of them are likely still here in trunk.

This is the issue containing the crashers.

----------
messages: 282518
nosy: arigo
priority: normal
severity: normal
status: open
title: Python 3.5.2 crashers (from PyPy)
versions: Python 3.5

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

From report at bugs.python.org  Tue Dec  6 06:50:22 2016
From: report at bugs.python.org (Armin Rigo)
Date: Tue, 06 Dec 2016 11:50:22 +0000
Subject: [issue28883] Python 3.5.2 crashers (from PyPy)
In-Reply-To: <1481024987.78.0.673131645253.issue28883@psf.upfronthosting.co.za>
Message-ID: <1481025022.67.0.209140991294.issue28883@psf.upfronthosting.co.za>


Armin Rigo added the comment:

os.scandir() returns an iterable object that should not be used
  from multiple threads.  Doing so can e.g. cause one thread to
  close the dirp while another thread is still using it.  This is
  likely to crash.  Similarly, the test for (!iterator->dirp) at
  the start of ScandirIterator_iternext() is only done once even
  if the following loop runs two or three times because of "." or
  ".." entries.

----------

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

From report at bugs.python.org  Tue Dec  6 06:50:44 2016
From: report at bugs.python.org (Armin Rigo)
Date: Tue, 06 Dec 2016 11:50:44 +0000
Subject: [issue28883] Python 3.5.2 crashers (from PyPy)
In-Reply-To: <1481024987.78.0.673131645253.issue28883@psf.upfronthosting.co.za>
Message-ID: <1481025044.95.0.7981776943.issue28883@psf.upfronthosting.co.za>


Armin Rigo added the comment:

(C2) os.scandir() direntry objects should not have stat() called from two
  threads concurrently.  It will make two stat objects and leak one of
  them.

----------

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

From report at bugs.python.org  Tue Dec  6 06:51:08 2016
From: report at bugs.python.org (Armin Rigo)
Date: Tue, 06 Dec 2016 11:51:08 +0000
Subject: [issue28883] Python 3.5.2 crashers (from PyPy)
In-Reply-To: <1481024987.78.0.673131645253.issue28883@psf.upfronthosting.co.za>
Message-ID: <1481025068.61.0.497625321202.issue28883@psf.upfronthosting.co.za>


Armin Rigo added the comment:

(C3) _PyGen_yf() checks the opcode at [f_lasti + 1], which is the next
  opcode that will run when we resume the generator: either it is the
  opcode following the YIELD, or it is exactly YIELD_FROM.  It is not
  possible at the moment to write Python code that compiles to a YIELD
  immediately followed by YIELD_FROM, so by chance the two cases are
  correctly distinguished.  *However,* the discussion so far assumes
  that the generator is not currently running.  If it is (which probably
  doesn't occur in reasonable Python code but can be constructed
  manually), then this checks for example the byte/word that describes
  the argument of the currently running opcode.  If we're very unlucky
  this byte has the value 72, which is YIELD_FROM.  Total nonsense and
  crashes follow.

----------

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

From report at bugs.python.org  Tue Dec  6 06:51:23 2016
From: report at bugs.python.org (Armin Rigo)
Date: Tue, 06 Dec 2016 11:51:23 +0000
Subject: [issue28883] Python 3.5.2 crashers (from PyPy)
In-Reply-To: <1481024987.78.0.673131645253.issue28883@psf.upfronthosting.co.za>
Message-ID: <1481025083.54.0.921408554688.issue28883@psf.upfronthosting.co.za>


Armin Rigo added the comment:

(C4) faulthandler: register(): the signal handler, faulthandler_user(),
  changes errno in faulthandler_dump_traceback() but fails to restore it
  if chain=False.  This can rarely cause random nonsense in the main
  program.

----------

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

From report at bugs.python.org  Tue Dec  6 06:51:53 2016
From: report at bugs.python.org (Armin Rigo)
Date: Tue, 06 Dec 2016 11:51:53 +0000
Subject: [issue28883] Python 3.5.2 crashers (from PyPy)
In-Reply-To: <1481024987.78.0.673131645253.issue28883@psf.upfronthosting.co.za>
Message-ID: <1481025113.14.0.88132106313.issue28883@psf.upfronthosting.co.za>


Armin Rigo added the comment:

(C5) setting f_lineno didn't evolve when the rest of the bytecodes evolved,
  which means it is not safe any more::

    import sys

    def f():
        try:
            raise ValueError    # line 5
        except ValueError:
            print(42)           # line 7

    def my_trace(*args):
        print(args)
        if args[1] == 'line':
            f = args[0]
            if f.f_lineno == 5:
                f.f_lineno = 7
        return my_trace

    sys.settrace(my_trace)
    f()
    sys.settrace(None)

----------

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

From report at bugs.python.org  Tue Dec  6 06:52:22 2016
From: report at bugs.python.org (Armin Rigo)
Date: Tue, 06 Dec 2016 11:52:22 +0000
Subject: [issue28883] Python 3.5.2 crashers (from PyPy)
In-Reply-To: <1481024987.78.0.673131645253.issue28883@psf.upfronthosting.co.za>
Message-ID: <1481025142.72.0.985036744887.issue28883@psf.upfronthosting.co.za>


Armin Rigo added the comment:

(C6) I didn't try, but it seems that typeobject.c:mro_internal() is prone
  to a refcount crash.  It does this::

     old_mro = type->tp_mro;
     ...mro_invoke()...  /* might cause reentrance */
     type->tp_mro = new_mro;
     ...
     Py_XDECREF(old_mro);

----------

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

From report at bugs.python.org  Tue Dec  6 06:52:43 2016
From: report at bugs.python.org (Armin Rigo)
Date: Tue, 06 Dec 2016 11:52:43 +0000
Subject: [issue28883] Python 3.5.2 crashers (from PyPy)
In-Reply-To: <1481024987.78.0.673131645253.issue28883@psf.upfronthosting.co.za>
Message-ID: <1481025163.02.0.936603970463.issue28883@psf.upfronthosting.co.za>


Changes by Armin Rigo <arigo at users.sourceforge.net>:


----------
Removed message: http://bugs.python.org/msg282524

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

From report at bugs.python.org  Tue Dec  6 06:53:06 2016
From: report at bugs.python.org (Armin Rigo)
Date: Tue, 06 Dec 2016 11:53:06 +0000
Subject: [issue28883] Python 3.5.2 crashers (from PyPy)
In-Reply-To: <1481024987.78.0.673131645253.issue28883@psf.upfronthosting.co.za>
Message-ID: <1481025186.28.0.487795876763.issue28883@psf.upfronthosting.co.za>


Armin Rigo added the comment:

(C6) I didn't try, but it seems that typeobject.c:mro_internal() is prone
  to a refcount crash.  It does this::

     old_mro = type->tp_mro;
     ...mro_invoke()...  /* might cause reentrance */
     type->tp_mro = new_mro;
     ...
     Py_XDECREF(old_mro);

  This last XDECREF drops the reference held by the previous value of
  ``type->tp_mro`` after we changed it.  But ``type->tp_mro`` might have
  changed because of mro_invoke(), which calls pure Python code.  If it
  did change, then old_mro is no longer the old value of
  ``type->tp_mro``.  The wrong object gets decrefed.

----------

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

From report at bugs.python.org  Tue Dec  6 06:55:03 2016
From: report at bugs.python.org (Armin Rigo)
Date: Tue, 06 Dec 2016 11:55:03 +0000
Subject: [issue28884] Python 3.5.2 non-segfaulting bugs (from PyPy)
Message-ID: <1481025303.32.0.218031723176.issue28884@psf.upfronthosting.co.za>


New submission from Armin Rigo:

As discussed on python-dev, I am creating omnibus issues from the lists of crashers, of wrong-according-to-the-docs, and of strange-behavior-only issues that I found while developing Python 3.5.2 support for PyPy.  These occur with CPython 3.5.2 but most of them are likely still here in trunk.

This is the issue containing the bugs that are wrong according to documentation, or at least clearly (imo) unexpected behavior.

----------
messages: 282526
nosy: arigo
priority: normal
severity: normal
status: open
title: Python 3.5.2 non-segfaulting bugs (from PyPy)
versions: Python 3.5

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

From report at bugs.python.org  Tue Dec  6 06:55:23 2016
From: report at bugs.python.org (Armin Rigo)
Date: Tue, 06 Dec 2016 11:55:23 +0000
Subject: [issue28884] Python 3.5.2 non-segfaulting bugs (from PyPy)
In-Reply-To: <1481025303.32.0.218031723176.issue28884@psf.upfronthosting.co.za>
Message-ID: <1481025323.27.0.498691434506.issue28884@psf.upfronthosting.co.za>


Armin Rigo added the comment:

(B1) on modern Linux: if the first call in the process to
  socketpair() ends in a EINVAL, then cpython will (possibly wrongly)
  assume it was caused by SOCK_CLOEXEC and not use SOCK_CLOEXEC at all
  in the future

----------

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

From report at bugs.python.org  Tue Dec  6 06:55:34 2016
From: report at bugs.python.org (Armin Rigo)
Date: Tue, 06 Dec 2016 11:55:34 +0000
Subject: [issue28884] Python 3.5.2 non-segfaulting bugs (from PyPy)
In-Reply-To: <1481025303.32.0.218031723176.issue28884@psf.upfronthosting.co.za>
Message-ID: <1481025334.98.0.47326643477.issue28884@psf.upfronthosting.co.za>


Armin Rigo added the comment:

(B2) fcntl.ioctl(x, y, buf, mutate_flag): mutate_flag is there for the case
  of buf being a read-write buffer, which is then mutated in-place.
  But if we call with a read-only buffer, mutate_flag is ignored (instead
  of rejecting a True value)---ioctl(x, y, "foo", True) will not actually
  mutate the string "foo", but the True is completely ignored.  (I think
  this is a bug introduced during the Argument Clinic refactoring.)

----------

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

From report at bugs.python.org  Tue Dec  6 06:55:49 2016
From: report at bugs.python.org (Armin Rigo)
Date: Tue, 06 Dec 2016 11:55:49 +0000
Subject: [issue28884] Python 3.5.2 non-segfaulting bugs (from PyPy)
In-Reply-To: <1481025303.32.0.218031723176.issue28884@psf.upfronthosting.co.za>
Message-ID: <1481025349.5.0.376157422337.issue28884@psf.upfronthosting.co.za>


Armin Rigo added the comment:

(B3) re.sub(b'y', bytearray(b'a'), bytearray(b'xyz')) -> b'xaz'

  re.sub(b'y', bytearray(b'\\n'), bytearray(b'xyz')) -> internal TypeError

----------

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

From report at bugs.python.org  Tue Dec  6 06:56:16 2016
From: report at bugs.python.org (Armin Rigo)
Date: Tue, 06 Dec 2016 11:56:16 +0000
Subject: [issue28884] Python 3.5.2 non-segfaulting bugs (from PyPy)
In-Reply-To: <1481025303.32.0.218031723176.issue28884@psf.upfronthosting.co.za>
Message-ID: <1481025376.08.0.891565434717.issue28884@psf.upfronthosting.co.za>


Armin Rigo added the comment:

(B4) if you have a stack of generators where each is in 'yield from' from
  the next one, and you call '.next()' on the outermost, then it enters
  and leaves all intermediate frames.  This is costly but may be
  required to get the sys.settrace()/setprofile() hooks called.
  However, if you call '.throw()' or '.close()' instead, then it uses a
  much more efficient way to go from the outermost to the innermost
  frame---as a result, the enter/leave of the intermediate frames is not
  invoked.  This can confuse coverage tools and profilers.  For example,
  in a stack ``f1()->f2()->f3()``, vmprof would show f3() as usually
  called via f2() from f1() but occasionally called directly from f1().

----------

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

From report at bugs.python.org  Tue Dec  6 06:56:58 2016
From: report at bugs.python.org (Armin Rigo)
Date: Tue, 06 Dec 2016 11:56:58 +0000
Subject: [issue28884] Python 3.5.2 non-segfaulting bugs (from PyPy)
In-Reply-To: <1481025303.32.0.218031723176.issue28884@psf.upfronthosting.co.za>
Message-ID: <1481025418.85.0.187901644209.issue28884@psf.upfronthosting.co.za>


Armin Rigo added the comment:

(B5) this is an old issue that was forgotten twice on the
  issue tracker: ``class C: __new__=int.__new__`` and ``class C(int):
  __new__=object.__new__`` can each be instantiated, even though they
  shouldn't.  This is because ``__new__`` is completely ignored if it is
  set to any built-in function that uses ``tp_new_wrapper`` as its C code
  (many of the built-in types' ``__new__`` are like that).
  http://bugs.python.org/issue1694663#msg75957,
  http://bugs.python.org/issue5322#msg84112.  In (at least) CPython 3.5,
  a few classes work only thanks to abuse of this bug: for example,
  ``io.UnsupportedOperation.__new__(io.UnsupportedOperation)`` doesn't
  work, but that was not noticed because ``io.UnsupportedOperation()``
  mistakenly works.

----------

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

From report at bugs.python.org  Tue Dec  6 06:57:17 2016
From: report at bugs.python.org (Armin Rigo)
Date: Tue, 06 Dec 2016 11:57:17 +0000
Subject: [issue28884] Python 3.5.2 non-segfaulting bugs (from PyPy)
In-Reply-To: <1481025303.32.0.218031723176.issue28884@psf.upfronthosting.co.za>
Message-ID: <1481025437.98.0.335601727204.issue28884@psf.upfronthosting.co.za>


Armin Rigo added the comment:

(B6) this program fails the check for no sys.exc_info(), even though at
  the point this assert runs (called from the <== line) we are not in
  any except/finally block.  This is a generalization of
  test_exceptions:test_generator_doesnt_retain_old_exc::

    import sys

    def g():
        try:
            raise ValueError
        except ValueError:
            yield 1
        assert sys.exc_info() == (None, None, None)
        yield 2

    gen = g()

    try:
        raise IndexError
    except IndexError:
        assert next(gen) is 1
    assert next(gen) is 2    # <==

----------

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

From report at bugs.python.org  Tue Dec  6 06:57:39 2016
From: report at bugs.python.org (Armin Rigo)
Date: Tue, 06 Dec 2016 11:57:39 +0000
Subject: [issue28884] Python 3.5.2 non-segfaulting bugs (from PyPy)
In-Reply-To: <1481025303.32.0.218031723176.issue28884@psf.upfronthosting.co.za>
Message-ID: <1481025459.28.0.556916407815.issue28884@psf.upfronthosting.co.za>


Armin Rigo added the comment:

(B7) frame.clear() does not clear f_locals, unlike what a test says
  (Lib/test/test_frame.py)::

    def test_locals_clear_locals(self):
        # Test f_locals before and after clear() (to exercise caching)
        f, outer, inner = self.make_frames()
        outer.f_locals
        inner.f_locals
        outer.clear()
        inner.clear()
        self.assertEqual(outer.f_locals, {})
        self.assertEqual(inner.f_locals, {})

  This test passes, but the C-level PyFrameObject has got a strong
  reference to f_locals, which is only updated (to be empty) if the
  Python code tries to read this attribute.  In the normal case,
  code that calls clear() but doesn't read f_locals afterwards will
  still leak everything contained in the C-level f_locals field.  This
  can be shown by this failing test::

    import sys

    def g():
        x = 42
        return sys._getframe()

    frame = g()
    d = frame.f_locals
    frame.clear()
    print(d)
    assert d == {}   # fails!  but 'assert d is frame.f_locals' passes,
                     # which shows that this dict is kept alive by
                     # 'frame'; and we've seen that it is non-empty
                     # as long as we don't read frame.f_locals.

----------

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

From report at bugs.python.org  Tue Dec  6 06:58:44 2016
From: report at bugs.python.org (Armin Rigo)
Date: Tue, 06 Dec 2016 11:58:44 +0000
Subject: [issue28884] Python 3.5.2 non-segfaulting bugs (from PyPy)
In-Reply-To: <1481025303.32.0.218031723176.issue28884@psf.upfronthosting.co.za>
Message-ID: <1481025524.61.0.807686786444.issue28884@psf.upfronthosting.co.za>


Armin Rigo added the comment:

(B8) also discussed in connection with https://bugs.python.org/issue28427

  weak dicts (both kinds) and weak sets have an implementation of
  __len__ which doesn't give the "expected" result on PyPy, and in some
  cases on CPython too.  I'm not sure what is expected and what is not.
  Here is an example on CPython 3.5.2+ (using a thread to run the weakref
  callbacks only, not to explicitly inspect or modify 'd')::

    import weakref, _thread
    from queue import Queue

    queue = Queue()
    def subthread(queue):
        while True:
            queue.get()
    _thread.start_new_thread(subthread, (queue,))

    class X:
        pass
    d = weakref.WeakValueDictionary()
    while True:
        x = X()
        d[52] = x
        queue.put(x)
        del x
        while list(d) != []:
            pass
        assert len(d) == 0  # we've checked that list(d)==[], but this may fail

  On CPython I've seen the assert fail only after editing the function
  WeakValueDictionary.__init__.remove() to add ``time.sleep(0.01)`` as
  the first line.  Otherwise I guess the timings happen to make that test
  pass.

----------

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

From report at bugs.python.org  Tue Dec  6 06:59:25 2016
From: report at bugs.python.org (Armin Rigo)
Date: Tue, 06 Dec 2016 11:59:25 +0000
Subject: [issue28884] Python 3.5.2 non-segfaulting bugs (from PyPy)
In-Reply-To: <1481025303.32.0.218031723176.issue28884@psf.upfronthosting.co.za>
Message-ID: <1481025565.28.0.169524902167.issue28884@psf.upfronthosting.co.za>


Armin Rigo added the comment:

(B9) CPython 3.5.2: this ``nonlocal`` seems not to have a reasonable
  effect (note that if we use a different name instead of ``__class__``,
  this example correctly complain that there is no binding in the outer
  scope of ``Y``)::

    class Y:
        class X:
            nonlocal __class__
            __class__ = 42
        print(locals()['__class__'])     # 42
        print(__class__)                 # but this is a NameError

----------

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

From report at bugs.python.org  Tue Dec  6 06:59:40 2016
From: report at bugs.python.org (Armin Rigo)
Date: Tue, 06 Dec 2016 11:59:40 +0000
Subject: [issue28884] Python 3.5.2 non-segfaulting bugs (from PyPy)
In-Reply-To: <1481025303.32.0.218031723176.issue28884@psf.upfronthosting.co.za>
Message-ID: <1481025580.55.0.516723271661.issue28884@psf.upfronthosting.co.za>


Armin Rigo added the comment:

(B10) Follow-up on issue #25388: running ``python x.py`` if x.py contains
  the following bytes...

  * ``b"#\xfd\n"`` => we get a SyntaxError: Non-UTF-8 code
  * ``b"# coding: utf-8\n#\xfd\n"`` => we get no error!

----------

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

From report at bugs.python.org  Tue Dec  6 07:02:48 2016
From: report at bugs.python.org (Armin Rigo)
Date: Tue, 06 Dec 2016 12:02:48 +0000
Subject: [issue28885] Python 3.5.2 strange-behavior issues (from PyPy)
Message-ID: <1481025768.53.0.205646799997.issue28885@psf.upfronthosting.co.za>


New submission from Armin Rigo:

As discussed on python-dev, I am creating omnibus issues from the lists of crashers, of wrong-according-to-the-docs, and of strange-behavior-only issues that I found while developing Python 3.5.2 support for PyPy.  These occur with CPython 3.5.2 but most of them are likely still here in trunk.

This is the issue containing the "strange behaviors" and some of them, or possibly most, will turn out to be my own feelings only and not python-dev's, which is fine by me.

----------
messages: 282537
nosy: arigo
priority: normal
severity: normal
status: open
title: Python 3.5.2 strange-behavior issues (from PyPy)

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

From report at bugs.python.org  Tue Dec  6 07:03:01 2016
From: report at bugs.python.org (Armin Rigo)
Date: Tue, 06 Dec 2016 12:03:01 +0000
Subject: [issue28885] Python 3.5.2 strange-behavior issues (from PyPy)
In-Reply-To: <1481025768.53.0.205646799997.issue28885@psf.upfronthosting.co.za>
Message-ID: <1481025781.26.0.113988199064.issue28885@psf.upfronthosting.co.za>


Armin Rigo added the comment:

(S1) ceval.c: GET_AITER: calls _PyCoro_GetAwaitableIter(), which might
  get an exception from calling the user-defined __await__() or checking
  what it returns; such an exception is completely eaten.

----------

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

From report at bugs.python.org  Tue Dec  6 07:03:16 2016
From: report at bugs.python.org (Armin Rigo)
Date: Tue, 06 Dec 2016 12:03:16 +0000
Subject: [issue28885] Python 3.5.2 strange-behavior issues (from PyPy)
In-Reply-To: <1481025768.53.0.205646799997.issue28885@psf.upfronthosting.co.za>
Message-ID: <1481025796.39.0.882123542906.issue28885@psf.upfronthosting.co.za>


Armin Rigo added the comment:

(S2) argument clinic turns the "bool" specifier into
  PyObject_IsTrue(), accepting any argument whatsoever.  This can easily
  get very confusing for the user, e.g. after messing up the number of
  arguments.  For example: os.symlink("/path1", "/path2", "/path3")
  doesn't fail, it just considers the 3rd argument as some true value.

----------

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

From report at bugs.python.org  Tue Dec  6 07:03:26 2016
From: report at bugs.python.org (Armin Rigo)
Date: Tue, 06 Dec 2016 12:03:26 +0000
Subject: [issue28885] Python 3.5.2 strange-behavior issues (from PyPy)
In-Reply-To: <1481025768.53.0.205646799997.issue28885@psf.upfronthosting.co.za>
Message-ID: <1481025806.28.0.899999813908.issue28885@psf.upfronthosting.co.za>


Armin Rigo added the comment:

(S3) hash({}.values()) works (but hash({}.keys()) correctly gives
  TypeError).  That's a bit confusing and, as far as I can tell, always
  pointless.  Also, related: d.keys()==d.keys() but
  d.values()!=d.values().

----------

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

From report at bugs.python.org  Tue Dec  6 07:03:34 2016
From: report at bugs.python.org (Armin Rigo)
Date: Tue, 06 Dec 2016 12:03:34 +0000
Subject: [issue28885] Python 3.5.2 strange-behavior issues (from PyPy)
In-Reply-To: <1481025768.53.0.205646799997.issue28885@psf.upfronthosting.co.za>
Message-ID: <1481025814.76.0.570730370792.issue28885@psf.upfronthosting.co.za>


Armin Rigo added the comment:

(S4) if you write ``from .a import b`` inside the Python prompt, or in
  a module not in any package, then you get a SystemError(!) with an
  error message that is unlikely to help newcomers.

----------

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

From report at bugs.python.org  Tue Dec  6 07:03:44 2016
From: report at bugs.python.org (Armin Rigo)
Date: Tue, 06 Dec 2016 12:03:44 +0000
Subject: [issue28885] Python 3.5.2 strange-behavior issues (from PyPy)
In-Reply-To: <1481025768.53.0.205646799997.issue28885@psf.upfronthosting.co.za>
Message-ID: <1481025824.93.0.55818393914.issue28885@psf.upfronthosting.co.za>


Armin Rigo added the comment:

(S5) pep 475: unclear why 'os.fchmod(fd)' retries automatically when
  it gets EINTR but the otherwise-equivalent 'os.chmod(fd)' does not.
  (The documentation says they are fully equivalent, so someone is
  wrong.)

----------

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

From report at bugs.python.org  Tue Dec  6 07:04:46 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 06 Dec 2016 12:04:46 +0000
Subject: [issue28838] Uniformize argument names of "call" functions (C API)
In-Reply-To: <1480504437.73.0.907175245586.issue28838@psf.upfronthosting.co.za>
Message-ID: <1481025886.47.0.665403979102.issue28838@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Added comments on Rietveld.

I think we can keep "func" instead of "callable" in the source code for decreasing the number of changes.

----------

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

From report at bugs.python.org  Tue Dec  6 07:08:13 2016
From: report at bugs.python.org (Armin Rigo)
Date: Tue, 06 Dec 2016 12:08:13 +0000
Subject: [issue28885] Python 3.5.2 strange-behavior issues (from PyPy)
In-Reply-To: <1481025768.53.0.205646799997.issue28885@psf.upfronthosting.co.za>
Message-ID: <1481026093.46.0.628339009484.issue28885@psf.upfronthosting.co.za>


Changes by Armin Rigo <arigo at users.sourceforge.net>:


----------
versions: +Python 3.5

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

From report at bugs.python.org  Tue Dec  6 07:08:35 2016
From: report at bugs.python.org (Armin Rigo)
Date: Tue, 06 Dec 2016 12:08:35 +0000
Subject: [issue28883] Python 3.5.2 crashers (from PyPy)
In-Reply-To: <1481024987.78.0.673131645253.issue28883@psf.upfronthosting.co.za>
Message-ID: <1481026115.81.0.106449208443.issue28883@psf.upfronthosting.co.za>


Changes by Armin Rigo <arigo at users.sourceforge.net>:


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

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

From report at bugs.python.org  Tue Dec  6 07:08:48 2016
From: report at bugs.python.org (Armin Rigo)
Date: Tue, 06 Dec 2016 12:08:48 +0000
Subject: [issue28884] Python 3.5.2 non-segfaulting bugs (from PyPy)
In-Reply-To: <1481025303.32.0.218031723176.issue28884@psf.upfronthosting.co.za>
Message-ID: <1481026128.43.0.764915368065.issue28884@psf.upfronthosting.co.za>


Changes by Armin Rigo <arigo at users.sourceforge.net>:


----------
type:  -> behavior

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

From report at bugs.python.org  Tue Dec  6 07:09:05 2016
From: report at bugs.python.org (Armin Rigo)
Date: Tue, 06 Dec 2016 12:09:05 +0000
Subject: [issue28885] Python 3.5.2 strange-behavior issues (from PyPy)
In-Reply-To: <1481025768.53.0.205646799997.issue28885@psf.upfronthosting.co.za>
Message-ID: <1481026145.79.0.396200589553.issue28885@psf.upfronthosting.co.za>


Changes by Armin Rigo <arigo at users.sourceforge.net>:


----------
type:  -> behavior

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

From report at bugs.python.org  Tue Dec  6 07:15:00 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 06 Dec 2016 12:15:00 +0000
Subject: [issue28884] Python 3.5.2 non-segfaulting bugs (from PyPy)
In-Reply-To: <1481025303.32.0.218031723176.issue28884@psf.upfronthosting.co.za>
Message-ID: <1481026500.02.0.136590301706.issue28884@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

About (B10) see issue18961 and issue25937.

----------
dependencies: +DIfference between utf8 and utf-8 when i define python source code encoding., Non-UTF8 encoding line
nosy: +serhiy.storchaka

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

From report at bugs.python.org  Tue Dec  6 07:48:18 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 06 Dec 2016 12:48:18 +0000
Subject: [issue28884] Python 3.5.2 non-segfaulting bugs (from PyPy)
In-Reply-To: <1481025303.32.0.218031723176.issue28884@psf.upfronthosting.co.za>
Message-ID: <1481028498.91.0.48948240579.issue28884@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

About (B3): Only str and bytes are supported. The support of bytearray templates is not documented and is not guarantied.

----------

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

From report at bugs.python.org  Tue Dec  6 07:59:07 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 06 Dec 2016 12:59:07 +0000
Subject: [issue28885] Python 3.5.2 strange-behavior issues (from PyPy)
In-Reply-To: <1481025768.53.0.205646799997.issue28885@psf.upfronthosting.co.za>
Message-ID: <1481029147.22.0.553643473009.issue28885@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

(S4) was fixed in 3.6 (issue18018). But the fix was not applied to 3.5.

----------
dependencies: +SystemError: Parent module '' not loaded, cannot perform relative import
nosy: +brett.cannon, serhiy.storchaka

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

From report at bugs.python.org  Tue Dec  6 08:02:59 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 06 Dec 2016 13:02:59 +0000
Subject: [issue28885] Python 3.5.2 strange-behavior issues (from PyPy)
In-Reply-To: <1481025768.53.0.205646799997.issue28885@psf.upfronthosting.co.za>
Message-ID: <1481029379.92.0.230943617446.issue28885@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

(S2) is related not to Argument Clinic itself, but to the 'p' format unit added in 3.3 (issue14705).

----------

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

From report at bugs.python.org  Tue Dec  6 08:43:37 2016
From: report at bugs.python.org (John Hagen)
Date: Tue, 06 Dec 2016 13:43:37 +0000
Subject: [issue28886] Deprecated abstract base class (abc) decorators do not
 raise DeprecationWarning
Message-ID: <1481031817.69.0.735601842725.issue28886@psf.upfronthosting.co.za>


New submission from John Hagen:

In the abc module (https://docs.python.org/3/library/abc.html) the following decorators have been deprecated since Python 3.3:

- abstractclassmethod
- abstractstaticmethod
- abstractproperty

But if you run the following example code using Python 3.5.2 with -Werror, no DeprecationWarnings are thrown. Throwing DeprecationWarnings will help make it more clear that these properties should not be used. PyCharm, for example, will strikethrough the usage of methods that throw DeprecationWarning so that even new users will be notified quickly even if they don't run with -Werror.


import abc


class Base(abc.ABC):
    @abc.abstractclassmethod
    def abstract_class(cls):
        pass

    @abc.abstractstaticmethod
    def abstract_static():
        pass

    @abc.abstractproperty
    def abstract_property(self):
        pass


class Child(Base):
    @classmethod
    def abstract_class(cls):
        print('Abstract class method')

    @staticmethod
    def abstract_static():
        print('Abstract static method')

    @property
    def abstract_property(self):
        return 'Abstract property'


child = Child()
child.abstract_class()
child.abstract_static()
print(child.abstract_property)

----------
components: Library (Lib)
messages: 282548
nosy: John Hagen
priority: normal
severity: normal
status: open
title: Deprecated abstract base class (abc) decorators do not raise DeprecationWarning
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Tue Dec  6 08:57:45 2016
From: report at bugs.python.org (Henning von Bargen)
Date: Tue, 06 Dec 2016 13:57:45 +0000
Subject: [issue28879] smtplib RFC 5322 date header missing
In-Reply-To: <1480952895.22.0.418354723664.issue28879@psf.upfronthosting.co.za>
Message-ID: <1481032665.41.0.522925381384.issue28879@psf.upfronthosting.co.za>


Henning von Bargen added the comment:

I can give a little more information.
First, I created a very simple stand-alone test script (for Python >= 2.6):

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

import smtplib

# Adjust these!

HOST = "smtp.nowhere.local"
PORT = 25

from_name = u"Test Python smtplib"
from_addr = u"valid.address at nowhere.local"

to_name = u"Python Test Recipient"
to_addr = u"some.address at yourcompany.com"

subject = "Test Nr. 1"
smtp = smtplib.SMTP(HOST, PORT, timeout=10)
smtp.set_debuglevel(1)
smtp.sendmail(from_addr, [to_addr], subject)
smtp.quit()


This script shows the same behavior, which shows that the problem is not related to my program, but it is indeed a problem with smtplib.py.

Unfortunately, I could only test this with Python 2.6, because I'm not allowed to install Python 2.7 on that machine; OTOH I have to run it on that machine to have access to the mail server.

The observations are:

* The message is sent (I sent it to one of my email addresses).

* Spam Assassin flags the message with additional header lines: X-Amavis-Alert: BAD HEADER SECTION, Missing required header field: "Date"
X-Spam-Status: No, score=-2.36 ...
* In some cases the message is silently dropped, because the missing date header caues a negative score; which in turn may be bad enough to classify it as spam, depending on the content.
* The SMTP server used here is Postfix.
* When I receive the message, a Date header is present (obviously it has been inserted during the message's journey through the internet).

Personal opinion: 
I think classifying a message as spam just because a practically useless header field is missing is bad behavior of Spam Assaassin.
Nevertheless, the standard library should try to conform to RFC 5322.
It is good practise to be forgiving while reading but pedantic while writing.

----------

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

From report at bugs.python.org  Tue Dec  6 09:39:07 2016
From: report at bugs.python.org (WayEasy Corporation)
Date: Tue, 06 Dec 2016 14:39:07 +0000
Subject: [issue28887] Login with Google not working on PyPi site
Message-ID: <1481035147.21.0.438294076255.issue28887@psf.upfronthosting.co.za>


New submission from WayEasy Corporation:

When I try to login with Google I don't get an error but I'm not logged in either.

----------
messages: 282550
nosy: WayEasy Corporation
priority: normal
severity: normal
status: open
title: Login with Google not working on PyPi site
type: performance

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

From report at bugs.python.org  Tue Dec  6 10:32:03 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 06 Dec 2016 15:32:03 +0000
Subject: [issue28838] Uniformize argument names of "call" functions (C API)
In-Reply-To: <1480504437.73.0.907175245586.issue28838@psf.upfronthosting.co.za>
Message-ID: <20161206153150.14238.80322.5A09637F@psf.io>


Roundup Robot added the comment:

New changeset e6ad41a3f3bd by Victor Stinner in branch 'default':
Uniformize argument names of "call" functions
https://hg.python.org/cpython/rev/e6ad41a3f3bd

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

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

From report at bugs.python.org  Tue Dec  6 10:36:48 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 06 Dec 2016 15:36:48 +0000
Subject: [issue28838] Uniformize argument names of "call" functions (C API)
In-Reply-To: <1480504437.73.0.907175245586.issue28838@psf.upfronthosting.co.za>
Message-ID: <1481038608.21.0.781105942671.issue28838@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I pushed a change which is rename.patch with fixes on comments in abstract.h. It seems like comments were no more revelant or moved to random places. I moved many comments, rewrote some of them, etc. Some comments were wrong like "This is the equivalent of the Python expression: o.method(args)", it's "o.method(*args)" in fact. Serhiy catched this mistake, it should now be fixed.

I chose to push this large change, instead of having another round of review, because it's tricky to handle such large changes. I suggest to push following changes if you still see issues.

I also wanted to push it quickly because I have pending changes modifying the same parts of the code in my queue :-)

Thanks for reviews Serhiy! Very useful, as usual ;-)


Serhiy: "I think we can keep "func" instead of "callable" in the source code for decreasing the number of changes."

I prefer to "fix" it as well, the purpose of the issue is to uniformize everything: .c files, .h files and .rst documentation.

----------

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

From report at bugs.python.org  Tue Dec  6 10:59:15 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 06 Dec 2016 15:59:15 +0000
Subject: [issue28879] smtplib send_message should add Date header if it is
 missing, per RFC5322
In-Reply-To: <1480952895.22.0.418354723664.issue28879@psf.upfronthosting.co.za>
Message-ID: <1481039955.43.0.860526970688.issue28879@psf.upfronthosting.co.za>


R. David Murray added the comment:

As I implied but did not say explicitly, this is the expected behavior of smtplib.  You are responsible for adding any headers to the message that you want smtplib to send.  In particular, the 'sendmail' method takes a string to send, and smtplib does not modify it except for cr/lf transformation.  smtplib does not itself understand RFC5322 message syntax.

We can, however, add a Date header in the new send_message method of the python3 email library, because it accepts a Message object, and smtplib can use the knowledge the Message object encapsulates to check for the Date header and add one if it is missing.  That's why I've left this issue open.  I have now adjusted versions accordingly (ie: this is not a bug in python2.7, it is an enhancement request for Python3).  Sorry I wasn't clear about this earlier.

Hmm.  Actually, we can argue that it is an RFC compliance issue, as you have suggested, and change it in 3.6 as well, since it isn't likely to break anyone's working code.  So I'll put 3.6 in the versions unless someone objects to that logic.  But even after this is changed in python3, the smtplib sendmail method will not add a Date header, only the send_message method.

----------
keywords: +easy
title: smtplib RFC 5322 date header missing -> smtplib send_message should add Date header if it is missing, per RFC5322
type:  -> behavior
versions: +Python 3.6, Python 3.7 -Python 2.7

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

From report at bugs.python.org  Tue Dec  6 11:02:53 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 06 Dec 2016 16:02:53 +0000
Subject: [issue28838] Using consistent naming for arguments of "call"
 functions (C API)
In-Reply-To: <1480504437.73.0.907175245586.issue28838@psf.upfronthosting.co.za>
Message-ID: <1481040173.67.0.597304193389.issue28838@psf.upfronthosting.co.za>


R. David Murray added the comment:

"Uniformize" isn't really an English word :)

----------
nosy: +r.david.murray
title: Uniformize argument names of "call" functions (C API) -> Using consistent naming for arguments of "call" functions (C API)

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

From report at bugs.python.org  Tue Dec  6 11:25:03 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 06 Dec 2016 16:25:03 +0000
Subject: [issue28838] Using consistent naming for arguments of "call"
 functions (C API)
In-Reply-To: <1480504437.73.0.907175245586.issue28838@psf.upfronthosting.co.za>
Message-ID: <1481041503.59.0.230348336524.issue28838@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Oh, you have mixed up comments! In headers descriptions are written after function declarations. You have moved some comments and now some descriptions are placed below the corresponding declaration, and some descriptions are placed above. Now it is not clear to what function every comment is related.

You should either revert your changes or change *all* headers by moving *all* descriptions above corresponding declarations. That would be very large patch, and I doubt it will be approved.

Please don't make such large changes without a review.

----------

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

From report at bugs.python.org  Tue Dec  6 11:56:29 2016
From: report at bugs.python.org (Ned Deily)
Date: Tue, 06 Dec 2016 16:56:29 +0000
Subject: [issue27030] Remove deprecated re features
In-Reply-To: <1463337497.02.0.81864271809.issue27030@psf.upfronthosting.co.za>
Message-ID: <1481043389.39.0.675319108532.issue27030@psf.upfronthosting.co.za>


Ned Deily added the comment:

It is unfortunate that the deprecation note did not explicitly mention replacement templates as well as regexp patterns.  While there are good arguments to be made for either case, I think it makes more sense to treat the replacement template as following the rules for strings rather than for regexps which would argue for making the proposed change to cause only a deprecation warning in templates for 3.6 - although I'm not happy about making such a change at the last minute.  Serhiy, please push to 3.6 for rc1.  There should also be a note in the What's New for 3.6 document.

----------
assignee: ned.deily -> serhiy.storchaka
stage: patch review -> commit review

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

From report at bugs.python.org  Tue Dec  6 12:25:46 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 06 Dec 2016 17:25:46 +0000
Subject: [issue27030] Remove deprecated re features
In-Reply-To: <1463337497.02.0.81864271809.issue27030@psf.upfronthosting.co.za>
Message-ID: <20161206172543.29438.32428.3C31EED1@psf.io>


Roundup Robot added the comment:

New changeset 1b162d6e3d01 by Serhiy Storchaka in branch '3.6':
Issue #27030: Unknown escapes in re.sub() replacement template are allowed
https://hg.python.org/cpython/rev/1b162d6e3d01

New changeset 5904d2ced3d8 by Serhiy Storchaka in branch 'default':
Merge documentation for issue #27030 from 3.6.
https://hg.python.org/cpython/rev/5904d2ced3d8

----------

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

From report at bugs.python.org  Tue Dec  6 12:34:56 2016
From: report at bugs.python.org (Eric Lafontaine)
Date: Tue, 06 Dec 2016 17:34:56 +0000
Subject: [issue28879] smtplib send_message should add Date header if it is
 missing, per RFC5322
In-Reply-To: <1480952895.22.0.418354723664.issue28879@psf.upfronthosting.co.za>
Message-ID: <1481045696.92.0.677556121984.issue28879@psf.upfronthosting.co.za>


Eric Lafontaine added the comment:

Hi,  Not sure this is where the comment goes...

I work with the smtplib and email libraries.  I understand Henning von Bargen when he say that we should have a way to support RFC 5322 without asking the user to understand how to support it.  The issue is that the SMTP protocol is NOT the protocol that format the e-mail.  SMTP is the protocol that identify the "from", the "to", start encryption and finally transfert the message.  The actual e-mail content is all passed inside the SMTP "DATA" Command.  I strongly believe that an email should not be modified by a SMTP library.

the discussion should be focused on trying to make it available to the user WITHOUT changing the current behavior of email.message class.  


In other words, I disagree to change the SMTPlib module and suggest that it's how you construct your email in the first place that should consider it;
class MessageRfc5322(email.message.Message):
    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        if self.get('Date', None) is None:
            self.add_header('Date', email.utils.formatdate())

msg = email.message_from_string(string_message, MessageRfc5322)



But, that's my opinion as someone who uses the smtplib and email library but also need to support rfc822 clients...

----------
nosy: +Eric Lafontaine

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

From report at bugs.python.org  Tue Dec  6 12:38:18 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 06 Dec 2016 17:38:18 +0000
Subject: [issue28838] Using consistent naming for arguments of "call"
 functions (C API)
In-Reply-To: <1480504437.73.0.907175245586.issue28838@psf.upfronthosting.co.za>
Message-ID: <20161206173747.30852.47141.C2BDA89F@psf.io>


Roundup Robot added the comment:

New changeset 69c7451c3ec1 by Victor Stinner in branch 'default':
Issue #28838: Fix weird indentation of abstract.h
https://hg.python.org/cpython/rev/69c7451c3ec1

----------

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

From report at bugs.python.org  Tue Dec  6 12:39:51 2016
From: report at bugs.python.org (Steve Dower)
Date: Tue, 06 Dec 2016 17:39:51 +0000
Subject: [issue28888] Installer fails when newer version of CRT is pending
 installation
Message-ID: <1481045991.8.0.918552180321.issue28888@psf.upfronthosting.co.za>


New submission from Steve Dower:

We just discovered an issue where CPython install can fail on Windows 8, 8.1 and Server 2012.

* do not install the recommended UCRT update
* install any other Windows Update that requires a reboot
* install the *latest* VC Redist and do not reboot
* install CPython

Because of the pending reboot, the UCRT update in the VC Redist will be queued but not installed. When we install CPython, because we don't find the UCRT we will try and install it, but because we install a slightly older version than the latest VC Redist we get 0x80240017 WU_E_NOT_APPLICABLE returned. Since this is an error code, we abort installation.

However, the correct action to take here is to continue installation, but trigger a mid-setup reboot before doing any of the custom actions that require Python to be installed (bootstrap pip, precompile stdlib) or require a reboot after install. We also need to do a reboot if our own installation of the UCRT requests it, since we may be the ones to queue the update.

At the very least, continuing with installation, failing the custom actions and telling the user to reboot and repair Python would also be less impactful than aborting. But I believe we can set it up to do that automatically.

Ned FYI, but I won't be forcing this in to 3.6.0. The workaround is fine for interactive installs (reboot your machine and try again) - it's only a problem when Python is being chained into a larger install (e.g. Visual Studio, or an automated deployment).

----------
assignee: steve.dower
components: Windows
messages: 282560
nosy: ned.deily, paul.moore, steve.dower, tim.golden, zach.ware
priority: high
severity: normal
stage: needs patch
status: open
title: Installer fails when newer version of CRT is pending installation
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Tue Dec  6 12:45:21 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 06 Dec 2016 17:45:21 +0000
Subject: [issue28838] Using consistent naming for arguments of "call"
 functions (C API)
In-Reply-To: <1480504437.73.0.907175245586.issue28838@psf.upfronthosting.co.za>
Message-ID: <1481046321.85.0.862787234017.issue28838@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I pushed another large patch to "fix" the indentation of abstract.h. I would prefer to also have this "reindent" change on review, but our reviewing tool doesn't support patch series :-(


Attached cleanup.patch reformats deeply the header file to use the same style for all comments, use the same style used in other Python headers. IMO it makes the header file more consistent with other header files and it makes the file more readable.


R. David Murray (r.david.murray):
> Uniformize" isn't really an English word :)

Oh, it's a frenglish word in this case :-) Good to know.


Serhiy Storchaka: "You have moved some comments and now some descriptions are placed below the corresponding declaration, and some descriptions are placed above. Now it is not clear to what function every comment is related."

It don't think that my change makes abstract.h worse, some comments were far from their declaration, and there is was no unique style for comments. It's a mess.


Serhiy: "You should either revert your changes or change *all* headers by moving *all* descriptions above corresponding declarations."

My plan is to rewrite completely abstact.h, this file annoys me since many months :-)


"That would be very large patch, and I doubt it will be approved."

Why not?


"Please don't make such large changes without a review."

You reviewed rename.patch, I only made tiny changes after this patch. As I explained, it's hard to work on such large patch.

----------
Added file: http://bugs.python.org/file45777/cleanup.patch

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

From report at bugs.python.org  Tue Dec  6 13:16:50 2016
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 06 Dec 2016 18:16:50 +0000
Subject: [issue28885] Python 3.5.2 strange-behavior issues (from PyPy)
In-Reply-To: <1481025768.53.0.205646799997.issue28885@psf.upfronthosting.co.za>
Message-ID: <1481048210.35.0.36758145796.issue28885@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Victor & Yury for S1.

----------
nosy: +haypo, yselivanov

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

From report at bugs.python.org  Tue Dec  6 13:24:01 2016
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 06 Dec 2016 18:24:01 +0000
Subject: [issue28835] Change in behavior when overriding warnings.showwarning
 and with catch_warnings(record=True)
In-Reply-To: <1480465767.99.0.401403947818.issue28835@psf.upfronthosting.co.za>
Message-ID: <1481048641.85.0.0601232546391.issue28835@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Serhiy's patch LGTM.

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

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

From report at bugs.python.org  Tue Dec  6 13:30:07 2016
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 06 Dec 2016 18:30:07 +0000
Subject: [issue28883] Python 3.5.2 crashers (from PyPy)
In-Reply-To: <1481024987.78.0.673131645253.issue28883@psf.upfronthosting.co.za>
Message-ID: <1481049007.87.0.0325270826357.issue28883@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Victor for C4.

----------
nosy: +brett.cannon, haypo

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

From report at bugs.python.org  Tue Dec  6 13:36:44 2016
From: report at bugs.python.org (nemunaire)
Date: Tue, 06 Dec 2016 18:36:44 +0000
Subject: [issue27629] Cannot create ssl.SSLSocket without existing socket
In-Reply-To: <1469575305.76.0.392837082138.issue27629@psf.upfronthosting.co.za>
Message-ID: <1481049404.59.0.603505964599.issue27629@psf.upfronthosting.co.za>


nemunaire added the comment:

The documentation already recommends to use SSLContext.wrap_socket(), but it didn't cover all use cases. Eg. I use multiple inheritance to handle both socket and SSLSocket inside a factory pattern, in order to override some methods defined in both classes. If I use SSLContext.wrap_socket(), it erases my overrides.

As the patch add some tests on this feature, this is no more dead code; however I let you decide the future of this issue: I've updated my patch with your remarks if you want to include it (it applies from Python 3.3 to current Python 3.6).

----------
Added file: http://bugs.python.org/file45778/fix_sslsocket_init_without_socket_3_3-3_6.patch

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

From report at bugs.python.org  Tue Dec  6 13:37:25 2016
From: report at bugs.python.org (nemunaire)
Date: Tue, 06 Dec 2016 18:37:25 +0000
Subject: [issue27629] Cannot create ssl.SSLSocket without existing socket
In-Reply-To: <1469575305.76.0.392837082138.issue27629@psf.upfronthosting.co.za>
Message-ID: <1481049445.98.0.100585812707.issue27629@psf.upfronthosting.co.za>


Changes by nemunaire <python at nemunai.re>:


Removed file: http://bugs.python.org/file43927/fix_sslsocket_init_without_socket_3_3-3_6.patch

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

From report at bugs.python.org  Tue Dec  6 13:40:03 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 06 Dec 2016 18:40:03 +0000
Subject: [issue28885] Python 3.5.2 strange-behavior issues (from PyPy)
In-Reply-To: <1481025768.53.0.205646799997.issue28885@psf.upfronthosting.co.za>
Message-ID: <1481049603.69.0.970202218238.issue28885@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

I'll take a look at s1 later tonight

----------

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

From report at bugs.python.org  Tue Dec  6 14:02:26 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 06 Dec 2016 19:02:26 +0000
Subject: [issue28889] IDLE needs the ability to pass in command-line arguments
Message-ID: <1481050946.76.0.826535117808.issue28889@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

[--- Feature request posted on behalf of Balakrishnan Sakthidharan ---]

IDLE lets you run scripts with F5.

What is needs is an F6 that opens a dialog box and asks for command-line arguments.  This will help develop and test command line scripts in the IDE.

  F6 -q5 -v=8 somefile.txt

----------
assignee: terry.reedy
components: IDLE
messages: 282567
nosy: rhettinger, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE needs the ability to pass in command-line arguments
type: enhancement
versions: Python 3.7

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

From report at bugs.python.org  Tue Dec  6 14:37:13 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 06 Dec 2016 19:37:13 +0000
Subject: [issue28838] Using consistent naming for arguments of "call"
 functions (C API)
In-Reply-To: <1481046321.85.0.862787234017.issue28838@psf.upfronthosting.co.za>
Message-ID: <4028818.WRc9st0TEA@xarax>


Serhiy Storchaka added the comment:

> It don't think that my change makes abstract.h worse, some comments were far
> from their declaration, and there is was no unique style for comments. It's
> a mess.

Seems most of comments that did not follow common style are your comments to 
"fast call" functions. It would be better to fix only that comments.

> "That would be very large patch, and I doubt it will be approved."
> Why not?

Because it breaks "hg annotation" and makes harder researching the history of 
the file. That harms the workflow of other developers. Ask on Python-Dev before 
making such larger and questionable changes.

> You reviewed rename.patch, I only made tiny changes after this patch.

Reviewed patch did not contain committed changes. That changes are not tiny.

----------

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

From report at bugs.python.org  Tue Dec  6 15:00:38 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 06 Dec 2016 20:00:38 +0000
Subject: [issue28886] Deprecated abstract base class (abc) decorators do not
 raise DeprecationWarning
In-Reply-To: <1481031817.69.0.735601842725.issue28886@psf.upfronthosting.co.za>
Message-ID: <1481054438.6.0.456505247381.issue28886@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Not all features deprecated in the source should be deprecated in the code. May be reasons for not doing this in the code.

Adding the deprecation in maintained releases can introduce a regression. It seems to me that these decorators are not broken. They is just other, more preferable way to write the same, with the combination of other decorators.

----------
nosy: +Darren.Dale, benjamin.peterson, daniel.urban, dsdale24, eric.araujo, eric.snow, ncoghlan, python-dev, serhiy.storchaka, stutzbach

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

From report at bugs.python.org  Tue Dec  6 15:27:33 2016
From: report at bugs.python.org (Julien Castiaux)
Date: Tue, 06 Dec 2016 20:27:33 +0000
Subject: [issue28890] logging.handlers: Document that QueueListener is a
 daemon thread
Message-ID: <1481056053.22.0.0948056967724.issue28890@psf.upfronthosting.co.za>


Changes by Julien Castiaux <julien.castiaux at gmail.com>:


----------
assignee: docs at python
components: Documentation
nosy: Julien Castiaux, docs at python
priority: normal
severity: normal
status: open
title: logging.handlers: Document that QueueListener is a daemon thread
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Tue Dec  6 17:15:28 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 06 Dec 2016 22:15:28 +0000
Subject: [issue28835] Change in behavior when overriding warnings.showwarning
 and with catch_warnings(record=True)
In-Reply-To: <1480465767.99.0.401403947818.issue28835@psf.upfronthosting.co.za>
Message-ID: <20161206221525.117974.59649.3BBB9DB5@psf.io>


Roundup Robot added the comment:

New changeset aaee06743c61 by Ned Deily in branch '3.6':
Issue #28835: Tidy previous showwarning changes based on review comments.
https://hg.python.org/cpython/rev/aaee06743c61

New changeset 7bca3bf6401a by Ned Deily in branch 'default':
Issue #28835: merge from 3.6
https://hg.python.org/cpython/rev/7bca3bf6401a

----------

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

From report at bugs.python.org  Tue Dec  6 17:16:58 2016
From: report at bugs.python.org (Ned Deily)
Date: Tue, 06 Dec 2016 22:16:58 +0000
Subject: [issue28835] Change in behavior when overriding warnings.showwarning
 and with catch_warnings(record=True)
In-Reply-To: <1480465767.99.0.401403947818.issue28835@psf.upfronthosting.co.za>
Message-ID: <1481062618.75.0.949333973241.issue28835@psf.upfronthosting.co.za>


Ned Deily added the comment:

Thanks everyone for getting this resolved for 360rc1!

----------
priority: release blocker -> 
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed
versions: +Python 3.7

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

From report at bugs.python.org  Tue Dec  6 17:26:24 2016
From: report at bugs.python.org (Ned Deily)
Date: Tue, 06 Dec 2016 22:26:24 +0000
Subject: [issue27030] Remove deprecated re features
In-Reply-To: <1463337497.02.0.81864271809.issue27030@psf.upfronthosting.co.za>
Message-ID: <1481063184.85.0.73610736208.issue27030@psf.upfronthosting.co.za>


Ned Deily added the comment:

Thanks, Serhiy, for reverting the error handling for 3.6.0 (in 3.6.0rc1).  I'm going to mark this as closed.  Issue28450 is still open at the moment regarding the documentation and possible 3.7 changes.

----------
priority: release blocker -> 
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed
versions: +Python 3.7

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

From report at bugs.python.org  Tue Dec  6 17:30:30 2016
From: report at bugs.python.org (Ned Deily)
Date: Tue, 06 Dec 2016 22:30:30 +0000
Subject: [issue28450] Misleading/inaccurate documentation about unknown escape
 sequences in regular expressions
In-Reply-To: <1476529213.17.0.132534478532.issue28450@psf.upfronthosting.co.za>
Message-ID: <1481063430.11.0.778632843333.issue28450@psf.upfronthosting.co.za>


Ned Deily added the comment:

Note that 1b162d6e3d01 in Issue27030 (for 3.6.0rc1) has changed the behavior for re.sub replacement templates to produce a deprecation warning in 3.6 while still being treated as an error in 3.7.

----------

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

From report at bugs.python.org  Tue Dec  6 17:46:58 2016
From: report at bugs.python.org (Ned Deily)
Date: Tue, 06 Dec 2016 22:46:58 +0000
Subject: [issue24254] Make class definition namespace ordered by default
In-Reply-To: <1432186488.39.0.20621749373.issue24254@psf.upfronthosting.co.za>
Message-ID: <1481064418.32.0.327443676394.issue24254@psf.upfronthosting.co.za>


Ned Deily added the comment:

What's the status of this issue?  It's still marked as a "deferred blocker" for 3.6.

----------
nosy: +ned.deily

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

From report at bugs.python.org  Tue Dec  6 18:06:39 2016
From: report at bugs.python.org (Ned Deily)
Date: Tue, 06 Dec 2016 23:06:39 +0000
Subject: [issue28339] "TypeError: Parameterized generics cannot be used with
 class or instance checks" in test_functools after importing typing module
In-Reply-To: <1475421693.5.0.638809019729.issue28339@psf.upfronthosting.co.za>
Message-ID: <1481065599.82.0.414228514109.issue28339@psf.upfronthosting.co.za>


Ned Deily added the comment:

This is still marked as "deferred blocker". Is there anything more that needs to be done for 3.6.0?  I'm assuming not.

----------

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

From report at bugs.python.org  Tue Dec  6 18:24:36 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 06 Dec 2016 23:24:36 +0000
Subject: [issue28838] Using consistent naming for arguments of "call"
 functions (C API)
In-Reply-To: <1480504437.73.0.907175245586.issue28838@psf.upfronthosting.co.za>
Message-ID: <1481066676.61.0.877764894874.issue28838@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Serhiy:
> Seems most of comments that did not follow common style are your comments to  "fast call" functions. It would be better to fix only that comments.

I would like to modify abstract.h because its weird style annoy me for years. I would like to make the header consistent with all other headers.

I checked unicodeobject.h, code.h, frameobject.h, floatobject.h, etc.: comments are always before declaration.

About "fast calls" in abstract.h, sorry, it's my fault. When I added new code, I used the same style than all other files. I didn't notice that abstract.h has a special style. That's why I would like to make it consistent again.


Serhiy:
> Reviewed patch did not contain committed changes.

You wrote on the review that a comment is misplaced: "The comment is related to PyObject_Call() declared 85 lines above."

That's why I took the opportunity of a refactoring change to fix comments.


Serhiy:
> That changes are not tiny.

Between rename.patch and the pushed change e6ad41a3f3bd, I only moved 5 comments: see attached rename_pushed.patch which is the diff between the two patches.

For me, it was obvious that the comment must be before the declaration, since it is the style used in all other Python headers. Sorry, I didn't expect that you didn't want to change that. I misunderstood your comment on the review.

----------
Added file: http://bugs.python.org/file45779/rename_pushed.patch

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

From report at bugs.python.org  Tue Dec  6 18:31:12 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 06 Dec 2016 23:31:12 +0000
Subject: [issue28810] Document bytecode changes in 3.6
In-Reply-To: <1480184644.53.0.660721117392.issue28810@psf.upfronthosting.co.za>
Message-ID: <1481067072.56.0.469508227299.issue28810@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Because nobody proposed a patch, here is my attempt. Following patch documents opcodes CALL_FUNCTION, CALL_FUNCTION_KW and CALL_FUNCTION_EX.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file45780/docs-call-function-opcodes.patch

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

From report at bugs.python.org  Tue Dec  6 19:33:44 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 07 Dec 2016 00:33:44 +0000
Subject: [issue28882] RFC: Slice confusing with negative strides and the 0th
 element.
In-Reply-To: <1481000800.36.0.0535087899648.issue28882@psf.upfronthosting.co.za>
Message-ID: <1481070824.12.0.70550811743.issue28882@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

I find this report nigh incomprehensible, but I will admit that I can't seem to find any good explanations of the extended slicing rules in the Python docs.

The tutorial covers slicing, but, AFAICT, it never mentions extended slicing at all, not in 3.1.2 or 3.1.3 (Strings and Lists introduction), nor anywhere in section 5 (Data structures). 3.1.2 and 3.1.3 even lie a little (claiming the implicit start is always 0, and the implicit end is always len(sequence), when those reverse for a negative slice step).

The slice object and the slice glossary entry doesn't cover it either, nor link to anything that does. The Data model entry for Slicings doesn't seem to describe meaning either.

----------
nosy: +josh.r

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

From report at bugs.python.org  Tue Dec  6 19:52:03 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 07 Dec 2016 00:52:03 +0000
Subject: [issue28885] Python 3.5.2 strange-behavior issues (from PyPy)
In-Reply-To: <1481025768.53.0.205646799997.issue28885@psf.upfronthosting.co.za>
Message-ID: <1481071923.65.0.500502354021.issue28885@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

+larry for (S2) regarding argument clinic's treatment of bool.

----------
nosy: +gregory.p.smith, larry

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

From report at bugs.python.org  Tue Dec  6 19:52:50 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 07 Dec 2016 00:52:50 +0000
Subject: [issue28886] Move deprecated abc module decorators to separate
 section in docs
In-Reply-To: <1481031817.69.0.735601842725.issue28886@psf.upfronthosting.co.za>
Message-ID: <1481071970.09.0.357741057037.issue28886@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Right, these are in the "Don't use them in new code, but we have absolutely no plans to actually remove them" documentation-only category of deprecation warning.

However, I'm converting this to a documentation enhancement request, as the documentation could make that status clearer by moving them to a separate "Legacy builtin decorator subclasses" section at the end of https://docs.python.org/3/library/abc.html

Then that section can *start* with the information on simply applying the builtin decorators on top of the abc.abstractproperty() decorator, before moving on to document the available subclasses.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python
stage:  -> needs patch
title: Deprecated abstract base class (abc) decorators do not raise DeprecationWarning -> Move deprecated abc module decorators to separate section in docs
type: behavior -> enhancement

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

From report at bugs.python.org  Tue Dec  6 19:56:52 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 07 Dec 2016 00:56:52 +0000
Subject: [issue24254] Make class definition namespace ordered by default
In-Reply-To: <1432186488.39.0.20621749373.issue24254@psf.upfronthosting.co.za>
Message-ID: <1481072212.76.0.9637196273.issue24254@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Thanks for the ping Ned.

Closing this again, as Guido explained the rationale for the change in the python-dev thread referenced above: https://mail.python.org/pipermail/python-dev/2016-September/146371.html

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

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

From report at bugs.python.org  Tue Dec  6 20:16:05 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 07 Dec 2016 01:16:05 +0000
Subject: [issue28885] Python 3.5.2 strange-behavior issues (from PyPy)
In-Reply-To: <1481025768.53.0.205646799997.issue28885@psf.upfronthosting.co.za>
Message-ID: <1481073365.67.0.647860406702.issue28885@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

attaching a proposed fix for (S5).  os.chmod should have the same EINTR retry treatment as everything else.  That it does not appears to have been an oversight.

----------
keywords: +patch
Added file: http://bugs.python.org/file45781/os-chmod-EINTR-retry.gps01.diff

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

From report at bugs.python.org  Tue Dec  6 20:24:29 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 07 Dec 2016 01:24:29 +0000
Subject: [issue28891] Standardise more behaviours for zero-argument super()
 __class__ and __classcell__
Message-ID: <1481073868.22.0.737500382194.issue28891@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

In http://bugs.python.org/issue28884#msg282535 Armin Rigo points out that the zero-argument super() cell injection currently interacts a little strangely with explicit "nonlocal __class__" statements in nested namespaces.

Specifically, it acts like a closure variable that isn't visible in its own scope, but can be accessed via nonlocal in nested class scopes:

>>> class C_with_nested_nonlocal:
...     class Inner:
...         nonlocal __class__
...         __class__ = 42
...     print(locals())
...
{'__module__': '__main__', '__qualname__': 'C_with_nested_nonlocal', 'Inner': <class '__main__.C_with_nested_nonlocal.Inner'>, '__class__': 42}

This weird behaviour is due to the way the CPython code generator injects __class__ into the namespaces we track during symbol table generation (specifically, it's made available as a free variable for nested namespaces to reference without actually adding it to the local symbol namespace for the class body). There's no requirement for other implementations to replicate the full details of that idiosyncratic behaviour, but there is a requirement that __class__ and (in 3.6+) __classcell__ not show up in locals() by default when evaluating the class body.

And methods can similarly overwrite the interpreter provided reference to the defining class:

>>> class C_with_method_assignment_to_class_cell:
...     def bad_method(self):
...         nonlocal __class__
...         __class__ = 42
...     def other_method(self):
...         return __class__
...     bad_method(None)
...     print(locals()["__class__"])
... 
42
>>> C_with_method_assignment_to_class_cell().other_method()
<class '__main__.C_with_method_assignment_to_class_cell'>
>>> C_with_method_assignment_to_class_cell().bad_method()
>>> C_with_method_assignment_to_class_cell().other_method()
42

One possible approach here would be to implement an outright language level ban on the use of "__class__" in explicit "nonlocal" declarations, and then add a test to Lib/test_super.py that ensures "__class__" and "__classcell__" don't show up in the class locals() while the statement body is executing.

----------
messages: 282585
nosy: arigo, ncoghlan
priority: normal
severity: normal
stage: test needed
status: open
title: Standardise more behaviours for zero-argument super() __class__ and __classcell__
type: behavior

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

From report at bugs.python.org  Tue Dec  6 20:27:44 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 07 Dec 2016 01:27:44 +0000
Subject: [issue28884] Python 3.5.2 non-segfaulting bugs (from PyPy)
In-Reply-To: <1481025303.32.0.218031723176.issue28884@psf.upfronthosting.co.za>
Message-ID: <1481074064.69.0.139573285234.issue28884@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I broke B9 for the "nonlocal __class__" misbehaviour out to a separate issue: http://bugs.python.org/issue28891

I love zero-argument super() as a user, but as an interpreter maintainer... ugh :P

----------
nosy: +ncoghlan

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

From report at bugs.python.org  Tue Dec  6 20:36:23 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 07 Dec 2016 01:36:23 +0000
Subject: [issue28891] Standardise more behaviours for zero-argument super()
 __class__ and __classcell__
In-Reply-To: <1481073868.22.0.737500382194.issue28891@psf.upfronthosting.co.za>
Message-ID: <1481074583.68.0.502804970382.issue28891@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Breaking the concrete proposal out to its own post:

- for CPython, "nonlocal __class__" becomes a SyntaxError generated by the symbol table pass in the compiler in 3.7+ and a DeprecationWarning in 3.6.1+
- other implementations (including PyPy) can just make "nonlocal __class__" a SyntaxError immediately
- an explicit test be added to https://hg.python.org/cpython/file/default/Lib/test/test_super.py for 3.6+ that "__class__" and "__classcell__" don't show up in the class locals() during execution of the class body

----------

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

From report at bugs.python.org  Tue Dec  6 21:52:27 2016
From: report at bugs.python.org (Dale)
Date: Wed, 07 Dec 2016 02:52:27 +0000
Subject: [issue28892] pandas.to_datetime crashes in 3.6b4
Message-ID: <1481079147.57.0.642166298292.issue28892@psf.upfronthosting.co.za>


New submission from Dale:

I'm trying 3.6b4 on my mac (OS X 10.10.5) and when I run the following code  (after doing pip install numpy and pandas) I see a 'SystemError':

>>> import pandas as pd
>>> pd.to_datetime('10/31/2016')
ValueError: Error parsing datetime string "10/31/2016" at position 2

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/schouten/virtualenvs/tmp/lib/python3.6/site-packages/pandas/util/decorators.py", line 91, in wrapper
    return func(*args, **kwargs)
  File "/Users/schouten/virtualenvs/tmp/lib/python3.6/site-packages/pandas/tseries/tools.py", line 430, in to_datetime
    return _convert_listlike(np.array([arg]), box, format)[0]
  File "/Users/schouten/virtualenvs/tmp/lib/python3.6/site-packages/pandas/tseries/tools.py", line 401, in _convert_listlike
    require_iso8601=require_iso8601
  File "pandas/tslib.pyx", line 2302, in pandas.tslib.array_to_datetime (pandas/tslib.c:43278)
  File "pandas/tslib.pyx", line 2458, in pandas.tslib.array_to_datetime (pandas/tslib.c:41773)
  File "pandas/tslib.pyx", line 2416, in pandas.tslib.array_to_datetime (pandas/tslib.c:41009)
  File "pandas/src/datetime.pxd", line 141, in datetime._string_to_dts (pandas/tslib.c:90460)
SystemError: <class 'str'> returned a result with an error set
>>>

sys.version says:

>>> import sys
>>> sys.version
'3.6.0b4 (v3.6.0b4:18496abdb3d5, Nov 21 2016, 20:44:47) \n[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]'
>>> 



With 3.5 it works as expected:

>>> import sys
>>> sys.version
'3.5.1 (v3.5.1:37a07cee5969, Dec  5 2015, 21:12:44) \n[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]'
>>> import pandas as pd
>>> pd.to_datetime('10/31/2016')
Timestamp('2016-10-31 00:00:00')
>>> 


I know it looks like pandas might be at fault, but given that the only thing I've changed is the Python version, I'm thinking it might be exposing a 3.6 bug (or vice versa, I suppose).


My apologies if I'm doing this all wrong, I'm new around here.

----------
components: Extension Modules, Interpreter Core, macOS
messages: 282588
nosy: Schouten, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: pandas.to_datetime crashes in 3.6b4
type: crash
versions: Python 3.6

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

From report at bugs.python.org  Tue Dec  6 22:36:31 2016
From: report at bugs.python.org (Larry Hastings)
Date: Wed, 07 Dec 2016 03:36:31 +0000
Subject: [issue28885] Python 3.5.2 strange-behavior issues (from PyPy)
In-Reply-To: <1481025768.53.0.205646799997.issue28885@psf.upfronthosting.co.za>
Message-ID: <1481081791.58.0.783473078284.issue28885@psf.upfronthosting.co.za>


Larry Hastings added the comment:

I assert that Argument Clinic's / PyArg_ParseTuple's handling of bool is correct.

* Python has a well-established concept of "truth":

  https://docs.python.org/3/library/stdtypes.html#truth-value-testing

  The C equivalent is, indeed, PyObject_IsTrue().

* When we added the 'p' format unit to PyArg_ParseTuple, I originally had a second format unit 'P' that would only accept boolean literal values.  But nobody could come up with a use case for it.  So we removed it.  See #14705 for the discussion.

* Existing code often does something half-assed here.  eg. stat_float_times uses the PyArg_ParseTuple "i" format unit for its boolean parameter, which accepts booleans and integers but not strings.  This is strange and inconsistent.  (Of course, you can do this with Argument Clinic, just specify the parameter as an int.  But, yuck.)

If you have a counter-proposal for how it should behave, I'd be interested to hear it.  But as far as I'm concerned, the two legitimate answers for "how to handle integers" are either a) accept literally only True and False--an approach which nobody has a use case for--or b) PyObject_IsTrue(), which behaves exactly like Python.

----------

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

From report at bugs.python.org  Tue Dec  6 22:54:21 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 07 Dec 2016 03:54:21 +0000
Subject: [issue28091] Document PEP 525
In-Reply-To: <1480969186.28.0.879526881588.issue28091@psf.upfronthosting.co.za>
Message-ID: <1481082861.3.0.434505849779.issue28091@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Eric, are you working on a patch?  If not, I'll be focusing on this myself in the next couple of days.

----------

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

From report at bugs.python.org  Tue Dec  6 22:57:40 2016
From: report at bugs.python.org (Ned Deily)
Date: Wed, 07 Dec 2016 03:57:40 +0000
Subject: [issue28892] pandas.to_datetime crashes in 3.6b4
In-Reply-To: <1481079147.57.0.642166298292.issue28892@psf.upfronthosting.co.za>
Message-ID: <1481083060.37.0.541391068878.issue28892@psf.upfronthosting.co.za>


Ned Deily added the comment:

Thanks for the report. This problem was reported previously in Issue28636 where it was determined that the problem is in Pandas (https://github.com/pandas-dev/pandas/issues/14561).  It looks like the Pandas project has pushed a fix for it.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> strange issue with Pandas-0.19.1 on Python-3.6.0b3
type: crash -> 

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

From report at bugs.python.org  Tue Dec  6 23:04:58 2016
From: report at bugs.python.org (Dale)
Date: Wed, 07 Dec 2016 04:04:58 +0000
Subject: [issue28892] pandas.to_datetime crashes in 3.6b4
In-Reply-To: <1481079147.57.0.642166298292.issue28892@psf.upfronthosting.co.za>
Message-ID: <1481083498.49.0.775246550788.issue28892@psf.upfronthosting.co.za>


Dale added the comment:

Thanks for the quick response!

----------

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

From report at bugs.python.org  Tue Dec  6 23:10:32 2016
From: report at bugs.python.org (Eric Appelt)
Date: Wed, 07 Dec 2016 04:10:32 +0000
Subject: [issue28091] Document PEP 525
In-Reply-To: <1480969186.28.0.879526881588.issue28091@psf.upfronthosting.co.za>
Message-ID: <1481083832.75.0.328717911686.issue28091@psf.upfronthosting.co.za>


Eric Appelt added the comment:

Hi Yury - Yes, I am excited about doing this and getting to work on it. Today was pretty busy but I have some time blocked out tomorrow to really dig in. I was planning to give myself a deadline of Friday afternoon if that works for the review/release schedule. If needed I can try to get it up earlier.

----------

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

From report at bugs.python.org  Tue Dec  6 23:11:22 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 07 Dec 2016 04:11:22 +0000
Subject: [issue28091] Document PEP 525
In-Reply-To: <1480969186.28.0.879526881588.issue28091@psf.upfronthosting.co.za>
Message-ID: <1481083882.02.0.142204409128.issue28091@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Friday is good, take your time!

----------

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

From report at bugs.python.org  Tue Dec  6 23:41:33 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 07 Dec 2016 04:41:33 +0000
Subject: [issue28893] Make sure exceptions raised in __aiter__ are properly
 chained in ceval
Message-ID: <1481085693.53.0.293766364883.issue28893@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

Originally reported in http://bugs.python.org/issue28885#msg282538

Ned, please take a look at the attached patch.  While I think that the change is quite small & safe to merge, I think it's OK if we push this only in 3.6.1.  It's a nice usability improvement, but only for people that implement objects with custom __await__, which is quite a rare case.

----------
assignee: yselivanov
components: Interpreter Core
files: chain.patch
keywords: patch
messages: 282595
nosy: brett.cannon, haypo, ned.deily, serhiy.storchaka, yselivanov
priority: normal
severity: normal
stage: patch review
status: open
title: Make sure exceptions raised in __aiter__ are properly chained in ceval
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45782/chain.patch

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

From report at bugs.python.org  Tue Dec  6 23:42:07 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 07 Dec 2016 04:42:07 +0000
Subject: [issue28885] Python 3.5.2 strange-behavior issues (from PyPy)
In-Reply-To: <1481025768.53.0.205646799997.issue28885@psf.upfronthosting.co.za>
Message-ID: <1481085727.09.0.0446608470563.issue28885@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

I created an issue to track S1: http://bugs.python.org/issue28893

----------

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

From report at bugs.python.org  Wed Dec  7 00:29:42 2016
From: report at bugs.python.org (Jon Dufresne)
Date: Wed, 07 Dec 2016 05:29:42 +0000
Subject: [issue28867] NamedTemporaryFile does not generate a ResourceWarning
 for unclosed files (unlike TemporaryFile)
In-Reply-To: <1480873647.39.0.877280517926.issue28867@psf.upfronthosting.co.za>
Message-ID: <1481088582.41.0.977952622191.issue28867@psf.upfronthosting.co.za>


Changes by Jon Dufresne <jon.dufresne at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file45783/namedtemporaryfile-resourcewarning.patch

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

From report at bugs.python.org  Wed Dec  7 00:36:04 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 07 Dec 2016 05:36:04 +0000
Subject: [issue28886] Move deprecated abc module decorators to separate
 section in docs
In-Reply-To: <1481031817.69.0.735601842725.issue28886@psf.upfronthosting.co.za>
Message-ID: <1481088964.05.0.18599237303.issue28886@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Dec  7 00:44:46 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 07 Dec 2016 05:44:46 +0000
Subject: [issue28893] Make sure exceptions raised in __aiter__ are properly
 chained in ceval
In-Reply-To: <1481085693.53.0.293766364883.issue28893@psf.upfronthosting.co.za>
Message-ID: <1481089486.25.0.448011031649.issue28893@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Should the original exception be stored on the __context__ or the __cause__ attribute? In the latter case you should use _PyErr_FormatFromCause().

----------

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

From report at bugs.python.org  Wed Dec  7 02:06:01 2016
From: report at bugs.python.org (Julien Palard)
Date: Wed, 07 Dec 2016 07:06:01 +0000
Subject: [issue28866] Type cache is not correctly invalidated on a class
 defining mro()
In-Reply-To: <1480862145.72.0.468660451957.issue28866@psf.upfronthosting.co.za>
Message-ID: <1481094361.0.0.822574682374.issue28866@psf.upfronthosting.co.za>


Julien Palard added the comment:

> issue28866.diff always invalidates the cache, so it works. But it is suboptimal, IMO it defeats the whole purpose of a cache.

Not sure about defeating the purpose of the cache as I only invalidate in setattr, getattr are still cache hitting. I tried:

$ python3 -m performance run --python=./python --rigorous -b all -o master.json
$ git checkout issue28866; make -j 8
$ python3 -m performance run --python=./python --rigorous -b all -o issue28866.json
$ python3 -m performance compare master.json issue28866.json

And I don't see much differences, probably only noise as I get some faster tests:

### call_method_unknown ###
Median +- Std dev: 56.8 ms +- 3.3 ms -> 52.9 ms +- 1.6 ms: 1.08x faster
Significant (t=12.92)

### pybench.IfThenElse ###
Median +- Std dev: 247 ns +- 3 ns -> 224 ns +- 16 ns: 1.11x faster
Significant (t=15.15)

and some slower:
### pybench.StringPredicates ###
Median +- Std dev: 1.89 us +- 0.05 us -> 2.18 us +- 0.21 us: 1.15x slower
Significant (t=-15.20)

### unpack_sequence ###
Median +- Std dev: 207 ns +- 4 ns -> 231 ns +- 27 ns: 1.12x slower
Significant (t=-11.63)

I'm not yet accustomed to this perf suite, so I may miss something obvious. I'll ran it again on master to measure the noise and should probably fine-tune my system for stability.

I'll also try a benchmark without the cache for comparison.

----------

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

From report at bugs.python.org  Wed Dec  7 02:49:49 2016
From: report at bugs.python.org (SilentGhost)
Date: Wed, 07 Dec 2016 07:49:49 +0000
Subject: [issue28867] NamedTemporaryFile does not generate a ResourceWarning
 for unclosed files (unlike TemporaryFile)
In-Reply-To: <1480873647.39.0.877280517926.issue28867@psf.upfronthosting.co.za>
Message-ID: <1481096989.02.0.208461816727.issue28867@psf.upfronthosting.co.za>


SilentGhost added the comment:

The ResourceWarning that you've introduced need to be "fixed" in a few place in test_urllib2

----------
stage:  -> needs patch
versions: +Python 3.7

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

From report at bugs.python.org  Wed Dec  7 02:56:36 2016
From: report at bugs.python.org (SilentGhost)
Date: Wed, 07 Dec 2016 07:56:36 +0000
Subject: [issue28887] Login with Google not working on PyPi site
In-Reply-To: <1481035147.21.0.438294076255.issue28887@psf.upfronthosting.co.za>
Message-ID: <1481097396.43.0.348178376887.issue28887@psf.upfronthosting.co.za>


SilentGhost added the comment:

This is the wrong bug tracker. The issue seems to have already been reported to pypa https://github.com/pypa/pypi-legacy/issues/492

----------
nosy: +SilentGhost
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type: performance -> behavior

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

From report at bugs.python.org  Wed Dec  7 03:48:16 2016
From: report at bugs.python.org (Armin Rigo)
Date: Wed, 07 Dec 2016 08:48:16 +0000
Subject: [issue28885] Python 3.5.2 strange-behavior issues (from PyPy)
In-Reply-To: <1481025768.53.0.205646799997.issue28885@psf.upfronthosting.co.za>
Message-ID: <1481100496.09.0.103070190846.issue28885@psf.upfronthosting.co.za>


Armin Rigo added the comment:

(S5) gregory: actually there is also fchown/chown in the same situation.

----------

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

From report at bugs.python.org  Wed Dec  7 04:11:46 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 07 Dec 2016 09:11:46 +0000
Subject: [issue28847] dumbdbm should not commit if in read mode
In-Reply-To: <1480564427.92.0.600594500998.issue28847@psf.upfronthosting.co.za>
Message-ID: <20161207091142.99231.43812.5DDEC514@psf.io>


Roundup Robot added the comment:

New changeset 0a74bc7ba462 by Serhiy Storchaka in branch '3.5':
Issue #28847: dbm.dumb now supports reading read-only files and no longer
https://hg.python.org/cpython/rev/0a74bc7ba462

New changeset 0c532bd28539 by Serhiy Storchaka in branch '3.6':
Issue #28847: dbm.dumb now supports reading read-only files and no longer
https://hg.python.org/cpython/rev/0c532bd28539

New changeset 2f59be67830c by Serhiy Storchaka in branch 'default':
Issue #28847: dbm.dumb now supports reading read-only files and no longer
https://hg.python.org/cpython/rev/2f59be67830c

New changeset a10361dfbf64 by Serhiy Storchaka in branch 'default':
Issue #28847: A deprecation warning is now emitted if the index file is missed
https://hg.python.org/cpython/rev/a10361dfbf64

----------

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

From report at bugs.python.org  Wed Dec  7 04:12:22 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 07 Dec 2016 09:12:22 +0000
Subject: [issue28847] dumbdbm should not commit if in read mode
In-Reply-To: <1480564427.92.0.600594500998.issue28847@psf.upfronthosting.co.za>
Message-ID: <1481101942.53.0.96486968531.issue28847@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Dec  7 04:15:02 2016
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 07 Dec 2016 09:15:02 +0000
Subject: [issue12660] test_gdb fails when installed
In-Reply-To: <1312038409.05.0.274432685937.issue12660@psf.upfronthosting.co.za>
Message-ID: <1481102102.97.0.741954700344.issue12660@psf.upfronthosting.co.za>


Changes by INADA Naoki <songofacandy at gmail.com>:


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

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

From report at bugs.python.org  Wed Dec  7 04:16:54 2016
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 07 Dec 2016 09:16:54 +0000
Subject: [issue28770] Update python-gdb.py for fastcalls
In-Reply-To: <1479814975.16.0.381517171433.issue28770@psf.upfronthosting.co.za>
Message-ID: <1481102214.1.0.821126857071.issue28770@psf.upfronthosting.co.za>


INADA Naoki added the comment:

3.6 branch is reopened

----------

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

From report at bugs.python.org  Wed Dec  7 04:19:31 2016
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 07 Dec 2016 09:19:31 +0000
Subject: [issue28328] statistics.geometric_mean has no tests. Defer to 3.7?
In-Reply-To: <1475325234.65.0.257375698668.issue28328@psf.upfronthosting.co.za>
Message-ID: <1481102371.42.0.699667312902.issue28328@psf.upfronthosting.co.za>


INADA Naoki added the comment:

3.6rc1 is released.
What is status of this issue?

----------

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

From report at bugs.python.org  Wed Dec  7 04:28:14 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 07 Dec 2016 09:28:14 +0000
Subject: [issue5322] Python 2.6 object.__new__ argument calling autodetection
 faulty
In-Reply-To: <1235075665.37.0.301694124748.issue5322@psf.upfronthosting.co.za>
Message-ID: <20161207092810.99657.85699.5672B418@psf.io>


Roundup Robot added the comment:

New changeset 1f31bf3f76f5 by Serhiy Storchaka in branch '3.5':
Issue #5322: Fixed setting __new__ to a PyCFunction inside Python code.
https://hg.python.org/cpython/rev/1f31bf3f76f5

New changeset 747de8acb7e4 by Serhiy Storchaka in branch '3.6':
Issue #5322: Fixed setting __new__ to a PyCFunction inside Python code.
https://hg.python.org/cpython/rev/747de8acb7e4

New changeset 9605c558ab58 by Serhiy Storchaka in branch 'default':
Issue #5322: Fixed setting __new__ to a PyCFunction inside Python code.
https://hg.python.org/cpython/rev/9605c558ab58

----------

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

From report at bugs.python.org  Wed Dec  7 04:32:05 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 07 Dec 2016 09:32:05 +0000
Subject: [issue28885] Python 3.5.2 strange-behavior issues (from PyPy)
In-Reply-To: <1481025768.53.0.205646799997.issue28885@psf.upfronthosting.co.za>
Message-ID: <1481103125.88.0.357152713049.issue28885@psf.upfronthosting.co.za>


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


----------
dependencies: +Make sure exceptions raised in __aiter__ are properly chained in ceval

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

From report at bugs.python.org  Wed Dec  7 04:32:35 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 07 Dec 2016 09:32:35 +0000
Subject: [issue28884] Python 3.5.2 non-segfaulting bugs (from PyPy)
In-Reply-To: <1481025303.32.0.218031723176.issue28884@psf.upfronthosting.co.za>
Message-ID: <1481103155.89.0.45233908404.issue28884@psf.upfronthosting.co.za>


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


----------
dependencies: +Standardise more behaviours for zero-argument super() __class__ and __classcell__

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

From report at bugs.python.org  Wed Dec  7 04:39:37 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 07 Dec 2016 09:39:37 +0000
Subject: [issue28731] _PyDict_NewPresized() creates too small dict
In-Reply-To: <1479466985.37.0.124038643632.issue28731@psf.upfronthosting.co.za>
Message-ID: <20161207093934.117974.23823.D98072C1@psf.io>


Roundup Robot added the comment:

New changeset d03562dcbb82 by INADA Naoki in branch '3.6':
Issue #28731: Optimize _PyDict_NewPresized() to create correct size dict.
https://hg.python.org/cpython/rev/d03562dcbb82

----------

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

From report at bugs.python.org  Wed Dec  7 04:40:06 2016
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 07 Dec 2016 09:40:06 +0000
Subject: [issue28731] _PyDict_NewPresized() creates too small dict
In-Reply-To: <1479466985.37.0.124038643632.issue28731@psf.upfronthosting.co.za>
Message-ID: <1481103606.04.0.502366569661.issue28731@psf.upfronthosting.co.za>


Changes by INADA Naoki <songofacandy at gmail.com>:


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

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

From report at bugs.python.org  Wed Dec  7 04:45:22 2016
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 07 Dec 2016 09:45:22 +0000
Subject: [issue28328] statistics.geometric_mean has no tests. Defer to 3.7?
In-Reply-To: <1475325234.65.0.257375698668.issue28328@psf.upfronthosting.co.za>
Message-ID: <1481103922.22.0.52252785321.issue28328@psf.upfronthosting.co.za>


INADA Naoki added the comment:

It had been rolled back.
https://hg.python.org/cpython/rev/9dce0e41bedd

Can we close this issue? #27181 is still open.

----------

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

From report at bugs.python.org  Wed Dec  7 04:57:50 2016
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 07 Dec 2016 09:57:50 +0000
Subject: [issue10401] Globals / builtins cache
In-Reply-To: <1289597080.96.0.9732660757.issue10401@psf.upfronthosting.co.za>
Message-ID: <1481104670.01.0.272833531884.issue10401@psf.upfronthosting.co.za>


INADA Naoki added the comment:

dict has ma_version for now.

@haypo, how do you think about this patch?
Would you reimplement global cache?  Or may I update this patch?

----------
versions: +Python 3.7 -Python 3.3

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

From report at bugs.python.org  Wed Dec  7 05:07:00 2016
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 07 Dec 2016 10:07:00 +0000
Subject: [issue28818] simplify lookdict functions
In-Reply-To: <1480331020.89.0.515440713784.issue28818@psf.upfronthosting.co.za>
Message-ID: <1481105220.54.0.828842955842.issue28818@psf.upfronthosting.co.za>


INADA Naoki added the comment:

@rhettinger, could you review simplify-lookdict2.patch?

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

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

From report at bugs.python.org  Wed Dec  7 05:15:19 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 07 Dec 2016 10:15:19 +0000
Subject: [issue28818] simplify lookdict functions
In-Reply-To: <1480331020.89.0.515440713784.issue28818@psf.upfronthosting.co.za>
Message-ID: <1481105719.4.0.113281167289.issue28818@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

simplify-lookdict2.patch differs from simplify-lookdict.patch only by variable names. It LGTM as well.

----------

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

From report at bugs.python.org  Wed Dec  7 05:20:22 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 07 Dec 2016 10:20:22 +0000
Subject: [issue28818] simplify lookdict functions
In-Reply-To: <1480331020.89.0.515440713784.issue28818@psf.upfronthosting.co.za>
Message-ID: <1481106022.39.0.656454579991.issue28818@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

It looks to me that changes to find_empty_slot() can be committed independently. If this would make reviewing easier, may be split the patch on two parts?

----------

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

From report at bugs.python.org  Wed Dec  7 05:37:03 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 07 Dec 2016 10:37:03 +0000
Subject: [issue5322] Python 2.6 object.__new__ argument calling autodetection
 faulty
In-Reply-To: <1235075665.37.0.301694124748.issue5322@psf.upfronthosting.co.za>
Message-ID: <1481107023.76.0.1575951376.issue5322@psf.upfronthosting.co.za>


STINNER Victor added the comment:

test_file started to crash after the change "Issue #5322: Fixed setting __new__ to a PyCFunction inside Python code." :-/ (so all buildbots became red.)

Can someone fix it or revert it? (Sorry, I don't have the bandwith right to investigate the crash.)

----------
nosy: +haypo

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

From report at bugs.python.org  Wed Dec  7 05:37:17 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 07 Dec 2016 10:37:17 +0000
Subject: [issue28884] Python 3.5.2 non-segfaulting bugs (from PyPy)
In-Reply-To: <1481025303.32.0.218031723176.issue28884@psf.upfronthosting.co.za>
Message-ID: <1481107037.43.0.30499654378.issue28884@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

(B5) seems was just fixed in issue5322.

>>> class C: __new__ = int.__new__
... 
>>> C()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: int.__new__(C): C is not a subtype of int
>>> class C(int): __new__ = object.__new__
... 
>>> C()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: object.__new__(C) is not safe, use int.__new__()

----------
dependencies: +Python 2.6 object.__new__ argument calling autodetection faulty

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

From report at bugs.python.org  Wed Dec  7 05:48:26 2016
From: report at bugs.python.org (Samuel Shapiro)
Date: Wed, 07 Dec 2016 10:48:26 +0000
Subject: [issue10016] shutil.copyfile -- allow sparse copying
In-Reply-To: <1286029015.57.0.815158740908.issue10016@psf.upfronthosting.co.za>
Message-ID: <1481107706.1.0.569213333669.issue10016@psf.upfronthosting.co.za>


Samuel Shapiro added the comment:

Patch fails on CentOS 6 -- python 2.6

[root at LG-E1A-LNX python2.6]# patch --dry-run -l -p1 -i shutil-2.6.patch shutil.py
patching file shutil.py
Hunk #1 succeeded at 22 (offset 1 line).
Hunk #2 succeeded at 52 with fuzz 1 (offset 1 line).
Hunk #3 FAILED at 61.
1 out of 3 hunks FAILED -- saving rejects to file shutil.py.rej

----------
nosy: +Samuel Shapiro

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

From report at bugs.python.org  Wed Dec  7 05:51:19 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 07 Dec 2016 10:51:19 +0000
Subject: [issue5322] Python 2.6 object.__new__ argument calling autodetection
 faulty
In-Reply-To: <1235075665.37.0.301694124748.issue5322@psf.upfronthosting.co.za>
Message-ID: <1481107879.55.0.328174389651.issue5322@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The test is fixed if change order of base classes of UnsupportedOperation. This is rather a workaround, we should find more general fix.

----------
Added file: http://bugs.python.org/file45784/UnsupportedOperation-bases-order.patch

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

From report at bugs.python.org  Wed Dec  7 06:07:39 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Wed, 07 Dec 2016 11:07:39 +0000
Subject: [issue28596] on Android _bootlocale on startup relies on too many
 library modules
In-Reply-To: <1478166520.26.0.975749703987.issue28596@psf.upfronthosting.co.za>
Message-ID: <1481108859.75.0.211569959332.issue28596@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

Patch version 5, updated comments. Thanks for all of those feedbacks :)

----------
Added file: http://bugs.python.org/file45785/android-locale-utf8.patch

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

From report at bugs.python.org  Wed Dec  7 06:32:27 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 07 Dec 2016 11:32:27 +0000
Subject: [issue5322] Python 2.6 object.__new__ argument calling autodetection
 faulty
In-Reply-To: <1235075665.37.0.301694124748.issue5322@psf.upfronthosting.co.za>
Message-ID: <20161207113224.117560.80594.A77575C3@psf.io>


Roundup Robot added the comment:

New changeset 4a610bc8577b by Serhiy Storchaka in branch '3.5':
Change order of io.UnsupportedOperation base classes.
https://hg.python.org/cpython/rev/4a610bc8577b

----------

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

From report at bugs.python.org  Wed Dec  7 06:42:16 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 07 Dec 2016 11:42:16 +0000
Subject: [issue28818] simplify lookdict functions
In-Reply-To: <1480331020.89.0.515440713784.issue28818@psf.upfronthosting.co.za>
Message-ID: <20161207114213.13388.45189.A5AED1F3@psf.io>


Roundup Robot added the comment:

New changeset 8d4b2c6a0a7f by INADA Naoki in branch 'default':
Issue #28818: Simplify lookdict functions
https://hg.python.org/cpython/rev/8d4b2c6a0a7f

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

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

From report at bugs.python.org  Wed Dec  7 06:45:11 2016
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 07 Dec 2016 11:45:11 +0000
Subject: [issue28818] simplify lookdict functions
In-Reply-To: <1480331020.89.0.515440713784.issue28818@psf.upfronthosting.co.za>
Message-ID: <1481111111.7.0.28712645881.issue28818@psf.upfronthosting.co.za>


Changes by INADA Naoki <songofacandy at gmail.com>:


----------
assignee: rhettinger -> 
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Wed Dec  7 06:46:24 2016
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 07 Dec 2016 11:46:24 +0000
Subject: [issue28818] simplify lookdict functions
In-Reply-To: <1480331020.89.0.515440713784.issue28818@psf.upfronthosting.co.za>
Message-ID: <1481111184.46.0.676716308715.issue28818@psf.upfronthosting.co.za>


INADA Naoki added the comment:

Thank you for review. And I'm sorry about I committed the patch
before seeing last comment.

----------

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

From report at bugs.python.org  Wed Dec  7 07:39:06 2016
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 07 Dec 2016 12:39:06 +0000
Subject: [issue26110] Speedup method calls 1.2x
In-Reply-To: <1452791347.05.0.923215900831.issue26110@psf.upfronthosting.co.za>
Message-ID: <1481114346.48.0.929123303868.issue26110@psf.upfronthosting.co.za>


Changes by INADA Naoki <songofacandy at gmail.com>:


----------
versions: +Python 3.7 -Python 3.6
Added file: http://bugs.python.org/file45786/call_method_4.patch

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

From report at bugs.python.org  Wed Dec  7 07:53:17 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 07 Dec 2016 12:53:17 +0000
Subject: [issue26110] Speedup method calls 1.2x
In-Reply-To: <1452791347.05.0.923215900831.issue26110@psf.upfronthosting.co.za>
Message-ID: <1481115197.64.0.341573711759.issue26110@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Please increase the magic number by 10. We need to reserve few numbers for the case of bytecode bug fixes in 3.6.

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

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

From report at bugs.python.org  Wed Dec  7 08:50:48 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 07 Dec 2016 13:50:48 +0000
Subject: [issue26110] Speedup method calls 1.2x
In-Reply-To: <1452791347.05.0.923215900831.issue26110@psf.upfronthosting.co.za>
Message-ID: <1481118648.08.0.308851427849.issue26110@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Added comments on Rietveld. Please document new bytecodes in the dis module documentation and What's New.

----------

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

From report at bugs.python.org  Wed Dec  7 09:37:59 2016
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 07 Dec 2016 14:37:59 +0000
Subject: [issue26110] Speedup method calls 1.2x
In-Reply-To: <1452791347.05.0.923215900831.issue26110@psf.upfronthosting.co.za>
Message-ID: <1481121479.33.0.843555314321.issue26110@psf.upfronthosting.co.za>


INADA Naoki added the comment:

$ ./python-default -m perf compare_to default.json callmethod4.json -G
Slower (7):
- pickle_dict: 66.0 us +- 4.6 us -> 77.0 us +- 5.9 us: 1.17x slower
- json_loads: 63.7 us +- 0.7 us -> 68.4 us +- 1.4 us: 1.07x slower
- unpack_sequence: 120 ns +- 2 ns -> 125 ns +- 3 ns: 1.04x slower
- scimark_lu: 499 ms +- 12 ms -> 514 ms +- 24 ms: 1.03x slower
- scimark_monte_carlo: 272 ms +- 10 ms -> 278 ms +- 9 ms: 1.02x slower
- scimark_sor: 517 ms +- 9 ms -> 526 ms +- 10 ms: 1.02x slower
- regex_effbot: 5.25 ms +- 0.15 ms -> 5.27 ms +- 0.17 ms: 1.00x slower

Faster (52):
- call_method: 18.1 ms +- 0.1 ms -> 14.8 ms +- 0.1 ms: 1.22x faster
- call_method_slots: 17.9 ms +- 0.2 ms -> 14.7 ms +- 0.2 ms: 1.22x faster
- call_method_unknown: 20.0 ms +- 0.9 ms -> 16.5 ms +- 0.1 ms: 1.21x faster
- xml_etree_parse: 304 ms +- 13 ms -> 283 ms +- 6 ms: 1.07x faster
- float: 310 ms +- 4 ms -> 292 ms +- 4 ms: 1.06x faster
- call_simple: 14.2 ms +- 0.6 ms -> 13.4 ms +- 0.3 ms: 1.06x faster
- pickle_pure_python: 1.34 ms +- 0.02 ms -> 1.27 ms +- 0.02 ms: 1.05x faster
- richards: 189 ms +- 3 ms -> 180 ms +- 7 ms: 1.05x faster
- logging_silent: 793 ns +- 14 ns -> 754 ns +- 9 ns: 1.05x faster
- deltablue: 18.4 ms +- 0.2 ms -> 17.6 ms +- 0.1 ms: 1.05x faster
- go: 623 ms +- 5 ms -> 594 ms +- 5 ms: 1.05x faster
- genshi_xml: 202 ms +- 2 ms -> 193 ms +- 3 ms: 1.04x faster
- fannkuch: 1.10 sec +- 0.02 sec -> 1.05 sec +- 0.02 sec: 1.04x faster
- raytrace: 1.38 sec +- 0.02 sec -> 1.32 sec +- 0.00 sec: 1.04x faster
- django_template: 419 ms +- 5 ms -> 402 ms +- 4 ms: 1.04x faster
- hexiom: 24.2 ms +- 0.2 ms -> 23.3 ms +- 0.2 ms: 1.04x faster
- xml_etree_iterparse: 225 ms +- 4 ms -> 216 ms +- 5 ms: 1.04x faster
- spectral_norm: 282 ms +- 14 ms -> 271 ms +- 4 ms: 1.04x faster
- python_startup_no_site: 9.83 ms +- 0.02 ms -> 9.46 ms +- 0.03 ms: 1.04x faster
- python_startup: 16.4 ms +- 0.0 ms -> 15.7 ms +- 0.0 ms: 1.04x faster
- unpickle_pure_python: 918 us +- 24 us -> 884 us +- 24 us: 1.04x faster
- unpickle: 33.0 us +- 0.4 us -> 31.8 us +- 0.4 us: 1.04x faster
- dulwich_log: 158 ms +- 1 ms -> 153 ms +- 1 ms: 1.04x faster
- html5lib: 234 ms +- 6 ms -> 225 ms +- 6 ms: 1.04x faster
- scimark_fft: 735 ms +- 19 ms -> 709 ms +- 22 ms: 1.04x faster
- sqlalchemy_declarative: 325 ms +- 4 ms -> 314 ms +- 3 ms: 1.04x faster
- mako: 45.4 ms +- 0.3 ms -> 43.8 ms +- 0.7 ms: 1.04x faster
- genshi_text: 90.1 ms +- 0.9 ms -> 87.0 ms +- 0.9 ms: 1.04x faster
- tornado_http: 388 ms +- 4 ms -> 375 ms +- 4 ms: 1.03x faster
- 2to3: 758 ms +- 4 ms -> 734 ms +- 4 ms: 1.03x faster
- scimark_sparse_mat_mult: 8.75 ms +- 0.25 ms -> 8.48 ms +- 0.39 ms: 1.03x faster
- json_dumps: 29.9 ms +- 0.4 ms -> 29.0 ms +- 0.3 ms: 1.03x faster
- sqlite_synth: 10.1 us +- 0.2 us -> 9.80 us +- 0.19 us: 1.03x faster
- regex_dna: 286 ms +- 6 ms -> 278 ms +- 4 ms: 1.03x faster
- crypto_pyaes: 235 ms +- 2 ms -> 228 ms +- 2 ms: 1.03x faster
- pidigits: 320 ms +- 0 ms -> 311 ms +- 1 ms: 1.03x faster
- logging_format: 38.1 us +- 0.5 us -> 37.1 us +- 0.4 us: 1.03x faster
- meteor_contest: 206 ms +- 3 ms -> 201 ms +- 1 ms: 1.03x faster
- xml_etree_process: 248 ms +- 4 ms -> 241 ms +- 4 ms: 1.03x faster
- chameleon: 30.9 ms +- 0.4 ms -> 30.1 ms +- 0.4 ms: 1.03x faster
- logging_simple: 32.8 us +- 0.4 us -> 32.0 us +- 0.3 us: 1.03x faster
- sqlalchemy_imperative: 61.3 ms +- 1.6 ms -> 59.9 ms +- 1.6 ms: 1.02x faster
- chaos: 308 ms +- 2 ms -> 301 ms +- 2 ms: 1.02x faster
- unpickle_list: 7.90 us +- 0.04 us -> 7.73 us +- 0.10 us: 1.02x faster
- sympy_integrate: 47.9 ms +- 0.3 ms -> 46.9 ms +- 0.4 ms: 1.02x faster
- sympy_sum: 216 ms +- 6 ms -> 212 ms +- 6 ms: 1.02x faster
- sympy_str: 481 ms +- 5 ms -> 473 ms +- 2 ms: 1.02x faster
- sympy_expand: 1.08 sec +- 0.01 sec -> 1.06 sec +- 0.01 sec: 1.02x faster
- regex_compile: 449 ms +- 3 ms -> 442 ms +- 5 ms: 1.02x faster
- nqueens: 275 ms +- 3 ms -> 271 ms +- 3 ms: 1.02x faster
- pathlib: 51.6 ms +- 0.6 ms -> 50.9 ms +- 0.7 ms: 1.01x faster
- pickle_list: 8.85 us +- 0.09 us -> 8.79 us +- 0.11 us: 1.01x faster

Benchmark hidden because not significant (5): nbody, pickle, regex_v8, telco, xml_etree_generate

----------
Added file: http://bugs.python.org/file45787/default.json.gz

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

From report at bugs.python.org  Wed Dec  7 09:38:11 2016
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 07 Dec 2016 14:38:11 +0000
Subject: [issue26110] Speedup method calls 1.2x
In-Reply-To: <1452791347.05.0.923215900831.issue26110@psf.upfronthosting.co.za>
Message-ID: <1481121490.99.0.635500191083.issue26110@psf.upfronthosting.co.za>


Changes by INADA Naoki <songofacandy at gmail.com>:


Added file: http://bugs.python.org/file45788/callmethod4.json.gz

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

From report at bugs.python.org  Wed Dec  7 09:47:11 2016
From: report at bugs.python.org (Marius Gedminas)
Date: Wed, 07 Dec 2016 14:47:11 +0000
Subject: [issue28894] Memory leak in dict.pop()
Message-ID: <1481122031.58.0.509371094394.issue28894@psf.upfronthosting.co.za>


New submission from Marius Gedminas:

Run the following script with Python 3.6.0rc1:

    class O:
        pass

    o = O()
    for n in range(20):
        print(n)
        o.x = 42
        o.__dict__.pop('x', None)

You can observe the memory usage of the Python process growing exponentially.

E.g. in bash:

    ulimit -v 1000000    # don't push other processes into swap please
    python3.6 break.py
    0
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    Traceback (most recent call last):
      File "break.py", line 7, in <module>
        o.x = 42
    MemoryError

----------
components: Interpreter Core
messages: 282623
nosy: mgedmin
priority: normal
severity: normal
status: open
title: Memory leak in dict.pop()
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Wed Dec  7 09:48:45 2016
From: report at bugs.python.org (Marius Gedminas)
Date: Wed, 07 Dec 2016 14:48:45 +0000
Subject: [issue28894] Memory leak in dict.pop()
In-Reply-To: <1481122031.58.0.509371094394.issue28894@psf.upfronthosting.co.za>
Message-ID: <1481122125.76.0.323737235047.issue28894@psf.upfronthosting.co.za>


Marius Gedminas added the comment:

If you're curious where this happens in real life, py.test's CaptureManager.deactivate_funcargs() does

    self.__dict__.pop("_capfuncarg", None)

and I found it by running 'tox -e py36' on https://github.com/mgedmin/eazysvn

----------

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

From report at bugs.python.org  Wed Dec  7 09:49:13 2016
From: report at bugs.python.org (Mark Summerfield)
Date: Wed, 07 Dec 2016 14:49:13 +0000
Subject: [issue28895] Two suggestions for windows.html
Message-ID: <1481122153.16.0.608374359054.issue28895@psf.upfronthosting.co.za>


New submission from Mark Summerfield:

This document is v. useful for Windows Python users:
https://docs.python.org/dev/using/windows.html

However, I think it could be improved as follows:

(1) Explain which Python installer to get (since there are so many)! Even a "get the Windows x86 executable installer if you just want it now!". Alternatively, the https://www.python.org/downloads/windows/ page could begine with a brief explanation of the differences.

(2) Explain the trade-offs between Admin & User install & the effect this has on using pip (e.g., an Admin install may require pip to be used in an Admin console or to be used with the --user option).

----------
assignee: docs at python
components: Documentation
messages: 282625
nosy: docs at python, mark
priority: normal
severity: normal
status: open
title: Two suggestions for windows.html
type: enhancement
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Wed Dec  7 09:58:58 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 07 Dec 2016 14:58:58 +0000
Subject: [issue28894] Memory leak in dict.pop()
In-Reply-To: <1481122031.58.0.509371094394.issue28894@psf.upfronthosting.co.za>
Message-ID: <1481122738.13.0.944709293705.issue28894@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

This is the same problem as #28147.

----------
nosy: +xiang.zhang
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Unbounded memory growth resizing split-table dicts

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

From report at bugs.python.org  Wed Dec  7 10:16:46 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 07 Dec 2016 15:16:46 +0000
Subject: [issue26110] Speedup method calls 1.2x
In-Reply-To: <1481121491.05.0.573494548698.issue26110@psf.upfronthosting.co.za>
Message-ID: <9037F13B-9602-433E-B2AD-7841147DF833@gmail.com>


Yury Selivanov added the comment:

Please don't merge this without my review.

----------

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

From report at bugs.python.org  Wed Dec  7 10:47:41 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 07 Dec 2016 15:47:41 +0000
Subject: [issue28895] Two suggestions for windows.html
In-Reply-To: <1481122153.16.0.608374359054.issue28895@psf.upfronthosting.co.za>
Message-ID: <1481125661.5.0.414930741503.issue28895@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +steve.dower

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

From report at bugs.python.org  Wed Dec  7 10:51:54 2016
From: report at bugs.python.org (Ulrich Petri)
Date: Wed, 07 Dec 2016 15:51:54 +0000
Subject: [issue21978] Support index access on OrderedDict views (e.g.
 o.keys()[7])
In-Reply-To: <1405329303.68.0.861089422528.issue21978@psf.upfronthosting.co.za>
Message-ID: <1481125914.56.0.785104241494.issue21978@psf.upfronthosting.co.za>


Ulrich Petri added the comment:

Should this maybe reconsidered now that dicts are ordered by default?

Having to explain why list is needed in list(some_ordered_dict.values())[0] is  a constant thorn in my side when dealing with people new to Python.

----------
nosy: +ulope

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

From report at bugs.python.org  Wed Dec  7 10:52:09 2016
From: report at bugs.python.org (Jon Dufresne)
Date: Wed, 07 Dec 2016 15:52:09 +0000
Subject: [issue28867] NamedTemporaryFile does not generate a ResourceWarning
 for unclosed files (unlike TemporaryFile)
In-Reply-To: <1480873647.39.0.877280517926.issue28867@psf.upfronthosting.co.za>
Message-ID: <1481125929.8.0.0818424458324.issue28867@psf.upfronthosting.co.za>


Jon Dufresne added the comment:

Thanks for the review. I have updated the patch. Now all warnings during tests handled. Please let me know if there are any other concerns with the changes.

----------
Added file: http://bugs.python.org/file45789/namedtemporaryfile-resourcewarning-2.patch

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

From report at bugs.python.org  Wed Dec  7 10:58:08 2016
From: report at bugs.python.org (R. David Murray)
Date: Wed, 07 Dec 2016 15:58:08 +0000
Subject: [issue28867] NamedTemporaryFile does not generate a ResourceWarning
 for unclosed files (unlike TemporaryFile)
In-Reply-To: <1480873647.39.0.877280517926.issue28867@psf.upfronthosting.co.za>
Message-ID: <1481126288.1.0.199297564864.issue28867@psf.upfronthosting.co.za>


R. David Murray added the comment:

Hmm.  That e.close() looks like there may be a deeper problem here.  I don't have time to investigate myself, unfortunately.

----------

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

From report at bugs.python.org  Wed Dec  7 11:25:45 2016
From: report at bugs.python.org (Jon Dufresne)
Date: Wed, 07 Dec 2016 16:25:45 +0000
Subject: [issue28867] NamedTemporaryFile does not generate a ResourceWarning
 for unclosed files (unlike TemporaryFile)
In-Reply-To: <1480873647.39.0.877280517926.issue28867@psf.upfronthosting.co.za>
Message-ID: <1481127945.72.0.59434970401.issue28867@psf.upfronthosting.co.za>


Jon Dufresne added the comment:

Just for some context, the e.close() is handling this bit of code:

https://github.com/python/cpython/blob/d8132c4da7c46587221c5a244224b770d03860b6/Lib/urllib/request.py#L739-L754

When there is no error, http_error_302() will close the passed fp, on error, it will not. The following comment indicates this is intentional:

# Don't close the fp until we are sure that we won't use it
# with HTTPError.

But I agree, this may pose a problem when enforcing deterministic resource handling.

----------

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

From report at bugs.python.org  Wed Dec  7 11:38:28 2016
From: report at bugs.python.org (Alexey Izbyshev)
Date: Wed, 07 Dec 2016 16:38:28 +0000
Subject: [issue28896] Embeddable zip allows Windows registry to override
 module location
Message-ID: <1481128708.35.0.521458556277.issue28896@psf.upfronthosting.co.za>


New submission from Alexey Izbyshev:

The docs claim: "... the embedded distribution is (almost) fully isolated from the user?s system, including environment variables, system registry settings, and installed packages."

Via ProcessMonitor tool I've discovered that python.exe still accesses keys like "HKLM\Software\Python\PythonCore\3.5\Modules\collections" on every module import, allowing registry settings to override the location of any non-builtin module.

Digging into the 3.5.2 code revealed that WindowsRegistryFinder is unconditionally added to sys.meta_path (Lib/importlib/_bootstrap_external.py, line 1422):

    if _os.__name__ == 'nt':
        sys.meta_path.append(WindowsRegistryFinder)

It can also be confirmed in runtime:

Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:18:55) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> print(sys.meta_path)
[<class '_frozen_importlib.BuiltinImporter'>, <class '_frozen_importlib.FrozenImporter'>, <class '_frozen_importlib_external.WindowsRegistryFinder'>, <class '_frozen_importlib_external.PathFinder'>]

Is this behavior intended? It seems to be against doc claims and the goal of embeddability.

----------
components: Windows
messages: 282632
nosy: izbyshev, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Embeddable zip allows Windows registry to override module location
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Wed Dec  7 11:54:01 2016
From: report at bugs.python.org (Charles Harris)
Date: Wed, 07 Dec 2016 16:54:01 +0000
Subject: [issue28897] Python 3.6.0rc1 breaks NumPy tests.
Message-ID: <1481129641.34.0.0925136712294.issue28897@psf.upfronthosting.co.za>


New submission from Charles Harris:

The lastest Python 3.6 pre-release broke a number of NumPy tests. The failing tests are of the sort

    with warnings.catch_warnings(record=True) as w:
        warnings.simplefilter('always')
        ...

And the failure seems to be that nothing is recorded in w. None of the beta releases caused problems. It is possible that the testing environment (Travis CI) messed up, but reporting this here just in case.

----------
components: Library (Lib)
messages: 282633
nosy: charris44
priority: normal
severity: normal
status: open
title: Python 3.6.0rc1 breaks NumPy tests.
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Wed Dec  7 11:57:00 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 07 Dec 2016 16:57:00 +0000
Subject: [issue28810] Document bytecode changes in 3.6
In-Reply-To: <1480184644.53.0.660721117392.issue28810@psf.upfronthosting.co.za>
Message-ID: <1481129820.85.0.651950718796.issue28810@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag

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

From report at bugs.python.org  Wed Dec  7 12:11:36 2016
From: report at bugs.python.org (Ned Deily)
Date: Wed, 07 Dec 2016 17:11:36 +0000
Subject: [issue28897] Python 3.6.0rc1 breaks NumPy tests.
In-Reply-To: <1481129641.34.0.0925136712294.issue28897@psf.upfronthosting.co.za>
Message-ID: <1481130696.78.0.0510094541936.issue28897@psf.upfronthosting.co.za>


Ned Deily added the comment:

Serhiy, Victor, can you look at this please?

----------
nosy: +haypo, ned.deily, serhiy.storchaka
priority: normal -> release blocker

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

From report at bugs.python.org  Wed Dec  7 12:17:01 2016
From: report at bugs.python.org (Ned Deily)
Date: Wed, 07 Dec 2016 17:17:01 +0000
Subject: [issue28147] Unbounded memory growth resizing split-table dicts
In-Reply-To: <1473853453.13.0.556951743271.issue28147@psf.upfronthosting.co.za>
Message-ID: <1481131021.13.0.494052775554.issue28147@psf.upfronthosting.co.za>


Ned Deily added the comment:

This issue seems to have slipped through. Should it be a release blocker for 3.6.0 final or can it wait for 3.6.1?

----------
nosy: +ned.deily

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

From report at bugs.python.org  Wed Dec  7 12:24:12 2016
From: report at bugs.python.org (Charles Harris)
Date: Wed, 07 Dec 2016 17:24:12 +0000
Subject: [issue28897] Python 3.6.0rc1 breaks NumPy tests.
In-Reply-To: <1481129641.34.0.0925136712294.issue28897@psf.upfronthosting.co.za>
Message-ID: <1481131452.4.0.882519815351.issue28897@psf.upfronthosting.co.za>


Charles Harris added the comment:

Probably this commit: https://hg.python.org/cpython/rev/aaee06743c61 .

----------

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

From report at bugs.python.org  Wed Dec  7 12:25:02 2016
From: report at bugs.python.org (Steve Dower)
Date: Wed, 07 Dec 2016 17:25:02 +0000
Subject: [issue28896] Embeddable zip allows Windows registry to override
 module location
In-Reply-To: <1481128708.35.0.521458556277.issue28896@psf.upfronthosting.co.za>
Message-ID: <1481131502.44.0.682797748087.issue28896@psf.upfronthosting.co.za>


Steve Dower added the comment:

It's not intentional, but we clearly haven't done anything to prevent it.

Arguably this finder should be omitted when you run in isolated mode, and I'm on the fence about deprecating it entirely. Adding the importlib experts in case they have opinions (relevant ones, ideally).

A one line workaround that can be added to any code base is:

>>> sys.meta_path[:] = [m for m in sys.meta_path if m.__name__ != 'WindowsRegistryFinder']

But it would also be good to close off this hole. Thoughts on the best option? (-I, move to site.py and -S, something new...)

----------
nosy: +brett.cannon, eric.snow, ncoghlan
versions: +Python 3.6, Python 3.7

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

From report at bugs.python.org  Wed Dec  7 12:31:41 2016
From: report at bugs.python.org (Paul Moore)
Date: Wed, 07 Dec 2016 17:31:41 +0000
Subject: [issue28896] Embeddable zip allows Windows registry to override
 module location
In-Reply-To: <1481128708.35.0.521458556277.issue28896@psf.upfronthosting.co.za>
Message-ID: <1481131901.52.0.234144640895.issue28896@psf.upfronthosting.co.za>


Paul Moore added the comment:

I thought that most of the users of this functionality had stopped doing so (the only one I recall for certain was pywin32, and last time this came up, I think someone said they had stopped).

If the functionality isn't used in any of the well-known modules, I'm +1 on deprecating it (if it is, I'm all for encouraging them to stop and then *still* deprecating it :-))

Use of the registry keys would prevent virtual environments from managing proper isolation, as well, so it's not just an issue for the embedded distribution.

----------

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

From report at bugs.python.org  Wed Dec  7 12:32:54 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 07 Dec 2016 17:32:54 +0000
Subject: [issue28897] Python 3.6.0rc1 breaks NumPy tests.
In-Reply-To: <1481129641.34.0.0925136712294.issue28897@psf.upfronthosting.co.za>
Message-ID: <1481131974.67.0.78772670194.issue28897@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could you please show an example of failing test?

----------

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

From report at bugs.python.org  Wed Dec  7 12:36:05 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Wed, 07 Dec 2016 17:36:05 +0000
Subject: [issue20211] setup.py: do not add invalid header locations
In-Reply-To: <1389308528.92.0.403642458985.issue20211@psf.upfronthosting.co.za>
Message-ID: <1481132165.9.0.297155448296.issue20211@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

Got the same issue here on building Python for Android. See https://circleci.com/gh/yan12125/python3-android/11 for an example build log. /usr/include is erroneously included and leads to build failures:

building 'xxlimited' extension
/home/ubuntu/android-ndk-r13/toolchains/llvm/prebuilt/linux-x86_64/bin/clang -target aarch64-none-linux-android -gcc-toolchain /home/ubuntu/android-ndk-r13/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64 --sysroot=/home/ubuntu/android-ndk-r13/platforms/android-21/arch-arm64/usr -fPIC -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIE -fno-integrated-as -fPIE -fno-integrated-as -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -DPy_LIMITED_API=0x03050000 -I../Include -I/usr/include -IObjects -IPython -I. -I/home/ubuntu/python3-android/build/21-aarch64-linux-android-4.9/usr/include -I/home/ubuntu/python3-android/src/cpython/Include -I/home/ubuntu/python3-android/src/cpython/build-target -c /home/ubuntu/python3-android/src/cpython/Modules/xxlimited.c -o build/temp.linux-aarch64-3.7/home/ubuntu/python3-android/src/cpython/Modules/xxlimited.o
In file included from /home/ubuntu/python3-android/src/cpython/Modules/xxlimited.c:17:
In file included from ../Include/Python.h:11:
In file included from /usr/include/limits.h:25:
/usr/include/features.h:398:10: fatal error: 'gnu/stubs.h' file not found
#include <gnu/stubs.h>
         ^
1 error generated.

The patch looks reasonable and still applies to the default branch. With this patch the build is fine: https://circleci.com/gh/yan12125/python3-android/12

----------
nosy: +Chi Hsuan Yen

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

From report at bugs.python.org  Wed Dec  7 12:37:31 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Wed, 07 Dec 2016 17:37:31 +0000
Subject: [issue20211] setup.py: do not add system header locations when cross
 compiling
In-Reply-To: <1389308528.92.0.403642458985.issue20211@psf.upfronthosting.co.za>
Message-ID: <1481132251.65.0.16017199423.issue20211@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

Modified this issue a bit and add some experts on the build system

----------
nosy: +zach.ware
title: setup.py: do not add invalid header locations -> setup.py: do not add system header locations when cross compiling
versions: +Python 3.5, Python 3.6, Python 3.7 -Python 3.4

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

From report at bugs.python.org  Wed Dec  7 12:40:09 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Wed, 07 Dec 2016 17:40:09 +0000
Subject: [issue20211] setup.py: do not add system header locations when cross
 compiling
In-Reply-To: <1389308528.92.0.403642458985.issue20211@psf.upfronthosting.co.za>
Message-ID: <1481132409.85.0.23064142831.issue20211@psf.upfronthosting.co.za>


Changes by Chi Hsuan Yen <yan12125 at gmail.com>:


----------
nosy: +xdegaye

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

From report at bugs.python.org  Wed Dec  7 12:41:53 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 07 Dec 2016 17:41:53 +0000
Subject: [issue28147] Unbounded memory growth resizing split-table dicts
In-Reply-To: <1473853453.13.0.556951743271.issue28147@psf.upfronthosting.co.za>
Message-ID: <1481132513.85.0.617308181333.issue28147@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Calling pop() for instance's __dict__ is not common operation. I expected that this bug does not affect any real code. But the case in issue28894 looks as a real case. This might be a release blocker.

----------

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

From report at bugs.python.org  Wed Dec  7 12:45:27 2016
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 07 Dec 2016 17:45:27 +0000
Subject: [issue28147] Unbounded memory growth resizing split-table dicts
In-Reply-To: <1481131021.13.0.494052775554.issue28147@psf.upfronthosting.co.za>
Message-ID: <CAEfz+TzjZLy7X_vUxaT5i7dLoWQohQ=1G63FojGrGgjjsO6hRQ@mail.gmail.com>


INADA Naoki added the comment:

> Ned Deily added the comment:
>
> This issue seems to have slipped through. Should it be a release blocker for 3.6.0 final or can it wait for 3.6.1?

On Python 3.5, instance.__dict__.popitem() cause this issue.
On Python 3.6, instance.__dict__.popitem() and instance.__dict__.pop()
cause this issue.

This is not new issue, but there is small regression.

I don't know this should be fixed in 3.6.0.
I'll make patch smaller anyway.

----------

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

From report at bugs.python.org  Wed Dec  7 12:53:21 2016
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 07 Dec 2016 17:53:21 +0000
Subject: [issue28896] Embeddable zip allows Windows registry to override
 module location
In-Reply-To: <1481128708.35.0.521458556277.issue28896@psf.upfronthosting.co.za>
Message-ID: <1481133201.05.0.584987724734.issue28896@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Deprecate the importer. If I remember correctly it took us a while to even notice it was missing due to missing tests prior to importlib coming into existence (and getting anyone to care enough to help write those tests also took a lot of effort).

----------

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

From report at bugs.python.org  Wed Dec  7 12:56:39 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 07 Dec 2016 17:56:39 +0000
Subject: [issue28897] Python 3.6.0rc1 breaks NumPy tests.
In-Reply-To: <1481129641.34.0.0925136712294.issue28897@psf.upfronthosting.co.za>
Message-ID: <1481133399.31.0.821861385645.issue28897@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See also msg278976.

----------

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

From report at bugs.python.org  Wed Dec  7 13:00:23 2016
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 07 Dec 2016 18:00:23 +0000
Subject: [issue28835] Change in behavior when overriding warnings.showwarning
 and with catch_warnings(record=True)
In-Reply-To: <1480465767.99.0.401403947818.issue28835@psf.upfronthosting.co.za>
Message-ID: <1481133623.79.0.0440947140558.issue28835@psf.upfronthosting.co.za>


Brett Cannon added the comment:

There's also issue #28835 which might be related.

----------

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

From report at bugs.python.org  Wed Dec  7 13:02:20 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Wed, 07 Dec 2016 18:02:20 +0000
Subject: [issue28190] Detect curses headers correctly for cross-compiling
In-Reply-To: <1474132808.23.0.788365161086.issue28190@psf.upfronthosting.co.za>
Message-ID: <1481133740.09.0.196212564635.issue28190@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

A clean patch without changes in ./configure. autoreconf necessary

----------
Added file: http://bugs.python.org/file45790/ncurses-headers.patch

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

From report at bugs.python.org  Wed Dec  7 13:09:43 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 07 Dec 2016 18:09:43 +0000
Subject: [issue28147] Unbounded memory growth resizing split-table dicts
In-Reply-To: <CAEfz+TzjZLy7X_vUxaT5i7dLoWQohQ=1G63FojGrGgjjsO6hRQ@mail.gmail.com>
Message-ID: <CAMpsgwYQCC-piO9-+h0o63x9M9H9OJGu7Xj_+p8g6rWDDuZbTA@mail.gmail.com>


STINNER Victor added the comment:

In this case, I suggest to wait for 3.6.1 to fix it.

----------

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

From report at bugs.python.org  Wed Dec  7 13:14:39 2016
From: report at bugs.python.org (Charalampos Stratakis)
Date: Wed, 07 Dec 2016 18:14:39 +0000
Subject: [issue28898] Can't compile gdb with Python 3.6
Message-ID: <1481134479.52.0.174259382887.issue28898@psf.upfronthosting.co.za>


New submission from Charalampos Stratakis:

Trying to compile gdb, with python support and by having it depend on Python 3.6 produces an error that the HAVE_LONG_LONG has been redefined [0].

This seems to have been introduced by this commit [1].

I'm in no way expert on gdb, but from what I could deduct from the build logs, the #define HAVE_LONG_LONG line in pyport.h [2] is the issue, as gdb also sets the same constant to 1 [3][4]

I build python and gdb as rpm's, but I can't verify if it happens as well outside this environment. Could someone more experienced with gdb take a look at it?

The issue seems to be fixed by wrapping the #define HAVE_LONG_LONG with an #ifndef HAVE_LONG_LONG

Attaching a patch for consideration

[0] https://copr-be.cloud.fedoraproject.org/results/cstratak/python3.6/fedora-26-x86_64/00485858-gdb/build.log.gz

[1] https://hg.python.org/cpython/rev/cf6e9968ebb7/

[2] https://hg.python.org/cpython/file/tip/Include/pyport.h#l42

[3] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gdb/config.in;h=3f8a72326b5d32db6ad8966c05045e248f955498;hb=HEAD#l282

[4] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gdb/configure;h=6df88d9049b546a9e906b943f67374dc90d90d6d;hb=HEAD#l11662

----------
components: Interpreter Core
files: fix-gdb-compilation.patch
keywords: patch
messages: 282649
nosy: cstratak
priority: normal
severity: normal
status: open
title: Can't compile gdb with Python 3.6
versions: Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45791/fix-gdb-compilation.patch

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

From report at bugs.python.org  Wed Dec  7 13:20:05 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 07 Dec 2016 18:20:05 +0000
Subject: [issue28898] Can't compile gdb with Python 3.6
In-Reply-To: <1481134479.52.0.174259382887.issue28898@psf.upfronthosting.co.za>
Message-ID: <1481134805.16.0.239095509633.issue28898@psf.upfronthosting.co.za>


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


----------
nosy: +benjamin.peterson

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

From report at bugs.python.org  Wed Dec  7 13:34:55 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 07 Dec 2016 18:34:55 +0000
Subject: [issue28147] Unbounded memory growth resizing split-table dicts
In-Reply-To: <1473853453.13.0.556951743271.issue28147@psf.upfronthosting.co.za>
Message-ID: <1481135695.7.0.148518024489.issue28147@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

__dict__.pop seems not uncommon. Searching Github could give many practical codes using it. And many of them are acting as generic containers and could be used against massive cases.

----------

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

From report at bugs.python.org  Wed Dec  7 13:45:59 2016
From: report at bugs.python.org (Marco Buttu)
Date: Wed, 07 Dec 2016 18:45:59 +0000
Subject: [issue27200] make doctest in CPython has failures
In-Reply-To: <1464988408.0.0.840317371896.issue27200@psf.upfronthosting.co.za>
Message-ID: <1481136359.68.0.274762541792.issue27200@psf.upfronthosting.co.za>


Marco Buttu added the comment:

This last patch (make_doctest_ok.patch) makes all doctests pass (Sphinx 1.5, Python 3.6). Before applaying the patch there are 466 failures in 2096 tests, and after we have more tests (2414) and 0 failures. Actually, sometimes 3 tests fail in Doc/library/unittest.mock-examples.rst, but I did not get why :/

----------
Added file: http://bugs.python.org/file45792/make_doctest_ok.patch

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

From report at bugs.python.org  Wed Dec  7 13:48:42 2016
From: report at bugs.python.org (Marco Buttu)
Date: Wed, 07 Dec 2016 18:48:42 +0000
Subject: [issue28863] Doc/includes/*.py files and doctests
In-Reply-To: <1480801685.13.0.102040139052.issue28863@psf.upfronthosting.co.za>
Message-ID: <1481136522.44.0.617947468427.issue28863@psf.upfronthosting.co.za>


Marco Buttu added the comment:

I attached a patch in issue 27200 that makes all doctests pass, so I close here.

----------
resolution:  -> duplicate
status: open -> closed

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

From report at bugs.python.org  Wed Dec  7 13:49:47 2016
From: report at bugs.python.org (Marco Buttu)
Date: Wed, 07 Dec 2016 18:49:47 +0000
Subject: [issue28860] Fixed all the doctest failures in
 Doc/library/configparser.rst
In-Reply-To: <1480717712.23.0.651677304063.issue28860@psf.upfronthosting.co.za>
Message-ID: <1481136587.38.0.431395384676.issue28860@psf.upfronthosting.co.za>


Marco Buttu added the comment:

I attached a patch in issue 27200 that makes all doctests pass, so I close here.

----------
resolution:  -> duplicate
status: open -> closed

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

From report at bugs.python.org  Wed Dec  7 14:15:51 2016
From: report at bugs.python.org (Eli Collins)
Date: Wed, 07 Dec 2016 19:15:51 +0000
Subject: [issue672115] Assignment to __bases__ of direct object subclasses
Message-ID: <1481138151.1.0.895069784872.issue672115@psf.upfronthosting.co.za>


Changes by Eli Collins <elic at assurancetechnologies.com>:


----------
nosy: +eli.collins

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

From report at bugs.python.org  Wed Dec  7 14:16:38 2016
From: report at bugs.python.org (Steve Dower)
Date: Wed, 07 Dec 2016 19:16:38 +0000
Subject: [issue28896] Embeddable zip allows Windows registry to override
 module location
In-Reply-To: <1481128708.35.0.521458556277.issue28896@psf.upfronthosting.co.za>
Message-ID: <1481138198.17.0.971177600516.issue28896@psf.upfronthosting.co.za>


Steve Dower added the comment:

+Ned

Could we get a doc patch into 3.6 marking this class as deprecated? It appears like the importlib docs are the only ones that refer to the class, and none of the docs describe the functionality or indicate that it is enabled by default.

I could also pitch this as a security vulnerability and push for removing the default .append() right now? Since we wouldn't remove the class itself, restoring the previous behavior just requires inserting it into meta_path again. And Alexey is right that it actually allows a non-admin user to shadow any non-builtin module.

Looking at the latest pywin32 installer, they actually *remove* the keys they used to add here because they cause problems. So I think we're fairly safe to disable the finder by default and deprecate it into the future.

----------
nosy: +ned.deily

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

From report at bugs.python.org  Wed Dec  7 14:30:30 2016
From: report at bugs.python.org (Charles Harris)
Date: Wed, 07 Dec 2016 19:30:30 +0000
Subject: [issue28897] Python 3.6.0rc1 breaks NumPy tests.
In-Reply-To: <1481129641.34.0.0925136712294.issue28897@psf.upfronthosting.co.za>
Message-ID: <1481139030.03.0.137441952993.issue28897@psf.upfronthosting.co.za>


Charles Harris added the comment:

The failing tests don't use the context manager mentioned in msg278976 and which was fixed. In any case, the failures are new an appeared today. A failing test may be viewed at: https://github.com/numpy/numpy/blob/master/numpy/lib/tests/test_nanfunctions.py#L546

----------

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

From report at bugs.python.org  Wed Dec  7 14:50:36 2016
From: report at bugs.python.org (Ned Deily)
Date: Wed, 07 Dec 2016 19:50:36 +0000
Subject: [issue28896] Embeddable zip allows Windows registry to override
 module location
In-Reply-To: <1481128708.35.0.521458556277.issue28896@psf.upfronthosting.co.za>
Message-ID: <1481140236.65.0.863584373966.issue28896@psf.upfronthosting.co.za>


Ned Deily added the comment:

I'm OK with adding a doc change before 3.6.0 final.  But since this behavior is not new with 3.6, I would rather save any code changes for 3.6.1 unless there is a consensus that this is an urgent security issue.

----------

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

From report at bugs.python.org  Wed Dec  7 14:56:59 2016
From: report at bugs.python.org (Ned Deily)
Date: Wed, 07 Dec 2016 19:56:59 +0000
Subject: [issue28835] Change in behavior when overriding warnings.showwarning
 and with catch_warnings(record=True)
In-Reply-To: <1480465767.99.0.401403947818.issue28835@psf.upfronthosting.co.za>
Message-ID: <1481140619.69.0.0527651650852.issue28835@psf.upfronthosting.co.za>


Ned Deily added the comment:

Brett, msg282646 ?

----------

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

From report at bugs.python.org  Wed Dec  7 15:03:50 2016
From: report at bugs.python.org (=?utf-8?q?Arkady_=E2=80=9CKindDragon=E2=80=9D_Shapkin?=)
Date: Wed, 07 Dec 2016 20:03:50 +0000
Subject: [issue28899] Symbols doesn't match in VS for python.exe and
 python35.dll
Message-ID: <1481141030.49.0.258736096374.issue28899@psf.upfronthosting.co.za>


New submission from Arkady ?KindDragon? Shapkin:

I installed Python 3.5.2 with PDB, but they can't be loaded.
If I try to load them manually Visual Studio displays message "A matching symbol file was not found in this folder."

----------
components: Windows
messages: 282658
nosy: Arkady ?KindDragon? Shapkin, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Symbols doesn't match in VS for python.exe and python35.dll
versions: Python 3.5

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

From report at bugs.python.org  Wed Dec  7 15:06:02 2016
From: report at bugs.python.org (Ned Deily)
Date: Wed, 07 Dec 2016 20:06:02 +0000
Subject: [issue28893] Make sure exceptions raised in __aiter__ are properly
 chained in ceval
In-Reply-To: <1481085693.53.0.293766364883.issue28893@psf.upfronthosting.co.za>
Message-ID: <1481141162.74.0.158108301033.issue28893@psf.upfronthosting.co.za>


Ned Deily added the comment:

Yury, sounds like a bug to me so it would be appropriate for a maintenance release.  And not a showstopper release critical.

----------

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

From report at bugs.python.org  Wed Dec  7 15:11:53 2016
From: report at bugs.python.org (=?utf-8?q?Arkady_=E2=80=9CKindDragon=E2=80=9D_Shapkin?=)
Date: Wed, 07 Dec 2016 20:11:53 +0000
Subject: [issue28899] Symbols doesn't match in VS for python.exe and
 python35.dll
In-Reply-To: <1481141030.49.0.258736096374.issue28899@psf.upfronthosting.co.za>
Message-ID: <1481141513.17.0.728212848146.issue28899@psf.upfronthosting.co.za>


Arkady ?KindDragon? Shapkin added the comment:

That was my fault

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

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

From report at bugs.python.org  Wed Dec  7 15:12:24 2016
From: report at bugs.python.org (=?utf-8?q?Arkady_=E2=80=9CKindDragon=E2=80=9D_Shapkin?=)
Date: Wed, 07 Dec 2016 20:12:24 +0000
Subject: [issue28899] Symbols doesn't match in VS for python.exe and
 python35.dll
In-Reply-To: <1481141030.49.0.258736096374.issue28899@psf.upfronthosting.co.za>
Message-ID: <1481141544.4.0.707670463445.issue28899@psf.upfronthosting.co.za>


Changes by Arkady ?KindDragon? Shapkin <kinddragon33 at gmail.com>:


----------
resolution:  -> not a bug

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

From report at bugs.python.org  Wed Dec  7 15:17:56 2016
From: report at bugs.python.org (Ned Deily)
Date: Wed, 07 Dec 2016 20:17:56 +0000
Subject: [issue28898] Can't compile gdb with Python 3.6
In-Reply-To: <1481134479.52.0.174259382887.issue28898@psf.upfronthosting.co.za>
Message-ID: <1481141876.09.0.402489603164.issue28898@psf.upfronthosting.co.za>


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


----------
keywords: +3.6regression -patch

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

From report at bugs.python.org  Wed Dec  7 15:25:54 2016
From: report at bugs.python.org (Ned Deily)
Date: Wed, 07 Dec 2016 20:25:54 +0000
Subject: [issue28897] Python 3.6.0rc1 breaks NumPy tests.
In-Reply-To: <1481129641.34.0.0925136712294.issue28897@psf.upfronthosting.co.za>
Message-ID: <1481142354.01.0.0173953632377.issue28897@psf.upfronthosting.co.za>


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


----------
keywords: +3.6regression

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

From report at bugs.python.org  Wed Dec  7 15:30:50 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 07 Dec 2016 20:30:50 +0000
Subject: [issue26865] Meta-issue: support of the android platform
In-Reply-To: <1461685011.99.0.617135447086.issue26865@psf.upfronthosting.co.za>
Message-ID: <1481142650.51.0.330921328735.issue26865@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

issue #20211: setup.py: do not add system header locations when cross compiling
issue #28190: Detect curses headers correctly for cross-compiling

----------
dependencies: +Detect curses headers correctly for cross-compiling, setup.py: do not add system header locations when cross compiling

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

From report at bugs.python.org  Wed Dec  7 15:33:33 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 07 Dec 2016 20:33:33 +0000
Subject: [issue28897] Python 3.6.0rc1 breaks NumPy tests.
In-Reply-To: <1481129641.34.0.0925136712294.issue28897@psf.upfronthosting.co.za>
Message-ID: <1481142813.65.0.358458676205.issue28897@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

So `warnings.catch_warnings` doesn't work anymore in 3.6?

----------
nosy: +pitrou

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

From report at bugs.python.org  Wed Dec  7 15:35:09 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 07 Dec 2016 20:35:09 +0000
Subject: [issue28779] set_forkserver_preload() can crash the forkserver if
 preloaded module instantiate multiprocessing classes
In-Reply-To: <1479914801.47.0.114591938702.issue28779@psf.upfronthosting.co.za>
Message-ID: <1481142909.07.0.423558465146.issue28779@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I will probably commit this in the coming days.

----------

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

From report at bugs.python.org  Wed Dec  7 15:48:43 2016
From: report at bugs.python.org (Julien Palard)
Date: Wed, 07 Dec 2016 20:48:43 +0000
Subject: [issue26483] docs unclear on difference between str.isdigit() and
 str.isdecimal()
In-Reply-To: <1457121897.81.0.495681677897.issue26483@psf.upfronthosting.co.za>
Message-ID: <1481143723.4.0.625769762991.issue26483@psf.upfronthosting.co.za>


Changes by Julien Palard <julien+python at palard.fr>:


Added file: http://bugs.python.org/file45793/issue26483.diff

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

From report at bugs.python.org  Wed Dec  7 15:50:20 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 07 Dec 2016 20:50:20 +0000
Subject: [issue28897] Python 3.6.0rc1 breaks NumPy tests.
In-Reply-To: <1481129641.34.0.0925136712294.issue28897@psf.upfronthosting.co.za>
Message-ID: <1481143820.17.0.205050929382.issue28897@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

It works in usual circumstances.

>>> import warnings
>>> with warnings.catch_warnings(record=True) as w:
...     warnings.simplefilter('always')
...     warnings.warn('a test warning', DeprecationWarning)
...     print(w)
... 
[<warnings.WarningMessage object at 0xb6f1714c>]

----------

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

From report at bugs.python.org  Wed Dec  7 15:51:13 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 07 Dec 2016 20:51:13 +0000
Subject: [issue28897] Python 3.6.0rc1 breaks NumPy tests.
In-Reply-To: <1481129641.34.0.0925136712294.issue28897@psf.upfronthosting.co.za>
Message-ID: <1481143873.85.0.168809848674.issue28897@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

What is Numpy doing that is breaking it?

----------

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

From report at bugs.python.org  Wed Dec  7 15:54:55 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 07 Dec 2016 20:54:55 +0000
Subject: [issue28897] Python 3.6.0rc1 breaks NumPy tests.
In-Reply-To: <1481129641.34.0.0925136712294.issue28897@psf.upfronthosting.co.za>
Message-ID: <1481144095.1.0.705103370851.issue28897@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I have installed NumPy 1.11.2 and ran tests. Tests are passes successfully.

----------

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

From report at bugs.python.org  Wed Dec  7 16:01:28 2016
From: report at bugs.python.org (Steve Dower)
Date: Wed, 07 Dec 2016 21:01:28 +0000
Subject: [issue28896] Embeddable zip allows Windows registry to override
 module location
In-Reply-To: <1481128708.35.0.521458556277.issue28896@psf.upfronthosting.co.za>
Message-ID: <1481144488.85.0.15664398761.issue28896@psf.upfronthosting.co.za>


Steve Dower added the comment:

Here's my proposed doc change for 3.6.0. Any concerns about wording? (The change to remove the line from _bootstrap_external.py will be separate, for ease of cherry-picking.)


diff --git a/Doc/library/importlib.rst b/Doc/library/importlib.rst
--- a/Doc/library/importlib.rst
+++ b/Doc/library/importlib.rst
@@ -806,6 +806,10 @@
 
    .. versionadded:: 3.3
 
+   .. deprecated:: 3.6
+      Use :mod:`site` configuration instead. Future versions of Python may
+      not enable this finder by default.
+
 
 .. class:: PathFinder
 
diff --git a/Doc/using/windows.rst b/Doc/using/windows.rst
--- a/Doc/using/windows.rst
+++ b/Doc/using/windows.rst
@@ -823,6 +823,14 @@
       * Adds ``pythonXX.zip`` as a potential landmark when directly adjacent
         to the executable.
 
+.. deprecated::
+   3.6
+
+      Modules specified in the registry under ``Modules`` (not ``PythonPath``)
+      may be imported by :class:`importlib.machinery.WindowsRegistryFinder`.
+      This finder is enabled on Windows in 3.6.0 and earlier, but may need to
+      be explicitly added to :attr:`sys.meta_path` in the future.
+
 Additional modules
 ==================

----------

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

From report at bugs.python.org  Wed Dec  7 16:02:47 2016
From: report at bugs.python.org (Steve Dower)
Date: Wed, 07 Dec 2016 21:02:47 +0000
Subject: [issue28896] Embeddable zip allows Windows registry to override
 module location
In-Reply-To: <1481128708.35.0.521458556277.issue28896@psf.upfronthosting.co.za>
Message-ID: <1481144567.05.0.589813494175.issue28896@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at python.org>:


----------
keywords: +patch
Added file: http://bugs.python.org/file45794/28896_doc.patch

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

From report at bugs.python.org  Wed Dec  7 16:02:54 2016
From: report at bugs.python.org (Julien Palard)
Date: Wed, 07 Dec 2016 21:02:54 +0000
Subject: [issue28755] Rework syntax highlighing in howto/clinic.rst
In-Reply-To: <1479679317.44.0.842687607942.issue28755@psf.upfronthosting.co.za>
Message-ID: <1481144574.93.0.619654463796.issue28755@psf.upfronthosting.co.za>


Julien Palard added the comment:

Just rebasing my patch on tip as it does no longer cleanly apply.

----------
Added file: http://bugs.python.org/file45795/issue28755-3.diff

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

From report at bugs.python.org  Wed Dec  7 16:24:17 2016
From: report at bugs.python.org (Charles Harris)
Date: Wed, 07 Dec 2016 21:24:17 +0000
Subject: [issue28897] Python 3.6.0rc1 breaks NumPy tests.
In-Reply-To: <1481129641.34.0.0925136712294.issue28897@psf.upfronthosting.co.za>
Message-ID: <1481145857.73.0.367946358214.issue28897@psf.upfronthosting.co.za>


Charles Harris added the comment:

I downloaded the tarball and installed the release here and got the same errors. We setup the tests in developement mode by turning some warnings into errors, in particular DeprecationWarnings and RuntimeWarnings, and suppressing others. The tests that are failing are checking for warnings turn the errors back into warnings. The latter seems to be failing.

There could be an interaction between the setup and recent changes in Python 3.6.0rc1. What exactly was changed in the warnings module after the last beta?

----------

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

From report at bugs.python.org  Wed Dec  7 16:29:10 2016
From: report at bugs.python.org (Charles Harris)
Date: Wed, 07 Dec 2016 21:29:10 +0000
Subject: [issue28897] Python 3.6.0rc1 breaks NumPy tests.
In-Reply-To: <1481129641.34.0.0925136712294.issue28897@psf.upfronthosting.co.za>
Message-ID: <1481146150.69.0.372970355068.issue28897@psf.upfronthosting.co.za>


Charles Harris added the comment:

You probably need to run NumPy 1.12 to see the problem. Tt looks like the new suppress_warnings context manager is what has been broken. Note that is was broken by 3.6 before, fixed, and now seems to be broken again.

----------

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

From report at bugs.python.org  Wed Dec  7 16:30:43 2016
From: report at bugs.python.org (Charles Harris)
Date: Wed, 07 Dec 2016 21:30:43 +0000
Subject: [issue28897] Python 3.6.0rc1 breaks NumPy tests.
In-Reply-To: <1481129641.34.0.0925136712294.issue28897@psf.upfronthosting.co.za>
Message-ID: <1481146243.88.0.738013230712.issue28897@psf.upfronthosting.co.za>


Charles Harris added the comment:

The NumPy 1.12.0b1 tarball is available on PyPI if you want to download it.

----------

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

From report at bugs.python.org  Wed Dec  7 17:07:01 2016
From: report at bugs.python.org (Min RK)
Date: Wed, 07 Dec 2016 22:07:01 +0000
Subject: [issue28147] Unbounded memory growth resizing split-table dicts
In-Reply-To: <1473853453.13.0.556951743271.issue28147@psf.upfronthosting.co.za>
Message-ID: <1481148421.81.0.465969740335.issue28147@psf.upfronthosting.co.za>


Min RK added the comment:

This affects IPython (specifically the traitlets component), which is what prompted the report. We were able to push out a release of traitlets with a workaround for the bug (4.3.1), but earlier versions of IPython / traitlets will still be affected (all IPython >= 4, traitlets 4.0 <= v < 4.3.1). So I hope 3.6.0 will be released with the fix attached here.

----------

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

From report at bugs.python.org  Wed Dec  7 17:07:29 2016
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Wed, 07 Dec 2016 22:07:29 +0000
Subject: [issue28339] "TypeError: Parameterized generics cannot be used with
 class or instance checks" in test_functools after importing typing module
In-Reply-To: <1475421693.5.0.638809019729.issue28339@psf.upfronthosting.co.za>
Message-ID: <1481148449.38.0.228991720171.issue28339@psf.upfronthosting.co.za>


Ivan Levkivskyi added the comment:

The failure is fixed now, but it is fixed not in an elegant way (sys._getframe is used).

I think this is not urgent. If there are no objections, then I would propose to change priority to normal.

----------

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

From report at bugs.python.org  Wed Dec  7 17:14:21 2016
From: report at bugs.python.org (Julien Palard)
Date: Wed, 07 Dec 2016 22:14:21 +0000
Subject: [issue28897] Python 3.6.0rc1 breaks NumPy tests.
In-Reply-To: <1481129641.34.0.0925136712294.issue28897@psf.upfronthosting.co.za>
Message-ID: <1481148861.44.0.972009490882.issue28897@psf.upfronthosting.co.za>


Julien Palard added the comment:

Tried to run the test_nanfunctions.py on tip and Python 3.6.0b4+, on numpy 1.11 and 1.12.0b1, can't make it fail.

Installed numpy 1.12.0b1 using: ./python -m pip install --user numpy==1.12.0b1

I suspect Charles tested using Python 3.6.0b3 (can you confirm?), which was released before the latest patches (commited yesterday) from http://bugs.python.org/issue28835.

----------
nosy: +mdk

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

From report at bugs.python.org  Wed Dec  7 17:26:12 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 07 Dec 2016 22:26:12 +0000
Subject: [issue28339] "TypeError: Parameterized generics cannot be used with
 class or instance checks" in test_functools after importing typing module
In-Reply-To: <1475421693.5.0.638809019729.issue28339@psf.upfronthosting.co.za>
Message-ID: <1481149572.06.0.236191208118.issue28339@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


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

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

From report at bugs.python.org  Wed Dec  7 17:56:43 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 07 Dec 2016 22:56:43 +0000
Subject: [issue28893] Make sure exceptions raised in __aiter__ are properly
 chained in ceval
In-Reply-To: <1481085693.53.0.293766364883.issue28893@psf.upfronthosting.co.za>
Message-ID: <1481151403.52.0.128700164679.issue28893@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Ned, sounds good.

Serhiy, we don't have _PyErr_FormatFromCause in 3.5, so I'll probably commit the patch as is in 3.5.  For 3.6 is definitely makes sense to use _PyErr_FormatFromCause.

----------

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

From report at bugs.python.org  Wed Dec  7 18:03:09 2016
From: report at bugs.python.org (Charles Harris)
Date: Wed, 07 Dec 2016 23:03:09 +0000
Subject: [issue28897] Python 3.6.0rc1 breaks NumPy tests.
In-Reply-To: <1481129641.34.0.0925136712294.issue28897@psf.upfronthosting.co.za>
Message-ID: <1481151789.4.0.00892977054655.issue28897@psf.upfronthosting.co.za>


Charles Harris added the comment:

I ran with Python 3.6.0rc1 (default, Dec  7 2016, 14:00:51) and get the same errors in both NumPy 1.13.0-dev and 1.12. But I gave you a wrong suggestion, we disable some test errors for releases, which is what is on PyPI, and that is doubtless why you don't see them. My fault, and I apologize. You will probably need to clone the github repo (https://github.com/numpy/numpy) and do a `python3.6 runtests.py` in the master branch to see the problem. 

I'm suspecting the problem needs to be fixed on the numpy end, but need to know what the changes were made to get an idea of a fix. We do some odd stuff with the warnings queue in order to make sure no warnings are inadvertently disabled in the tests.

----------

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

From report at bugs.python.org  Wed Dec  7 18:29:30 2016
From: report at bugs.python.org (Ned Deily)
Date: Wed, 07 Dec 2016 23:29:30 +0000
Subject: [issue28897] Python 3.6.0rc1 breaks NumPy tests.
In-Reply-To: <1481129641.34.0.0925136712294.issue28897@psf.upfronthosting.co.za>
Message-ID: <1481153370.18.0.134083085444.issue28897@psf.upfronthosting.co.za>


Ned Deily added the comment:

Charles, these are the two changes that went into Lib/warnings.py between b4 and rc1:

changeset:   105490:aaee06743c61
branch:      3.6
parent:      105488:c0f59410ccfc
user:        Ned Deily <nad at python.org>
date:        Tue Dec 06 17:12:47 2016 -0500
files:       Lib/warnings.py
description:
Issue #28835: Tidy previous showwarning changes based on review comments.
Patch by Serhiy Storchaka.


changeset:   105474:726308cfe3b5
branch:      3.6
parent:      105472:ab66423c3581
user:        Victor Stinner <victor.stinner at gmail.com>
date:        Tue Dec 06 10:53:52 2016 +0100
files:       Lib/test/test_warnings/__init__.py Lib/warnings.py Misc/NEWS
description:
catch_warnings() calls showwarning() if overriden

Issue #28089: Fix a regression introduced in warnings.catch_warnings(): call
warnings.showwarning() if it was overriden inside the context manager.

----------

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

From report at bugs.python.org  Wed Dec  7 19:16:36 2016
From: report at bugs.python.org (Charles Harris)
Date: Thu, 08 Dec 2016 00:16:36 +0000
Subject: [issue28897] Python 3.6.0rc1 breaks NumPy tests.
In-Reply-To: <1481129641.34.0.0925136712294.issue28897@psf.upfronthosting.co.za>
Message-ID: <1481156196.83.0.811442937609.issue28897@psf.upfronthosting.co.za>


Charles Harris added the comment:

OK, you fixed what broke us before. If I revert our fixes the problem goes away. So, thanks I guess ;)

You can close this.

----------

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

From report at bugs.python.org  Wed Dec  7 19:20:17 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 08 Dec 2016 00:20:17 +0000
Subject: [issue28635] Update What's New for 3.6
In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za>
Message-ID: <20161208002014.117305.39468.FF6AD448@psf.io>


Roundup Robot added the comment:

New changeset d12bc674b74e by Yury Selivanov in branch '3.6':
Issue #28635: Drop the note that whatsnew is incomplete
https://hg.python.org/cpython/rev/d12bc674b74e

New changeset 1883072efc5f by Yury Selivanov in branch 'default':
Merge 3.6 (issue #28635)
https://hg.python.org/cpython/rev/1883072efc5f

----------

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

From report at bugs.python.org  Wed Dec  7 20:35:28 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 08 Dec 2016 01:35:28 +0000
Subject: [issue28897] Python 3.6.0rc1 breaks NumPy tests.
In-Reply-To: <1481129641.34.0.0925136712294.issue28897@psf.upfronthosting.co.za>
Message-ID: <1481160928.02.0.898966804411.issue28897@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Closing as not a bug as Charles suggested, since the problem was due to a workaround NumPy introduced for a regression in the beta releases that was fixed for rc1.

----------
nosy: +ncoghlan
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Wed Dec  7 20:54:35 2016
From: report at bugs.python.org (Ned Deily)
Date: Thu, 08 Dec 2016 01:54:35 +0000
Subject: [issue28897] Python 3.6.0rc1 breaks NumPy tests.
In-Reply-To: <1481129641.34.0.0925136712294.issue28897@psf.upfronthosting.co.za>
Message-ID: <1481162075.76.0.341565225814.issue28897@psf.upfronthosting.co.za>


Ned Deily added the comment:

Yes, thanks, Charles, and thanks everyone else. Sorry about the confusion with the changes in rc1.

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

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

From report at bugs.python.org  Wed Dec  7 22:18:11 2016
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 08 Dec 2016 03:18:11 +0000
Subject: [issue28147] Unbounded memory growth resizing split-table dicts
In-Reply-To: <1473853453.13.0.556951743271.issue28147@psf.upfronthosting.co.za>
Message-ID: <1481167091.16.0.422581805799.issue28147@psf.upfronthosting.co.za>


INADA Naoki added the comment:

Which revision should I make patch based on? 3.6 branch? or 3.6rc1 tag?

After 3.6rc1 is tagged, I pushed optimization which contains same one line change.

https://hg.python.org/cpython/rev/d03562dcbb82

-#define ESTIMATE_SIZE(n)  (((n)*3) >> 1)
+#define ESTIMATE_SIZE(n)  (((n)*3+1) >> 1)

----------

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

From report at bugs.python.org  Wed Dec  7 22:26:44 2016
From: report at bugs.python.org (Ned Deily)
Date: Thu, 08 Dec 2016 03:26:44 +0000
Subject: [issue28147] Unbounded memory growth resizing split-table dicts
In-Reply-To: <1473853453.13.0.556951743271.issue28147@psf.upfronthosting.co.za>
Message-ID: <1481167604.87.0.339575098979.issue28147@psf.upfronthosting.co.za>


Ned Deily added the comment:

Just follow the normal 3.6 branch which will ensure it gets into 3.6.1.  If we end up deciding to also add it to 3.6.0 final, I will handle the cherrypicking.

----------

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

From report at bugs.python.org  Wed Dec  7 22:28:03 2016
From: report at bugs.python.org (Matthias v/d Meent)
Date: Thu, 08 Dec 2016 03:28:03 +0000
Subject: [issue28900] update 'docs for other versions'
Message-ID: <1481167683.31.0.460396131564.issue28900@psf.upfronthosting.co.za>


New submission from Matthias v/d Meent:

The 'docs for other versions' links in the sidebar of docs.python.org do not link to 3.5 in both the 3.6 and 3.7 docs. As I didn't find any docs guidelines, I presume this is an error and should be fixed.

A link to the Python 3.6 docs should get added under all active documentations before or the moment python 3.6 is released (though I suspect this is automated).

----------
assignee: docs at python
components: Documentation
messages: 282684
nosy: Matthias v/d Meent, docs at python
priority: normal
severity: normal
status: open
title: update 'docs for other versions'
type: enhancement
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Wed Dec  7 22:31:00 2016
From: report at bugs.python.org (Ned Deily)
Date: Thu, 08 Dec 2016 03:31:00 +0000
Subject: [issue28900] update 'docs for other versions'
In-Reply-To: <1481167683.31.0.460396131564.issue28900@psf.upfronthosting.co.za>
Message-ID: <1481167860.56.0.961881664872.issue28900@psf.upfronthosting.co.za>


Ned Deily added the comment:

Links to 3.5, 3.6, and dev (future 2.7) docs are available in the pulldown menu above the Download sidebar.  Does that work for you?

----------
nosy: +ned.deily

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

From report at bugs.python.org  Wed Dec  7 22:34:22 2016
From: report at bugs.python.org (Matthias v/d Meent)
Date: Thu, 08 Dec 2016 03:34:22 +0000
Subject: [issue28900] update 'docs for other versions'
In-Reply-To: <1481167683.31.0.460396131564.issue28900@psf.upfronthosting.co.za>
Message-ID: <1481168062.62.0.213098923215.issue28900@psf.upfronthosting.co.za>


Matthias v/d Meent added the comment:

Yes, they do work. It's just that the links to 3.5 are missing in the sidebar of 3.6 and 3.7. The docs are still reachable though.

----------

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

From report at bugs.python.org  Wed Dec  7 22:40:02 2016
From: report at bugs.python.org (Ned Deily)
Date: Thu, 08 Dec 2016 03:40:02 +0000
Subject: [issue28900] update 'docs for other versions'
In-Reply-To: <1481167683.31.0.460396131564.issue28900@psf.upfronthosting.co.za>
Message-ID: <1481168402.43.0.31793095516.issue28900@psf.upfronthosting.co.za>


Ned Deily added the comment:

OK, I see what needs to be changed.  Thanks for the reminder!

----------
assignee: docs at python -> ned.deily
priority: normal -> release blocker
stage:  -> needs patch

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

From report at bugs.python.org  Wed Dec  7 22:48:02 2016
From: report at bugs.python.org (Mariatta Wijaya)
Date: Thu, 08 Dec 2016 03:48:02 +0000
Subject: [issue28900] update 'docs for other versions'
In-Reply-To: <1481167683.31.0.460396131564.issue28900@psf.upfronthosting.co.za>
Message-ID: <1481168882.29.0.620648761632.issue28900@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

If it's ok, I'd like to work on a patch for this :)

----------
nosy: +Mariatta

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

From report at bugs.python.org  Wed Dec  7 22:49:49 2016
From: report at bugs.python.org (Ned Deily)
Date: Thu, 08 Dec 2016 03:49:49 +0000
Subject: [issue28900] update 'docs for other versions'
In-Reply-To: <1481167683.31.0.460396131564.issue28900@psf.upfronthosting.co.za>
Message-ID: <1481168989.63.0.358128333305.issue28900@psf.upfronthosting.co.za>


Ned Deily added the comment:

Thanks but I'm almost done, Mariatta. The most important part is ensuring PEP 101 is correct.

----------

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

From report at bugs.python.org  Wed Dec  7 22:51:10 2016
From: report at bugs.python.org (Mariatta Wijaya)
Date: Thu, 08 Dec 2016 03:51:10 +0000
Subject: [issue28900] update 'docs for other versions'
In-Reply-To: <1481167683.31.0.460396131564.issue28900@psf.upfronthosting.co.za>
Message-ID: <1481169070.75.0.216869496225.issue28900@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

No prob. Thanks, Ned.

----------

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

From report at bugs.python.org  Wed Dec  7 23:38:59 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 08 Dec 2016 04:38:59 +0000
Subject: [issue28900] update 'docs for other versions'
In-Reply-To: <1481167683.31.0.460396131564.issue28900@psf.upfronthosting.co.za>
Message-ID: <20161208043856.117097.92370.FFA03462@psf.io>


Roundup Robot added the comment:

New changeset e414fb1640e0 by Ned Deily in branch '2.7':
Issue #28900: Update documentation sidebar for 3.6.0rc.
https://hg.python.org/cpython/rev/e414fb1640e0

New changeset d350fc4d78ff by Ned Deily in branch '3.5':
Issue #28900: Update documentation sidebar for 3.6.0rc.
https://hg.python.org/cpython/rev/d350fc4d78ff

New changeset 148c46d180b2 by Ned Deily in branch '3.6':
Issue #28900: Update documentation sidebar for 3.6.0rc.
https://hg.python.org/cpython/rev/148c46d180b2

New changeset f200ff0a0057 by Ned Deily in branch 'default':
Issue #28900: Update documentation sidebar for 3.6.0rc.
https://hg.python.org/cpython/rev/f200ff0a0057

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

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

From report at bugs.python.org  Wed Dec  7 23:43:48 2016
From: report at bugs.python.org (Ned Deily)
Date: Thu, 08 Dec 2016 04:43:48 +0000
Subject: [issue28900] update 'docs for other versions'
In-Reply-To: <1481167683.31.0.460396131564.issue28900@psf.upfronthosting.co.za>
Message-ID: <1481172228.34.0.327065856037.issue28900@psf.upfronthosting.co.za>


Ned Deily added the comment:

With the above changes, the sidebar should get updated for the current 2.7, 3.5, 3.6, and 3.7 front pages within the next 24 hours.  I'm leaving this open as a "release blocker" as a reminder to go back and update them all again once 3.6.0 final happens.  I've also added a reminder to PEP 101 to do this.

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

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

From report at bugs.python.org  Thu Dec  8 00:36:04 2016
From: report at bugs.python.org (Matthias v/d Meent)
Date: Thu, 08 Dec 2016 05:36:04 +0000
Subject: [issue28901] Embedded Release interactive mode documentation
Message-ID: <1481175364.84.0.951011976369.issue28901@psf.upfronthosting.co.za>


New submission from Matthias v/d Meent:

The Windows Embedded release (at least the x86_64 version) does not include the usual helper functions (exit, help, ...) when run interactively (~ python.exe). This is not documented at the docs of Windows Embedded release, which might mean that this is a bug.

Documentation on Embedded release here (https://docs.python.org/3/using/windows.html#embedded-distribution)

missing in interactive mode of embedded release: (output of diff):
['copyright', 'credits', 'exit', 'help', 'license', 'quit']

Notice that 'help', a builtin function according to the docs [0], is missing in the Embedded release. Even when embedded, a builtin should be available IMO.


[0] https://docs.python.org/3.6/library/functions.html

This comparison was only between running the python executable in the [zip] and python installed from this [installer]. It is very well possible this is a long-standing issue since 3.5 (the first Embedded release), and this may occur on other architectures as well.

[zip] https://www.python.org/ftp/python/3.6.0/python-3.6.0rc1-embed-amd64.zip 
[installer] https://www.python.org/ftp/python/3.6.0/python-3.6.0rc1-amd64.exe

----------
assignee: docs at python
components: Documentation, Windows
messages: 282693
nosy: Matthias v/d Meent, docs at python, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Embedded Release interactive mode documentation
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Thu Dec  8 01:24:42 2016
From: report at bugs.python.org (Decorater)
Date: Thu, 08 Dec 2016 06:24:42 +0000
Subject: [issue28902] 3.6.0rc1 installer fails to install / uninstall.
Message-ID: <1481178281.99.0.0821886789548.issue28902@psf.upfronthosting.co.za>


New submission from Decorater:

When installing python 3.6.0rc1 it errors saying that it cannot find python.dll  in cab1.cab (or some sort of file name similar to that) which it would obviously not exist. and then when I try to uninstall it it will fail saying 3.6 is not installed but not check the registry to remove the entries for the windows Installed programs list.

I would like if the (web and non web) installers would actually get better and check right before closing if 3.6 is in the registry when it cant find one installed and remove those entries. As well as looking for previous python versions that lo longer are on disk but are on the registry as if they are installed (basically allows for proper cleanup).

----------
components: Installation, Windows
messages: 282694
nosy: Decorater, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: 3.6.0rc1 installer fails to install / uninstall.
versions: Python 3.6

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

From report at bugs.python.org  Thu Dec  8 01:35:33 2016
From: report at bugs.python.org (Decorater)
Date: Thu, 08 Dec 2016 06:35:33 +0000
Subject: [issue28902] 3.6.0rc1 installer fails to install / uninstall.
In-Reply-To: <1481178281.99.0.0821886789548.issue28902@psf.upfronthosting.co.za>
Message-ID: <1481178933.95.0.0945071971877.issue28902@psf.upfronthosting.co.za>


Changes by Decorater <seandhunt_7 at yahoo.com>:


----------
type:  -> behavior

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

From report at bugs.python.org  Thu Dec  8 02:55:14 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 08 Dec 2016 07:55:14 +0000
Subject: [issue28898] Can't compile gdb with Python 3.6
In-Reply-To: <1481134479.52.0.174259382887.issue28898@psf.upfronthosting.co.za>
Message-ID: <20161208075509.13336.93239.4F3C32CE@psf.io>


Roundup Robot added the comment:

New changeset 4745d801cae2 by Benjamin Peterson in branch '3.6':
guard HAVE_LONG_LONG definition to prevent redefinition (#28898)
https://hg.python.org/cpython/rev/4745d801cae2

New changeset 1afc3f4f5502 by Benjamin Peterson in branch 'default':
merge 3.6 (#28898)
https://hg.python.org/cpython/rev/1afc3f4f5502

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

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

From report at bugs.python.org  Thu Dec  8 02:55:35 2016
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 08 Dec 2016 07:55:35 +0000
Subject: [issue28898] Can't compile gdb with Python 3.6
In-Reply-To: <1481134479.52.0.174259382887.issue28898@psf.upfronthosting.co.za>
Message-ID: <1481183735.14.0.879820130219.issue28898@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

I think we should take this for 3.6.

----------
assignee:  -> ned.deily
nosy: +ned.deily
priority: normal -> release blocker

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

From report at bugs.python.org  Thu Dec  8 03:34:03 2016
From: report at bugs.python.org (Ethan Smith)
Date: Thu, 08 Dec 2016 08:34:03 +0000
Subject: [issue28903] Windows Embeddable Python exit not defined
Message-ID: <1481186043.87.0.802350781562.issue28903@psf.upfronthosting.co.za>


New submission from Ethan Smith:

Hearing about the RC1 today, I downloaded the x64 Windows embeddable zip. I opened a Command Prompt window and ran python.exe to try it out.

I was quite surprised when I ran:
>>>exit()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'exit' is not defined

I read through the notes on the embedded Python releases, but I did not see anything that would lead me to believe that exit should not defined.
 
I also downloaded the distribution for 3.5.2, and did not have the same issue, which leads me to believe this is unintended behavior.

If this behavior is intended, I do apologize for raising this issue.

OS: Windows 10 x64.

----------
components: Windows
messages: 282697
nosy: Ethan Smith, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows Embeddable Python exit not defined
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Thu Dec  8 03:39:30 2016
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 08 Dec 2016 08:39:30 +0000
Subject: [issue28190] Detect curses headers correctly for cross-compiling
In-Reply-To: <1474132808.23.0.788365161086.issue28190@psf.upfronthosting.co.za>
Message-ID: <1481186370.96.0.049947534748.issue28190@psf.upfronthosting.co.za>


Matthias Klose added the comment:

the upstream ncurses has the ncursesw subdirinclude name, so you apparently can assume that this directory name is fixed *iff* it exists, however the ncursesw installation can be found in <prefix>/include instead.  Can your changes cope with that?

second issue is that you apparently don't do the changes for term.h (and possibly for other headers in other places as well, I only looked at the diff), so you mix ncursesw and ncurses headers. So you have to make these changes in all other places as well.

Third issue is that you can't make these changes for third party extensions, if there are any relying on the ncurses/ncursesw distinction.

fyi, "all" ncursesw headers are:

/usr/include/ncursesw/curses.h
/usr/include/ncursesw/cursesapp.h
/usr/include/ncursesw/cursesf.h
/usr/include/ncursesw/cursesm.h
/usr/include/ncursesw/cursesp.h
/usr/include/ncursesw/cursesw.h
/usr/include/ncursesw/cursslk.h
/usr/include/ncursesw/eti.h
/usr/include/ncursesw/etip.h
/usr/include/ncursesw/form.h
/usr/include/ncursesw/menu.h
/usr/include/ncursesw/nc_tparm.h
/usr/include/ncursesw/ncurses_dll.h
/usr/include/ncursesw/panel.h
/usr/include/ncursesw/term.h
/usr/include/ncursesw/term_entry.h
/usr/include/ncursesw/termcap.h
/usr/include/ncursesw/tic.h
/usr/include/ncursesw/unctrl.h

----------

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

From report at bugs.python.org  Thu Dec  8 03:59:08 2016
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 08 Dec 2016 08:59:08 +0000
Subject: [issue28147] Unbounded memory growth resizing split-table dicts
In-Reply-To: <1473853453.13.0.556951743271.issue28147@psf.upfronthosting.co.za>
Message-ID: <1481187548.92.0.869500575448.issue28147@psf.upfronthosting.co.za>


INADA Naoki added the comment:

Here is patch for Python 3.6.

----------
Added file: http://bugs.python.org/file45796/fix28147-py36.patch

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

From report at bugs.python.org  Thu Dec  8 04:05:52 2016
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 08 Dec 2016 09:05:52 +0000
Subject: [issue28147] Unbounded memory growth resizing split-table dicts
In-Reply-To: <1473853453.13.0.556951743271.issue28147@psf.upfronthosting.co.za>
Message-ID: <1481187952.32.0.624760172038.issue28147@psf.upfronthosting.co.za>


Changes by INADA Naoki <songofacandy at gmail.com>:


Added file: http://bugs.python.org/file45797/fix28147-py36-2.patch

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

From report at bugs.python.org  Thu Dec  8 04:47:48 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 08 Dec 2016 09:47:48 +0000
Subject: [issue28897] Python 3.6.0rc1 breaks NumPy tests.
In-Reply-To: <1481162075.76.0.341565225814.issue28897@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbv_Kb-r2PQh4eHUUibH7v4xyHJUpZLZ8i-Wi3c5wm+Qg@mail.gmail.com>


STINNER Victor added the comment:

Charles: "OK, you fixed what broke us before. If I revert our fixes
the problem goes away. So, thanks I guess ;) You can close this."

Cool, happy to read that the issue was fixed :-)

If you missed it, the whole mess were backward compatibility when I
extended the warnings API (only internally currently) to implement a
new feature:
https://docs.python.org/dev/whatsnew/3.6.html#warnings

ResourceWarning are now displayed with a traceback where the object
was allocated when tracemalloc is enabled.

----------

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

From report at bugs.python.org  Thu Dec  8 04:53:03 2016
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 08 Dec 2016 09:53:03 +0000
Subject: [issue21978] Support index access on OrderedDict views (e.g.
 o.keys()[7])
In-Reply-To: <1405329303.68.0.861089422528.issue21978@psf.upfronthosting.co.za>
Message-ID: <1481190783.97.0.828172670895.issue21978@psf.upfronthosting.co.za>


INADA Naoki added the comment:

While dict is ordered, it doesn't support O(1) random access by index.

----------
nosy: +inada.naoki

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

From report at bugs.python.org  Thu Dec  8 04:55:55 2016
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 08 Dec 2016 09:55:55 +0000
Subject: [issue28147] Unbounded memory growth resizing split-table dicts
In-Reply-To: <1473853453.13.0.556951743271.issue28147@psf.upfronthosting.co.za>
Message-ID: <1481190955.69.0.249061777964.issue28147@psf.upfronthosting.co.za>


INADA Naoki added the comment:

http://bugs.python.org/issue28894 was duplicate of this issue.

Since real world program suffered by this, I'm +1 to fix this by 3.6.0

----------

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

From report at bugs.python.org  Thu Dec  8 05:10:37 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 08 Dec 2016 10:10:37 +0000
Subject: [issue26939] android: test_functools hangs on armv7
In-Reply-To: <1462289866.52.0.349587333392.issue26939@psf.upfronthosting.co.za>
Message-ID: <20161208101033.30662.79023.2F43FA54@psf.io>


Roundup Robot added the comment:

New changeset fd1718badb67 by Xavier de Gaye in branch '3.6':
Issue #26939: Add the support.setswitchinterval() function to fix
https://hg.python.org/cpython/rev/fd1718badb67

New changeset c5d7e46926ac by Xavier de Gaye in branch 'default':
Issue #26939: Merge 3.6.
https://hg.python.org/cpython/rev/c5d7e46926ac

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

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

From report at bugs.python.org  Thu Dec  8 05:28:05 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 08 Dec 2016 10:28:05 +0000
Subject: [issue26940] android: test_importlib hangs on armv7
In-Reply-To: <1462290134.16.0.615698223309.issue26940@psf.upfronthosting.co.za>
Message-ID: <20161208102802.117519.33050.E002F000@psf.io>


Roundup Robot added the comment:

New changeset 1bb2f4b8440e by Xavier de Gaye in branch '3.6':
Issue #26940: Fix test_importlib that hangs on the Android armv7 qemu emulator.
https://hg.python.org/cpython/rev/1bb2f4b8440e

New changeset e401c5a95758 by Xavier de Gaye in branch 'default':
Issue #26940: Merge 3.6.
https://hg.python.org/cpython/rev/e401c5a95758

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

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

From report at bugs.python.org  Thu Dec  8 05:45:30 2016
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 08 Dec 2016 10:45:30 +0000
Subject: [issue28331] "CPython implementation detail:" removed when content
 translated
In-Reply-To: <1475328552.4.0.631332821236.issue28331@psf.upfronthosting.co.za>
Message-ID: <1481193930.42.0.0478250797667.issue28331@psf.upfronthosting.co.za>


Changes by INADA Naoki <songofacandy at gmail.com>:


----------
nosy: +Julien.Palard, JulienPalard

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

From report at bugs.python.org  Thu Dec  8 06:02:41 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 08 Dec 2016 11:02:41 +0000
Subject: [issue26939] android: test_functools hangs on armv7
In-Reply-To: <1462289866.52.0.349587333392.issue26939@psf.upfronthosting.co.za>
Message-ID: <1481194961.0.0.933918480624.issue26939@psf.upfronthosting.co.za>


Changes by Xavier de Gaye <xdegaye at gmail.com>:


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

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

From report at bugs.python.org  Thu Dec  8 06:03:07 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 08 Dec 2016 11:03:07 +0000
Subject: [issue26940] android: test_importlib hangs on armv7
In-Reply-To: <1462290134.16.0.615698223309.issue26940@psf.upfronthosting.co.za>
Message-ID: <1481194987.69.0.485493022964.issue26940@psf.upfronthosting.co.za>


Changes by Xavier de Gaye <xdegaye at gmail.com>:


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

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

From report at bugs.python.org  Thu Dec  8 06:22:26 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 08 Dec 2016 11:22:26 +0000
Subject: [issue26941] android: test_threading hangs on armv7
In-Reply-To: <1462290426.09.0.613967464154.issue26941@psf.upfronthosting.co.za>
Message-ID: <20161208112223.30481.48909.798390DC@psf.io>


Roundup Robot added the comment:

New changeset b64ba5604e48 by Xavier de Gaye in branch '3.6':
Issue #26941: Fix test_threading that hangs on the Android armv7 qemu emulator.
https://hg.python.org/cpython/rev/b64ba5604e48

New changeset 8688a664995c by Xavier de Gaye in branch 'default':
Issue #26941: Merge 3.6.
https://hg.python.org/cpython/rev/8688a664995c

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

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

From report at bugs.python.org  Thu Dec  8 07:49:36 2016
From: report at bugs.python.org (Jason Madden)
Date: Thu, 08 Dec 2016 12:49:36 +0000
Subject: [issue28147] Unbounded memory growth resizing split-table dicts
In-Reply-To: <1473853453.13.0.556951743271.issue28147@psf.upfronthosting.co.za>
Message-ID: <1481201376.16.0.141977109924.issue28147@psf.upfronthosting.co.za>


Changes by Jason Madden <jason at nextthought.com>:


----------
nosy: +jmadden

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

From report at bugs.python.org  Thu Dec  8 07:54:45 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 08 Dec 2016 12:54:45 +0000
Subject: [issue26941] android: test_threading hangs on armv7
In-Reply-To: <1462290426.09.0.613967464154.issue26941@psf.upfronthosting.co.za>
Message-ID: <1481201685.29.0.982516076844.issue26941@psf.upfronthosting.co.za>


Changes by Xavier de Gaye <xdegaye at gmail.com>:


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

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

From report at bugs.python.org  Thu Dec  8 09:08:24 2016
From: report at bugs.python.org (Steve Dower)
Date: Thu, 08 Dec 2016 14:08:24 +0000
Subject: [issue28902] 3.6.0rc1 installer fails to install / uninstall.
In-Reply-To: <1481178281.99.0.0821886789548.issue28902@psf.upfronthosting.co.za>
Message-ID: <1481206104.06.0.494082148372.issue28902@psf.upfronthosting.co.za>


Steve Dower added the comment:

If you run the installer through the Programs and Features dialog to modify or uninstall it should definitely find the current installation (as the registration it looks for is the same registration that makes it appear in that dialog). Because there are different installers, unfortunately they can't always detect each other despite laying down the same version of Python. I too would like them to get better at this, but it's not at all simple.

We can't go wiping install information arbitrarily or it will corrupt user machines.

For the missing file error, you should have a whole lot of log files in your %TEMP% directory. Could you zip them up and attach them here so I can take a look at what went wrong?

----------

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

From report at bugs.python.org  Thu Dec  8 09:37:06 2016
From: report at bugs.python.org (Samuel Colvin)
Date: Thu, 08 Dec 2016 14:37:06 +0000
Subject: [issue28904] add more format conversion flags eg. "len" and "id"
Message-ID: <1481207826.64.0.85637037523.issue28904@psf.upfronthosting.co.za>


New submission from Samuel Colvin:

(The "Components" selection might be wrong, I wasn't sure what to use)

As https://docs.python.org/3.6/library/string.html

> Three conversion flags are currently supported: '!s' which calls str() on the value, '!r' which calls repr() and '!a' which calls ascii().

It would be great if further conversation flags were added for more built-in methods. In particular:
* '!l' for len()
* '!i' for id()

(There might be others but these are the two I would find most useful.)

format() is now very powerful, but it's very common for strings, lists, dicts, sets etc. to want to include their length in strings. This is currently ugly.

This enhancement will be even more sought after with string literals in python 3.6.

Example of when this would be very useful:

v = {'type': 'whatever, 'items': ['foo', 'bar', 'spam']}
'{type}{items!l}'.format(**v)

Would also be very useful with getattr, and getitem usage.

----------
components: Library (Lib)
messages: 282707
nosy: Samuel Colvin
priority: normal
severity: normal
status: open
title: add more format conversion flags eg. "len" and "id"
type: enhancement
versions: Python 3.7

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

From report at bugs.python.org  Thu Dec  8 09:40:39 2016
From: report at bugs.python.org (Samuel Colvin)
Date: Thu, 08 Dec 2016 14:40:39 +0000
Subject: [issue28904] add more format conversion flags eg. "len" and "id"
In-Reply-To: <1481207826.64.0.85637037523.issue28904@psf.upfronthosting.co.za>
Message-ID: <1481208039.7.0.249134034239.issue28904@psf.upfronthosting.co.za>


Samuel Colvin added the comment:

I know contributing to python is currently a pain (bring on github!) but I'd be happy to attempt a patch if others agree this would be useful.

----------

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

From report at bugs.python.org  Thu Dec  8 10:20:24 2016
From: report at bugs.python.org (R. David Murray)
Date: Thu, 08 Dec 2016 15:20:24 +0000
Subject: [issue28904] add more format conversion flags eg. "len" and "id"
In-Reply-To: <1481207826.64.0.85637037523.issue28904@psf.upfronthosting.co.za>
Message-ID: <1481210424.63.0.73304279139.issue28904@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks for the idea, but I think we're going to see a shift away from format calls and toward fstrings, so I don't think this is worth doing.  See https://www.python.org/dev/peps/pep-0498/#id45; the ! expressions are only supported by fstrings only for consistency with format, not because they are particularly useful with fstrings.

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

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

From report at bugs.python.org  Thu Dec  8 10:25:12 2016
From: report at bugs.python.org (Samuel Colvin)
Date: Thu, 08 Dec 2016 15:25:12 +0000
Subject: [issue28904] add more format conversion flags eg. "len" and "id"
In-Reply-To: <1481207826.64.0.85637037523.issue28904@psf.upfronthosting.co.za>
Message-ID: <1481210712.4.0.432312389966.issue28904@psf.upfronthosting.co.za>


Samuel Colvin added the comment:

I see, I hadn't appreciated fstrings where entirely different and more powerful than format(), I'll close this.

For anyone else coming to this, with fstrings in >=3.6 you can do:

In [4]: value = [1,2, 3]

In [5]: f'The value is {value}.'
Out[5]: 'The value is [1, 2, 3].'

In [6]: f'The value is {len(value)}.'
Out[6]: 'The value is 3.'

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

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

From report at bugs.python.org  Thu Dec  8 10:27:19 2016
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 08 Dec 2016 15:27:19 +0000
Subject: [issue28903] Windows Embeddable Python exit not defined
In-Reply-To: <1481186043.87.0.802350781562.issue28903@psf.upfronthosting.co.za>
Message-ID: <1481210839.74.0.140701955372.issue28903@psf.upfronthosting.co.za>


Zachary Ware added the comment:

This is a duplicate of #28901.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Embedded Release interactive mode documentation

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

From report at bugs.python.org  Thu Dec  8 10:29:20 2016
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 08 Dec 2016 15:29:20 +0000
Subject: [issue28901] Windows: document that site is not imported by default
 by embeddable distribution
In-Reply-To: <1481175364.84.0.951011976369.issue28901@psf.upfronthosting.co.za>
Message-ID: <1481210960.75.0.578161065158.issue28901@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Each of those items is added to builtins by site.py, which I believe is not imported by default by the embeddable distribution.  I didn't immediately find that fact mentioned in the docs, though.

Also note that the embeddable distribution isn't really meant for regular usage, it's meant for embedding :).  While this is definitely worth some clarification in the docs, it's not a high-priority issue.

+Ethan Smith from #28903.

----------
nosy: +Ethan Smith
stage:  -> needs patch
title: Embedded Release interactive mode documentation -> Windows: document that site is not imported by default by embeddable distribution

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

From report at bugs.python.org  Thu Dec  8 10:34:37 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 08 Dec 2016 15:34:37 +0000
Subject: [issue28904] add more format conversion flags eg. "len" and "id"
In-Reply-To: <1481207826.64.0.85637037523.issue28904@psf.upfronthosting.co.za>
Message-ID: <1481211277.33.0.365361548265.issue28904@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
resolution: fixed -> rejected
stage:  -> resolved

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

From report at bugs.python.org  Thu Dec  8 11:02:58 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 08 Dec 2016 16:02:58 +0000
Subject: [issue28898] Can't compile gdb with Python 3.6
In-Reply-To: <1481134479.52.0.174259382887.issue28898@psf.upfronthosting.co.za>
Message-ID: <1481212978.73.0.975998844189.issue28898@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The pushed change 4745d801cae2 LGTM for a cherry-pick in 3.6.0.

----------
nosy: +haypo

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

From report at bugs.python.org  Thu Dec  8 11:09:59 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 08 Dec 2016 16:09:59 +0000
Subject: [issue28838] Using consistent naming for arguments of "call"
 functions (C API)
In-Reply-To: <1480504437.73.0.907175245586.issue28838@psf.upfronthosting.co.za>
Message-ID: <1481213399.86.0.491463507689.issue28838@psf.upfronthosting.co.za>


STINNER Victor added the comment:

cleanup-2.patch: Rebase cleanup.patch.

This patch is the last part of my work to cleanup Include/abstract.h to make it more consistent with other header files.

----------
Added file: http://bugs.python.org/file45798/cleanup-2.patch

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

From report at bugs.python.org  Thu Dec  8 11:17:28 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 08 Dec 2016 16:17:28 +0000
Subject: [issue28770] Update python-gdb.py for fastcalls
In-Reply-To: <1479814975.16.0.381517171433.issue28770@psf.upfronthosting.co.za>
Message-ID: <20161208161722.99139.81899.C6A6B2BB@psf.io>


Roundup Robot added the comment:

New changeset f41d02d7da37 by Victor Stinner in branch '3.6':
Issue #28770: Update python-gdb.py for fastcalls
https://hg.python.org/cpython/rev/f41d02d7da37

----------

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

From report at bugs.python.org  Thu Dec  8 11:19:50 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 08 Dec 2016 16:19:50 +0000
Subject: [issue28770] Update python-gdb.py for fastcalls
In-Reply-To: <1479814975.16.0.381517171433.issue28770@psf.upfronthosting.co.za>
Message-ID: <1481213990.48.0.291107320379.issue28770@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I fixed the issue in Python 3.6 (future 3.6.1).

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

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

From report at bugs.python.org  Thu Dec  8 11:32:23 2016
From: report at bugs.python.org (Steve Dower)
Date: Thu, 08 Dec 2016 16:32:23 +0000
Subject: [issue28901] Windows: document that site is not imported by default
 by embeddable distribution
In-Reply-To: <1481175364.84.0.951011976369.issue28901@psf.upfronthosting.co.za>
Message-ID: <1481214743.45.0.629459348914.issue28901@psf.upfronthosting.co.za>


Steve Dower added the comment:

If you go to the 3.6 version of that doc page and also read the section on finding modules, you'll see that the presence of a "python._pth" file causes -S (skip importing site) to be implied unless the ._pth file includes "import site":

https://docs.python.org/3.6/using/windows.html#finding-modules

You'll then notice that the embeddable distro includes a ._pth file by default (though you don't have to distribute that with your app, just as you may want to omit the exe files). That could certainly be called out more clearly in the section on the embeddable distro, though so far it hasn't come up with anyone who's using it for its proper purpose (that I'm aware of).

----------

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

From report at bugs.python.org  Thu Dec  8 12:02:13 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 08 Dec 2016 17:02:13 +0000
Subject: [issue28896] Embeddable zip allows Windows registry to override
 module location
In-Reply-To: <1481128708.35.0.521458556277.issue28896@psf.upfronthosting.co.za>
Message-ID: <20161208170210.117097.22467.406C5331@psf.io>


Roundup Robot added the comment:

New changeset 25df9671663b by Steve Dower in branch '3.6':
Issue #28896: Deprecate WindowsRegistryFinder
https://hg.python.org/cpython/rev/25df9671663b

New changeset 5376b3a168c8 by Steve Dower in branch 'default':
Issue #28896: Deprecate WindowsRegistryFinder
https://hg.python.org/cpython/rev/5376b3a168c8

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

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

From report at bugs.python.org  Thu Dec  8 12:02:58 2016
From: report at bugs.python.org (Danny Yoo)
Date: Thu, 08 Dec 2016 17:02:58 +0000
Subject: [issue28905] re.sub appears not to check count optional argument for
 integerness
Message-ID: <1481216578.4.0.700543113224.issue28905@psf.upfronthosting.co.za>


New submission from Danny Yoo:

This comes from diagnosing a beginner's question on Python-tutor.

https://mail.python.org/pipermail/tutor/2016-December/110066.html

It appears that re.sub is not checking whether the count argument is integer or not, and silently accepts a nonsensical argument.  For example:


>>> import re
>>> s = "AAAcBBB\nAAAdBBB"
>>> print(re.sub(r'^AAA', "aaa", s, re.MULTILINE))
aaacBBB
AAAdBBB


Of course, the user intended to pass re.MULTILINE to flags, not to count, but the fact that this isn't raising a TypeError is error-prone.

----------
components: Library (Lib)
messages: 282719
nosy: Danny Yoo
priority: normal
severity: normal
status: open
title: re.sub appears not to check count optional argument for integerness
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Thu Dec  8 12:04:18 2016
From: report at bugs.python.org (Steve Dower)
Date: Thu, 08 Dec 2016 17:04:18 +0000
Subject: [issue28896] Embeddable zip allows Windows registry to override
 module location
In-Reply-To: <1481128708.35.0.521458556277.issue28896@psf.upfronthosting.co.za>
Message-ID: <1481216658.15.0.390849662684.issue28896@psf.upfronthosting.co.za>


Steve Dower added the comment:

I assumed silence meant everyone was happy with the wording, so I extended it to whatsnew and NEWS and pushed.

Ned - the changeset above should be good for you to cherrypick.

I'll leave this issue open to cover actually removing the finder from sys.meta_path in 3.7 and potentially 3.6.1.

----------
assignee:  -> steve.dower
priority: normal -> release blocker
stage:  -> commit review
versions:  -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28896>
_______________________________________

From report at bugs.python.org  Thu Dec  8 12:11:37 2016
From: report at bugs.python.org (Danny Yoo)
Date: Thu, 08 Dec 2016 17:11:37 +0000
Subject: [issue28905] re.sub appears not to check count optional argument for
 integerness
In-Reply-To: <1481216578.4.0.700543113224.issue28905@psf.upfronthosting.co.za>
Message-ID: <1481217097.34.0.105645345513.issue28905@psf.upfronthosting.co.za>


Danny Yoo added the comment:

Ugh.  I suddenly realize that this is complicated by the fact that flag values are themselves represented as integers, and Python's type system isn't rich enough to label flag values as a distinct type for the purposes.

It may be worthwhile to add a warning in the documentation about this, as it is an easy mistake to make.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28905>
_______________________________________

From report at bugs.python.org  Thu Dec  8 12:32:51 2016
From: report at bugs.python.org (Danny Yoo)
Date: Thu, 08 Dec 2016 17:32:51 +0000
Subject: [issue28905] re.sub appears not to check count optional argument for
 integerness
In-Reply-To: <1481216578.4.0.700543113224.issue28905@psf.upfronthosting.co.za>
Message-ID: <1481218371.67.0.185317403078.issue28905@psf.upfronthosting.co.za>


Danny Yoo added the comment:

Alternatively, change the representation of flag values from integers to some class extension that supports the common bitwise operators.

As a very rough sketch:

>>> class FlagInt(int):
...     def __or__(self, other):
...         return FlagInt(int(self) | int(other))
... 
>>> f1 = FlagInt(1)
>>> f2 = FlagInt(2)
>>> f1 | f2
3
>>> isinstance(3, FlagInt)
False
>>> isinstance(f1 | f2, FlagInt)
True


That way, flag arguments can be determined at runtime to have derived from the proper flag values.

This kind of approach may have some backwards-incompatibility, unfortunately, since other folks have been hardcoding integers rather than use the flag constants.  Other concerns might include serialization, in case someone tries to save a FlagInt somewhere and pull it out at some other time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28905>
_______________________________________

From report at bugs.python.org  Thu Dec  8 12:42:58 2016
From: report at bugs.python.org (Preston Landers)
Date: Thu, 08 Dec 2016 17:42:58 +0000
Subject: [issue28906] Can't inherit sockets with multiprocessing on Windows
Message-ID: <1481218978.59.0.0663276612908.issue28906@psf.upfronthosting.co.za>


New submission from Preston Landers:

I'm porting a Python 2.6 based application to Python 3.6. This app uses a customized version of the "flup" package to do FastCGI services on Windows using the multiprocessing package. This requires a few sockets to be inherited across processes - the main FastCGI protocol socket plus a control socket.

In Python 2.6, the `socket.from_fd` function was not available on Windows. However I patched Python's socketmodule.c to provide that function using DuplicateHandle. In Python 2.6's version of multiprocessing it spawned a process with CreateProcess and bInheritHandles=True. This worked well for me.

Now I'm trying to get this working after moving from Python 2.6 to 3.6 (currently using 3.6.0b4). Fortunately, the socket module now has a working `socket.from_fd` on Windows so I no longer have to patch that. Unfortunately for me, though, the multiprocessing module now calls CreateProcess with bInheritHandles=False. This causes my scenario to fail.

Here's a short test script which illustrates this problem:
https://gist.github.com/Preston-Landers/712fee10fb557cf0b5592b57561a7c08

If you run with an unpatched multiprocessing, it will fail with an error like:

OSError: [WinError 10038] An operation was attempted on something that is not a socket

If you patch multiprocessing to set bInheritHandles=True this now works. (Change is in popen_spawn_win32.py where it does _winapi.CreateProcess.)

I'm sure there's a good reason for that change in multiprocessing, whether for security or for unrelated/undesired file handles being passed.
https://www.python.org/dev/peps/pep-0446/#inheritance-of-file-descriptors-on-windows

However it does break my scenario and I don't see a way to tell multiprocessing to allow certain handles to be inherited. The docs for multiprocessing say "In particular, unnecessary file descriptors and handles from the parent process will not be inherited." It would be nice to have a way to tell it that my sockets are "necessary." You would think that calling socket.set_inheritable(True) would do it. In fact you must do that, but you must also pass bInheritHandles=True to CreateProcess for it to actually work. There doesn't seem to be a way to pass through an argument to multiprocessing to tell it to set this flag.

I do realize I could be going about this completely wrong, though. But right now it looks like my immediate options are:

a) Go ahead and patch my copy of popen_spawn_win32.py to allow inherited handles despite other possible risks.

b) Try to rewrite things to not use multiprocessing at all and directly spawn my processes instead. That's not attractive because multiprocessing otherwise does what I need to do.

Are there any other options I'm missing? Maybe some way to duplicate the socket on the other end without relying on CreateProcess with bInheritHandles=True?

Otherwise, I guess I'm asking for an option to be made available in multiprocessing to allow handles to be inherited on Windows.

----------
components: Library (Lib)
messages: 282723
nosy: planders
priority: normal
severity: normal
status: open
title: Can't inherit sockets with multiprocessing on Windows
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28906>
_______________________________________

From report at bugs.python.org  Thu Dec  8 13:07:47 2016
From: report at bugs.python.org (Alexey Izbyshev)
Date: Thu, 08 Dec 2016 18:07:47 +0000
Subject: [issue28896] Embeddable zip allows Windows registry to override
 module location
In-Reply-To: <1481128708.35.0.521458556277.issue28896@psf.upfronthosting.co.za>
Message-ID: <1481220467.06.0.230533007127.issue28896@psf.upfronthosting.co.za>


Alexey Izbyshev added the comment:

Thanks to Steve and everyone for quick and decisive action!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28896>
_______________________________________

From report at bugs.python.org  Thu Dec  8 13:18:10 2016
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 08 Dec 2016 18:18:10 +0000
Subject: [issue28835] Change in behavior when overriding warnings.showwarning
 and with catch_warnings(record=True)
In-Reply-To: <1480465767.99.0.401403947818.issue28835@psf.upfronthosting.co.za>
Message-ID: <1481221090.95.0.834304523441.issue28835@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I just happened to look at that bug before seeing this bug and both mentioned recording issues so I thought I would mention there was a chance of a connection.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28835>
_______________________________________

From report at bugs.python.org  Thu Dec  8 13:37:08 2016
From: report at bugs.python.org (R. David Murray)
Date: Thu, 08 Dec 2016 18:37:08 +0000
Subject: [issue28905] re.sub appears not to check count optional argument for
 integerness
In-Reply-To: <1481216578.4.0.700543113224.issue28905@psf.upfronthosting.co.za>
Message-ID: <1481222228.82.0.66984884397.issue28905@psf.upfronthosting.co.za>


R. David Murray added the comment:

See issue 28082.

----------
nosy: +r.david.murray
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> re: convert re flags to (much friendlier) IntFlag constants

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28905>
_______________________________________

From report at bugs.python.org  Thu Dec  8 13:43:58 2016
From: report at bugs.python.org (Douglas Greiman)
Date: Thu, 08 Dec 2016 18:43:58 +0000
Subject: [issue28425] Python3 ignores __init__.py that are links to /dev/null
In-Reply-To: <1476317932.87.0.807629965942.issue28425@psf.upfronthosting.co.za>
Message-ID: <1481222638.21.0.120134739459.issue28425@psf.upfronthosting.co.za>


Douglas Greiman added the comment:

Is there a reasonable place to document that __init__.py (and probably source files in general) must be a "regular file" by the Unix definition, and not a device file, socket, etc?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28425>
_______________________________________

From report at bugs.python.org  Thu Dec  8 14:10:18 2016
From: report at bugs.python.org (Neil Schemenauer)
Date: Thu, 08 Dec 2016 19:10:18 +0000
Subject: [issue28907] test_pydoc fails if build is in sub-directory
Message-ID: <1481224218.05.0.36648491601.issue28907@psf.upfronthosting.co.za>


New submission from Neil Schemenauer:

test_pydoc is failing for me for 3.6rc1.  I build in a sub-directory, e.g. Python-3.6.0rc1/build-opt.  The root of the issue is that pydoc getdocloc() is broken.  It cannot build 'basedir' as it does and assume that is the location of standard modules.  Fixing that is tricky though, I will open a separate issue for that.

For this issue, I think the test_mixed_case_module_names_are_lower_cased() function needs to be fixed to handle that case that get_pydoc_link() returns None.  I.e. it thinks that the module is not a standard module and so returns no link.

Attached is a patch.  It is trivial and I think should go into 3.6.

----------
assignee: r.david.murray
components: Tests
files: test_pydoc_fix.txt
messages: 282728
nosy: nascheme, r.david.murray
priority: high
severity: normal
stage: patch review
status: open
title: test_pydoc fails if build is in sub-directory
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file45799/test_pydoc_fix.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28907>
_______________________________________

From report at bugs.python.org  Thu Dec  8 14:24:29 2016
From: report at bugs.python.org (Neil Schemenauer)
Date: Thu, 08 Dec 2016 19:24:29 +0000
Subject: [issue28908] pydoc getdocloc() is broken
Message-ID: <1481225069.67.0.983808754033.issue28908@psf.upfronthosting.co.za>


New submission from Neil Schemenauer:

The getdocloc() method in pydoc.py is supposed to return the doc location for modules.  It uses a 'basedir' parameter that is supposed to point to the location of the standard library modules.

That logic is broken for a number of different scenarios, I think.  One is if you build Python in a sub-directory, not in the root of the source tree.  Another I think is if you are using a Zip file for the std lib.

Fixing this properly is not so easy.  One solution would be to explictly mark modules that have docs available.  E.g. create a __pydoc global variable or similar that the 'pydoc' module to inspect.  That would have to be done on every module that has documentation.

Another idea is at build time, crawl through Doc/library and generate a list of modules that have docs.  That's a bit tricky because that generation needs to work on all platforms that Python is built on.

A third idea is to manually add the list to the pydoc.py module.  When new documentation is created under Doc/library, that list would have to be updated.

----------
components: Library (Lib)
messages: 282729
nosy: nascheme
priority: normal
severity: normal
stage: needs patch
status: open
title: pydoc getdocloc() is broken
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28908>
_______________________________________

From report at bugs.python.org  Thu Dec  8 14:35:20 2016
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 08 Dec 2016 19:35:20 +0000
Subject: [issue28906] Can't inherit sockets with multiprocessing on Windows
In-Reply-To: <1481218978.59.0.0663276612908.issue28906@psf.upfronthosting.co.za>
Message-ID: <1481225720.83.0.0536685199874.issue28906@psf.upfronthosting.co.za>


Eryk Sun added the comment:

You should be able to directly pass the socket to the child process. multiprocessing registers a reduction for this. On Windows it uses the DupSocket class from multiprocessing.resource_sharer:

    class DupSocket(object):
        '''Picklable wrapper for a socket.'''
        def __init__(self, sock):
            new_sock = sock.dup()
            def send(conn, pid):
                share = new_sock.share(pid)
                conn.send_bytes(share)
            self._id = _resource_sharer.register(send, new_sock.close)

        def detach(self):
            '''Get the socket.  This should only be called once.'''
            with _resource_sharer.get_connection(self._id) as conn:
                share = conn.recv_bytes()
                return socket.fromshare(share)

This calls the Windows socket share() method [1], which calls WSADuplicateSocket [2]. In the child, socket.fromshare() passes the protocol info buffer to the socket constructor, which passes it to WSASocket [3].

[1]: https://docs.python.org/3/library/socket.html#socket.socket.share
[2]: https://msdn.microsoft.com/en-us/library/ms741565
[3]: https://msdn.microsoft.com/en-us/library/ms742212

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28906>
_______________________________________

From report at bugs.python.org  Thu Dec  8 14:36:35 2016
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 08 Dec 2016 19:36:35 +0000
Subject: [issue28906] Can't inherit sockets with multiprocessing on Windows
In-Reply-To: <1481218978.59.0.0663276612908.issue28906@psf.upfronthosting.co.za>
Message-ID: <1481225795.61.0.220756642183.issue28906@psf.upfronthosting.co.za>


Changes by Eryk Sun <eryksun+pybugs at gmail.com>:


----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28906>
_______________________________________

From report at bugs.python.org  Thu Dec  8 14:46:09 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 08 Dec 2016 19:46:09 +0000
Subject: [issue25711] Rewrite zipimport from scratch
In-Reply-To: <1448296120.48.0.872112518039.issue25711@psf.upfronthosting.co.za>
Message-ID: <1481226369.58.0.115679181469.issue25711@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is preliminary translation of zipimport to Python. It is not frozen and imports other modules. I tried to keep the implementation close to C implementation. As a consequence, some raised exceptions look arbitrary.

----------
keywords: +patch
stage:  -> patch review
type:  -> enhancement
versions: +Python 3.7 -Python 3.6
Added file: http://bugs.python.org/file45800/zipimport.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25711>
_______________________________________

From report at bugs.python.org  Thu Dec  8 14:56:39 2016
From: report at bugs.python.org (Neil Schemenauer)
Date: Thu, 08 Dec 2016 19:56:39 +0000
Subject: [issue28908] pydoc getdocloc() is broken
In-Reply-To: <1481225069.67.0.983808754033.issue28908@psf.upfronthosting.co.za>
Message-ID: <1481226999.6.0.172154679975.issue28908@psf.upfronthosting.co.za>


Neil Schemenauer added the comment:

Attached is a first pass at the idea of just keeping a list of standard modules that have docs.  I generated the list with:

$ (cd Doc/library; ls *.rst | sed 's/.rst//')

Probably that should be incorporated into the Doc/Makefile somehow.

Perhaps instead of generating a text file, we should generate a Python module that contains a set literal, e.g. Lib/pydoc_data/libs.py.  That would have the advantage of working for frozen distributions or stdlib as Zip files.

----------
Added file: http://bugs.python.org/file45801/pydoc_getdocloc.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28908>
_______________________________________

From report at bugs.python.org  Thu Dec  8 15:04:36 2016
From: report at bugs.python.org (Francis Deslauriers)
Date: Thu, 08 Dec 2016 20:04:36 +0000
Subject: [issue28909] Adding LTTng-UST tracing support
Message-ID: <1481227474.94.0.337411886613.issue28909@psf.upfronthosting.co.za>


New submission from Francis Deslauriers:

This patch extends the tracing infrastructure to support LTTng UserSpace
Tracer. Using LTTng-UST, users would have access to a low overhead tracing 
done entirely from userspace.

Depending on the tracing configure option used (none, --with-dtrace or
--with-lttngust) macros will be expanded to probes and tracepoints of the
desired tracer if any. Only the needed instrumentation will be added to the
binary. This technique is used to different degrees by other projects like 
Qemu[1] and Node.js[2].

I attached a patch adding this feature. I tested the changes and the 
instrumentation on LTTng-UST and SystemTap on Ubuntu 16.04. I would 
appreciate if someone could test those changes on macOS and other
platforms supporting USDT probes.

[1]https://github.com/qemu/qemu/blob/master/configure#L4303
[2]https://github.com/nodejs/node/blob/master/configure#L811

----------
files: 0001-Add-LTTng-UST-probe-and-tracepoints.patch
keywords: patch
messages: 282733
nosy: Francis Deslauriers
priority: normal
severity: normal
status: open
title: Adding LTTng-UST tracing support
type: enhancement
versions: Python 3.7
Added file: http://bugs.python.org/file45802/0001-Add-LTTng-UST-probe-and-tracepoints.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28909>
_______________________________________

From report at bugs.python.org  Thu Dec  8 15:07:57 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 08 Dec 2016 20:07:57 +0000
Subject: [issue28835] Change in behavior when overriding warnings.showwarning
 and with catch_warnings(record=True)
In-Reply-To: <1480465767.99.0.401403947818.issue28835@psf.upfronthosting.co.za>
Message-ID: <1481227677.66.0.574478276608.issue28835@psf.upfronthosting.co.za>


Martin Panter added the comment:

Brett, what was the other bug? The bug number you posted is for this bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28835>
_______________________________________

From report at bugs.python.org  Thu Dec  8 15:08:48 2016
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 08 Dec 2016 20:08:48 +0000
Subject: [issue28909] Adding LTTng-UST tracing support
In-Reply-To: <1481227474.94.0.337411886613.issue28909@psf.upfronthosting.co.za>
Message-ID: <1481227728.83.0.542936848197.issue28909@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28909>
_______________________________________

From report at bugs.python.org  Thu Dec  8 15:35:47 2016
From: report at bugs.python.org (R. David Murray)
Date: Thu, 08 Dec 2016 20:35:47 +0000
Subject: [issue28908] pydoc getdocloc() is broken
In-Reply-To: <1481225069.67.0.983808754033.issue28908@psf.upfronthosting.co.za>
Message-ID: <1481229347.78.0.877725556098.issue28908@psf.upfronthosting.co.za>


R. David Murray added the comment:

It is possible that we only care about this for release builds.  I don't think maintain a hard-coded, hand-coded list is a good idea, regardless.  There might be some way to generate it at build time, though.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28908>
_______________________________________

From report at bugs.python.org  Thu Dec  8 15:36:40 2016
From: report at bugs.python.org (Preston Landers)
Date: Thu, 08 Dec 2016 20:36:40 +0000
Subject: [issue28906] Can't inherit sockets with multiprocessing on Windows
In-Reply-To: <1481218978.59.0.0663276612908.issue28906@psf.upfronthosting.co.za>
Message-ID: <1481229400.93.0.131464459904.issue28906@psf.upfronthosting.co.za>


Preston Landers added the comment:

Wow, good call. That does work for me. Wish I had thought to try it. I assume you want me to go ahead and close the issue. Sorry for the noise, but this really helps!

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28906>
_______________________________________

From report at bugs.python.org  Thu Dec  8 15:48:36 2016
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 08 Dec 2016 20:48:36 +0000
Subject: [issue28906] Can't inherit sockets with multiprocessing on Windows
In-Reply-To: <1481218978.59.0.0663276612908.issue28906@psf.upfronthosting.co.za>
Message-ID: <1481230116.23.0.867664176865.issue28906@psf.upfronthosting.co.za>


Changes by Eryk Sun <eryksun+pybugs at gmail.com>:


----------
stage:  -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28906>
_______________________________________

From report at bugs.python.org  Thu Dec  8 16:18:19 2016
From: report at bugs.python.org (Eric Appelt)
Date: Thu, 08 Dec 2016 21:18:19 +0000
Subject: [issue28910] Async generator does not raise RuntimeError if finalizer
 not set
Message-ID: <1481231899.72.0.681247930354.issue28910@psf.upfronthosting.co.za>


New submission from Eric Appelt:

While testing my understanding in order to document PEP525 asynchronous generators in the Language Reference (issue 28091) I noticed that the implemented behavior deviates from PEP525, specifically the PEP states that:

"When an asynchronous generator is iterated for the first time, it stores a reference to the current finalizer. If there is none, a RuntimeError is raised. This provides a strong guarantee that every asynchronous generator object will always have a finalizer installed by the correct event loop."

I created an asynchronous generator to try to run calling __anext__ interactively without an event loop to check the behavior, and was surprised when I didn't get a RuntimeError even though I had not called sys.set_asyncgen_hooks() to set a finalizer function.

I looked at the function async_gen_init_hooks defined in Objects/genobject.c and it appears that if the thread state async_gen_finalizer is NULL, then it just returns zero and allows the calling function to continue.

I'm not sure if this is a bug, or this is intentional and the finalizer mechanism should be optional. If it is the latter should PEP525 get updated?

----------
components: Interpreter Core
messages: 282737
nosy: Eric Appelt, yselivanov
priority: normal
severity: normal
status: open
title: Async generator does not raise RuntimeError if finalizer not set
type: behavior
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28910>
_______________________________________

From report at bugs.python.org  Thu Dec  8 16:27:35 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 08 Dec 2016 21:27:35 +0000
Subject: [issue28910] Async generator does not raise RuntimeError if finalizer
 not set
In-Reply-To: <1481231899.72.0.681247930354.issue28910@psf.upfronthosting.co.za>
Message-ID: <1481232455.87.0.0916671819884.issue28910@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> I'm not sure if this is a bug, or this is intentional and the finalizer mechanism should be optional. If it is the latter should PEP525 get updated?

This is intentional, PEP 525 is slightly outdated.  I'll update it right now.  Thanks for reporting this!

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28910>
_______________________________________

From report at bugs.python.org  Thu Dec  8 16:30:55 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 08 Dec 2016 21:30:55 +0000
Subject: [issue28910] Async generator does not raise RuntimeError if finalizer
 not set
In-Reply-To: <1481231899.72.0.681247930354.issue28910@psf.upfronthosting.co.za>
Message-ID: <1481232655.8.0.936500202984.issue28910@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

fix: https://github.com/python/peps/commit/3e23210fe3aebefb269436e16246f63e1f006291

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28910>
_______________________________________

From report at bugs.python.org  Thu Dec  8 16:48:20 2016
From: report at bugs.python.org (Arne de Laat)
Date: Thu, 08 Dec 2016 21:48:20 +0000
Subject: [issue28911] Clarify the behaviour of assert_called_once_with
Message-ID: <1481233700.68.0.637550951007.issue28911@psf.upfronthosting.co.za>


New submission from Arne de Laat:

The name assert_called_once_with and the current method documentation can be interpreted to mean that it asserts that there is precisely one call matching the given signature, regardless of the total number of calls. However, the method first checks that there is precisely one call, and then checks if that call has a signature matching the provided signature.

Additionally, the assert_any_call method documentation references assert_called_once_with in a way that enforces the possible misinterpretation: "? assert_called_with and assert_called_once_with that only pass if the call is the most recent one". This may lead to the interpretation that there must be only one call with the given signature and  that it must be the most recent one, it must in fact be the only one.

In the mock examples documentation there is an important sentence that clarifies the actual functionality: "you can use the assert_called_once_with method that also asserts that the call_count is one".

The example provided in the method documentation also does not satisfactorily address the ambiguity, because it only calls the mock with one call signature. By changing the call signature of the second call (and in the assert) in the example the purpose of the method becomes clearer.

----------
assignee: docs at python
components: Documentation, Tests
files: assert_once_with_doc.patch
keywords: patch
messages: 282740
nosy: 153957, docs at python
priority: normal
severity: normal
status: open
title: Clarify the behaviour of assert_called_once_with
type: enhancement
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45803/assert_once_with_doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28911>
_______________________________________

From report at bugs.python.org  Thu Dec  8 16:51:45 2016
From: report at bugs.python.org (Brandon VanVaerenbergh - NOAA Affiliate)
Date: Thu, 08 Dec 2016 21:51:45 +0000
Subject: [issue22343] Install bash activate script on Windows when using venv
In-Reply-To: <1409948648.7.0.892236136888.issue22343@psf.upfronthosting.co.za>
Message-ID: <1481233905.46.0.0443254890617.issue22343@psf.upfronthosting.co.za>


Brandon VanVaerenbergh - NOAA Affiliate added the comment:

+1 just experienced this issue migrating from Python3.4 to Python3.5 on windows with bash (MINGW git bash) as primary shell

Temporarily resolved issue (on this workstation) by simply copying Python35\Lib\venv\scripts\posix\activate file, into folder: Python35\Lib\venv\scripts\nt\

then recreating venv

----------
nosy: +Brandon VanVaerenbergh - NOAA Affiliate
versions: +Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22343>
_______________________________________

From report at bugs.python.org  Thu Dec  8 17:44:37 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 08 Dec 2016 22:44:37 +0000
Subject: [issue28867] NamedTemporaryFile does not generate a ResourceWarning
 for unclosed files (unlike TemporaryFile)
In-Reply-To: <1480873647.39.0.877280517926.issue28867@psf.upfronthosting.co.za>
Message-ID: <1481237077.99.0.243409384797.issue28867@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28867>
_______________________________________

From report at bugs.python.org  Thu Dec  8 18:00:34 2016
From: report at bugs.python.org (Joshua Bronson)
Date: Thu, 08 Dec 2016 23:00:34 +0000
Subject: [issue28912] collections.abc.OrderedMapping
Message-ID: <1481238034.34.0.119082165821.issue28912@psf.upfronthosting.co.za>


New submission from Joshua Bronson:

Since code can be clearer than prose, I just sketched this idea out in the attached patch. Please take a look at it as a minimum demonstration of the concept.

Rationale:

The Python standard library provides collections.OrderedDict, along with several ABCs which OrderedDict extends, such as collections.abc.Mapping and (as of 3.6) collections.abc.Reversible, to enable better composability and interoperability.

Currently there is no collections.abc.OrderedMapping ABC, but I wonder if there should be. OrderedMapping could provide a concrete, generic implementation of __eq__, that performed an order-sensitive comparison when passed another OrderedMapping, while performing an order-insensitive comparison when passed an unordered Mapping. Then OrderedDict could derive from OrderedMapping, inheriting its generic __eq__ implementation, rather than implementing its own __eq__ method. Currently, OrderedDict's own __eq__ implementation does ``isinstance(other, OrderedDict)`` to decide whether to perform an order-sensitive comparison, which thwarts interoperability. OrderedMapping could also derive from Reversible, signaling that classes that extend it implement __reversed__.

The interoperability gain here is not just theoretical. Several packages are published on PyPI which would be able to interoperate better if they could all extend a common OrderedMapping interface. Grant Jenks' sortedcontainers.SortedDict[1] and my own bidict.OrderedBidict[2] are two particularly popular examples.

Thanks for your consideration, and look forward to your feedback.

[1] http://www.grantjenks.com/docs/sortedcontainers/sorteddict.html
[2] https://bidict.readthedocs.io/en/dev/other-bidict-types.html#orderedbidict

----------
components: Library (Lib)
files: jab-orderedmapping-1.patch
keywords: patch
messages: 282742
nosy: gvanrossum, jab, rhettinger
priority: normal
severity: normal
status: open
title: collections.abc.OrderedMapping
type: enhancement
Added file: http://bugs.python.org/file45804/jab-orderedmapping-1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28912>
_______________________________________

From report at bugs.python.org  Thu Dec  8 18:23:06 2016
From: report at bugs.python.org (Ned Deily)
Date: Thu, 08 Dec 2016 23:23:06 +0000
Subject: [issue28147] Unbounded memory growth resizing split-table dicts
In-Reply-To: <1473853453.13.0.556951743271.issue28147@psf.upfronthosting.co.za>
Message-ID: <1481239386.92.0.994575847913.issue28147@psf.upfronthosting.co.za>


Ned Deily added the comment:

I think these proposed patches need careful review but, even so, given the extent of the fix28147-py36-2.patch changes, I don't think they should go into 3.6.0 at the last minute.  Unless somebody can convince me otherwise, I'm going to let this wait for 3.6.1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28147>
_______________________________________

From report at bugs.python.org  Thu Dec  8 18:34:00 2016
From: report at bugs.python.org (Joshua Bronson)
Date: Thu, 08 Dec 2016 23:34:00 +0000
Subject: [issue28912] collections.abc.OrderedMapping
In-Reply-To: <1481238034.34.0.119082165821.issue28912@psf.upfronthosting.co.za>
Message-ID: <1481240040.85.0.940568454428.issue28912@psf.upfronthosting.co.za>


Joshua Bronson added the comment:

This patch improves the OrderedMapping.__eq__ implementation to be more generic in the case that ``other`` is an unordered Mapping of the same length as ``self``.

----------
Added file: http://bugs.python.org/file45805/jab-orderedmapping-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28912>
_______________________________________

From report at bugs.python.org  Thu Dec  8 18:47:17 2016
From: report at bugs.python.org (Richard Eames)
Date: Thu, 08 Dec 2016 23:47:17 +0000
Subject: [issue28913] "Fatal Python error: Cannot recover from stack
 overflow." from RecursionError
Message-ID: <1481240837.05.0.510119516433.issue28913@psf.upfronthosting.co.za>


New submission from Richard Eames:

I've been porting a project to the latest version of Django, and due to one of the changes in the Django, caused a recursion error in my code. However, the error (under certain conditions) then causes the python interpreter to core dump. I'm not 100% sure what causes this to happen, but it does seem to be similar to https://bugs.python.org/issue6028

I've created a minimal django project: 
https://github.com/Naddiseo/python-core-dump

However, it does rely on some interaction between mysql, pymysql, and django to be reproduced, the latter two being 100% python code. I'm sorry that I could not reduce the test case further.

One of the interesting/weird things about this bug is that (on my machine at least) it requires exactly 15 entries in the `MIDDLEWARE` variable in "coredump/settings.py" in my test project, any more, or any less will cause the interpreter to issue a `RecursionError` as expected, but not to core dump. 

This appears to happen in 3.5, and not in 3.6 so perhaps whatever fix was applied to 3.6 can be backported to 3.5 so that it doesn't core dump?

----------
components: Interpreter Core
messages: 282745
nosy: Richard Eames
priority: normal
severity: normal
status: open
title: "Fatal Python error: Cannot recover from stack overflow." from RecursionError
type: crash
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28913>
_______________________________________

From report at bugs.python.org  Thu Dec  8 18:48:33 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 08 Dec 2016 23:48:33 +0000
Subject: [issue28913] "Fatal Python error: Cannot recover from stack
 overflow." from RecursionError in Python 3.5
In-Reply-To: <1481240837.05.0.510119516433.issue28913@psf.upfronthosting.co.za>
Message-ID: <1481240913.81.0.262325577453.issue28913@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
title: "Fatal Python error: Cannot recover from stack overflow." from RecursionError -> "Fatal Python error: Cannot recover from stack overflow." from RecursionError in Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28913>
_______________________________________

From report at bugs.python.org  Thu Dec  8 19:35:21 2016
From: report at bugs.python.org (Wataru Matsumoto)
Date: Fri, 09 Dec 2016 00:35:21 +0000
Subject: [issue28914] selectmodule build fails
Message-ID: <1481243721.04.0.91028253928.issue28914@psf.upfronthosting.co.za>


New submission from Wataru Matsumoto:

selectmodule build fails with the linux without epoll_create1(before kernel 2.6.27).


building 'select' extension
gcc -pthread -fPIC -fno-strict-aliasing -Wsign-compare -g -O0 -Wall -Wstrict-prototypes -std=c99 -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -I./Include -I. -I/usr/local/include -I/home/wmatsumo/download/cpython/Include -I/home/wmatsumo/download/cpython -c /home/wmatsumo/download/cpython/Modules/selectmodule.c -o build/temp.linux-x86_64-3.7-pydebug/home/wmatsumo/download/cpython/Modules/selectmodule.o
/home/wmatsumo/download/cpython/Modules/selectmodule.c: In function 'pyepoll_new':
/home/wmatsumo/download/cpython/Modules/selectmodule.c:1306: error: 'EPOLL_CLOEXEC' undeclared (first use in this function)
/home/wmatsumo/download/cpython/Modules/selectmodule.c:1306: error: (Each undeclared identifier is reported only once
/home/wmatsumo/download/cpython/Modules/selectmodule.c:1306: error: for each function it appears in.)

It seems due to the below change.
http://bugs.python.org/issue20100
It have to check HAVE_EPOLL_CREATE1 is defined before using EPOLL_CLOEXEC.

----------
files: selectmodule.patch
keywords: patch
messages: 282746
nosy: sxsns243
priority: normal
severity: normal
status: open
title: selectmodule build fails
type: compile error
versions: Python 3.7
Added file: http://bugs.python.org/file45806/selectmodule.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28914>
_______________________________________

From report at bugs.python.org  Thu Dec  8 19:38:46 2016
From: report at bugs.python.org (Roy Williams)
Date: Fri, 09 Dec 2016 00:38:46 +0000
Subject: [issue22294] 2to3 consuming_calls:  len, min, max, zip, map, reduce, 
 filter, dict, xrange
In-Reply-To: <1409226181.07.0.476582309368.issue22294@psf.upfronthosting.co.za>
Message-ID: <1481243926.86.0.282021572931.issue22294@psf.upfronthosting.co.za>


Changes by Roy Williams <rwilliams at lyft.com>:


----------
nosy: +Roy Williams

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22294>
_______________________________________

From report at bugs.python.org  Thu Dec  8 19:41:01 2016
From: report at bugs.python.org (Ned Deily)
Date: Fri, 09 Dec 2016 00:41:01 +0000
Subject: [issue28914] selectmodule build fails
In-Reply-To: <1481243721.04.0.91028253928.issue28914@psf.upfronthosting.co.za>
Message-ID: <1481244061.45.0.85217364032.issue28914@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28914>
_______________________________________

From report at bugs.python.org  Thu Dec  8 19:44:23 2016
From: report at bugs.python.org (Ammar Askar)
Date: Fri, 09 Dec 2016 00:44:23 +0000
Subject: [issue26267] UUID docs should say how to get "standard form"
In-Reply-To: <1454438589.41.0.991764109365.issue26267@psf.upfronthosting.co.za>
Message-ID: <1481244263.71.0.218536111482.issue26267@psf.upfronthosting.co.za>


Ammar Askar added the comment:

I've updated the patch to document the comparison operators in prose instead of with markup as requested.

----------
Added file: http://bugs.python.org/file45807/uuiddocs.diff5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26267>
_______________________________________

From report at bugs.python.org  Thu Dec  8 20:07:34 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Dec 2016 01:07:34 +0000
Subject: [issue28915] Modify PyObject_CallFunction() to use fast call
 internally
Message-ID: <1481245654.11.0.143889949597.issue28915@psf.upfronthosting.co.za>


New submission from STINNER Victor:

This issue tracks changes to support the "fast call" calling convention in functions:

* PyObject_CallFunctionObjArgs()
* PyObject_CallMethodObjArgs()
* _PyObject_CallMethodIdObjArgs()

A "stack" of Python objects is created to pass arguments to _PyObject_FastCall(). The goal is to avoid the creation of a temporary tuple to call functions.

The patch serie changes slots (typeobject.c), so calling Python slots from Python should avoid completely the creation of temporary tuples to pass parameters.


Microbenchmark on a simple class with an __int__() method, call int(o):

int(o): Median +- std dev: [ref] 239 ns +- 13 ns -> [patch] 219 ns +- 14 ns: 1.10x faster (-9%)


Microbenchmark on a simple class with an __getitem__() method, call o[100]:

o[100]: Median +- std dev: [ref] 211 ns +- 11 ns -> [patch] 172 ns +- 11 ns: 1.23x faster (-19%)


Comparison between Python 2.7, 3.5, 3.7 and 3.7+patch, 3.5 is used as the reference:

int(o)
======

Median +- std dev: [3.5] 271 ns +- 15 ns -> [3.7] 239 ns +- 13 ns: 1.13x faster (-12%)
Median +- std dev: [3.5] 271 ns +- 15 ns -> [patch] 219 ns +- 14 ns: 1.24x faster (-19%)
Median +- std dev: [3.5] 271 ns +- 15 ns -> [2.7] 401 ns +- 21 ns: 1.48x slower (+48%)

o[100]
======

Median +- std dev: [3.5] 206 ns +- 5 ns -> [3.7] 211 ns +- 11 ns: 1.02x slower (+2%)
Not significant!
Median +- std dev: [3.5] 206 ns +- 5 ns -> [patch] 172 ns +- 11 ns: 1.20x faster (-17%)
Median +- std dev: [3.5] 206 ns +- 5 ns -> [2.7] 254 ns +- 15 ns: 1.23x slower (+23%)

----------
messages: 282748
nosy: haypo
priority: normal
severity: normal
status: open
title: Modify PyObject_CallFunction() to use fast call internally
type: performance
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28915>
_______________________________________

From report at bugs.python.org  Thu Dec  8 20:15:03 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Dec 2016 01:15:03 +0000
Subject: [issue28915] Modify PyObject_CallFunction() to use fast call
 internally
In-Reply-To: <1481245654.11.0.143889949597.issue28915@psf.upfronthosting.co.za>
Message-ID: <1481246103.19.0.946284116008.issue28915@psf.upfronthosting.co.za>


STINNER Victor added the comment:

bench_slots.py: microbenchmark on __int__ and __getitem__ slots.

----------
Added file: http://bugs.python.org/file45808/bench_slots.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28915>
_______________________________________

From report at bugs.python.org  Thu Dec  8 20:16:25 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Dec 2016 01:16:25 +0000
Subject: [issue28914] selectmodule build fails
In-Reply-To: <1481243721.04.0.91028253928.issue28914@psf.upfronthosting.co.za>
Message-ID: <1481246185.54.0.101859846333.issue28914@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Probably a regression caused by the change ac24e5c2fd3e.

I'm curious: what is your Linux distribution? (Can't you get a more Linux kernel?)

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28914>
_______________________________________

From report at bugs.python.org  Thu Dec  8 20:17:09 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 09 Dec 2016 01:17:09 +0000
Subject: [issue28915] Modify PyObject_CallFunction() to use fast call
 internally
In-Reply-To: <1481245654.11.0.143889949597.issue28915@psf.upfronthosting.co.za>
Message-ID: <20161209011658.99922.61633.723F974A@psf.io>


Roundup Robot added the comment:

New changeset b771cf37714b by Victor Stinner in branch 'default':
Add _PyObject_FastCallVa() helper
https://hg.python.org/cpython/rev/b771cf37714b

New changeset 455169e87bb3 by Victor Stinner in branch 'default':
Add _PyObject_CallFunctionVa() helper
https://hg.python.org/cpython/rev/455169e87bb3

New changeset dd0d162593c5 by Victor Stinner in branch 'default':
modsupport: replace int with Py_ssize_t
https://hg.python.org/cpython/rev/dd0d162593c5

New changeset 69d5dcf31f4a by Victor Stinner in branch 'default':
modsupport: replace int with Py_ssize_t
https://hg.python.org/cpython/rev/69d5dcf31f4a

New changeset c1414b182232 by Victor Stinner in branch 'default':
Add _Py_VaBuildStack() function
https://hg.python.org/cpython/rev/c1414b182232

New changeset 69948a157507 by Victor Stinner in branch 'default':
_PyObject_CallFunctionVa() uses fast call
https://hg.python.org/cpython/rev/69948a157507

New changeset b9eb35435178 by Victor Stinner in branch 'default':
Don't parenthesis in _PyObject_CallMethodId() format
https://hg.python.org/cpython/rev/b9eb35435178

New changeset 67302e6caa29 by Victor Stinner in branch 'default':
Use _PyObject_CallMethodIdObjArgs()
https://hg.python.org/cpython/rev/67302e6caa29

New changeset 032cbdb596fe by Victor Stinner in branch 'default':
build_struct_time() uses Py_BuildValue()
https://hg.python.org/cpython/rev/032cbdb596fe

New changeset 49a7fdc0d40a by Victor Stinner in branch 'default':
time_strptime() uses PyObject_Call()
https://hg.python.org/cpython/rev/49a7fdc0d40a

New changeset 6e748eb79038 by Victor Stinner in branch 'default':
Add _PyObject_VaCallFunctionObjArgs() private function
https://hg.python.org/cpython/rev/6e748eb79038

New changeset adcd9131b7c6 by Victor Stinner in branch 'default':
Use _PyObject_FastCallVa() in type slots
https://hg.python.org/cpython/rev/adcd9131b7c6

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28915>
_______________________________________

From report at bugs.python.org  Thu Dec  8 20:29:04 2016
From: report at bugs.python.org (Whitequill Riclo)
Date: Fri, 09 Dec 2016 01:29:04 +0000
Subject: [issue28875] test fails and freezes
In-Reply-To: <1480940483.62.0.177315073409.issue28875@psf.upfronthosting.co.za>
Message-ID: <CAEWBzXPVUqJoLzTpbQUgyPyJLbCsHUQVRO+0n4=9wqUZv14TLA@mail.gmail.com>


Whitequill Riclo added the comment:

It was an accident. I didn't know if I had mistakenly closed it the first
time.

On Mon, Dec 5, 2016 at 7:21 AM, Berker Peksag <report at bugs.python.org>
wrote:

>
> Berker Peksag added the comment:
>
> Please do not reopen this one. You already opened issue 28874.
>
> ----------
> nosy: +berker.peksag
> stage:  -> resolved
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue28875>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28875>
_______________________________________

From report at bugs.python.org  Thu Dec  8 20:34:18 2016
From: report at bugs.python.org (Wataru Matsumoto)
Date: Fri, 09 Dec 2016 01:34:18 +0000
Subject: [issue23395] _thread.interrupt_main() errors if SIGINT handler in
 SIG_DFL, SIG_IGN
In-Reply-To: <1423093850.42.0.241477195496.issue23395@psf.upfronthosting.co.za>
Message-ID: <1481247258.73.0.153157334817.issue23395@psf.upfronthosting.co.za>


Changes by Wataru Matsumoto <sxsns243 at gmail.com>:


----------
nosy: +sxsns243

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23395>
_______________________________________

From report at bugs.python.org  Thu Dec  8 20:48:34 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Dec 2016 01:48:34 +0000
Subject: [issue28898] Can't compile gdb with Python 3.6
In-Reply-To: <1481134479.52.0.174259382887.issue28898@psf.upfronthosting.co.za>
Message-ID: <1481248114.32.0.0409223557766.issue28898@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oh, the problem has introduced a crash on OpenIndiana:
---
Fatal Python error: Aborted

Current thread 0x0000000000000001 (most recent call first):
  File "/export/home/buildbot/64bits/3.x.cea-indiana-amd64/build/Lib/ctypes/__init__.py", line 273 in _reset_cache
...
---

http://buildbot.python.org/all/builders/AMD64%20OpenIndiana%203.x/builds/37/steps/test/logs/stdio

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28898>
_______________________________________

From report at bugs.python.org  Thu Dec  8 20:50:44 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Dec 2016 01:50:44 +0000
Subject: [issue28898] Can't compile gdb with Python 3.6
In-Reply-To: <1481134479.52.0.174259382887.issue28898@psf.upfronthosting.co.za>
Message-ID: <1481248244.77.0.0602686773579.issue28898@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The OpenIndiana uses gcc and has the long long type. Extract of the ./configure script:
---
checking for gcc... gcc
(...)
checking size of long long... 8
---
http://buildbot.python.org/all/builders/AMD64%20OpenIndiana%203.x/builds/37/steps/configure/logs/stdio

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28898>
_______________________________________

From report at bugs.python.org  Thu Dec  8 20:55:33 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Dec 2016 01:55:33 +0000
Subject: [issue28874] test_logging fails and freezes
In-Reply-To: <1480923682.41.0.106352881958.issue28874@psf.upfronthosting.co.za>
Message-ID: <1481248533.54.0.704931665676.issue28874@psf.upfronthosting.co.za>


STINNER Victor added the comment:

What is your OS? A Linux on bare metal? Or a container? What are versions of Linux kernel, libc and C compiler? Or more generally the name and verison of your Linux distro?

There are many errors:

* test_fcntl failed
* test_import failed
* test_epoll failed

Can you please run only these tests in verbose mode, and attach the output?

Example:

./python -m test -v test_fcntl test_import test_epolls

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28874>
_______________________________________

From report at bugs.python.org  Thu Dec  8 21:37:20 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 09 Dec 2016 02:37:20 +0000
Subject: [issue22294] 2to3 consuming_calls:  len, min, max, zip, map, reduce, 
 filter, dict, xrange
In-Reply-To: <1409226181.07.0.476582309368.issue22294@psf.upfronthosting.co.za>
Message-ID: <1481251040.28.0.841994936822.issue22294@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22294>
_______________________________________

From report at bugs.python.org  Thu Dec  8 22:05:34 2016
From: report at bugs.python.org (Wataru Matsumoto)
Date: Fri, 09 Dec 2016 03:05:34 +0000
Subject: [issue23395] _thread.interrupt_main() errors if SIGINT handler in
 SIG_DFL, SIG_IGN
In-Reply-To: <1423093850.42.0.241477195496.issue23395@psf.upfronthosting.co.za>
Message-ID: <1481252734.23.0.513932902403.issue23395@psf.upfronthosting.co.za>


Wataru Matsumoto added the comment:

Recently I've encountered the similar problem.
I found the case that SIGINT signal is ignored(set as SIG_IGN) due to the external reason.
If the python program starts background in bash script, bash set SIGINT as SIG_IGN.

test_interrupt.py
import _thread
_thread.interrupt_main()

run.sh
#!/bin/bash
python test_interrupt.py &
sleep 1s

./run.sh 
Traceback (most recent call last):
  File "test_interrupt.py", line 2, in <module>
    _thread.interrupt_main()
RuntimeError: the SIGINT signal is ignored
(it was TypeError: 'int' object is not callable before the patch)

Python mapped default_int_handler to SIG_INT on SIG_DFL in PyInit__signal.
As the python developer can't control how the program is started, it may be better to setup default_int_handler regardless the handler type.

And initially SIG_INT is mapped to default_int_handler but once signal.signal is called, the mapping is lost even though the SIG_DFL is specified.
It may need to handle SIG_INT specially in signal_signal_impl as well to keep the consistent behavior.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23395>
_______________________________________

From report at bugs.python.org  Thu Dec  8 22:07:30 2016
From: report at bugs.python.org (Wataru Matsumoto)
Date: Fri, 09 Dec 2016 03:07:30 +0000
Subject: [issue28914] selectmodule build fails
In-Reply-To: <1481243721.04.0.91028253928.issue28914@psf.upfronthosting.co.za>
Message-ID: <1481252850.24.0.391632620768.issue28914@psf.upfronthosting.co.za>


Wataru Matsumoto added the comment:

I'm using Red Hat Enterprise.
cat /proc/version 
Linux version 2.6.18-238.9.1.el5 (mockbuild at x86-002.build.bos.redhat.com) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-50)) #1 SMP Fri Mar 18 12:42:39 EDT 2011

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28914>
_______________________________________

From report at bugs.python.org  Thu Dec  8 22:20:11 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 09 Dec 2016 03:20:11 +0000
Subject: [issue28835] Change in behavior when overriding warnings.showwarning
 and with catch_warnings(record=True)
In-Reply-To: <1480465767.99.0.401403947818.issue28835@psf.upfronthosting.co.za>
Message-ID: <1481253611.29.0.743068004504.issue28835@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

If the intended reference was to #28897, then yes, it was related: NumPy had introduced a workaround for the regression that existed in the beta releases (presumably thinking it was an intentional change that just hadn't been added to the porting guide yet), and this fix for the regression broke their workaround.

Reverting the workaround on the NumPy side restored compatibility :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28835>
_______________________________________

From report at bugs.python.org  Thu Dec  8 23:52:21 2016
From: report at bugs.python.org (Decorater)
Date: Fri, 09 Dec 2016 04:52:21 +0000
Subject: [issue28902] 3.6.0rc1 installer fails to install / uninstall.
In-Reply-To: <1481178281.99.0.0821886789548.issue28902@psf.upfronthosting.co.za>
Message-ID: <1481259141.71.0.270380700092.issue28902@psf.upfronthosting.co.za>


Decorater added the comment:

Ah I know what the problem is now. It is the fact that the 32 Bit Webinstaller does not check to see if a 64 bit version is installed at the folder that the 32 bit version is set to to uninstall the 64 bit version 1st thereby it overwrites the data to the 36 bit install without removing the registry entries for the 64 bit install. Thereby why I cant uninstall, repair, or even reinstall the 64 bit version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28902>
_______________________________________

From report at bugs.python.org  Thu Dec  8 23:54:48 2016
From: report at bugs.python.org (Eric Appelt)
Date: Fri, 09 Dec 2016 04:54:48 +0000
Subject: [issue28091] Document PEP 525
In-Reply-To: <1480969186.28.0.879526881588.issue28091@psf.upfronthosting.co.za>
Message-ID: <1481259288.58.0.348260724225.issue28091@psf.upfronthosting.co.za>


Eric Appelt added the comment:

I think this needs considerable checking and polishing, but I am submitting this "Work In Progress" patch for the PEP525 and PEP530 documentation so that I can get some general feedback since I am new to this, and to ensure that if this is not generally what was needed or expected I don't delay the effort.

I tried to start where possible by using the wording in corresponding generator sections, so this may err on the side of redundant phrasing, which I can change.

I had some difficulty with the following points, and am not sure if they merit opening other tickets:

1. In PEP525 the documentation for aclose() is a bit terse and unclear to me. It appeared to suggest that you could catch GeneratorExit and yield, but I found this to result in a RuntimeError like a normal generator. I tried to document this as it actually behaves.

2. One thing that I noticed documented about normal generators is that they raise a ValueError if you try to run send() while another send() call is currently running. I verified this using threads. I looked into corresponding behavior for asynchronous generators, calling asend(), running the awaitable halfway through, and then calling asend() again to get a second awaitable before the first one finished. Asyncio seems to prevent more than one awaitable from a single async generator running at the same time, but I couldn't figure out how. Running some coroutines "by hand" calling asend() and send(), I was permitted to run multiple awaitables concurrently which produced odd results.

I did not attempt to document the behavior in (2) in the submitted patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file45809/pep525_pep530_docs_WIP.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28091>
_______________________________________

From report at bugs.python.org  Fri Dec  9 00:18:30 2016
From: report at bugs.python.org (Joshua Bronson)
Date: Fri, 09 Dec 2016 05:18:30 +0000
Subject: [issue28912] collections.abc.OrderedMapping
In-Reply-To: <1481238034.34.0.119082165821.issue28912@psf.upfronthosting.co.za>
Message-ID: <1481260710.25.0.228215629872.issue28912@psf.upfronthosting.co.za>


Joshua Bronson added the comment:

Come to think of it, to be exact, rather than extending Reversible, OrderedMapping could extend a narrower interface, something like collections.abc.Ordered, along with extending Mapping. (Reversible implies Ordered, but Ordered does not imply Reversible: a singly-linked list is Ordered but not Reversible, for example.)

I guess we don't currently have Ordered because it wouldn't necessarily add any abstractmethods beyond what Iterable already provides. But it could provide a generic, concrete __eq__ implementation, something like:

class Ordered(Iterable):
    def __eq__(self, other):
        if not isinstance(other, Ordered):
            return NotImplemented
        return all(i == j for (i, j) in zip(self, other))


which is not something that any existing collections.abc Iterable currently provides.

Even if an Ordered interface that's totally empty were available in the standard library, then Iterables across diparate codebases could opt into extending it as a standard signal that they iterate over their elements in a well-defined order, and could participate in other polymorphic code. Currently we have no such standard signal, do we?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28912>
_______________________________________

From report at bugs.python.org  Fri Dec  9 00:20:41 2016
From: report at bugs.python.org (woo yoo)
Date: Fri, 09 Dec 2016 05:20:41 +0000
Subject: [issue28916] Not matched behavior of modulo operator % with the
 description of the documentation
Message-ID: <1481260841.6.0.53772469659.issue28916@psf.upfronthosting.co.za>


New submission from woo yoo:

Mismatch occurs within the "Notes" section,row 1.Here is the link:https://docs.python.org/3/library/stdtypes.html#old-string-formatting

The course of coding shows below:
>>>'%#07o' % 1223
Result value is '0o02307',which is not in line with the description.

Description is "The alternate form causes a leading zero ('0') to be inserted between left-hand padding and the formatting of the number if the leading character of the result is not already a zero."

----------
assignee: docs at python
components: Documentation
messages: 282762
nosy: docs at python, woo yoo
priority: normal
severity: normal
status: open
title: Not matched behavior of modulo operator % with the description of the documentation
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28916>
_______________________________________

From report at bugs.python.org  Fri Dec  9 00:33:44 2016
From: report at bugs.python.org (Joshua Bronson)
Date: Fri, 09 Dec 2016 05:33:44 +0000
Subject: [issue28912] collections.abc.OrderedMapping
In-Reply-To: <1481238034.34.0.119082165821.issue28912@psf.upfronthosting.co.za>
Message-ID: <1481261624.51.0.297536787506.issue28912@psf.upfronthosting.co.za>


Joshua Bronson added the comment:

I only just found the "[Python-ideas] Adding collections.abc.Ordered" thread at https://mail.python.org/pipermail/python-ideas/2015-November/037146.html - sorry for not seeing it sooner. Looking forward to catching up on what I missed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28912>
_______________________________________

From report at bugs.python.org  Fri Dec  9 00:34:59 2016
From: report at bugs.python.org (Anand Reddy Pandikunta)
Date: Fri, 09 Dec 2016 05:34:59 +0000
Subject: [issue28917] Docs: Add missing protocol to pickle
Message-ID: <1481261699.94.0.5034553243.issue28917@psf.upfronthosting.co.za>


New submission from Anand Reddy Pandikunta:

In Python 2.7, it is documented. It is missing in Python 3 documentation.

----------
assignee: docs at python
components: Documentation
files: docs_pickle_add_missing_protocol.patch
keywords: patch
messages: 282764
nosy: ChillarAnand, abz64, docs at python, r.david.murray
priority: normal
severity: normal
status: open
title: Docs: Add missing protocol to pickle
type: enhancement
versions: Python 3.7
Added file: http://bugs.python.org/file45810/docs_pickle_add_missing_protocol.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28917>
_______________________________________

From report at bugs.python.org  Fri Dec  9 01:08:05 2016
From: report at bugs.python.org (Steve Dower)
Date: Fri, 09 Dec 2016 06:08:05 +0000
Subject: [issue28902] 3.6.0rc1 installer fails to install / uninstall.
In-Reply-To: <1481178281.99.0.0821886789548.issue28902@psf.upfronthosting.co.za>
Message-ID: <1481263685.7.0.39916181341.issue28902@psf.upfronthosting.co.za>


Steve Dower added the comment:

Ah, did you change the default install directory to be the same as your previous install? Yeah, that's bad :) There's other registration information that we look at, so we don't even try and look at the existing files.

However, if you didn't change the directory, then that's a really bad bug on our side. But I think we'd be hearing many more issues if that was the problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28902>
_______________________________________

From report at bugs.python.org  Fri Dec  9 01:20:47 2016
From: report at bugs.python.org (Mariatta Wijaya)
Date: Fri, 09 Dec 2016 06:20:47 +0000
Subject: [issue28917] Docs: Add missing protocol to pickle
In-Reply-To: <1481261699.94.0.5034553243.issue28917@psf.upfronthosting.co.za>
Message-ID: <1481264447.16.0.335069741086.issue28917@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

Hi, isn't it documented here? 
https://docs.python.org/3.7/library/pickle.html#pickle.Pickler

"If a negative number is specified, HIGHEST_PROTOCOL is selected."

----------
nosy: +Mariatta

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28917>
_______________________________________

From report at bugs.python.org  Fri Dec  9 02:31:26 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 09 Dec 2016 07:31:26 +0000
Subject: [issue28916] Not matched behavior of modulo operator % with the
 description of the documentation
In-Reply-To: <1481260841.6.0.53772469659.issue28916@psf.upfronthosting.co.za>
Message-ID: <1481268686.11.0.227733454597.issue28916@psf.upfronthosting.co.za>


Martin Panter added the comment:

Looks like a leftover relic from Python 2. In Python 3, the prefix is ?0o?, not just ?0?. This matches to change in Python 2 to 3 octal literal syntax. And there is no special handling of zero in 3:

>>> "%#o" % 0
'0o0'

----------
nosy: +martin.panter
stage:  -> needs patch
versions: +Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28916>
_______________________________________

From report at bugs.python.org  Fri Dec  9 02:42:38 2016
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 09 Dec 2016 07:42:38 +0000
Subject: [issue28898] Can't compile gdb with Python 3.6
In-Reply-To: <1481134479.52.0.174259382887.issue28898@psf.upfronthosting.co.za>
Message-ID: <1481269358.91.0.16137450676.issue28898@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Why do you think this change caused that breakage? That bot looks like it's been broken for days. This change should have no behavior change whatsoever for Python itself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28898>
_______________________________________

From report at bugs.python.org  Fri Dec  9 03:08:21 2016
From: report at bugs.python.org (Anand Reddy Pandikunta)
Date: Fri, 09 Dec 2016 08:08:21 +0000
Subject: [issue28917] Docs: Add missing protocol to pickle
In-Reply-To: <1481261699.94.0.5034553243.issue28917@psf.upfronthosting.co.za>
Message-ID: <1481270901.77.0.63179547424.issue28917@psf.upfronthosting.co.za>


Anand Reddy Pandikunta added the comment:

Yes, Thanks.

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28917>
_______________________________________

From report at bugs.python.org  Fri Dec  9 03:36:23 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 09 Dec 2016 08:36:23 +0000
Subject: [issue26937] the chown() method of the tarfile.TarFile class fails on
 Android
In-Reply-To: <1462288467.92.0.772791237683.issue26937@psf.upfronthosting.co.za>
Message-ID: <20161209083620.73356.41456.8A47F3A0@psf.io>


Roundup Robot added the comment:

New changeset e4e7bc640865 by Xavier de Gaye in branch '3.6':
Issue #26937: The chown() method of the tarfile.TarFile class does not fail now
https://hg.python.org/cpython/rev/e4e7bc640865

New changeset da510d1aa683 by Xavier de Gaye in branch 'default':
Issue #26937: Merge 3.6.
https://hg.python.org/cpython/rev/da510d1aa683

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26937>
_______________________________________

From report at bugs.python.org  Fri Dec  9 03:51:23 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 09 Dec 2016 08:51:23 +0000
Subject: [issue28918] cross compiling xxlimited fails with "Py_LIMITED_API is
 incompatible with Py_DEBUG"
Message-ID: <1481273483.19.0.548102187262.issue28918@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

This happens when the cross compilation is done with '--with-pydebug' while the native interpeter used to run setup.py has been built without it. The error message is:
    Py_LIMITED_API is incompatible with Py_DEBUG, Py_TRACE_REFS, and Py_REF_DEBUG

----------
assignee: xdegaye
components: Cross-Build
messages: 282771
nosy: Alex.Willmer, doko, xdegaye
priority: normal
severity: normal
stage: needs patch
status: open
title: cross compiling xxlimited fails with "Py_LIMITED_API is incompatible with Py_DEBUG"
type: behavior
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28918>
_______________________________________

From report at bugs.python.org  Fri Dec  9 04:14:36 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 09 Dec 2016 09:14:36 +0000
Subject: [issue26937] the chown() method of the tarfile.TarFile class fails on
 Android
In-Reply-To: <1462288467.92.0.772791237683.issue26937@psf.upfronthosting.co.za>
Message-ID: <1481274876.21.0.0627182306414.issue26937@psf.upfronthosting.co.za>


Changes by Xavier de Gaye <xdegaye at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26937>
_______________________________________

From report at bugs.python.org  Fri Dec  9 05:03:28 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Dec 2016 10:03:28 +0000
Subject: [issue28898] Can't compile gdb with Python 3.6
In-Reply-To: <1481134479.52.0.174259382887.issue28898@psf.upfronthosting.co.za>
Message-ID: <1481277808.08.0.378532467769.issue28898@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Why do you think this change caused that breakage? That bot looks like it's been broken for days. This change should have no behavior change whatsoever for Python itself.

It's right that the buildbot is broken for years:
https://mail.python.org/pipermail/python-dev/2016-September/146538.html

But the error changed, since the build 37, tests started to fail with a very specific error: "Fatal Python error: Aborted". The build 37 contains your change 1afc3f4f5502 and two other changes which only modify the Doc/ directory.

Sorry, I don't know more :-/ Maybe it's a false alarm, but it's worth to investigate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28898>
_______________________________________

From report at bugs.python.org  Fri Dec  9 05:12:46 2016
From: report at bugs.python.org (Jiajun Huang)
Date: Fri, 09 Dec 2016 10:12:46 +0000
Subject: [issue28919] Simplify `_copy_func_details` in unittest.mock
Message-ID: <1481278366.66.0.0560230618441.issue28919@psf.upfronthosting.co.za>


Changes by Jiajun Huang <gansteed at gmail.com>:


----------
components: Library (Lib)
files: mock.patch
keywords: patch
nosy: Jiajun Huang
priority: normal
pull_requests: 2
severity: normal
status: open
title: Simplify `_copy_func_details` in unittest.mock
type: enhancement
versions: Python 3.7
Added file: http://bugs.python.org/file45811/mock.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28919>
_______________________________________

From report at bugs.python.org  Fri Dec  9 05:33:40 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 09 Dec 2016 10:33:40 +0000
Subject: [issue28918] cross compiling xxlimited fails with "Py_LIMITED_API is
 incompatible with Py_DEBUG"
In-Reply-To: <1481273483.19.0.548102187262.issue28918@psf.upfronthosting.co.za>
Message-ID: <1481279620.2.0.284986144545.issue28918@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Patch attached.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file45812/xxlimited_abiflags.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28918>
_______________________________________

From report at bugs.python.org  Fri Dec  9 06:23:05 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Dec 2016 11:23:05 +0000
Subject: [issue28918] cross compiling xxlimited fails with "Py_LIMITED_API is
 incompatible with Py_DEBUG"
In-Reply-To: <1481273483.19.0.548102187262.issue28918@psf.upfronthosting.co.za>
Message-ID: <1481282585.4.0.942475114325.issue28918@psf.upfronthosting.co.za>


STINNER Victor added the comment:

xxlimited_abiflags.patch LGTM.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28918>
_______________________________________

From report at bugs.python.org  Fri Dec  9 07:02:45 2016
From: report at bugs.python.org (Ivan Pozdeev)
Date: Fri, 09 Dec 2016 12:02:45 +0000
Subject: [issue25458] ftplib: command response shift - mismatch
In-Reply-To: <1445510152.74.0.829316001802.issue25458@psf.upfronthosting.co.za>
Message-ID: <1481284965.04.0.704898504518.issue25458@psf.upfronthosting.co.za>


Changes by Ivan Pozdeev <ivan_pozdeev at mail.ru>:


----------
nosy: +Ivan.Pozdeev
versions: +Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25458>
_______________________________________

From report at bugs.python.org  Fri Dec  9 07:16:32 2016
From: report at bugs.python.org (Ivan Pozdeev)
Date: Fri, 09 Dec 2016 12:16:32 +0000
Subject: [issue25458] ftplib: command response shift - mismatch
In-Reply-To: <1445510152.74.0.829316001802.issue25458@psf.upfronthosting.co.za>
Message-ID: <1481285792.6.0.966197751715.issue25458@psf.upfronthosting.co.za>


Ivan Pozdeev added the comment:

The current solution looks fishy to me. We should stick to https://tools.ietf.org/html/rfc959 . In particular, 226 is sent when the server closes the auxiliary socket, so the module should react accordingly. Debug printing and/or issuing warnings is an obvious no-go.

Also attached a text file illustrating the problem.

----------
Added file: http://bugs.python.org/file45813/ftp_error_illustration.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25458>
_______________________________________

From report at bugs.python.org  Fri Dec  9 07:34:56 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 09 Dec 2016 12:34:56 +0000
Subject: [issue25711] Rewrite zipimport from scratch
In-Reply-To: <1448296120.48.0.872112518039.issue25711@psf.upfronthosting.co.za>
Message-ID: <1481286896.98.0.241741949068.issue25711@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Got rid of dependencies from os, stat and encodings.

----------
Added file: http://bugs.python.org/file45814/zipimport-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25711>
_______________________________________

From report at bugs.python.org  Fri Dec  9 08:16:50 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Dec 2016 13:16:50 +0000
Subject: [issue25711] Rewrite zipimport from scratch
In-Reply-To: <1448296120.48.0.872112518039.issue25711@psf.upfronthosting.co.za>
Message-ID: <1481289410.2.0.650959143224.issue25711@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Here is preliminary translation of zipimport to Python. It is not frozen and imports other modules.

Technically, will it be possible to freeze it? It seems useful to keep the ability to put the whole stdlib into a single ZIP. Using a ZIP is sometimes suggested to avoid fstat() on disk for example, to speedup Python startup.

But I also understand that the C code is painful to maintain and update.

Anyway, nice job Serhiy :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25711>
_______________________________________

From report at bugs.python.org  Fri Dec  9 08:38:13 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Dec 2016 13:38:13 +0000
Subject: [issue28920] Dangerous usage of "O" format string in _asynciomodule.c
Message-ID: <1481290693.49.0.157975678284.issue28920@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The new _asyncio module of Python 3.6 uses the _PyObject_CallMethodId() function to call functions. This function has a weird behaviour when using the format string "O": if the object is a tuple, the tuple is unpacked.

_PyObject_CallMethodId(obj, &PyId_meth, "O", tuple, NULL) calls obj.meth(*tuple) instead of obj.meth(tuple).

I only found one function which may have the bug: task_call_step(). But it seems like this function cannot be called with a tuple as "arg", only with an exception object.

But just in case, I would suggest to replace:
   _PyObject_CallMethodId(obj, nameid, "O", arg);
with
   _PyObject_CallMethodIdObjArgs(obj, nameid, arg, NULL);

Note: _PyObject_CallMethodId() is called with a NULL terminal in the argument list, but the NULL is useless. A terminator is only required by _PyObject_CallMethodIdObjArgs(). Yeah, Python has a wide choice of functions to call a callable object, with funny APIs... And I'm adding new ones to Python 3.7 ;-)

----------
components: asyncio
messages: 282778
nosy: gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: Dangerous usage of "O" format string in _asynciomodule.c
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28920>
_______________________________________

From report at bugs.python.org  Fri Dec  9 08:38:38 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Dec 2016 13:38:38 +0000
Subject: [issue28920] Dangerous usage of "O" format string in _asynciomodule.c
In-Reply-To: <1481290693.49.0.157975678284.issue28920@psf.upfronthosting.co.za>
Message-ID: <1481290718.59.0.876133449242.issue28920@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Previous similar bug in generators: issue #21209.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28920>
_______________________________________

From report at bugs.python.org  Fri Dec  9 08:43:19 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 09 Dec 2016 13:43:19 +0000
Subject: [issue28915] Modify PyObject_CallFunction() to use fast call
 internally
In-Reply-To: <1481245654.11.0.143889949597.issue28915@psf.upfronthosting.co.za>
Message-ID: <20161209134316.14399.58594.76055BEA@psf.io>


Roundup Robot added the comment:

New changeset 39bed12135c1 by Victor Stinner in branch 'default':
Issue #28915: Use _PyObject_CallNoArg()
https://hg.python.org/cpython/rev/39bed12135c1

New changeset b29c719d5992 by Victor Stinner in branch 'default':
Use _PyObject_CallMethodIdObjArgs() in _asyncio
https://hg.python.org/cpython/rev/b29c719d5992

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28915>
_______________________________________

From report at bugs.python.org  Fri Dec  9 08:44:17 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Dec 2016 13:44:17 +0000
Subject: [issue28920] Dangerous usage of "O" format string in _asynciomodule.c
In-Reply-To: <1481290693.49.0.157975678284.issue28920@psf.upfronthosting.co.za>
Message-ID: <1481291057.67.0.68624507486.issue28920@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The issue was in fixed in Python 3.7 with a change made for optimization, not directly to fix this issue:

changeset:   105547:b29c719d5992
tag:         tip
user:        Victor Stinner <victor.stinner at gmail.com>
date:        Fri Dec 09 14:24:02 2016 +0100
files:       Modules/_asynciomodule.c
description:
Use _PyObject_CallMethodIdObjArgs() in _asyncio

Issue #28915: Replace _PyObject_CallMethodId() with
_PyObject_CallMethodIdObjArgs() when the format string was only made of "O"
formats, PyObject* arguments.

_PyObject_CallMethodIdObjArgs() avoids the creation of a temporary tuple and
doesn't have to parse a format string.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28920>
_______________________________________

From report at bugs.python.org  Fri Dec  9 08:44:55 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Fri, 09 Dec 2016 13:44:55 +0000
Subject: [issue28190] Detect curses headers correctly for cross-compiling
In-Reply-To: <1474132808.23.0.788365161086.issue28190@psf.upfronthosting.co.za>
Message-ID: <1481291095.75.0.0505975218545.issue28190@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

> second issue is that you apparently don't do the changes for term.h

term.h is included only if ncurses is missing and the system (SysV) curses is used, so I didn't change it. See below:

#ifdef __sgi
#include <term.h>
#endif

#ifdef HAVE_NCURSES_H
#include <ncurses.h>
#else
#include <curses.h>
#ifdef HAVE_TERM_H
/* for tigetstr, which is not declared in SysV curses */
#include <term.h>
#endif
#endif


> Third issue is that you can't make these changes for third party extensions

Did you mean 3rd party extensions that include py_curses.h may get broken with this patch? IMO they shouldn't include this as it's CPython's implementation detail and shouldn't be used outside Modules/_cursesmodule.c and Modules/_curses_panel.c

> however the ncursesw installation can be found in <prefix>/include instead

This is what I want to solve at the first place - make _curses compatible with different configurations. In configure.ac, there's a line:

AC_CHECK_HEADERS(curses.h ncurses.h ncursesw/ncurses.h ncurses/ncurses.h panel.h ncursesw/panel.h ncurses/panel.h)

> so you apparently can assume that this directory name is fixed *iff* it exists

Did you mean there's no need to check panel.h? I'll try to update the patch.


There's something missing from this patch: if ncurses is built with --enable-reentrant, the library and include paths get an additional 't'. For example, the library name becomes libncursestw.so and includedir becomes $prefix/include/ncursestw. Note that 't' comes before 'w' as ncurses's configure.in handles --enable-widec before --enable-reentrant. I skip such cases as --enable-reentrant is not compatible with Modules/_cursesmodule.c yet (issue25720). I'd like to postpone it until issue25720 is resolved as it does not make sense to detect incompatible header paths.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28190>
_______________________________________

From report at bugs.python.org  Fri Dec  9 08:45:42 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Dec 2016 13:45:42 +0000
Subject: [issue28920] Dangerous usage of "O" format string in _asynciomodule.c
In-Reply-To: <1481290693.49.0.157975678284.issue28920@psf.upfronthosting.co.za>
Message-ID: <1481291142.15.0.300443930955.issue28920@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Minimum patch for Python 3.6: only modify calls using the "O" format.

----------
keywords: +patch
Added file: http://bugs.python.org/file45815/_asyncio.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28920>
_______________________________________

From report at bugs.python.org  Fri Dec  9 09:38:24 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 09 Dec 2016 14:38:24 +0000
Subject: [issue28921] Make str.count one character for latin1 string faster
Message-ID: <1481294304.37.0.437308839314.issue28921@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

I make a try to improve str.count one character for latin1 string. From benchmark, it could enhance the speed depending on the length of the string.

# short one, a little regression
./python3 -m perf timeit --compare-to ~/cpython/python -s 's="abcdefg"' 's.count("a")'
python: ..................... 190 ns +- 1 ns
python3: ..................... 197 ns +- 2 ns

Median +- std dev: [python] 190 ns +- 1 ns -> [python3] 197 ns +- 2 ns: 1.04x slower

# a little longer
./python3 -m perf timeit --compare-to ~/cpython/python -s 's="abcdefghi"' 's.count("a")'
python: ..................... 192 ns +- 15 ns
python3: ..................... 184 ns +- 2 ns

Median +- std dev: [python] 192 ns +- 15 ns -> [python3] 184 ns +- 2 ns: 1.05x faster

# longer
./python3 -m perf timeit --compare-to ~/cpython/python -s 's="abcdefghihijklmnopqrstuvwxyz~!@##$%^&*()-=_+{}|"' 's.count("a")'
python: ..................... 236 ns +- 12 ns
python3: ..................... 209 ns +- 9 ns

Median +- std dev: [python] 236 ns +- 12 ns -> [python3] 209 ns +- 9 ns: 1.13x faster

# very long
./python3 -m perf timeit --compare-to ~/cpython/python -s 's="abcdefgHijk"*100' 's.count("z")'
python: ..................... 1.02 us +- 0.00 us
python3: ..................... 610 ns +- 1 ns

Median +- std dev: [python] 1.02 us +- 0.00 us -> [python3] 610 ns +- 1 ns: 1.67x faster

And since str.replace may also go through the code path involving count, it's somewhat affected:

./python3 -m perf timeit --compare-to ~/cpython/python -s 's="abcdefghihijklmnopqrstuvwxyz~!@##$%^&*()-=_+{}|"' 's.replace("a", "ccc")'
python: ..................... 318 ns +- 31 ns
python3: ..................... 298 ns +- 19 ns

Median +- std dev: [python] 318 ns +- 31 ns -> [python3] 298 ns +- 19 ns: 1.07x faster

For ucs2 and ucs4, the benchmarks are not appealing so leave them untouched.

----------
components: Interpreter Core
files: latin1-str-count-one-character.patch
keywords: patch
messages: 282784
nosy: haypo, serhiy.storchaka, xiang.zhang
priority: normal
severity: normal
stage: patch review
status: open
title: Make str.count one character for latin1 string faster
type: enhancement
versions: Python 3.7
Added file: http://bugs.python.org/file45816/latin1-str-count-one-character.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28921>
_______________________________________

From report at bugs.python.org  Fri Dec  9 09:53:28 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Dec 2016 14:53:28 +0000
Subject: [issue28921] Make str.count one character for latin1 string faster
In-Reply-To: <1481294304.37.0.437308839314.issue28921@psf.upfronthosting.co.za>
Message-ID: <1481295208.95.0.470461654349.issue28921@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Hum, Serhiy is better than me to review such hardcore C code :-) I let him review the patch ;-)

> short one, a little regression

In stringlib, the usual solution is to use a threshold: use a dummy loop for less than N bytes, otherwise use the ultra-optimized loop. Serhiy event implemented a "dynamic" threshold in some functions, when too many false positive are found. I don't recall where.

"And since str.replace may also go through the code path involving count, it's somewhat affected: (...) 1.07x faster"

I'm not really excited by optimizing str.count, since I don't think that this function is commonly used. But if str.replace is made faster, I'm interested :-)

I understand that count() is only used when the old and new patterns of str.replace() have a different length.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28921>
_______________________________________

From report at bugs.python.org  Fri Dec  9 10:31:43 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 09 Dec 2016 15:31:43 +0000
Subject: [issue28915] Modify PyObject_CallFunction() to use fast call
 internally
In-Reply-To: <1481245654.11.0.143889949597.issue28915@psf.upfronthosting.co.za>
Message-ID: <20161209153139.117179.42744.AD85154D@psf.io>


Roundup Robot added the comment:

New changeset 807688539b56 by Victor Stinner in branch 'default':
Fix refleak introduced in change 032cbdb596fe
https://hg.python.org/cpython/rev/807688539b56

New changeset ceb22b8f6d32 by Victor Stinner in branch 'default':
Use _PyObject_CallMethodIdObjArgs() in _ctypes
https://hg.python.org/cpython/rev/ceb22b8f6d32

New changeset ef05cc5cc651 by Victor Stinner in branch 'default':
Use _PyObject_CallMethodIdObjArgs() in _elementtree
https://hg.python.org/cpython/rev/ef05cc5cc651

New changeset 5b41b92a7ccf by Victor Stinner in branch 'default':
Use _PyObject_CallMethodIdObjArgs() in _datetime
https://hg.python.org/cpython/rev/5b41b92a7ccf

New changeset 434e76e0ee17 by Victor Stinner in branch 'default':
Use _PyObject_CallMethodIdObjArgs() in _io
https://hg.python.org/cpython/rev/434e76e0ee17

New changeset 4545a2293e01 by Victor Stinner in branch 'default':
Use _PyObject_CallMethodIdObjArgs()
https://hg.python.org/cpython/rev/4545a2293e01

New changeset 4321f833a4e0 by Victor Stinner in branch 'default':
Use PyObject_CallFunctionObjArgs()
https://hg.python.org/cpython/rev/4321f833a4e0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28915>
_______________________________________

From report at bugs.python.org  Fri Dec  9 10:36:53 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 09 Dec 2016 15:36:53 +0000
Subject: [issue28912] collections.abc.OrderedMapping
In-Reply-To: <1481238034.34.0.119082165821.issue28912@psf.upfronthosting.co.za>
Message-ID: <1481297813.71.0.629999141757.issue28912@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
nosy:  -gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28912>
_______________________________________

From report at bugs.python.org  Fri Dec  9 11:11:44 2016
From: report at bugs.python.org (ProgVal)
Date: Fri, 09 Dec 2016 16:11:44 +0000
Subject: [issue28922] Add fixer for "import exceptions"
Message-ID: <1481299904.08.0.332005358401.issue28922@psf.upfronthosting.co.za>


New submission from ProgVal:

Hi,

Here is a fixer to remove "import exceptions" from Python 2 code and replace "exceptions.X" with "X".

Valentin

----------
components: 2to3 (2.x to 3.x conversion tool)
files: fix_import_exceptions.py
messages: 282787
nosy: Valentin.Lorentz
priority: normal
severity: normal
status: open
title: Add fixer for "import exceptions"
type: enhancement
versions: Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45817/fix_import_exceptions.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28922>
_______________________________________

From report at bugs.python.org  Fri Dec  9 11:23:49 2016
From: report at bugs.python.org (Marco Buttu)
Date: Fri, 09 Dec 2016 16:23:49 +0000
Subject: [issue27200] make doctest in CPython has failures
In-Reply-To: <1464988408.0.0.840317371896.issue27200@psf.upfronthosting.co.za>
Message-ID: <1481300629.65.0.75084737534.issue27200@psf.upfronthosting.co.za>


Marco Buttu added the comment:

I isolated all snippets in the unittest.mock documentation, and now all doctests pass without surprises :-)

----------
Added file: http://bugs.python.org/file45818/issue27200_3rd.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27200>
_______________________________________

From report at bugs.python.org  Fri Dec  9 11:28:57 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Dec 2016 16:28:57 +0000
Subject: [issue28915] Modify PyObject_CallFunction() to use fast call
 internally
In-Reply-To: <1481245654.11.0.143889949597.issue28915@psf.upfronthosting.co.za>
Message-ID: <1481300937.08.0.267749985947.issue28915@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The main feature was implemented, so I close the issue.

Enjoy faster slots! (Many other less important functions are also faster.)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28915>
_______________________________________

From report at bugs.python.org  Fri Dec  9 11:42:29 2016
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 09 Dec 2016 16:42:29 +0000
Subject: [issue27200] make doctest in CPython has failures
In-Reply-To: <1464988408.0.0.840317371896.issue27200@psf.upfronthosting.co.za>
Message-ID: <1481301749.43.0.122977356034.issue27200@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
assignee: Jelle Zijlstra -> 
stage:  -> patch review
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27200>
_______________________________________

From report at bugs.python.org  Fri Dec  9 12:20:34 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 09 Dec 2016 17:20:34 +0000
Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13
 files
In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za>
Message-ID: <20161209172031.99494.98117.F282A1B6@psf.io>


Roundup Robot added the comment:

New changeset c62352ec21bc by Victor Stinner in branch 'default':
Issue #20185: Convert _warnings.warn() to Argument Clinic
https://hg.python.org/cpython/rev/c62352ec21bc

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20185>
_______________________________________

From report at bugs.python.org  Fri Dec  9 12:21:10 2016
From: report at bugs.python.org (Ivan Pozdeev)
Date: Fri, 09 Dec 2016 17:21:10 +0000
Subject: [issue28923] Nonexisting encoding specified in Tix.py
Message-ID: <1481304070.27.0.11719456506.issue28923@psf.upfronthosting.co.za>


New submission from Ivan Pozdeev:

$ head 'c:\Py\Lib\lib-tk\Tix.py' -n 1
# -*-mode: python; fill-column: 75; tab-width: 8; coding: iso-latin-1-unix -*-

There's no "iso-latin-1-unix" encoding in Python, so this declaration produces an error in some code analysis tools (I have it in PyScripter), as it should according to PEP263 .

In 3.x, this was fixed in changeset d63344ba187888b6792ba8362a0dd09e06ed2f9a .

----------
components: Library (Lib)
files: 105052.patch
keywords: patch
messages: 282791
nosy: Ivan.Pozdeev
priority: normal
severity: normal
status: open
title: Nonexisting encoding specified in Tix.py
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file45819/105052.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28923>
_______________________________________

From report at bugs.python.org  Fri Dec  9 12:32:08 2016
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 09 Dec 2016 17:32:08 +0000
Subject: [issue28425] Python3 ignores __init__.py that are links to /dev/null
In-Reply-To: <1476317932.87.0.807629965942.issue28425@psf.upfronthosting.co.za>
Message-ID: <1481304728.38.0.411128702557.issue28425@psf.upfronthosting.co.za>


Brett Cannon added the comment:

There's probably a place to mention it in the language spec for import and/or importlib.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28425>
_______________________________________

From report at bugs.python.org  Fri Dec  9 12:33:11 2016
From: report at bugs.python.org (Ivan Pozdeev)
Date: Fri, 09 Dec 2016 17:33:11 +0000
Subject: [issue25458] ftplib: command response shift - mismatch
In-Reply-To: <1445510152.74.0.829316001802.issue25458@psf.upfronthosting.co.za>
Message-ID: <1481304791.23.0.80268576691.issue25458@psf.upfronthosting.co.za>


Ivan Pozdeev added the comment:

Found the root problem: a 1xx response doesn't complete a LIST command, it should wait further for a 2xx one. See RFC 959 section 6 (state diagrams).

This could be `urllib`'s rather than `ftplib`'s fault: the former calls low-level subroutines of the latter.

----------
Added file: http://bugs.python.org/file45820/ftp_error_illustration.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25458>
_______________________________________

From report at bugs.python.org  Fri Dec  9 12:33:20 2016
From: report at bugs.python.org (Ivan Pozdeev)
Date: Fri, 09 Dec 2016 17:33:20 +0000
Subject: [issue25458] ftplib: command response shift - mismatch
In-Reply-To: <1445510152.74.0.829316001802.issue25458@psf.upfronthosting.co.za>
Message-ID: <1481304800.72.0.318545109439.issue25458@psf.upfronthosting.co.za>


Changes by Ivan Pozdeev <ivan_pozdeev at mail.ru>:


Removed file: http://bugs.python.org/file45813/ftp_error_illustration.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25458>
_______________________________________

From report at bugs.python.org  Fri Dec  9 13:00:50 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 09 Dec 2016 18:00:50 +0000
Subject: [issue28924] Inline PyEval_EvalFrameEx() in callers
Message-ID: <1481306450.73.0.124326033178.issue28924@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Inline PyEval_EvalFrameEx() in callers. The PEP 523 modified PyEval_EvalFrameEx(): it's now an indirection to interp->eval_frame().

Inline the call in performance critical code. Leave PyEval_EvalFrame() unchanged, this function is only kept for backward compatibility (and so not important for performance).

I pushed directly my change as the revision 99c34e47348b, but it broke test_gdb. So now I doubt that it's 100% "safe" to inline the code. Outside test_gdb, does something else rely on PyEval_EvalFrameEx()? So I chose to open an issue to discuss the change. By "something", I'm thinking to Pyjion :-)

Attached patch updates also python-gdb.py to fix test_gdb.

----------
files: inline_evalframeex.patch
keywords: patch
messages: 282794
nosy: brett.cannon, haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Inline PyEval_EvalFrameEx() in callers
type: performance
versions: Python 3.7
Added file: http://bugs.python.org/file45821/inline_evalframeex.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28924>
_______________________________________

From report at bugs.python.org  Fri Dec  9 13:11:16 2016
From: report at bugs.python.org (Raoul Gough)
Date: Fri, 09 Dec 2016 18:11:16 +0000
Subject: [issue28925] Confusing exception from cPickle on reduce failure
Message-ID: <1481307076.91.0.720116511602.issue28925@psf.upfronthosting.co.za>


New submission from Raoul Gough:

Description
===========

Running the attached example program with Python 2.7.12 produces the output below. The demo deliberately raises a user-defined exception during the unpickling process, but the problem is that this exception does not propagate out of the unpickle call. Instead, it gets converted into a TypeError which is confusing and does not help identify the original problem.

INFO:root:Creating BadReduce object
INFO:root:Pickling
INFO:root:Unpickling
INFO:root:Raising exception "BadReduce init failed"
Traceback (most recent call last):
  File "cpickle_reduce_failure.py", line 48, in <module>
    main()
  File "cpickle_reduce_failure.py", line 41, in main
    pickler.loads(s1)
  File "cpickle_reduce_failure.py", line 27, in __init__
    raise exception
TypeError: __init__() takes exactly 2 arguments (4 given)

If you change the demo to use the Python pickle module, i.e. "import pickle as pickler", it produces the expected output below:

INFO:root:Creating BadReduce object
INFO:root:Pickling
INFO:root:Unpickling
INFO:root:Raising exception "BadReduce init failed"
INFO:root:Got MyException "BadReduce init failed"
INFO:root:Done

Analysis
========

The following code in Modules/cPickle.c in the function Instance_New (around https://github.com/python/cpython/blob/2.7/Modules/cPickle.c#L3917) does a PyErr_Restore with the exception type MyException, as raised from BadReduce.__init__, but it replaces the exception value with a tuple (original_exception, cls, args):

        PyObject *tp, *v, *tb, *tmp_value;

        PyErr_Fetch(&tp, &v, &tb);
        tmp_value = v;
        /* NULL occurs when there was a KeyboardInterrupt */
        if (tmp_value == NULL)
            tmp_value = Py_None;
        if ((r = PyTuple_Pack(3, tmp_value, cls, args))) {
            Py_XDECREF(v);
            v=r;
        }
        PyErr_Restore(tp,v,tb);

Later, PyErr_NormalizeException attempts to convert the exception value (the tuple) to the original exception type. This fails because MyException.__init__() can't handle the multiple arguments. This is what produces the TypeError "__init__() takes exactly 2 arguments (4 given)"


Proposed Fix
============

I think it would be better if Instance_New did the PyErr_NormalizeException itself instead of allowing it to be done lazily. If the normalize works, i.e. the exception type accepts the extra arguments, the behaviour would be almost unchanged - the only difference being the PyErr_NormalizeException happens earlier. However, if the normalize fails, Instance_New can restore the original exception unchanged. That means that we lose the cls, args information in this case, but not the original exception.

----------
components: Library (Lib)
files: cpickle_reduce_failure.py
messages: 282795
nosy: raoul_gough_baml
priority: normal
severity: normal
status: open
title: Confusing exception from cPickle on reduce failure
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file45822/cpickle_reduce_failure.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28925>
_______________________________________

From report at bugs.python.org  Fri Dec  9 13:45:26 2016
From: report at bugs.python.org (Ivan Pozdeev)
Date: Fri, 09 Dec 2016 18:45:26 +0000
Subject: [issue25458] ftplib: command response shift - mismatch
In-Reply-To: <1445510152.74.0.829316001802.issue25458@psf.upfronthosting.co.za>
Message-ID: <1481309126.17.0.566001043114.issue25458@psf.upfronthosting.co.za>


Ivan Pozdeev added the comment:

Darn, my problem _is_ in urllib and thus is different that the one in this ticket. Though it too results in a "command response shift".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25458>
_______________________________________

From report at bugs.python.org  Fri Dec  9 14:09:00 2016
From: report at bugs.python.org (Ivan Pozdeev)
Date: Fri, 09 Dec 2016 19:09:00 +0000
Subject: [issue25458] ftplib: command response shift - mismatch
In-Reply-To: <1445510152.74.0.829316001802.issue25458@psf.upfronthosting.co.za>
Message-ID: <1481310540.43.0.289514798463.issue25458@psf.upfronthosting.co.za>


Ivan Pozdeev added the comment:

The solution for the OP's problem is:

* after closing the data socket (whether it was returned by `transfercmd()'/`ntransfercmd()' or opened manually), an additional `FTP.getresp()'/`FTP.voidresp()' is required to process the 226 response.

The built-in `retrbinary()' and `retrlines()' do implement this logic.

But the documentation doesn't mention this requirement in `transfercmd()'/ntransfercmd()` entries (and `getresp()'/`voidresp()' are undocumented outright).

`urllib' authors have fallen into this same trap: they use `transfercmd' directly but don't call `voidresp()' afterwards.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25458>
_______________________________________

From report at bugs.python.org  Fri Dec  9 14:14:08 2016
From: report at bugs.python.org (Cathy Avery)
Date: Fri, 09 Dec 2016 19:14:08 +0000
Subject: [issue27584] New addition of vSockets to the python socket module
In-Reply-To: <1469115390.74.0.838831983223.issue27584@psf.upfronthosting.co.za>
Message-ID: <1481310848.67.0.636700939819.issue27584@psf.upfronthosting.co.za>


Cathy Avery added the comment:

Is there anything else that is needed for this patch?

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27584>
_______________________________________

From report at bugs.python.org  Fri Dec  9 14:29:58 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 09 Dec 2016 19:29:58 +0000
Subject: [issue28922] Add fixer for "import exceptions"
In-Reply-To: <1481299904.08.0.332005358401.issue28922@psf.upfronthosting.co.za>
Message-ID: <1481311798.74.0.433285458654.issue28922@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the report and for the patch! This is a duplicate of issue 2350.

Note that we accept patches from hg.python.org, not standalone Python files. See http://cpython-devguide.readthedocs.io/en/latest/patch.html for details.

----------
nosy: +berker.peksag
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> 'exceptions' import fixer

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28922>
_______________________________________

From report at bugs.python.org  Fri Dec  9 14:33:28 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 09 Dec 2016 19:33:28 +0000
Subject: [issue28921] Make str.count one character for latin1 string faster
In-Reply-To: <1481294304.37.0.437308839314.issue28921@psf.upfronthosting.co.za>
Message-ID: <1481312008.07.0.341994225324.issue28921@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

> I understand that count() is only used when the old and new patterns of str.replace() have a different length.

Yes. I thought it won't help much since str.replace get many operations. But for long string, looks good:

./python3 -m perf timeit --compare-to ~/cpython/python -s 's="abcdefghihijklmnopqrstuvwxyz~!@##$%^&*()-=_+{}|"*100' 's.replace("a", "bc")'
python: ..................... 7.36 us +- 0.04 us
python3: ..................... 4.91 us +- 0.04 us

Median +- std dev: [python] 7.36 us +- 0.04 us -> [python3] 4.91 us +- 0.04 us: 1.50x faster  # 50% ??!! how?

And this patch also applies to bytes since they share codes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28921>
_______________________________________

From report at bugs.python.org  Fri Dec  9 15:02:31 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 09 Dec 2016 20:02:31 +0000
Subject: [issue28882] Slice confusing with negative stop and strides and the
 0th element.
In-Reply-To: <1481000800.36.0.0535087899648.issue28882@psf.upfronthosting.co.za>
Message-ID: <1481313751.87.0.375079393085.issue28882@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Steven, your initial 'sentence' is missing something needed to make it a proper English sentence, and I cannot exactly guess what you meant.  But your later confusion is clear enough.

This tracker is for patching the Python docs and CPython code.  I believe the entry for the slice function/class, https://docs.python.org/3/library/functions.html#slice, could be improved.

First the word 'slice' is linked to the Glossary entry for 'slice'.  However, the latter is about subsequences, not about slice objects. It should instead link to the entry that contains the method description as https://docs.python.org/3/reference/datamodel.html#slice.indices.  (This is the target for the Index entry 'indices (slice method)'.  The 'slick objects' label needs to be made a target.

Second, the description "representing the set of indices specified by range(start, stop, step)" is only true when start and stop are valid non-negative indexes when applied to a particular sequence.  It is never true for negative values and not true when greater to or equal to the length of a particular sequence.  As the slice.indices entry says, 'Missing or out-of-bounds indices are handled in a manner consistent with regular slices."

In the example above, the issue is the negative stop, not the negative step.  Steven's problem was expecting the description to be true (whether or not he read it.)  It is worth noting, nowever, that reversed() was added because people had trouble using negative steps.  The following is much clearer than the corrected code above that the object is to separately reverse two haves of a list.

>>> n = 8
>>> a = range(8)
>>> [list(reversed(a[:n//2])), list(reversed(a[n//2:]))]
[[3, 2, 1, 0], [7, 6, 5, 4]]

As the Library Function entry hints, slice() is mainly intended for use internally and by 3rd-party extensions.

The description is even more wrong because the three arguments/attributes 'can have any type' (from the Data model slice object entry) whereas range arguments must be int-like.  (Allowing non-int-like arguments is for external extension use.)  In particular, slice(None) == slice(None, None) == slice(None, None, None) 'represents' all the indices of a particular sequence, in normal order, whereas None is not a valid argument for range().

I am not sure what replacement to propose.  I'd like to see if there is any previous discussion on the tracker.

A third and minor issue is that 'Numerical Python' should? be updated to "Numpy'.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, terry.reedy
stage:  -> needs patch
title: RFC: Slice confusing with negative strides and the 0th element. -> Slice confusing with negative stop and strides and the 0th element.
type: behavior -> 
versions: +Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28882>
_______________________________________

From report at bugs.python.org  Fri Dec  9 15:30:30 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 09 Dec 2016 20:30:30 +0000
Subject: [issue28091] Document PEP 525
In-Reply-To: <1480969186.28.0.879526881588.issue28091@psf.upfronthosting.co.za>
Message-ID: <1481315430.83.0.111300852359.issue28091@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> 1. In PEP525 the documentation for aclose() is a bit terse and unclear to me. It appeared to suggest that you could catch GeneratorExit and yield, but I found this to result in a RuntimeError like a normal generator. I tried to document this as it actually behaves.

Yes, it should result in a RuntimeError. What PEP 525 is trying to explain is that it's OK to do this (although 'finally' is better):

   async def gen():
      try:
         yield
      except GeneratorExit:
         await smth()
         # using 'yield' here will trigger a RuntimeError
         raise

> 2. One thing that I noticed documented about normal generators is that they raise a ValueError if you try to run send() while another send() call is currently running. I verified this using threads. I looked into corresponding behavior for asynchronous generators, calling asend(), running the awaitable halfway through, and then calling asend() again to get a second awaitable before the first one finished. Asyncio seems to prevent more than one awaitable from a single async generator running at the same time, but I couldn't figure out how. Running some coroutines "by hand" calling asend() and send(), I was permitted to run multiple awaitables concurrently which produced odd results.

Interesting.  This is something that has to be fixed (in 3.6.1)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28091>
_______________________________________

From report at bugs.python.org  Fri Dec  9 15:46:43 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 09 Dec 2016 20:46:43 +0000
Subject: [issue28921] Make str.count one character for latin1 string faster
In-Reply-To: <1481294304.37.0.437308839314.issue28921@psf.upfronthosting.co.za>
Message-ID: <1481316403.9.0.724573130274.issue28921@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The code looks too complex. I think that it is not worth to complicate the code so much for optimizing just few non-critical string operations.

Many optimizations were rejected in the past due to high cost and low benefit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28921>
_______________________________________

From report at bugs.python.org  Fri Dec  9 15:49:44 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 09 Dec 2016 20:49:44 +0000
Subject: [issue28925] Confusing exception from cPickle on reduce failure
In-Reply-To: <1481307076.91.0.720116511602.issue28925@psf.upfronthosting.co.za>
Message-ID: <1481316584.65.0.62049281696.issue28925@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
assignee:  -> serhiy.storchaka
nosy: +serhiy.storchaka
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28925>
_______________________________________

From report at bugs.python.org  Fri Dec  9 15:55:37 2016
From: report at bugs.python.org (Steven)
Date: Fri, 09 Dec 2016 20:55:37 +0000
Subject: [issue28926] subprocess.Popen + Sqlalchemy doesn't wait for process
Message-ID: <1481316937.81.0.393153740651.issue28926@psf.upfronthosting.co.za>


New submission from Steven:

Called subprocess.Popen("python_file.py", shell=True).wait(), which triggered a call to `Base.metadata.create_all(engine)` inside `python_file.py`

This caused nothing after the `create_all(engine)` call to execute in `python_file.py` But, if I changed `subprocess.Popen` to `subprocess.check_call("python_file", shell=True).wait()`, the desired behavior was achieved.

I was able to continue past `create_all(engine)` if there was an error in the parent script after the subprocess call. In this case, then `python_file.py` was able to execute fully as expected.

----------
components: Library (Lib)
messages: 282804
nosy: s1113950
priority: normal
severity: normal
status: open
title: subprocess.Popen + Sqlalchemy doesn't wait for process
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28926>
_______________________________________

From report at bugs.python.org  Fri Dec  9 16:00:29 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 09 Dec 2016 21:00:29 +0000
Subject: [issue28091] Document PEP 525
In-Reply-To: <1480969186.28.0.879526881588.issue28091@psf.upfronthosting.co.za>
Message-ID: <1481317229.96.0.213526140005.issue28091@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Eric, I've left you some review comments.

Guido, Nick, I have a question I hope you have an opinion on: for synchronous generators we define the following (sometimes confusing) terminology:

- "generator" = generator function
- "generator iterator" = generator object

I'm thinking if we can define asynchronous generators slightly differently:

- "asynchronous generator function"
- "asynchronous generator"

----------
nosy: +gvanrossum, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28091>
_______________________________________

From report at bugs.python.org  Fri Dec  9 16:10:24 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 09 Dec 2016 21:10:24 +0000
Subject: [issue28190] Detect curses headers correctly for cross-compiling
In-Reply-To: <1474132808.23.0.788365161086.issue28190@psf.upfronthosting.co.za>
Message-ID: <1481317824.07.0.827339469058.issue28190@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

The only change that is needed here is to not include /usr/include/ncursesw in setup.py when cross compiling to ensure that the headers of the build platform are not included.  When cross compiling Python, it is the responsability of the packager to set the appropriate CPPFLAGS and LDFLAGS upon invoking configure, so that the curses headers are included and the curses libraries are linked at build time.
The same is true for the other extension modules, readline, openssl, libffi, etc...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28190>
_______________________________________

From report at bugs.python.org  Fri Dec  9 16:49:17 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 09 Dec 2016 21:49:17 +0000
Subject: [issue28091] Document PEP 525
In-Reply-To: <1481317229.96.0.213526140005.issue28091@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJLXgRs=8Q3h2HFa28c5wgxy2_GVZ4C8bTmf8BT7wKboig@mail.gmail.com>


Guido van Rossum added the comment:

It sounds particularly confusing that an "[XXX] generator" is the function
in one case and the object in the other case.

There's of course also Nathaniel Smith's opinion that we should switch away
from the term coroutine and call those "async def". Is that relevant?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28091>
_______________________________________

From report at bugs.python.org  Fri Dec  9 17:04:12 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 09 Dec 2016 22:04:12 +0000
Subject: [issue28091] Document PEP 525
In-Reply-To: <1480969186.28.0.879526881588.issue28091@psf.upfronthosting.co.za>
Message-ID: <1481321052.49.0.1619052604.issue28091@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> It sounds particularly confusing that an "[XXX] generator" is the function
in one case and the object in the other case.

Right, this is the biggest argument against having slightly different terminology between async generators and sync generators.

Maybe we should update docs for synchronous generators and replace "generator" with "generator function" and "generator iterable" with "generator"?

Most of the existing documentation refers to generator objects when the term "generator" is used anyways.

> There's of course also Nathaniel Smith's opinion that we should switch away
from the term coroutine and call those "async def". Is that relevant?

IIRC he's advocating to refer to "coroutine functions" as "async functions" and to "coroutines" as "async something". I personally don't buy his arguments and think that the current terminology is good and people already seem to understand/like it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28091>
_______________________________________

From report at bugs.python.org  Fri Dec  9 18:01:32 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 09 Dec 2016 23:01:32 +0000
Subject: [issue28091] Document PEP 525
In-Reply-To: <1481321052.49.0.1619052604.issue28091@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJLgLPXFuvhOwd=CdObe++aOM3mBKvJJ0Of2v-UPrBJhRg@mail.gmail.com>


Guido van Rossum added the comment:

I think that most documentation uses "generator" to refer to both functions
and objects. So whenever you want to be clear you have to write the long
form.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28091>
_______________________________________

From report at bugs.python.org  Fri Dec  9 18:42:07 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 09 Dec 2016 23:42:07 +0000
Subject: [issue28882] Slice confusing with negative stop and strides and the
 0th element.
In-Reply-To: <1481000800.36.0.0535087899648.issue28882@psf.upfronthosting.co.za>
Message-ID: <1481326927.1.0.72607031604.issue28882@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think Steven?s main complaint is that it is hard to make a reversed slice extend to the start of the original sequence, unless you omit (or use None as) the endpoint:

>>> "01234567"[4:0:-1]  # Includes index [4], stops before reaching index [0]
'4321'
>>> "01234567"[3::-1]  # Includes index [3], stop omitted for start of string
'3210'
>>> "01234567"[3:None:-1]  # None means the same
'3210'
>>> "01234567"[3:-1:-1]  # Negative means len(...) - 1, i.e. index [7]
''

This is a consequence of (a) the stop parameter meaning ?stop _before_ reaching this index?, and (b) negative indexes are interpreted specially as being relative to the end.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28882>
_______________________________________

From report at bugs.python.org  Fri Dec  9 19:07:26 2016
From: report at bugs.python.org (Robert Xiao)
Date: Sat, 10 Dec 2016 00:07:26 +0000
Subject: [issue28927] bytes.fromhex should ignore all whitespace
Message-ID: <1481328446.9.0.450435696311.issue28927@psf.upfronthosting.co.za>


New submission from Robert Xiao:

bytes.fromhex ignores space characters now (yay!) but still barfs if fed newlines or tabs:

>>> bytes.fromhex('ab\ncd')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: non-hexadecimal number found in fromhex() arg at position 2
>>> bytes.fromhex('ab\tcd')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: non-hexadecimal number found in fromhex() arg at position 2

It's often quite useful to paste blobs of hex into source code (or the REPL) and call ".fromhex" on them. These might include spaces, tabs and/or newlines, and barfing on these other whitespace characters is inconvenient.

I propose that bytes.fromhex should ignore all whitespace. A patch + test is attached.

----------
files: fromhex.patch
keywords: patch
messages: 282811
nosy: nneonneo
priority: normal
severity: normal
status: open
title: bytes.fromhex should ignore all whitespace
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file45823/fromhex.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28927>
_______________________________________

From report at bugs.python.org  Fri Dec  9 19:16:44 2016
From: report at bugs.python.org (Douglas Greiman)
Date: Sat, 10 Dec 2016 00:16:44 +0000
Subject: [issue28425] Python3 ignores __init__.py that are links to /dev/null
In-Reply-To: <1476317932.87.0.807629965942.issue28425@psf.upfronthosting.co.za>
Message-ID: <1481329004.9.0.577086346007.issue28425@psf.upfronthosting.co.za>


Douglas Greiman added the comment:

To be thorough, I looked at non __init__.py source files as well, with erratic results.  And who knows what would happen on other OS's.  So a blanket "must be a regular file" seems reasonable.

$ ls -l b.*
lrwxrwxrwx 1 dgreiman eng 9 Dec  9 16:05 b.py -> /dev/null

$ python2.7 -m b             # Success
$ python2.7 -c 'import b'    # Success
$ python2.7 b.py             # Success

$ python3.5 b.py             # Success
$ python3.5 -m b             # Failure
/opt/python3.5/bin/python3.5: No module named b
$ python3.5 -c 'import b'    # Failure
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named 'b'

$ uname -a
Linux 53334eb940e6 3.13.0-101-generic #148-Ubuntu SMP Thu Oct 20 22:08:32 UTC 2016 x86_64 GNU/Linux

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28425>
_______________________________________

From report at bugs.python.org  Fri Dec  9 19:22:00 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 10 Dec 2016 00:22:00 +0000
Subject: [issue1446619] extended slice behavior inconsistent with docs
Message-ID: <1481329320.13.0.883626118951.issue1446619@psf.upfronthosting.co.za>


Martin Panter added the comment:

Fumihiro?s suggestion seems reasonable to me (assuming it still applies to the current text)

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1446619>
_______________________________________

From report at bugs.python.org  Fri Dec  9 19:28:35 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 10 Dec 2016 00:28:35 +0000
Subject: [issue28882] Slice confusing with negative stop and strides and the
 0th element.
In-Reply-To: <1481000800.36.0.0535087899648.issue28882@psf.upfronthosting.co.za>
Message-ID: <1481329715.19.0.574356793265.issue28882@psf.upfronthosting.co.za>


Martin Panter added the comment:

See also Issue 11842 about the behaviour of slice.indices() in this situation, and Issue 1446619 about fixing the documentation for reverse slices regarding positive out-of-range indexes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28882>
_______________________________________

From report at bugs.python.org  Fri Dec  9 19:39:27 2016
From: report at bugs.python.org (wkdewey)
Date: Sat, 10 Dec 2016 00:39:27 +0000
Subject: [issue28928] IDLE crashes when opening .py file from Finder
Message-ID: <1481330366.3.0.996309855229.issue28928@psf.upfronthosting.co.za>


New submission from wkdewey:

Every time I try to open a .py file from the Finder (macOS Sierra), IDLE opens up and then immediately "unexpectedly quits." I can open them from within IDLE without the same problem

I've attached Apple's crash report. Additionally, in the Console I get an error message like "IDLE[14872]: objc[14872]: Invalid or prematurely-freed autorelease pool 0x7f81bf959048." every time the crash happens 

I am using Python 2.7.12; I installed the correct version of tcltk (something that is frequently mentioned when I search online for this problem) so that isn't the issue.

----------
assignee: terry.reedy
components: IDLE
files: error.txt
messages: 282815
nosy: terry.reedy, wkdewey
priority: normal
severity: normal
status: open
title: IDLE crashes when opening .py file from Finder
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file45824/error.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28928>
_______________________________________

From report at bugs.python.org  Fri Dec  9 19:53:04 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 10 Dec 2016 00:53:04 +0000
Subject: [issue28927] bytes.fromhex should ignore all whitespace
In-Reply-To: <1481328446.9.0.450435696311.issue28927@psf.upfronthosting.co.za>
Message-ID: <1481331184.65.0.243954357893.issue28927@psf.upfronthosting.co.za>


Martin Panter added the comment:

Seems a reasonable feature. The documentation would also need updating.

Which specific (whitespace) characters do you propose to ignore? Just ASCII ones, as in bytes.isspace(), or others like b"\xA0" (non-breaking space) and U+2028 (line separator), as in str.isspace()? Perhaps you should add test cases to clarify.

----------
nosy: +martin.panter
stage:  -> patch review
versions: +Python 3.7 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28927>
_______________________________________

From report at bugs.python.org  Fri Dec  9 19:54:39 2016
From: report at bugs.python.org (Robert Xiao)
Date: Sat, 10 Dec 2016 00:54:39 +0000
Subject: [issue28927] bytes.fromhex should ignore all whitespace
In-Reply-To: <1481328446.9.0.450435696311.issue28927@psf.upfronthosting.co.za>
Message-ID: <1481331279.35.0.594101921829.issue28927@psf.upfronthosting.co.za>


Robert Xiao added the comment:

I used Py_ISSPACE, which uses the .strip() default charset - I think this is a reasonable choice. We don't have to go crazy and support all the Unicode spaces.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28927>
_______________________________________

From report at bugs.python.org  Fri Dec  9 19:58:56 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 10 Dec 2016 00:58:56 +0000
Subject: [issue28929] Provide a link from documentation back to its source file
Message-ID: <1481331536.86.0.539237207001.issue28929@psf.upfronthosting.co.za>


New submission from Brett Cannon:

It would be great if we provided a link from a documentation page back to the source file that the page is produced from, e.g. have https://docs.python.org/3.6/library/abc.html provide a link to https://github.com/python/cpython/blob/3.6/Doc/library/abc.rst.

----------
assignee: docs at python
components: Documentation
messages: 282818
nosy: brett.cannon, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: Provide a link from documentation back to its source file
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28929>
_______________________________________

From report at bugs.python.org  Fri Dec  9 20:39:30 2016
From: report at bugs.python.org (Douglas Greiman)
Date: Sat, 10 Dec 2016 01:39:30 +0000
Subject: [issue28424] pkgutil.get_data() doesn't work with namespace packages
In-Reply-To: <1476315360.41.0.557766587306.issue28424@psf.upfronthosting.co.za>
Message-ID: <1481333970.46.0.168848732271.issue28424@psf.upfronthosting.co.za>


Douglas Greiman added the comment:

Patch attached.  Feel free to wordsmith.

----------
keywords: +patch
Added file: http://bugs.python.org/file45825/issue28424.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28424>
_______________________________________

From report at bugs.python.org  Fri Dec  9 20:40:23 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 10 Dec 2016 01:40:23 +0000
Subject: [issue28912] collections.abc.OrderedMapping
In-Reply-To: <1481238034.34.0.119082165821.issue28912@psf.upfronthosting.co.za>
Message-ID: <1481334023.11.0.416785718176.issue28912@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28912>
_______________________________________

From report at bugs.python.org  Fri Dec  9 21:31:00 2016
From: report at bugs.python.org (Ned Deily)
Date: Sat, 10 Dec 2016 02:31:00 +0000
Subject: [issue28928] IDLE crashes when opening .py file from Finder
In-Reply-To: <1481330366.3.0.996309855229.issue28928@psf.upfronthosting.co.za>
Message-ID: <1481337060.23.0.665665466979.issue28928@psf.upfronthosting.co.za>


Ned Deily added the comment:

>From the crash report, it appears you are using a Python 2.7.12 and Tcl/Tk 8.6 installed from Homebrew.  The crash appears to be happening as a result of the Open Apple Event from the Finder to Tk.  At first glance, I'm not able to reproduce the crash using a python.org 2.7.12 with an ActiveState Tcl/Tk 8.5.18 also on macOS 10.12.1. I don't have a Homebrew installation handy to test with and I don't really have time right now to dig into it but I think it very unlikely to be an issue with Python itself.  You might want to open a Homebrew issue and/or a Tk issue.

----------
nosy: +ned.deily
resolution:  -> third party
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28928>
_______________________________________

From report at bugs.python.org  Fri Dec  9 22:12:34 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 10 Dec 2016 03:12:34 +0000
Subject: [issue28916] Not matched behavior of modulo operator % with the
 description of the documentation
In-Reply-To: <1481260841.6.0.53772469659.issue28916@psf.upfronthosting.co.za>
Message-ID: <1481339554.61.0.276115754648.issue28916@psf.upfronthosting.co.za>


Martin Panter added the comment:

The documentation for %x etc also had the same problem, and it applies to Python 2 for %x. Here is a patch for Python 3. The behaviour is already tested, but there were some quirks due to porting from Py 2 tests, and duplicate tests which I removed.

----------
keywords: +patch
stage: needs patch -> patch review
versions: +Python 2.7
Added file: http://bugs.python.org/file45826/py3-octal.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28916>
_______________________________________

From report at bugs.python.org  Fri Dec  9 22:41:23 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Sat, 10 Dec 2016 03:41:23 +0000
Subject: [issue28190] Detect curses headers correctly for cross-compiling
In-Reply-To: <1474132808.23.0.788365161086.issue28190@psf.upfronthosting.co.za>
Message-ID: <1481341283.91.0.912748022555.issue28190@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

> The only change that is needed here is to not include /usr/include/ncursesw in setup.py when cross compiling

No. Lots of codes in _cursesmodule.c need to know whether it's ncursesw, ncurses, or SysV's curses. For example: (segments below are from unpatched codebase)

#if !defined(__hpux) || defined(HAVE_NCURSES_H)
    /* On HP/UX 11, these are of type cchar_t, which is not an
       integral type. If this is a problem on more platforms, a
       configure test should be added to determine whether ACS_S1
       is of integral type. */
    SetDictInt("ACS_S1",            (ACS_S1));
    SetDictInt("ACS_S9",            (ACS_S9));
    SetDictInt("ACS_DIAMOND",       (ACS_DIAMOND));
    SetDictInt("ACS_CKBOARD",       (ACS_CKBOARD));
    SetDictInt("ACS_DEGREE",        (ACS_DEGREE));
    SetDictInt("ACS_PLMINUS",       (ACS_PLMINUS));
    SetDictInt("ACS_BULLET",        (ACS_BULLET));
    SetDictInt("ACS_LARROW",        (ACS_LARROW));
    SetDictInt("ACS_RARROW",        (ACS_RARROW));
    SetDictInt("ACS_DARROW",        (ACS_DARROW));
    SetDictInt("ACS_UARROW",        (ACS_UARROW));
    SetDictInt("ACS_BOARD",         (ACS_BOARD));
    SetDictInt("ACS_LANTERN",       (ACS_LANTERN));
    SetDictInt("ACS_BLOCK",         (ACS_BLOCK));
#endif

And

static int
PyCurses_ConvertToCchar_t(PyCursesWindowObject *win, PyObject *obj,
                          chtype *ch
#ifdef HAVE_NCURSESW
                          , wchar_t *wch
#endif
                          )

So detecting ncurses's actual include path is necessary.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28190>
_______________________________________

From report at bugs.python.org  Fri Dec  9 23:17:25 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 10 Dec 2016 04:17:25 +0000
Subject: [issue28091] Document PEP 525
In-Reply-To: <1480969186.28.0.879526881588.issue28091@psf.upfronthosting.co.za>
Message-ID: <1481343445.89.0.648224783598.issue28091@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I agree with Guido that the in-practice terminology for synchronous generators is:

 "generator" = infer from context (and/or the ambiguity doesn't matter)
 "generator function" = generator iterator factory defined with "def"
 "generator iterator" = result of calling a generator function

Hence the caveat on https://docs.python.org/3/glossary.html#term-generator: "Usually refers to a generator function, but may refer to a generator iterator in some contexts. In cases where the intended meaning isn?t clear, using the full terms avoids ambiguity."

For async I believe you may be better off avoiding the term "generator" entirely, and instead going with "native async iterator":

  "native async iterator" = infer from context
  "native async iterator function" = async iterator factory defined with "async def"
  "native async iterator object" = result of calling a native async iterator function

Yes, technically there's generator machinery under the hood, but I think we're better off letting the discovery of "Oh, coroutines, native async iterators, and generators are all basically the same thing at runtime" be delayed until new users are further along in the process of using Python productively.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28091>
_______________________________________

From report at bugs.python.org  Fri Dec  9 23:23:13 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Dec 2016 04:23:13 +0000
Subject: [issue28753] Clinic: Converting Your First Function is not up to date
In-Reply-To: <1479660244.5.0.379774731624.issue28753@psf.upfronthosting.co.za>
Message-ID: <20161210042310.117653.35258.B9A73E66@psf.io>


Roundup Robot added the comment:

New changeset 7a93d1a0a1cf by Martin Panter in branch '3.5':
Issue 28753: Argument Clinic howto docfix, courtesy Julien Palard.
https://hg.python.org/cpython/rev/7a93d1a0a1cf

New changeset d0859a11322c by Martin Panter in branch '3.6':
Issues #28755, #28753: Merge Arg Clinic howto from 3.5
https://hg.python.org/cpython/rev/d0859a11322c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28753>
_______________________________________

From report at bugs.python.org  Fri Dec  9 23:23:13 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Dec 2016 04:23:13 +0000
Subject: [issue28755] Rework syntax highlighing in howto/clinic.rst
In-Reply-To: <1479679317.44.0.842687607942.issue28755@psf.upfronthosting.co.za>
Message-ID: <20161210042310.117653.40345.720B0D17@psf.io>


Roundup Robot added the comment:

New changeset 3795ba7490b1 by Martin Panter in branch '3.5':
Issue #28755: Improve syntax highlighting in Arg Clinic howto
https://hg.python.org/cpython/rev/3795ba7490b1

New changeset d0859a11322c by Martin Panter in branch '3.6':
Issues #28755, #28753: Merge Arg Clinic howto from 3.5
https://hg.python.org/cpython/rev/d0859a11322c

New changeset 889cb7ebc38d by Martin Panter in branch 'default':
Issue #28755: Merge Arg Clinic howto from 3.6
https://hg.python.org/cpython/rev/889cb7ebc38d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28755>
_______________________________________

From report at bugs.python.org  Fri Dec  9 23:45:55 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 10 Dec 2016 04:45:55 +0000
Subject: [issue1446619] extended slice behavior inconsistent with docs
Message-ID: <1481345155.01.0.0335279257985.issue1446619@psf.upfronthosting.co.za>


Martin Panter added the comment:

Patch ruling out the len(s) corner case. I use a modified version of Fumihiro?s suggestion.

----------
versions: +Python 3.6, Python 3.7 -Python 3.4
Added file: http://bugs.python.org/file45827/extended_slicing_docs.v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1446619>
_______________________________________

From report at bugs.python.org  Sat Dec 10 00:04:48 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 10 Dec 2016 05:04:48 +0000
Subject: [issue26483] docs unclear on difference between str.isdigit() and
 str.isdecimal()
In-Reply-To: <1457121897.81.0.495681677897.issue26483@psf.upfronthosting.co.za>
Message-ID: <1481346288.13.0.0999853922118.issue26483@psf.upfronthosting.co.za>


Martin Panter added the comment:

I?m okay with this version unless anyone has any more improvements.

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26483>
_______________________________________

From report at bugs.python.org  Sat Dec 10 00:10:53 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 10 Dec 2016 05:10:53 +0000
Subject: [issue28755] Rework syntax highlighing in howto/clinic.rst
In-Reply-To: <1479679317.44.0.842687607942.issue28755@psf.upfronthosting.co.za>
Message-ID: <1481346653.91.0.0400945036015.issue28755@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28755>
_______________________________________

From report at bugs.python.org  Sat Dec 10 00:33:15 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 10 Dec 2016 05:33:15 +0000
Subject: [issue28928] IDLE crashes when opening .py file from Finder
In-Reply-To: <1481330366.3.0.996309855229.issue28928@psf.upfronthosting.co.za>
Message-ID: <1481347995.94.0.0112679548175.issue28928@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
assignee: terry.reedy -> 
components: +Installation, Tkinter, macOS
nosy: +ronaldoussoren
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28928>
_______________________________________

From report at bugs.python.org  Sat Dec 10 00:33:26 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 10 Dec 2016 05:33:26 +0000
Subject: [issue28928] IDLE crashes when opening .py file from Finder
In-Reply-To: <1481330366.3.0.996309855229.issue28928@psf.upfronthosting.co.za>
Message-ID: <1481348006.97.0.250077259758.issue28928@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28928>
_______________________________________

From report at bugs.python.org  Sat Dec 10 00:40:05 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Dec 2016 05:40:05 +0000
Subject: [issue28820] Typo in section 6 of the Python 3.4 documentation
In-Reply-To: <1480337245.94.0.248137980963.issue28820@psf.upfronthosting.co.za>
Message-ID: <20161210054002.125268.32914.7D1C0C9E@psf.io>


Roundup Robot added the comment:

New changeset 8e36c04d0e3e by Martin Panter in branch '3.5':
Issue #28820: Fix spelling of ?practice? as a noun
https://hg.python.org/cpython/rev/8e36c04d0e3e

New changeset e9b78a42e6c0 by Martin Panter in branch '3.6':
Issue #28820: Merge spelling fixes from 3.5
https://hg.python.org/cpython/rev/e9b78a42e6c0

New changeset d786c620838c by Martin Panter in branch 'default':
Issue #28820: Merge typo fixes from 3.6
https://hg.python.org/cpython/rev/d786c620838c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28820>
_______________________________________

From report at bugs.python.org  Sat Dec 10 01:02:49 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 10 Dec 2016 06:02:49 +0000
Subject: [issue28916] Not matched behavior of modulo operator % with the
 description of the documentation
In-Reply-To: <1481260841.6.0.53772469659.issue28916@psf.upfronthosting.co.za>
Message-ID: <1481349769.35.0.904405348905.issue28916@psf.upfronthosting.co.za>


Martin Panter added the comment:

Patch for %x in Py 2.

----------
Added file: http://bugs.python.org/file45828/alt-zero.py2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28916>
_______________________________________

From report at bugs.python.org  Sat Dec 10 01:10:52 2016
From: report at bugs.python.org (Mariatta Wijaya)
Date: Sat, 10 Dec 2016 06:10:52 +0000
Subject: [issue28929] Provide a link from documentation back to its source file
In-Reply-To: <1481331536.86.0.539237207001.issue28929@psf.upfronthosting.co.za>
Message-ID: <1481350252.13.0.584482448009.issue28929@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

On the left menu, there's already a Show Source link. 
Is the idea to replace that link to github.com/python/cpython/blob/.... ?

Or, are you thinking about adding a new link under the main heading, similar to 
**Source code:** :source:`Lib/abc.py` 
but for the docs, so maybe by creating a new role like:
**Docs Source code:** :docs_source:`Doc/library/abc.rst`

----------
nosy: +Mariatta

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28929>
_______________________________________

From report at bugs.python.org  Sat Dec 10 01:11:14 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Dec 2016 06:11:14 +0000
Subject: [issue28771] Update documented signatures of tp_get/setattr
In-Reply-To: <1479815588.93.0.810601241454.issue28771@psf.upfronthosting.co.za>
Message-ID: <20161210061111.14329.10655.C831A32F@psf.io>


Roundup Robot added the comment:

New changeset 5d51ac0be72a by Martin Panter in branch '3.5':
Issue #28771: Update tp_get/setattr signature documentation
https://hg.python.org/cpython/rev/5d51ac0be72a

New changeset ee8c8b79d1d5 by Martin Panter in branch '3.6':
Issue #28771: Merge C API doc fix from 3.5
https://hg.python.org/cpython/rev/ee8c8b79d1d5

New changeset c4865975b804 by Martin Panter in branch 'default':
Issue #28771: Merge C API doc fix from 3.6
https://hg.python.org/cpython/rev/c4865975b804

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28771>
_______________________________________

From report at bugs.python.org  Sat Dec 10 01:20:32 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 10 Dec 2016 06:20:32 +0000
Subject: [issue28930] bytes_methods.c won't recompile if related stringlib/*
 changed
Message-ID: <1481350832.04.0.902172752525.issue28930@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

bytes_methods.c includes files in stringlib, for example, stringlib/count.h. But if count.h changes, simply running make won't recompile bytes_methods.c and the methods of bytes remain unchanged. You have to make distclean and compile from scratch.

----------
components: Build
messages: 282832
nosy: xiang.zhang
priority: normal
severity: normal
status: open
title: bytes_methods.c won't recompile if related stringlib/* changed
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28930>
_______________________________________

From report at bugs.python.org  Sat Dec 10 01:32:38 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Dec 2016 06:32:38 +0000
Subject: [issue28930] bytes_methods.c won't recompile if related stringlib/*
 changed
In-Reply-To: <1481350832.04.0.902172752525.issue28930@psf.upfronthosting.co.za>
Message-ID: <1481351558.55.0.111225776596.issue28930@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Needed a rule in Makefile.

----------
nosy: +serhiy.storchaka
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28930>
_______________________________________

From report at bugs.python.org  Sat Dec 10 01:55:35 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 10 Dec 2016 06:55:35 +0000
Subject: [issue28771] Update documented signatures of tp_get/setattr
In-Reply-To: <1479815588.93.0.810601241454.issue28771@psf.upfronthosting.co.za>
Message-ID: <1481352935.0.0.434670393022.issue28771@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28771>
_______________________________________

From report at bugs.python.org  Sat Dec 10 01:55:54 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 10 Dec 2016 06:55:54 +0000
Subject: [issue28820] Typo in section 6 of the Python 3.4 documentation
In-Reply-To: <1480337245.94.0.248137980963.issue28820@psf.upfronthosting.co.za>
Message-ID: <1481352954.59.0.370173000372.issue28820@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28820>
_______________________________________

From report at bugs.python.org  Sat Dec 10 02:17:45 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 10 Dec 2016 07:17:45 +0000
Subject: [issue28930] bytes_methods.c won't recompile if related stringlib/*
 changed
In-Reply-To: <1481350832.04.0.902172752525.issue28930@psf.upfronthosting.co.za>
Message-ID: <1481354265.62.0.613167885181.issue28930@psf.upfronthosting.co.za>


Changes by Xiang Zhang <angwerzx at 126.com>:


----------
assignee:  -> xiang.zhang
keywords: +patch
stage: needs patch -> patch review
type: behavior -> 
versions: +Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45829/Makefile-bytes-methods.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28930>
_______________________________________

From report at bugs.python.org  Sat Dec 10 02:33:35 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Dec 2016 07:33:35 +0000
Subject: [issue28916] Not matched behavior of modulo operator % with the
 description of the documentation
In-Reply-To: <1481260841.6.0.53772469659.issue28916@psf.upfronthosting.co.za>
Message-ID: <1481355215.45.0.64184472084.issue28916@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Both patches LGTM.

----------
assignee: docs at python -> martin.panter
nosy: +serhiy.storchaka
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28916>
_______________________________________

From report at bugs.python.org  Sat Dec 10 02:46:59 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Dec 2016 07:46:59 +0000
Subject: [issue28930] bytes_methods.c won't recompile if related stringlib/*
 changed
In-Reply-To: <1481350832.04.0.902172752525.issue28930@psf.upfronthosting.co.za>
Message-ID: <1481356019.37.0.0294958863651.issue28930@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM. But be aware of possible differences in 3.5.

Alternatively just BYTESTR_DEPS can be used instead of BYTESMETHODS_DEPS. This would make easier moving implementations between bytesobject.c and bytes_methods.c.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28930>
_______________________________________

From report at bugs.python.org  Sat Dec 10 02:50:11 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Dec 2016 07:50:11 +0000
Subject: [issue26483] docs unclear on difference between str.isdigit() and
 str.isdecimal()
In-Reply-To: <1457121897.81.0.495681677897.issue26483@psf.upfronthosting.co.za>
Message-ID: <1481356211.17.0.829604025432.issue26483@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
assignee: docs at python -> martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26483>
_______________________________________

From report at bugs.python.org  Sat Dec 10 03:34:28 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 10 Dec 2016 08:34:28 +0000
Subject: [issue20211] setup.py: do not add system header locations when cross
 compiling
In-Reply-To: <1389308528.92.0.403642458985.issue20211@psf.upfronthosting.co.za>
Message-ID: <1481358868.46.0.190036938896.issue20211@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

When cross compiling, setup.py must not look for headers in the directory for installing C header files and must not look for libraries in the directory for installing object code libraries of the _native_ interpreter which is being used to run setup.py.
Thomas patch updated to the tip of the default branch.

----------
assignee:  -> xdegaye
stage:  -> commit review
versions:  -Python 3.5
Added file: http://bugs.python.org/file45830/no-native-headers-libraries.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20211>
_______________________________________

From report at bugs.python.org  Sat Dec 10 04:03:02 2016
From: report at bugs.python.org (Matthias Klose)
Date: Sat, 10 Dec 2016 09:03:02 +0000
Subject: [issue20211] setup.py: do not add system header locations when cross
 compiling
In-Reply-To: <1389308528.92.0.403642458985.issue20211@psf.upfronthosting.co.za>
Message-ID: <1481360582.83.0.710018533009.issue20211@psf.upfronthosting.co.za>


Matthias Klose added the comment:

this assumption is wrong for the multiarch case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20211>
_______________________________________

From report at bugs.python.org  Sat Dec 10 04:08:33 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 10 Dec 2016 09:08:33 +0000
Subject: [issue28190] Cross-build _curses failed if host ncurses headers and
 target ncurses headers have different layouts
In-Reply-To: <1474132808.23.0.788365161086.issue28190@psf.upfronthosting.co.za>
Message-ID: <1481360913.82.0.851343253187.issue28190@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

This patch does not add /usr/include/ncursesw to the include directories search paths when cross compiling.

Restoring the original title.

@Chi Hsuan Yen
Please open a new issue for the detection of the curses paths. The current issue is about the failure to cross compile _curses when /usr/include/ncursesw is added to these paths. See the original post and the original title.

----------
assignee:  -> xdegaye
components:  -Build
stage:  -> patch review
title: Detect curses headers correctly for cross-compiling -> Cross-build _curses failed if host ncurses headers and target ncurses headers have different layouts
versions: +Python 3.6
Added file: http://bugs.python.org/file45831/no-path-to-ncursesw.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28190>
_______________________________________

From report at bugs.python.org  Sat Dec 10 04:10:43 2016
From: report at bugs.python.org (Matthias Klose)
Date: Sat, 10 Dec 2016 09:10:43 +0000
Subject: [issue28190] Cross-build _curses failed if host ncurses headers and
 target ncurses headers have different layouts
In-Reply-To: <1474132808.23.0.788365161086.issue28190@psf.upfronthosting.co.za>
Message-ID: <1481361043.42.0.0408551796564.issue28190@psf.upfronthosting.co.za>


Matthias Klose added the comment:

> The only change that is needed here is to not include
> /usr/include/ncursesw in setup.py when cross compiling

no, this is a very wrong simplification.  Both gcc and clang offer a method to search for header files and libraries in a target specific location. Please use these options.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28190>
_______________________________________

From report at bugs.python.org  Sat Dec 10 04:26:57 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 10 Dec 2016 09:26:57 +0000
Subject: [issue28190] Cross-build _curses failed if host ncurses headers and
 target ncurses headers have different layouts
In-Reply-To: <1474132808.23.0.788365161086.issue28190@psf.upfronthosting.co.za>
Message-ID: <1481362017.63.0.144126179143.issue28190@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

> Both gcc and clang offer a method to search for header files and libraries in a target specific location.

AFAIK there is no target specific location when cross compiling. What are those cross compilation target specific locations according to you ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28190>
_______________________________________

From report at bugs.python.org  Sat Dec 10 04:35:00 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Sat, 10 Dec 2016 09:35:00 +0000
Subject: [issue20211] setup.py: do not add system header locations when cross
 compiling
In-Reply-To: <1389308528.92.0.403642458985.issue20211@psf.upfronthosting.co.za>
Message-ID: <1481362500.83.0.04248775804.issue20211@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

xdegaye's explanation is incorrect. The actual scene is much more complicated. First, let me explain why things may be broken. The wrong directory is included only if all of the following conditions are met:

1. PYTHON_FOR_BUILD is not installed with --prefix=/usr. A common example is those which are installed with pyenv. This condition is here simply because of `os.path.normpath(sys.base_prefix) != '/usr'`
2. The build script uses $DESTDIR convention to compile CPython
3. Header files in $DESTDIR$PREFIX/include are not equivalent to $PREFIX/include. Here "equivalent" means they are for the same set of architecture/kernel/... This is a common case when cross compiling, while a famous exception is the multiarch framework on Debian-based systems.

For example, if I use --prefix=/usr and DESTDIR=/tmp/python3-android/build, INCLUDEDIR will be /usr/include, which should not be included. On the other hand, if I use --prefix=/tmp/python3-android/build/usr and omit DESTDIR, INCLUDEDIR is correct /tmp/python3-android/build/usr/include. With $DESTDIR specified, the build script has the responsibility to specify $DESTDIR$PREFIX/include in CPPFLAGS, or CPython interpreter core won't even build, so skipping adding INCLUDEDIR in setup.py is safe. However, for the latter case (not using DESTDIR), the build script still needs to specify correct CPPFLAGS. I see it as a CPython limitation and worth documentation.

For Debian's multiarch framework, paths are already handled by add_multiarch_paths(). I'm not sure whether $PREFIX/include should still be included or not. (I don't use Debian-based systems)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20211>
_______________________________________

From report at bugs.python.org  Sat Dec 10 04:36:39 2016
From: report at bugs.python.org (Julien Palard)
Date: Sat, 10 Dec 2016 09:36:39 +0000
Subject: [issue28754] Argument Clinic for bisect.bisect_left
In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za>
Message-ID: <1481362599.73.0.00504424695847.issue28754@psf.upfronthosting.co.za>


Julien Palard added the comment:

I was able to simplify my patch a bit, I think I should also add a test to ensure we keep the hi=-1 and hi=None compatibility in the future.

----------
Added file: http://bugs.python.org/file45832/issue28754-8.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28754>
_______________________________________

From report at bugs.python.org  Sat Dec 10 04:49:11 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 10 Dec 2016 09:49:11 +0000
Subject: [issue20211] setup.py: do not add system header locations when cross
 compiling
In-Reply-To: <1389308528.92.0.403642458985.issue20211@psf.upfronthosting.co.za>
Message-ID: <1481363351.82.0.880907786087.issue20211@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

> this assumption is wrong for the multiarch case.

Please explain why it is wrong.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20211>
_______________________________________

From report at bugs.python.org  Sat Dec 10 04:50:48 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 10 Dec 2016 09:50:48 +0000
Subject: [issue28190] Cross-build _curses failed if host ncurses headers and
 target ncurses headers have different layouts
In-Reply-To: <1474132808.23.0.788365161086.issue28190@psf.upfronthosting.co.za>
Message-ID: <1481363448.06.0.161144878213.issue28190@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

> no, this is a very wrong simplification.  Both gcc and clang offer a method to search for header files and libraries in a target specific location. Please use these options.

Please open a new issue for the detection of the curses paths. The current issue is about the failure to cross compile _curses when /usr/include/ncursesw is added to these paths. See the original post and the original title.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28190>
_______________________________________

From report at bugs.python.org  Sat Dec 10 05:36:00 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 10 Dec 2016 10:36:00 +0000
Subject: [issue25677] Syntax error caret confused by indentation
In-Reply-To: <1447998656.06.0.471632717786.issue25677@psf.upfronthosting.co.za>
Message-ID: <1481366160.51.0.314949728574.issue25677@psf.upfronthosting.co.za>


Martin Panter added the comment:

(Long story short: need to strip form feeds in print_error_text(), but I agree that this otherwise does fix a bug.)

There is one minor regression that this patch causes IMO. Given the following file, where <FF> represents a form feed character ('\014')

if True:
<FF>    1 + 1 = 2

the error report now has a blank line (due to outputting the FF character) and extra indentation that wasn?t stripped:

  File "indent.py", line 2
    
        1 + 1 = 2
        ^
SyntaxError: can't assign to operator

I think the fix for this is to strip form feed characters in print_error_text(), in Python/pythonrun.c.

Apart from that, I agree with Serhiy and Michael that it is okay to push this change. The bug that we are fixing is that SyntaxError.offset does not correspond with SyntaxError.text, due to indentation. Before the patch, the offset refers to the line without indentation removed, but the text has indentation removed. Here is a really bad case, where there is more indentation than code, print_error_text() tries to find the next line, and ends up printing a blank line:

>>> code = "if True:\n" + " "*16 + "1 + 1 = 2\n"
>>> with open("indent.py", "wt") as f: f.write(code)
... 
35
>>> try: compile(code, "indent.py", "exec")
... except SyntaxError as err:
...     print("offset={err.offset} text={err.text!r}".format(err=err))
...     raise
... 
offset=16 text='1 + 1 = 2\n'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "indent.py", line 2
    
         ^
SyntaxError: can't assign to operator

In Michael?s original report, I was curious why the caret is only shifted three spaces, despite there being four spaces of indentation. This is because offset points to the start of the line, but the caret points to the character _before_ offset. So offset=0 and offset=1 are both represented by pointing at the first character on the line. This is related to Serhiy?s bug with inserting ?1;?. In some cases (e.g. the line ?1 +?), the offset is the string index _after_ the error. But in the case of ?1;1 + 1 = 2?, offset is the index where the error (statement) begins.

Both pieces of indentation stripping code were added in revision 27f04d714ecb (year 2001). It is strange that only one stripped form feeds though. The column offset was only added later (revision 861c35cef7aa). So Python 2 will have some of its SyntaxError.text lines stripped of indentation, but it does not matter so much because SyntaxError.offset is not set in those cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25677>
_______________________________________

From report at bugs.python.org  Sat Dec 10 05:43:36 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 10 Dec 2016 10:43:36 +0000
Subject: [issue28930] bytes_methods.c won't recompile if related stringlib/*
 changed
In-Reply-To: <1481350832.04.0.902172752525.issue28930@psf.upfronthosting.co.za>
Message-ID: <1481366616.19.0.99579623954.issue28930@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

> Alternatively just BYTESTR_DEPS can be used instead of BYTESMETHODS_DEPS. This would make easier moving implementations between bytesobject.c and bytes_methods.c.

Yes. The only downside of this is some changes may recompile bytes_methods.c unnecessarily but this is not a matter.

> But be aware of possible differences in 3.5.

In 3.5 bytes_methods.c doesn't rely on stringlib/*.

----------
nosy: +haypo
versions:  -Python 3.5
Added file: http://bugs.python.org/file45833/Makefile-bytes-methods-v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28930>
_______________________________________

From report at bugs.python.org  Sat Dec 10 05:51:00 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Dec 2016 10:51:00 +0000
Subject: [issue28930] bytes_methods.c won't recompile if related stringlib/*
 changed
In-Reply-To: <1481350832.04.0.902172752525.issue28930@psf.upfronthosting.co.za>
Message-ID: <1481367059.99.0.850801257676.issue28930@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Makefile-bytes-methods-v2.patch LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28930>
_______________________________________

From report at bugs.python.org  Sat Dec 10 07:20:33 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Sat, 10 Dec 2016 12:20:33 +0000
Subject: [issue28190] Cross-build _curses failed if host ncurses headers and
 target ncurses headers have different layouts
In-Reply-To: <1474132808.23.0.788365161086.issue28190@psf.upfronthosting.co.za>
Message-ID: <1481372433.11.0.940914015224.issue28190@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

@xdegaye: no-path-to-ncursesw.patch fixes a problem yet introducing a new one. With that patch auto-detection of ncurses include files are broken. Now users have to specify the path manually even for native builds.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28190>
_______________________________________

From report at bugs.python.org  Sat Dec 10 07:59:13 2016
From: report at bugs.python.org (patrila)
Date: Sat, 10 Dec 2016 12:59:13 +0000
Subject: [issue28815] test_socket fails if /proc/modules is existent but not
 readable
In-Reply-To: <1480263378.99.0.648069549511.issue28815@psf.upfronthosting.co.za>
Message-ID: <1481374753.86.0.809206308258.issue28815@psf.upfronthosting.co.za>


patrila added the comment:

Oops, sorry that was the draft version of the patch.
Attached the correct version. It was tested against "default" branch (but not against 2.7).

----------
Added file: http://bugs.python.org/file45834/test_socket_isTipcAvailable_proc_modules.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28815>
_______________________________________

From report at bugs.python.org  Sat Dec 10 08:21:31 2016
From: report at bugs.python.org (Ivan Pozdeev)
Date: Sat, 10 Dec 2016 13:21:31 +0000
Subject: [issue26960] urllib hangs when closing connection
In-Reply-To: <1462407954.17.0.565805320206.issue26960@psf.upfronthosting.co.za>
Message-ID: <1481376091.19.0.130163736772.issue26960@psf.upfronthosting.co.za>


Ivan Pozdeev added the comment:

This fix has caused issue25458 to manifest itself in `urllib', too. AFAICS, it's impossible to fully fix `urllib' to correctly handle end-of-transmission response without fixing `ftplib' first.

----------
nosy: +Ivan.Pozdeev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26960>
_______________________________________

From report at bugs.python.org  Sat Dec 10 08:47:48 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Sat, 10 Dec 2016 13:47:48 +0000
Subject: [issue14156] argparse.FileType for '-' doesn't work for a mode of 'rb'
In-Reply-To: <1330513271.31.0.437438851478.issue14156@psf.upfronthosting.co.za>
Message-ID: <1481377668.36.0.326652515261.issue14156@psf.upfronthosting.co.za>


Aviv Palivoda added the comment:

Pinging as mentioned in the devguide.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14156>
_______________________________________

From report at bugs.python.org  Sat Dec 10 08:51:17 2016
From: report at bugs.python.org (Tobias Hansen)
Date: Sat, 10 Dec 2016 13:51:17 +0000
Subject: [issue5322] Python 2.6 object.__new__ argument calling autodetection
 faulty
In-Reply-To: <1235075665.37.0.301694124748.issue5322@psf.upfronthosting.co.za>
Message-ID: <1481377877.94.0.456760902136.issue5322@psf.upfronthosting.co.za>


Tobias Hansen added the comment:

This change breaks backward compatibility in Python 2.7. This is the example that also broke in #25731. In that case the change was reverted. See https://bugs.python.org/issue25731#msg262922

$ cat foo.pxd 
cdef class B:
    cdef object b
$ cat foo.pyx 
cdef class A:
    pass

cdef class B:
    def __init__(self, b):
        self.b = b
$ cat bar.py
from foo import A, B

class C(A, B):
    def __init__(self):
        B.__init__(self, 1)

C()
$ cython foo.pyx && gcc -I/usr/include/python2.7 -Wall -shared -fPIC -o foo.so foo.c
$ python -c 'import bar'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "bar.py", line 7, in <module>
    C()
TypeError: foo.A.__new__(C) is not safe, use foo.B.__new__()

----------
nosy: +thansen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5322>
_______________________________________

From report at bugs.python.org  Sat Dec 10 09:54:33 2016
From: report at bugs.python.org (Ivan Pozdeev)
Date: Sat, 10 Dec 2016 14:54:33 +0000
Subject: [issue28931] urllib ignores FTP 226 response,
 breaking further FTP requests
Message-ID: <1481381673.54.0.845583442328.issue28931@psf.upfronthosting.co.za>


New submission from Ivan Pozdeev:

>>> urllib.urlretrieve("ftp://ftp.zlatkovic.com/pub/libxml/md5sum.txt","t.bin")
('t.bin', <mimetools.Message instance at 0x00D8C5D0>)
>>> urllib.urlretrieve("ftp://ftp.zlatkovic.com/pub/libxml/md5sum.txt","t.bin")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Py\lib\urllib.py", line 98, in urlretrieve
    return opener.retrieve(url, filename, reporthook, data)
  File "C:\Py\lib\urllib.py", line 245, in retrieve
    fp = self.open(url, data)
  File "C:\Py\lib\urllib.py", line 213, in open
    return getattr(self, name)(url)
  File "C:\Py\lib\urllib.py", line 558, in open_ftp
    (fp, retrlen) = self.ftpcache[key].retrfile(file, type)
  File "C:\Py\lib\urllib.py", line 906, in retrfile
    conn, retrlen = self.ftp.ntransfercmd(cmd)
  File "C:\Py\lib\ftplib.py", line 334, in ntransfercmd
    host, port = self.makepasv()
  File "C:\Py\lib\ftplib.py", line 312, in makepasv
    host, port = parse227(self.sendcmd('PASV'))
  File "C:\Py\lib\ftplib.py", line 830, in parse227
    raise error_reply, resp
IOError: [Errno ftp error] 200 Type set to I

The cause is the 226 Transfer Complete response being ignored, causing further response lines to be incorrectly matched to request lines.

The bug is a result of issue16270 for 3.x and issue26960 for 2.7.

----------
components: Library (Lib)
files: ftp_error_illustration.txt
messages: 282853
nosy: Ivan.Pozdeev
priority: normal
severity: normal
status: open
title: urllib ignores FTP 226 response, breaking further FTP requests
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45835/ftp_error_illustration.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28931>
_______________________________________

From report at bugs.python.org  Sat Dec 10 09:54:54 2016
From: report at bugs.python.org (Julien Palard)
Date: Sat, 10 Dec 2016 14:54:54 +0000
Subject: [issue28754] Argument Clinic for bisect.bisect_left
In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za>
Message-ID: <1481381694.92.0.913656060113.issue28754@psf.upfronthosting.co.za>


Julien Palard added the comment:

Added a test to ensure compatibility of both hi=None (introduced in original Python version) and hi=-1 (Introduced by the C version).

Modified Python version to be compatible with the C-introduced hi=-1, so that the new test pass.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28754>
_______________________________________

From report at bugs.python.org  Sat Dec 10 09:55:03 2016
From: report at bugs.python.org (Julien Palard)
Date: Sat, 10 Dec 2016 14:55:03 +0000
Subject: [issue28754] Argument Clinic for bisect.bisect_left
In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za>
Message-ID: <1481381703.72.0.765062883489.issue28754@psf.upfronthosting.co.za>


Changes by Julien Palard <julien+python at palard.fr>:


Added file: http://bugs.python.org/file45836/issue28754-9.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28754>
_______________________________________

From report at bugs.python.org  Sat Dec 10 10:17:39 2016
From: report at bugs.python.org (Ivan Pozdeev)
Date: Sat, 10 Dec 2016 15:17:39 +0000
Subject: [issue28931] urllib ignores FTP 226 response,
 breaking further FTP requests
In-Reply-To: <1481381673.54.0.845583442328.issue28931@psf.upfronthosting.co.za>
Message-ID: <1481383059.89.0.00302841909308.issue28931@psf.upfronthosting.co.za>


Ivan Pozdeev added the comment:

The attached patch fixes this case. It still leaves the following problem:

>>> u=urllib.urlopen("ftp://ftp.zlatkovic.com/pub/libxml/md5sum.txt").read()
>>> urllib.urlretrieve("ftp://ftp.zlatkovic.com/pub/libxml/md5sum.txt","t.bin")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Py\lib\urllib.py", line 98, in urlretrieve
    return opener.retrieve(url, filename, reporthook, data)
  File "C:\Py\lib\urllib.py", line 245, in retrieve
    fp = self.open(url, data)
  File "C:\Py\lib\urllib.py", line 213, in open
    return getattr(self, name)(url)
  File "C:\Py\lib\urllib.py", line 558, in open_ftp
    (fp, retrlen) = self.ftpcache[key].retrfile(file, type)
  File "C:\Py\lib\urllib.py", line 906, in retrfile
    conn, retrlen = self.ftp.ntransfercmd(cmd)
  File "C:\Py\lib\ftplib.py", line 334, in ntransfercmd
    host, port = self.makepasv()
  File "C:\Py\lib\ftplib.py", line 312, in makepasv
    host, port = parse227(self.sendcmd('PASV'))
  File "C:\Py\lib\ftplib.py", line 830, in parse227
    raise error_reply, resp
IOError: [Errno ftp error] 200 Type set to I

I reckon this can't be fully fixed without fixing `ftplib' first, see issue25458.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28931>
_______________________________________

From report at bugs.python.org  Sat Dec 10 10:48:46 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Dec 2016 15:48:46 +0000
Subject: [issue28918] cross compiling xxlimited fails with "Py_LIMITED_API is
 incompatible with Py_DEBUG"
In-Reply-To: <1481273483.19.0.548102187262.issue28918@psf.upfronthosting.co.za>
Message-ID: <20161210154843.14278.98490.3EACDEE0@psf.io>


Roundup Robot added the comment:

New changeset f9e0c864157c by Xavier de Gaye in branch '3.6':
Issue #28918: Fix the cross compilation of xxlimited when Python
https://hg.python.org/cpython/rev/f9e0c864157c

New changeset ff82dfd558df by Xavier de Gaye in branch 'default':
Issue #28918: Merge 3.6.
https://hg.python.org/cpython/rev/ff82dfd558df

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28918>
_______________________________________

From report at bugs.python.org  Sat Dec 10 11:22:12 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Dec 2016 16:22:12 +0000
Subject: [issue28779] set_forkserver_preload() can crash the forkserver if
 preloaded module instantiate multiprocessing classes
In-Reply-To: <1479914801.47.0.114591938702.issue28779@psf.upfronthosting.co.za>
Message-ID: <20161210162209.21418.29635.2E227B9F@psf.io>


Roundup Robot added the comment:

New changeset 1a955981b263 by Antoine Pitrou in branch '3.5':
Issue #28779: multiprocessing.set_forkserver_preload() would crash the forkserver process if a preloaded module instantiated some multiprocessing objects such as locks.
https://hg.python.org/cpython/rev/1a955981b263

New changeset f3b9fd41b5cb by Antoine Pitrou in branch '3.6':
Issue #28779: multiprocessing.set_forkserver_preload() would crash the forkserver process if a preloaded module instantiated some multiprocessing objects such as locks.
https://hg.python.org/cpython/rev/f3b9fd41b5cb

New changeset 5456b699788f by Antoine Pitrou in branch 'default':
Issue #28779: multiprocessing.set_forkserver_preload() would crash the forkserver process if a preloaded module instantiated some multiprocessing objects such as locks.
https://hg.python.org/cpython/rev/5456b699788f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28779>
_______________________________________

From report at bugs.python.org  Sat Dec 10 11:22:38 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 10 Dec 2016 16:22:38 +0000
Subject: [issue28779] set_forkserver_preload() can crash the forkserver if
 preloaded module instantiate multiprocessing classes
In-Reply-To: <1479914801.47.0.114591938702.issue28779@psf.upfronthosting.co.za>
Message-ID: <1481386958.57.0.81692251812.issue28779@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Now fixed, closing.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28779>
_______________________________________

From report at bugs.python.org  Sat Dec 10 11:35:19 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Dec 2016 16:35:19 +0000
Subject: [issue28849] do not define sys.implementation._multiarch on Android
In-Reply-To: <1480579567.9.0.848858013461.issue28849@psf.upfronthosting.co.za>
Message-ID: <20161210163516.30564.23077.DFE2A307@psf.io>


Roundup Robot added the comment:

New changeset b3ba41bf92c7 by Xavier de Gaye in branch '3.6':
Issue #28849: Do not define sys.implementation._multiarch on Android.
https://hg.python.org/cpython/rev/b3ba41bf92c7

New changeset 40e8b39199da by Xavier de Gaye in branch 'default':
Issue #28849: Merge 3.6.
https://hg.python.org/cpython/rev/40e8b39199da

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28849>
_______________________________________

From report at bugs.python.org  Sat Dec 10 11:49:07 2016
From: report at bugs.python.org (Alexandr Shadchin)
Date: Sat, 10 Dec 2016 16:49:07 +0000
Subject: [issue28932] Fail compile Python 3.6.0rc1 on OpenBSD 6.0
Message-ID: <1481388547.33.0.916805591486.issue28932@psf.upfronthosting.co.za>


New submission from Alexandr Shadchin:

In OpenBSD not exist sys/random.h.

----------
components: Build, Installation
files: patch-Python_random_c
messages: 282860
nosy: Alexandr Shadchin
priority: normal
severity: normal
status: open
title: Fail compile Python 3.6.0rc1 on OpenBSD 6.0
type: compile error
versions: Python 3.6
Added file: http://bugs.python.org/file45837/patch-Python_random_c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28932>
_______________________________________

From report at bugs.python.org  Sat Dec 10 12:12:56 2016
From: report at bugs.python.org (Julien Palard)
Date: Sat, 10 Dec 2016 17:12:56 +0000
Subject: [issue28933] AC: Accept None as a default value for any type
Message-ID: <1481389976.88.0.777049011956.issue28933@psf.upfronthosting.co.za>


New submission from Julien Palard:

Today, writing an AC declaration like:

    something: Py_ssize_t(c_default="-1") = None

Leads to the almost obvious "Py_ssize_t_converter: default value None for field something is not of type int".

But it actually make sense: 
 - Accept None as a default python value
 - Document "something=None" in the docstring
 - Write `Py_ssize_t something = -1` in the C code
 - Don't try to parse the argument if it's the default value, keeping the value from the C initialization

In other words, it's a "Give -1 to the C implementation when argument is not given or None, and it may be usefull, typically I'll use it in issue28754.

----------
components: Argument Clinic
messages: 282861
nosy: larry, mdk
priority: normal
severity: normal
status: open
title: AC: Accept None as a default value for any type
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28933>
_______________________________________

From report at bugs.python.org  Sat Dec 10 12:14:49 2016
From: report at bugs.python.org (Julien Palard)
Date: Sat, 10 Dec 2016 17:14:49 +0000
Subject: [issue28933] AC: Accept None as a Py_ssize_t default value
In-Reply-To: <1481389976.88.0.777049011956.issue28933@psf.upfronthosting.co.za>
Message-ID: <1481390089.31.0.235732688373.issue28933@psf.upfronthosting.co.za>


Changes by Julien Palard <julien+python at palard.fr>:


----------
title: AC: Accept None as a default value for any type -> AC: Accept None as a Py_ssize_t default value

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28933>
_______________________________________

From report at bugs.python.org  Sat Dec 10 12:17:14 2016
From: report at bugs.python.org (Julien Palard)
Date: Sat, 10 Dec 2016 17:17:14 +0000
Subject: [issue28933] AC: Accept None as a Py_ssize_t default value
In-Reply-To: <1481389976.88.0.777049011956.issue28933@psf.upfronthosting.co.za>
Message-ID: <1481390234.23.0.854054210157.issue28933@psf.upfronthosting.co.za>


Julien Palard added the comment:

Proposed a patch, but I'm not a huge fan of modifying getargs.c. If it's accepted, I'll obviously need to write tests before this is merged.

----------
keywords: +patch
Added file: http://bugs.python.org/file45838/issue28933.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28933>
_______________________________________

From report at bugs.python.org  Sat Dec 10 12:35:36 2016
From: report at bugs.python.org (bpoaugust)
Date: Sat, 10 Dec 2016 17:35:36 +0000
Subject: [issue28934] _mboxMMDF#get_message should delegate to get_bytes
Message-ID: <1481391336.7.0.180309653101.issue28934@psf.upfronthosting.co.za>


New submission from bpoaugust:

At present both _mboxMMDF#get_message and get_bytes read the file directly.

However the code in get_bytes duplicates some of the code in get_message. get_message should be recoded to use get_bytes.

It would then be possible to override get_bytes (which is also used by get_string) in order to transform the input stream e.g. to unmangle '>From ' lines.

But in any case it makes sense to reuse the code - DRY

----------
components: email
messages: 282863
nosy: barry, bpoaugust, r.david.murray
priority: normal
severity: normal
status: open
title: _mboxMMDF#get_message should delegate to get_bytes
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28934>
_______________________________________

From report at bugs.python.org  Sat Dec 10 12:58:39 2016
From: report at bugs.python.org (Julien Palard)
Date: Sat, 10 Dec 2016 17:58:39 +0000
Subject: [issue28754] Argument Clinic for bisect.bisect_left
In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za>
Message-ID: <1481392719.6.0.525795326775.issue28754@psf.upfronthosting.co.za>


Julien Palard added the comment:

Maybe wait for issue28933.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28754>
_______________________________________

From report at bugs.python.org  Sat Dec 10 14:12:20 2016
From: report at bugs.python.org (Axel Haustant)
Date: Sat, 10 Dec 2016 19:12:20 +0000
Subject: [issue28935] distutils use ConfigParser in Python 3.x and fails to
 parse setup.cfg with percent sign
Message-ID: <1481397140.66.0.236784364676.issue28935@psf.upfronthosting.co.za>


New submission from Axel Haustant:

Because of the Python 3.2 configparser renaming/refactoring, string interpolation has been enabled into distutils config parsing and so fails to read any setup.cfg with percent signs (try to perform string interpolation and fails).


To reproduce: create a project with a percent sign anywhere in the setup.cfg file and execute python setup.py egg_info.
It will pass on Python 2.x and fails on Python 3.x.

The attached patch suimply disable string interpolation in distutils config parsing.

That would be awesome to have this applied on any 3.x version (because project using tox to test against different Python versions also fails with the same issue Python 3.x and PyPI 3.x)

----------
components: Distutils
files: disable-distutils-string-interpolation.patch
keywords: patch
messages: 282865
nosy: Axel Haustant, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: distutils use ConfigParser in Python 3.x and fails to parse setup.cfg with percent sign
type: crash
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45839/disable-distutils-string-interpolation.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28935>
_______________________________________

From report at bugs.python.org  Sat Dec 10 14:45:37 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 10 Dec 2016 19:45:37 +0000
Subject: [issue28929] Provide a link from documentation back to its source file
In-Reply-To: <1481331536.86.0.539237207001.issue28929@psf.upfronthosting.co.za>
Message-ID: <1481399137.45.0.293716630595.issue28929@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Either idea works, but I want a link that someone who finds a spelling mistake can easily follow and submit a PR to fix the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28929>
_______________________________________

From report at bugs.python.org  Sat Dec 10 14:50:12 2016
From: report at bugs.python.org (Mariatta Wijaya)
Date: Sat, 10 Dec 2016 19:50:12 +0000
Subject: [issue28929] Provide a link from documentation back to its source file
In-Reply-To: <1481331536.86.0.539237207001.issue28929@psf.upfronthosting.co.za>
Message-ID: <1481399412.57.0.473489010591.issue28929@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

Thanks, Brett :) I think it's easier to update the existing Source Link to github. I'll work on a patch for this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28929>
_______________________________________

From report at bugs.python.org  Sat Dec 10 14:50:35 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 10 Dec 2016 19:50:35 +0000
Subject: [issue28924] Inline PyEval_EvalFrameEx() in callers
In-Reply-To: <1481306450.73.0.124326033178.issue28924@psf.upfronthosting.co.za>
Message-ID: <1481399435.0.0.868721915784.issue28924@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Inlining wouldn't break Pyjion since all of its smarts would be in the trampoline function in PyInterpreterState. It may break other debuggers like Python Tools for Visual Studio, though (+steve.dower for that).

But is the overhead honestly that high to warrant inlining? What kind of perf gain do you see from doing this? My worry is that if the perf isn't that much better that inlining will simply make it harder to tweak that function in the future.

----------
nosy: +dino.viehland, steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28924>
_______________________________________

From report at bugs.python.org  Sat Dec 10 14:53:48 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 10 Dec 2016 19:53:48 +0000
Subject: [issue28425] Python3 ignores __init__.py that are links to /dev/null
In-Reply-To: <1476317932.87.0.807629965942.issue28425@psf.upfronthosting.co.za>
Message-ID: <1481399628.92.0.052770177873.issue28425@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Those results are expected as passing in a file by path means it's just read by open() and then passed to exec() while the others pass through import itself which has the os.path.isfile() check.

Since this is a change from Python 2.7 I would be willing to look at a patch that loosened things that was fully backwards-compatible, but it would be an enhancement and not a bugfix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28425>
_______________________________________

From report at bugs.python.org  Sat Dec 10 14:55:07 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 10 Dec 2016 19:55:07 +0000
Subject: [issue28424] pkgutil.get_data() doesn't work with namespace packages
In-Reply-To: <1476315360.41.0.557766587306.issue28424@psf.upfronthosting.co.za>
Message-ID: <1481399707.61.0.0341207070514.issue28424@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Patch LGTM.

----------
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28424>
_______________________________________

From report at bugs.python.org  Sat Dec 10 14:55:40 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 10 Dec 2016 19:55:40 +0000
Subject: [issue28424] pkgutil.get_data() doesn't work with namespace packages
In-Reply-To: <1476315360.41.0.557766587306.issue28424@psf.upfronthosting.co.za>
Message-ID: <1481399740.41.0.223648066351.issue28424@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
versions: +Python 3.7 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28424>
_______________________________________

From report at bugs.python.org  Sat Dec 10 14:58:40 2016
From: report at bugs.python.org (Ivan Pozdeev)
Date: Sat, 10 Dec 2016 19:58:40 +0000
Subject: [issue28931] urllib ignores FTP 226 response,
 breaking further FTP requests
In-Reply-To: <1481381673.54.0.845583442328.issue28931@psf.upfronthosting.co.za>
Message-ID: <1481399920.35.0.456490565837.issue28931@psf.upfronthosting.co.za>


Changes by Ivan Pozdeev <ivan_pozdeev at mail.ru>:


----------
keywords: +patch
Added file: http://bugs.python.org/file45840/105577.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28931>
_______________________________________

From report at bugs.python.org  Sat Dec 10 15:14:24 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 10 Dec 2016 20:14:24 +0000
Subject: [issue25711] Rewrite zipimport from scratch
In-Reply-To: <1448296120.48.0.872112518039.issue25711@psf.upfronthosting.co.za>
Message-ID: <1481400864.35.0.599321958175.issue25711@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

So long as this code block that imports os is avoided, I believe that this can be properly frozen:

+        if not isinstance(path, str):
+            import os
+            path = os.fsdecode(path)

But it should be easy to avoid that code path when the standard library is a zip file.

Otherwise it uses importlib (frozen), marshal (builtin), sys (builtin), time (builtin), and zlib [if present] (extension module).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25711>
_______________________________________

From report at bugs.python.org  Sat Dec 10 15:17:18 2016
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 10 Dec 2016 20:17:18 +0000
Subject: [issue16737] Different behaviours in script run directly and via
 runpy.run_module
In-Reply-To: <1356010622.32.0.479096681415.issue16737@psf.upfronthosting.co.za>
Message-ID: <1481401038.39.0.414387876704.issue16737@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

I've found some other inconsistencies with the use of python -m. One is the surprising behavior when running pip:

$ touch logging.py
$ pip --help > /dev/null
$ python -m pip --help > /dev/null
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/runpy.py", line 183, in _run_module_as_main
    mod_name, mod_spec, code = _get_module_details(mod_name, _Error)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/runpy.py", line 142, in _get_module_details
    return _get_module_details(pkg_main_name, error)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/runpy.py", line 109, in _get_module_details
    __import__(pkg_name)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/pip/__init__.py", line 21, in <module>
    from pip._vendor.requests.packages.urllib3.exceptions import DependencyWarning
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/pip/_vendor/requests/__init__.py", line 62, in <module>
    from .packages.urllib3.exceptions import DependencyWarning
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/pip/_vendor/requests/packages/__init__.py", line 27, in <module>
    from . import urllib3
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/pip/_vendor/requests/packages/urllib3/__init__.py", line 8, in <module>
    from .connectionpool import (
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/pip/_vendor/requests/packages/urllib3/connectionpool.py", line 35, in <module>
    from .connection import (
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/pip/_vendor/requests/packages/urllib3/connection.py", line 44, in <module>
    from .util.ssl_ import (
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/pip/_vendor/requests/packages/urllib3/util/__init__.py", line 20, in <module>
    from .retry import Retry
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages/pip/_vendor/requests/packages/urllib3/util/retry.py", line 15, in <module>
    log = logging.getLogger(__name__)
AttributeError: module 'logging' has no attribute 'getLogger'

Obviously this is a case of don't create any files that mask stdlib or other modules that your call stack might try to import. But the takeaway is that you can't in general rely on `python -m` to launch behavior comparable to launching a script.


Additionally, this inconsistency led to a [subtle bug in pytest when launched with -m](https://github.com/pytest-dev/pytest/issues/2104). In that ticket, the recommended solution (at least thusfar) is "don't use -m". I imagine that pytest (and every other project that exposes a module for launching core behavior) could work around the issue by explicitly removing the cwd from sys.path, but that seems messy.

I imagine it could prove difficult to overcome the backward incompatibilities of changing this behavior now, so I don't have a strong recommendation, but I wanted to share these experiences and get feedback and recommendations.

----------
nosy: +jason.coombs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16737>
_______________________________________

From report at bugs.python.org  Sat Dec 10 15:36:31 2016
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 10 Dec 2016 20:36:31 +0000
Subject: [issue28933] AC: Accept None as a Py_ssize_t default value
In-Reply-To: <1481389976.88.0.777049011956.issue28933@psf.upfronthosting.co.za>
Message-ID: <1481402191.39.0.700570802892.issue28933@psf.upfronthosting.co.za>


Larry Hastings added the comment:

You propose an automatic conversion of "None" into "-1"?  That's awful.  Please don't commit that patch to CPython.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28933>
_______________________________________

From report at bugs.python.org  Sat Dec 10 15:43:09 2016
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 10 Dec 2016 20:43:09 +0000
Subject: [issue28933] AC: Accept None as a Py_ssize_t default value
In-Reply-To: <1481389976.88.0.777049011956.issue28933@psf.upfronthosting.co.za>
Message-ID: <1481402589.15.0.440310508364.issue28933@psf.upfronthosting.co.za>


Larry Hastings added the comment:

It looks like you did it with a converter for 28754.  That's okay.  But not in the default implementation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28933>
_______________________________________

From report at bugs.python.org  Sat Dec 10 15:44:31 2016
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 10 Dec 2016 20:44:31 +0000
Subject: [issue28754] Argument Clinic for bisect.bisect_left
In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za>
Message-ID: <1481402671.36.0.752297326204.issue28754@psf.upfronthosting.co.za>


Larry Hastings added the comment:

FWIW, pypy uses defaults of lo=0, hi=None.

https://bitbucket.org/pypy/pypy/src/25da7bc9719457aee57547993833d5168ba6aded/lib-python/2.7/bisect.py?at=default&fileviewer=file-view-default

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28754>
_______________________________________

From report at bugs.python.org  Sat Dec 10 16:06:06 2016
From: report at bugs.python.org (paul j3)
Date: Sat, 10 Dec 2016 21:06:06 +0000
Subject: [issue14156] argparse.FileType for '-' doesn't work for a mode of 'rb'
In-Reply-To: <1330513271.31.0.437438851478.issue14156@psf.upfronthosting.co.za>
Message-ID: <1481403966.91.0.18601525664.issue14156@psf.upfronthosting.co.za>


Changes by paul j3 <ajipanca at gmail.com>:


----------
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14156>
_______________________________________

From report at bugs.python.org  Sat Dec 10 16:16:17 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Dec 2016 21:16:17 +0000
Subject: [issue25711] Rewrite zipimport from scratch
In-Reply-To: <1448296120.48.0.872112518039.issue25711@psf.upfronthosting.co.za>
Message-ID: <1481404577.03.0.864106791408.issue25711@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Technically, will it be possible to freeze it?

I think yes. But I don't know how to do this. I hope on Brett's (or other import machinery expert) help.

Since zipimporter constructor is called only with string path by import machinery, the os module is not imported at initialization stage.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25711>
_______________________________________

From report at bugs.python.org  Sat Dec 10 16:22:13 2016
From: report at bugs.python.org (Julien Palard)
Date: Sat, 10 Dec 2016 21:22:13 +0000
Subject: [issue28754] Argument Clinic for bisect.bisect_left
In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za>
Message-ID: <1481404933.27.0.573440404868.issue28754@psf.upfronthosting.co.za>


Julien Palard added the comment:

Hi Larry,

In any cases it looks like supporting hi=-1 and hi=None is mandatory: 

hi=None is the current implementation in the bisect (Python) module.
hi=-1 is the current implementation in the _bisect (C) module.

Both are currently living together, the C version takes over the Python version when available, but the Python version is older, so both -1 and None has been the "current implementation" during some time.

Raymond legitimately fear that someone, somewhere, used -1 in some code. We should not break it (even if it had never been documented).

So let's just accept both for the moment, and if deprecation of one or another should be discussed, let's do it later, in another issue. I'm _just_ trying to make AC move forward here, without breaking anything.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28754>
_______________________________________

From report at bugs.python.org  Sat Dec 10 16:23:05 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 10 Dec 2016 21:23:05 +0000
Subject: [issue28190] Cross-build _curses failed if host ncurses headers and
 target ncurses headers have different layouts
In-Reply-To: <1474132808.23.0.788365161086.issue28190@psf.upfronthosting.co.za>
Message-ID: <1481404985.9.0.325349529344.issue28190@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy:  -haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28190>
_______________________________________

From report at bugs.python.org  Sat Dec 10 16:30:30 2016
From: report at bugs.python.org (paul j3)
Date: Sat, 10 Dec 2016 21:30:30 +0000
Subject: [issue25035] Getter/setter for argparse keys
In-Reply-To: <1441753315.66.0.921652253193.issue25035@psf.upfronthosting.co.za>
Message-ID: <1481405430.32.0.263370362098.issue25035@psf.upfronthosting.co.za>


paul j3 added the comment:

Yes, the information that `add_argument` returns a Action object is missing from the documentation.  It might be useful addition.

The documentation has many faults.  It isn't basic enough to be a tutorial, but many first time users use it as such, and get confused by its complexity.  But it also is not a formal reference document. And the automatic 'help(argparse)' isn't much better.

A regular user does not need to use the Action object directly.  But as a developer I often test argparse in an interactive shell (IPython), and the 'out' line shows a 'str' of the object (as a summary of its attributes).  So assigning that object to a variable is just as natural to me as saving the parser object returned by argparse.ArgumentParser, or the group object returned by parser.add_argument_group.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25035>
_______________________________________

From report at bugs.python.org  Sat Dec 10 17:13:47 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 10 Dec 2016 22:13:47 +0000
Subject: [issue28925] Confusing exception from cPickle on reduce failure
In-Reply-To: <1481307076.91.0.720116511602.issue28925@psf.upfronthosting.co.za>
Message-ID: <1481408027.1.0.38058075397.issue28925@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think it is better to remove this code.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file45841/load_classic_instance_error-2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28925>
_______________________________________

From report at bugs.python.org  Sat Dec 10 17:15:31 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 10 Dec 2016 22:15:31 +0000
Subject: [issue28424] pkgutil.get_data() doesn't work with namespace packages
In-Reply-To: <1476315360.41.0.557766587306.issue28424@psf.upfronthosting.co.za>
Message-ID: <20161210221528.12844.62614.5739412F@psf.io>


Roundup Robot added the comment:

New changeset 3484933ba904 by Brett Cannon in branch '3.5':
Issue #28424: Document pkgutil.get_data() doesn't work with namespace packages.
https://hg.python.org/cpython/rev/3484933ba904

New changeset c17d2a37d610 by Brett Cannon in branch '3.6':
Merge for issue #28424
https://hg.python.org/cpython/rev/c17d2a37d610

New changeset b396a2c97871 by Brett Cannon in branch 'default':
Merge for issue #28424
https://hg.python.org/cpython/rev/b396a2c97871

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28424>
_______________________________________

From report at bugs.python.org  Sat Dec 10 17:15:53 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 10 Dec 2016 22:15:53 +0000
Subject: [issue28424] pkgutil.get_data() doesn't work with namespace packages
In-Reply-To: <1476315360.41.0.557766587306.issue28424@psf.upfronthosting.co.za>
Message-ID: <1481408153.3.0.796888885843.issue28424@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Thanks for the patch, Douglas!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28424>
_______________________________________

From report at bugs.python.org  Sat Dec 10 17:19:53 2016
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 10 Dec 2016 22:19:53 +0000
Subject: [issue28754] Argument Clinic for bisect.bisect_left
In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za>
Message-ID: <1481408393.96.0.504187408746.issue28754@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Okay, but do it with a converter function, not by changing the default behavior for Py_ssize_t.  The vast majority of uses of Py_ssize_t should not accept None.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28754>
_______________________________________

From report at bugs.python.org  Sat Dec 10 17:23:25 2016
From: report at bugs.python.org (wkdewey)
Date: Sat, 10 Dec 2016 22:23:25 +0000
Subject: [issue28928] IDLE crashes when opening .py file from Finder
In-Reply-To: <1481330366.3.0.996309855229.issue28928@psf.upfronthosting.co.za>
Message-ID: <1481408605.55.0.169409142528.issue28928@psf.upfronthosting.co.za>


wkdewey added the comment:

The ultimate solution was to uninstall homebrew, since there is no obvious way to get it to use the right version of Tcl/Tk (8.5.18). And then to install the python binary from python.org, which does pick up the right version of Tcl/Tk. 

I can't remember why I was using homebrew, but the instructions at https://www.python.org/download/mac/tcltk/ (where you get pointed from IDLE) were a little unclear. I didn't realize that "if you are using OS X 10.9 or later and a Python from a python.org 64-bit/32-bit installer" didn't refer to the Python that came with macOS, or that I had to (or even could) install the python.org binary on top of the Python that was already there.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28928>
_______________________________________

From report at bugs.python.org  Sat Dec 10 17:52:36 2016
From: report at bugs.python.org (Decorater)
Date: Sat, 10 Dec 2016 22:52:36 +0000
Subject: [issue28902] 3.6.0rc1 installer fails to install / uninstall.
In-Reply-To: <1481178281.99.0.0821886789548.issue28902@psf.upfronthosting.co.za>
Message-ID: <1481410356.92.0.786418755413.issue28902@psf.upfronthosting.co.za>


Decorater added the comment:

Well, not only that but now when I try to uninstall the 64 bit version it seems to not be able to find when on the "Add to path" part of Uninstaller
E:\ProgramData\Package Cache\{815FC13F-79DD-484C-8788-028D69569000}v3.6.121.0\
and some other folders.

I think What the webinstaller should do when it cant find the file/files is to download them again and then run the uninstall in case otherwise there is no other way to actually uninstall it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28902>
_______________________________________

From report at bugs.python.org  Sat Dec 10 17:56:11 2016
From: report at bugs.python.org (Decorater)
Date: Sat, 10 Dec 2016 22:56:11 +0000
Subject: [issue28902] 3.6.0rc1 installer fails to install / uninstall.
In-Reply-To: <1481178281.99.0.0821886789548.issue28902@psf.upfronthosting.co.za>
Message-ID: <1481410571.34.0.0558939799714.issue28902@psf.upfronthosting.co.za>


Changes by Decorater <seandhunt_7 at yahoo.com>:


Added file: http://bugs.python.org/file45842/Python 3.6.0rc1 (64-bit)_20161210164706.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28902>
_______________________________________

From report at bugs.python.org  Sat Dec 10 17:56:51 2016
From: report at bugs.python.org (Decorater)
Date: Sat, 10 Dec 2016 22:56:51 +0000
Subject: [issue28902] 3.6.0rc1 installer fails to install / uninstall.
In-Reply-To: <1481178281.99.0.0821886789548.issue28902@psf.upfronthosting.co.za>
Message-ID: <1481410611.81.0.874252723281.issue28902@psf.upfronthosting.co.za>


Changes by Decorater <seandhunt_7 at yahoo.com>:


Removed file: http://bugs.python.org/file45842/Python 3.6.0rc1 (64-bit)_20161210164706.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28902>
_______________________________________

From report at bugs.python.org  Sat Dec 10 17:59:47 2016
From: report at bugs.python.org (Decorater)
Date: Sat, 10 Dec 2016 22:59:47 +0000
Subject: [issue28902] 3.6.0rc1 installer fails to install / uninstall.
In-Reply-To: <1481178281.99.0.0821886789548.issue28902@psf.upfronthosting.co.za>
Message-ID: <1481410787.38.0.065240728646.issue28902@psf.upfronthosting.co.za>


Changes by Decorater <seandhunt_7 at yahoo.com>:


Added file: http://bugs.python.org/file45843/Python 3.6.0rc1 (64-bit)_20161210164706.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28902>
_______________________________________

From report at bugs.python.org  Sat Dec 10 18:10:06 2016
From: report at bugs.python.org (Ned Deily)
Date: Sat, 10 Dec 2016 23:10:06 +0000
Subject: [issue28928] IDLE crashes when opening .py file from Finder
In-Reply-To: <1481330366.3.0.996309855229.issue28928@psf.upfronthosting.co.za>
Message-ID: <1481411406.99.0.185747892259.issue28928@psf.upfronthosting.co.za>


Ned Deily added the comment:

I'm glad you got it working.  The information at https://www.python.org/download/mac/tcltk/ pertains primarily to using Pythons from the python.org installers; it doesn't directly apply to Python instances built by and supplied by third-party distributors like Homebrew or MacPorts.  So there is nothing wrong about them supplying and linking their Pythons with their own version of Tcl/Tk, be it 8.6.x or 8.5.x.  It would be good to figure out what the problem was that you saw and whether it is a general problem for other Homebrew users but that is out of scope for this tracker.

----------
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28928>
_______________________________________

From report at bugs.python.org  Sat Dec 10 18:22:07 2016
From: report at bugs.python.org (Decorater)
Date: Sat, 10 Dec 2016 23:22:07 +0000
Subject: [issue28902] 3.6.0rc1 installer fails to install / uninstall.
In-Reply-To: <1481178281.99.0.0821886789548.issue28902@psf.upfronthosting.co.za>
Message-ID: <1481412127.5.0.299074223988.issue28902@psf.upfronthosting.co.za>


Decorater added the comment:

I found the registry keys for all python version Except for the keys that Adds it to path to manually uninstall the Add to Path. Other than that Everything Else has been found and take cared of manually thanks to Windows built in Registry Editor.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28902>
_______________________________________

From report at bugs.python.org  Sat Dec 10 18:47:46 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 10 Dec 2016 23:47:46 +0000
Subject: [issue28582] Invalid backslash syntax errors are not always accurate
 as to the location on the line where the error occurs
In-Reply-To: <1478024622.67.0.848531208626.issue28582@psf.upfronthosting.co.za>
Message-ID: <1481413666.46.0.424386400866.issue28582@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think there are actually two issues at play here:

1. The caret is not compensated for indentation removed from the code. This is what Issue 25677 was originally about. The current patch there will ensure that the behaviour is always like the second (top-level) case, no matter what the indentation was.

2. The caret points at the character before SyntaxError.offset. Sometimes the offset identifies the _end_ of the erroneous syntax, and the caret makes sense, because it points at the end of an invalid word (or directly at an invalid character). But other times, such as the invalid escape sequence, offset points at the _start_ of the invalid syntax, and the caret will point to the end of the previous valid syntax. This issue was brought up at the end of Issue 25677, but should probably be dealt with separately.

If you take the first case (indented function), and change the size of the indentation, you will see that the caret is no longer correct. It just happens that with four spaces, the two bugs kind of cancel each other out, and the positioning is actually better than it was designed to be :)

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28582>
_______________________________________

From report at bugs.python.org  Sat Dec 10 19:11:38 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 11 Dec 2016 00:11:38 +0000
Subject: [issue28754] Argument Clinic for bisect.bisect_left
In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za>
Message-ID: <1481415098.92.0.316429337385.issue28754@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Why does this need a converter function?  I there is any reason this can't use "O" with "hi" defaulting to None (matching the pure python API) and letting the C function handle both -1 and None in the implementation rather than in AC?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28754>
_______________________________________

From report at bugs.python.org  Sat Dec 10 19:18:58 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 11 Dec 2016 00:18:58 +0000
Subject: [issue1446619] extended slice behavior inconsistent with docs
Message-ID: <1481415538.58.0.351913671018.issue1446619@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1446619>
_______________________________________

From report at bugs.python.org  Sat Dec 10 19:27:09 2016
From: report at bugs.python.org (Julien Palard)
Date: Sun, 11 Dec 2016 00:27:09 +0000
Subject: [issue28754] Argument Clinic for bisect.bisect_left
In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za>
Message-ID: <1481416029.55.0.330807181389.issue28754@psf.upfronthosting.co.za>


Julien Palard added the comment:

Hi Raymond,

I don't like having the converters in the C implementation too, that's why I'm working on issue28933 to clean this.

> letting the C function handle both -1 and None in the implementation rather than in AC?

It works, yes. But I prefer to clearly split responsibilities: AC being responsible of adapting argument from PyObjects to C types, and C functions being responsible of ... doing their job.

If the idea in issue28933 is accepted, we'll be able to declare hi as simply as:

    hi: Py_ssize_t(c_default="-1") = None

meaning "C function will get a Py_ssize_t, default value for C code is -1, None is documented, and None can be passed to get the C default value", that's this last point "None can be passed to get the C default value" that I introduce in issue28933.

With this syntax, both C converters and the python hi_parameter_converter can be dropped.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28754>
_______________________________________

From report at bugs.python.org  Sat Dec 10 19:29:35 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 11 Dec 2016 00:29:35 +0000
Subject: [issue25677] Syntax error caret confused by indentation
In-Reply-To: <1447998656.06.0.471632717786.issue25677@psf.upfronthosting.co.za>
Message-ID: <1481416175.56.0.0899343413838.issue25677@psf.upfronthosting.co.za>


Martin Panter added the comment:

Patch v6 strips the form feed, and adds an extra test.

----------
Added file: http://bugs.python.org/file45844/cpython25677.v6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25677>
_______________________________________

From report at bugs.python.org  Sat Dec 10 19:32:38 2016
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 11 Dec 2016 00:32:38 +0000
Subject: [issue28754] Argument Clinic for bisect.bisect_left
In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za>
Message-ID: <1481416358.18.0.625319887506.issue28754@psf.upfronthosting.co.za>


Larry Hastings added the comment:

We don't *have* to use a converter function, no.  But consider: someone somewhere will have to convert a PyObject * into a Py_ssize_t, also accepting None.  Doing it in a converter function means we can easily share the code with bisect_right, which should presumably behave the same way.  It also keeps all the argument parsing logic in the Argument Clinic domain instead of having some in AC and some in the implementation.

Is there some drawback to using a converter function?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28754>
_______________________________________

From report at bugs.python.org  Sat Dec 10 19:55:59 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 11 Dec 2016 00:55:59 +0000
Subject: [issue28912] collections.abc.OrderedMapping
In-Reply-To: <1481238034.34.0.119082165821.issue28912@psf.upfronthosting.co.za>
Message-ID: <1481417759.17.0.203845759963.issue28912@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Thank you for the link, it was nice to see Guido's reasons for giving a -0 on the proposal.  I would add that I haven't see any code in the wild that would benefit from testing isinstance(m, OrderedMapping) and taking some different action depending on the result.

Grant's sortedcollection is more sequence-like than mapping-like and the bidict has its own interesting properties and neither are substitutable for an OrderedDict.  In other words, the only properties these cluster on is the ordered equality feature.  IMO, that particular feature hasn't established itself as being valuable (we don't see much use of it with the existing ordered dicts, and likewise in the database world, table equivalence based on exact order rather than content equivalence is uncommon).

Given the limited utility, I am going to decline the proposal.  It is an interesting idea but I believe it that it would clutter the module, slightly drowning-out the ABCs that have more broad and established utility.

One other thought is that the proposed OrderedMapping ABC might not fit well in a possible future Python where the behavior Python 3.6 ordered-and-compact dicts becomes guaranteed but where we retain the traditional unordered equality comparison.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28912>
_______________________________________

From report at bugs.python.org  Sat Dec 10 20:06:00 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 11 Dec 2016 01:06:00 +0000
Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13
 files
In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za>
Message-ID: <1481418360.63.0.115915245371.issue20185@psf.upfronthosting.co.za>


Martin Panter added the comment:

Julien, to help push these changes forward, I suggest start by rebasing and reviewing the conglomerate patch, since it seems that was almost ready.

Reading through the thread, it seems the current status is:

1. _crypt module handled elsewhere by Antoine

2. type, list, and float objects, the resource module, and Python/marshal.c are done by Vajrasky, in part of the conglomerate v4 patch. Zach said they look good, but wanted a second opinion from someone with good C knowledge. Check if Zach?s minor comments for float object and resource module were dealt with.

3. long object and gc module were updated by Vajrasky since last review, so probably need to check if there are any outstanding problems with them.

4. _bisect module by Julien via Issue 28754

5. Victor made a change to Python/_warnings.c, but there may be more to do

6. Not yet handled: Objects/exceptions.c, _thread, _bz2, nis modules.

----------
nosy: +martin.panter
stage: needs patch -> patch review
versions: +Python 3.7 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20185>
_______________________________________

From report at bugs.python.org  Sat Dec 10 21:13:06 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 11 Dec 2016 02:13:06 +0000
Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13
 files
In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za>
Message-ID: <1481422386.68.0.245278769606.issue20185@psf.upfronthosting.co.za>


Martin Panter added the comment:

Zach?s comments on float seem to have been addressed (https://bugs.python.org/review/20185/diff2/10940:10949/Objects/floatobject.c). The comments on the resource module were about return converters: <http://bugs.python.org/review/20185/diff2/10817:10949/Modules/resource.c>. One has been addressed.

The other was about the rlimit2py() function, used in two places. One of these is resource.prlimit(), which is not converted to Arg Clinic in the patch. If we don?t convert it, I agree that leaving rlimit2py() as it is is simplest.

Given that the current prlimit() arg parsing is buggy (Issue 20191), it would be good to convert it to Arg Clinic in the process of solving the bug, but that could be done as a separate step.

Tangentially, the rlimit2py() function has special HAVE_LONG_LONG handling. This is no longer needed in 3.6; see Issue 27961. But again, I think it is better to review and commit the existing patch than to keep perfecting it :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20185>
_______________________________________

From report at bugs.python.org  Sat Dec 10 21:42:36 2016
From: report at bugs.python.org (Joshua Bronson)
Date: Sun, 11 Dec 2016 02:42:36 +0000
Subject: [issue28912] collections.abc.OrderedMapping
In-Reply-To: <1481238034.34.0.119082165821.issue28912@psf.upfronthosting.co.za>
Message-ID: <1481424156.38.0.795630127347.issue28912@psf.upfronthosting.co.za>


Joshua Bronson added the comment:

Sorry to hear but thanks for the consideration. To follow up on your comments:

> nice to see Guido's reasons for giving a -0 on the proposal.

(Guido was giving his -0 on a proposal for collections.abc.Ordered, whereas the main proposal here is collections.abc.OrderedMapping, sorry if that was confusing.)


> I would add that I haven't see any code in the wild that would benefit from testing isinstance(m, OrderedMapping) and taking some different action depending on the result.

Just to give you another data point, bidict.orderedbidict has been released into the wild for a little over 10 months, and people are using it. OrderedMapping would give users the following benefits:

>>> noble = orderedbidict([(2, 'helium'), (10, 'neon'), (18, 'argon')])

>>> b = bidict(noble)  # Discards the order.
>>> b  # Calls BidictBase.__repr__.
bidict({10: 'neon', 18: 'argon', 2: 'helium'})

>>> noble  # Also calls BidictBase.__repr__.
orderedbidict([('Cairo', 'Egypt'), ('Lima', 'Peru'), ('Tokyo', 'Japan')])

>>> # i.e. BidictBase.__repr__ interrogates isinstance(self, OrderedMapping)
>>> # to reflect any ordering correctly in the string representation.

>>> # OrderedMapping.__eq__ also checks isinstance(other, OrderedMapping)
>>> # to conditionally turn on order-sensitivity:
>>> noble == collections.OrderedDict(noble.items())
True
>>> noble == collections.OrderedDict(reversed(noble.items()))
False
>>> noble == dict(reversed(noble.items()))  # order-insensitive
True

(collections.OrderedDict and sortedcontainers.SortedDict could reap these same benefits from an OrderedMapping class.)


> Grant's sortedcollection is more sequence-like than mapping-like and the bidict has its own interesting properties and neither are substitutable for an OrderedDict.

Hm, I don't quite follow this. OrderedDict, SortedDict, and orderedbidict are all OrderedMappings, and should therefore be passable to any function that expects an OrderedMapping.

This part I do follow:

> In other words, the only properties these cluster on is the ordered equality feature.  IMO, that particular feature hasn't established itself as being valuable.... It is an interesting idea but I believe it that it would clutter the module, slightly drowning-out the ABCs that have more broad and established utility.

But based on this rationale, I would have thought Reversible wouldn't have been added. It was only after I found https://bugs.python.org/issue25987 the other day and saw that Reversible will be in 3.6 that I thought OrderedMapping had a case of similar strength, and so it seemed worth taking the time to try to contribute it for 3.7.

In any case, thanks again for your consideration, and if you have any further thoughts to share, it'd be much appreciated.

----------
nosy: +abarnert

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28912>
_______________________________________

From report at bugs.python.org  Sat Dec 10 22:00:15 2016
From: report at bugs.python.org (bpoaugust)
Date: Sun, 11 Dec 2016 03:00:15 +0000
Subject: [issue28934] _mboxMMDF#get_message should delegate to get_bytes
In-Reply-To: <1481391336.7.0.180309653101.issue28934@psf.upfronthosting.co.za>
Message-ID: <1481425215.14.0.126010309501.issue28934@psf.upfronthosting.co.za>


bpoaugust added the comment:

On further investigation it sppears that overriding the get_bytes function does not help with unmangling >From.
However it would still be worth re-using the code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28934>
_______________________________________

From report at bugs.python.org  Sat Dec 10 22:13:20 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 11 Dec 2016 03:13:20 +0000
Subject: [issue6083] Reference counting bug in PyArg_ParseTuple and
 PyArg_ParseTupleAndKeywords
In-Reply-To: <1242980336.93.0.332167282409.issue6083@psf.upfronthosting.co.za>
Message-ID: <1481426000.23.0.298587117394.issue6083@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
dependencies: +resource.prlimit(int, int, str) crashs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6083>
_______________________________________

From report at bugs.python.org  Sat Dec 10 22:14:05 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 11 Dec 2016 03:14:05 +0000
Subject: [issue20191] resource.prlimit(int, int, str) crashs
In-Reply-To: <1389191622.9.0.0763750909735.issue20191@psf.upfronthosting.co.za>
Message-ID: <1481426045.57.0.666798582149.issue20191@psf.upfronthosting.co.za>


Martin Panter added the comment:

Revision 4bac47eb444c fixed setrlimit(). Perhaps those changes can just be applied again to prlimit().

I?m not an Arg Clinic expert, but isn?t one of its purposes to imitate native Python function signatures? Since argument unpacking was dropped from Python 2 to 3, I doubt Arg Clinic would grow support for this. I think the tuple should be unpacked inside the implementation body, just as a native Py 3 function has to unpack tuple arguments.

BTW I couldn?t get either Victor?s "\udbff" test case, nor Serhiy?s BadSequence test case to crash, but the original MyNum class from Issue 6083 does crash.

----------
nosy: +martin.panter
versions: +Python 3.5, Python 3.6, Python 3.7 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20191>
_______________________________________

From report at bugs.python.org  Sat Dec 10 22:14:20 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 11 Dec 2016 03:14:20 +0000
Subject: [issue20191] resource.prlimit(int, int, str) crashs
In-Reply-To: <1389191622.9.0.0763750909735.issue20191@psf.upfronthosting.co.za>
Message-ID: <1481426060.44.0.177350881251.issue20191@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20191>
_______________________________________

From report at bugs.python.org  Sat Dec 10 22:17:23 2016
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 11 Dec 2016 03:17:23 +0000
Subject: [issue20191] resource.prlimit(int, int, str) crashs
In-Reply-To: <1389191622.9.0.0763750909735.issue20191@psf.upfronthosting.co.za>
Message-ID: <1481426243.47.0.686296619072.issue20191@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Sorry, Argument Clinic doesn't support automatic tuple unpacking for arguments.  It was almost never used, I don't think it was ever a good idea, and it would have made an already-too-complicated program even more complicated-er.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20191>
_______________________________________

From report at bugs.python.org  Sat Dec 10 22:51:29 2016
From: report at bugs.python.org (Ivan Pozdeev)
Date: Sun, 11 Dec 2016 03:51:29 +0000
Subject: [issue28931] urllib ignores FTP 226 response,
 breaking further FTP requests
In-Reply-To: <1481381673.54.0.845583442328.issue28931@psf.upfronthosting.co.za>
Message-ID: <1481428289.98.0.634322908263.issue28931@psf.upfronthosting.co.za>


Changes by Ivan Pozdeev <ivan_pozdeev at mail.ru>:


Added file: http://bugs.python.org/file45845/105577.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28931>
_______________________________________

From report at bugs.python.org  Sat Dec 10 22:55:21 2016
From: report at bugs.python.org (Ivan Pozdeev)
Date: Sun, 11 Dec 2016 03:55:21 +0000
Subject: [issue25458] ftplib: command response shift - mismatch
In-Reply-To: <1445510152.74.0.829316001802.issue25458@psf.upfronthosting.co.za>
Message-ID: <1481428521.71.0.665532551022.issue25458@psf.upfronthosting.co.za>


Ivan Pozdeev added the comment:

Spawned the `urllib' issue to issue28931.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25458>
_______________________________________

From report at bugs.python.org  Sat Dec 10 23:10:48 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 11 Dec 2016 04:10:48 +0000
Subject: [issue26483] docs unclear on difference between str.isdigit() and
 str.isdecimal()
In-Reply-To: <1457121897.81.0.495681677897.issue26483@psf.upfronthosting.co.za>
Message-ID: <20161211041044.22840.41666.35665839@psf.io>


Roundup Robot added the comment:

New changeset c15f122617d5 by Martin Panter in branch '3.5':
Issue #26483: Clarify str.isdecimal() and isdigit()
https://hg.python.org/cpython/rev/c15f122617d5

New changeset bc7fc85beed1 by Martin Panter in branch '3.6':
Issues #28916, #26483: Merge stdtypes.rst from 3.5
https://hg.python.org/cpython/rev/bc7fc85beed1

New changeset b11850871300 by Martin Panter in branch 'default':
Issues #28916, #26483: Merge stdtypes.rst from 3.6
https://hg.python.org/cpython/rev/b11850871300

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26483>
_______________________________________

From report at bugs.python.org  Sat Dec 10 23:10:48 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 11 Dec 2016 04:10:48 +0000
Subject: [issue28916] Not matched behavior of modulo operator % with the
 description of the documentation
In-Reply-To: <1481260841.6.0.53772469659.issue28916@psf.upfronthosting.co.za>
Message-ID: <20161211041044.22840.3417.6FA473D7@psf.io>


Roundup Robot added the comment:

New changeset 35e66eb101da by Martin Panter in branch '3.5':
Issue #28916: Correct description of %o and %x alternative forms
https://hg.python.org/cpython/rev/35e66eb101da

New changeset bc7fc85beed1 by Martin Panter in branch '3.6':
Issues #28916, #26483: Merge stdtypes.rst from 3.5
https://hg.python.org/cpython/rev/bc7fc85beed1

New changeset b11850871300 by Martin Panter in branch 'default':
Issues #28916, #26483: Merge stdtypes.rst from 3.6
https://hg.python.org/cpython/rev/b11850871300

New changeset 8359ee62dde3 by Martin Panter in branch '2.7':
Issue #28916: No special case for leading zeros with %x alternative form
https://hg.python.org/cpython/rev/8359ee62dde3

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28916>
_______________________________________

From report at bugs.python.org  Sat Dec 10 23:44:35 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 11 Dec 2016 04:44:35 +0000
Subject: [issue28916] Not matched behavior of modulo operator % with the
 description of the documentation
In-Reply-To: <1481260841.6.0.53772469659.issue28916@psf.upfronthosting.co.za>
Message-ID: <1481431475.63.0.701735463961.issue28916@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28916>
_______________________________________

From report at bugs.python.org  Sat Dec 10 23:45:00 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 11 Dec 2016 04:45:00 +0000
Subject: [issue26483] docs unclear on difference between str.isdigit() and
 str.isdecimal()
In-Reply-To: <1457121897.81.0.495681677897.issue26483@psf.upfronthosting.co.za>
Message-ID: <1481431500.85.0.0494855476026.issue26483@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26483>
_______________________________________

From report at bugs.python.org  Sat Dec 10 23:47:04 2016
From: report at bugs.python.org (Mariatta Wijaya)
Date: Sun, 11 Dec 2016 04:47:04 +0000
Subject: [issue28929] Provide a link from documentation back to its source file
In-Reply-To: <1481331536.86.0.539237207001.issue28929@psf.upfronthosting.co.za>
Message-ID: <1481431624.6.0.0135003496738.issue28929@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

Hi,
This patch updates the Show Source link on the left of Docs menu and point it to github.
I tested it locally, and works for versions >= 3.5 
Please let me know if you have any feedback about this.
Thanks :)

Not sure if the older docs versions should be updated too? In that case, I'll need to prepare different patches for 3.4, 3.3 and 2.7

----------
keywords: +patch
Added file: http://bugs.python.org/file45846/issue28929dev.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28929>
_______________________________________

From report at bugs.python.org  Sun Dec 11 00:12:03 2016
From: report at bugs.python.org (Julien Palard)
Date: Sun, 11 Dec 2016 05:12:03 +0000
Subject: [issue28933] AC: Accept None as a Py_ssize_t default value
In-Reply-To: <1481389976.88.0.777049011956.issue28933@psf.upfronthosting.co.za>
Message-ID: <1481433123.82.0.202068293493.issue28933@psf.upfronthosting.co.za>


Julien Palard added the comment:

> It looks like you did it with a converter for 28754.  That's okay.  But not in the default implementation.

It's not by default, we have to declare "? = None" in the AC declaration, which was an error before my patch (incompatible types?).

Before:

    something: Py_ssize_t(c_default="-1") = None

    > Py_ssize_t_converter: default value None for field something is not of type int

After:

    something: Py_ssize_t(c_default="-1") = None

    > If the None (default) value is provided, the c_default is untouched.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28933>
_______________________________________

From report at bugs.python.org  Sun Dec 11 00:24:04 2016
From: report at bugs.python.org (Julien Palard)
Date: Sun, 11 Dec 2016 05:24:04 +0000
Subject: [issue28933] AC: Accept None as a Py_ssize_t default value
In-Reply-To: <1481389976.88.0.777049011956.issue28933@psf.upfronthosting.co.za>
Message-ID: <1481433844.2.0.727759567171.issue28933@psf.upfronthosting.co.za>


Julien Palard added the comment:

> You propose an automatic conversion of "None" into "-1"?  That's awful.  Please don't commit that patch to CPython.

Not really, I propose a way to do it with AC when needed. And the AC semantics introduced are not "Automatic conversion of None into -1" but "automatic "don't touch the C default" when the python default is given", so it's reusable for other values:

    something: Py_ssize_t(c_default="-1") = None
    something: Py_ssize_t(c_default="0") = None
    something: Py_ssize_t(c_default="42") = None
    ?

And this semantic can be extended to other types too if needed:

    something: a_type(c_default="a_c_side_default_value") = None

To get "a_c_side_default_value" when None is given.

I however did not introduced a way to keep the C default value by using something else than None in the Python side:

 - I'm not sure this is usefull to allow it but it can still be implemented if needed
 - Limiting to None permits to keep a type check so ``something: Py_ssize_t(c_default="-1") = "bar"`` will still fail at clinic.py runtime.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28933>
_______________________________________

From report at bugs.python.org  Sun Dec 11 00:48:02 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Dec 2016 05:48:02 +0000
Subject: [issue25677] Syntax error caret confused by indentation
In-Reply-To: <1447998656.06.0.471632717786.issue25677@psf.upfronthosting.co.za>
Message-ID: <1481435282.55.0.957546852312.issue25677@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM.

----------
assignee: serhiy.storchaka -> martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25677>
_______________________________________

From report at bugs.python.org  Sun Dec 11 01:19:38 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Dec 2016 06:19:38 +0000
Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13
 files
In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za>
Message-ID: <1481437178.24.0.460128908206.issue20185@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Victor, you perhaps could just use NULL as default:

+    source: object = NULL

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20185>
_______________________________________

From report at bugs.python.org  Sun Dec 11 02:23:21 2016
From: report at bugs.python.org (Steve Dower)
Date: Sun, 11 Dec 2016 07:23:21 +0000
Subject: [issue28783] Embedded/nuget packages incorrectly reference
 bdist_wininst
In-Reply-To: <1479925784.02.0.834073933599.issue28783@psf.upfronthosting.co.za>
Message-ID: <1481441001.15.0.693184319729.issue28783@psf.upfronthosting.co.za>


Steve Dower added the comment:

I have a better fix for this issue in the attached patch. It doesn't require any change to setuptools in order to avoid crashing when installing from sdist (e.g. Cython).

As before, this only involves changing the nuget package and its build scripts, so there is zero risk to the main installer. It's even simpler than before too, because I can reuse the infrastructure that was added. (That said, I haven't tested this patch with a real build on the real build machine yet - I will do so before committing.)

Ned - can I get this in for 3.6.0? If not, I'll patch the file by hand before publishing the nuget packages.

----------
nosy: +larry
priority: normal -> release blocker
resolution: fixed -> 
stage: resolved -> patch review
status: closed -> open
Added file: http://bugs.python.org/file45847/28783_1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28783>
_______________________________________

From report at bugs.python.org  Sun Dec 11 02:40:57 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 11 Dec 2016 07:40:57 +0000
Subject: [issue28930] bytes_methods.c won't recompile if related stringlib/*
 changed
In-Reply-To: <1481350832.04.0.902172752525.issue28930@psf.upfronthosting.co.za>
Message-ID: <1481442057.89.0.297766600216.issue28930@psf.upfronthosting.co.za>


STINNER Victor added the comment:

LGTM, you can push it to 3.6 and default.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28930>
_______________________________________

From report at bugs.python.org  Sun Dec 11 02:43:45 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Dec 2016 07:43:45 +0000
Subject: [issue20191] resource.prlimit(int, int, str) crashs
In-Reply-To: <1389191622.9.0.0763750909735.issue20191@psf.upfronthosting.co.za>
Message-ID: <1481442225.23.0.582632985947.issue20191@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Following patch applies to resource.prlimit() the same solution as to resource.setrlimit().

----------
components: +Extension Modules
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file45848/prlimit_refcount.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20191>
_______________________________________

From report at bugs.python.org  Sun Dec 11 02:50:44 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Dec 2016 07:50:44 +0000
Subject: [issue21134] Segfault when stringifying UnicodeEncodeError (or
 UnicodeDecodeError) created with __new__()
In-Reply-To: <1396447837.72.0.201261233456.issue21134@psf.upfronthosting.co.za>
Message-ID: <1481442644.63.0.663431989644.issue21134@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21134>
_______________________________________

From report at bugs.python.org  Sun Dec 11 02:54:15 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Dec 2016 07:54:15 +0000
Subject: [issue28739] PEP 498: docstrings as f-strings
In-Reply-To: <1479501831.35.0.531195928426.issue28739@psf.upfronthosting.co.za>
Message-ID: <1481442855.37.0.285654767667.issue28739@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Eric, could you please make a review of the patch?

----------
stage:  -> patch review
type:  -> behavior
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28739>
_______________________________________

From report at bugs.python.org  Sun Dec 11 02:56:49 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Dec 2016 07:56:49 +0000
Subject: [issue28826] Programming with Python 3.6
In-Reply-To: <1480371738.23.0.459754503807.issue28826@psf.upfronthosting.co.za>
Message-ID: <1481443009.38.0.550232070313.issue28826@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28826>
_______________________________________

From report at bugs.python.org  Sun Dec 11 03:00:34 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Dec 2016 08:00:34 +0000
Subject: [issue28512] PyErr_SyntaxLocationEx() and
 PyErr_SyntaxLocationObject() always set the offset attribute to None
In-Reply-To: <1477173007.35.0.842183977255.issue28512@psf.upfronthosting.co.za>
Message-ID: <1481443234.37.0.319636113094.issue28512@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28512>
_______________________________________

From report at bugs.python.org  Sun Dec 11 03:02:48 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Dec 2016 08:02:48 +0000
Subject: [issue28818] simplify lookdict functions
In-Reply-To: <1480331020.89.0.515440713784.issue28818@psf.upfronthosting.co.za>
Message-ID: <1481443368.26.0.0988779562438.issue28818@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your work Inada.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28818>
_______________________________________

From report at bugs.python.org  Sun Dec 11 04:35:39 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 11 Dec 2016 09:35:39 +0000
Subject: [issue28190] Cross-build _curses failed if host ncurses headers and
 target ncurses headers have different layouts
In-Reply-To: <1474132808.23.0.788365161086.issue28190@psf.upfronthosting.co.za>
Message-ID: <1481448939.45.0.309178870847.issue28190@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

> Now users have to specify the path manually even for native builds.

This does not make sense, the patch does not change anything for the native builds.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28190>
_______________________________________

From report at bugs.python.org  Sun Dec 11 04:36:10 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 11 Dec 2016 09:36:10 +0000
Subject: [issue28512] PyErr_SyntaxLocationEx() and
 PyErr_SyntaxLocationObject() always set the offset attribute to None
In-Reply-To: <1477173007.35.0.842183977255.issue28512@psf.upfronthosting.co.za>
Message-ID: <1481448970.02.0.0414327733007.issue28512@psf.upfronthosting.co.za>


Martin Panter added the comment:

Looks good apart from one quirky test case, see Reitveld

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28512>
_______________________________________

From report at bugs.python.org  Sun Dec 11 05:40:12 2016
From: report at bugs.python.org (Oliver Schode)
Date: Sun, 11 Dec 2016 10:40:12 +0000
Subject: [issue28711] IDLE doesn't open
In-Reply-To: <1479270325.09.0.272646595028.issue28711@psf.upfronthosting.co.za>
Message-ID: <1481452812.17.0.0477447938575.issue28711@psf.upfronthosting.co.za>


Oliver Schode added the comment:

This is a bug you'll run into whenever you set a key binding that is somehow ambiguous to IDLE and for some other reason than being already assigned (for in that case, IDLE will warn, but only then). Like when you set a binding, that would normally be interpreted by the editor for some input modification or so. I think this should be handled more gracefully or at least fail in a more informative way, esp. since beginners on Windows may not be that comfortable on the command line.

A "hard" workaround for the time being is to simply remove your config-keys.cfg file, thus resetting all bindings to their default. On Windows this is usually located in your .idlerc directory in C:\Users\YourName\. You might also edit this file by hand and just remove the offending binding, although that assumes you know which one it is, of course.

----------
nosy: +Ritornell

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28711>
_______________________________________

From report at bugs.python.org  Sun Dec 11 06:24:49 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Sun, 11 Dec 2016 11:24:49 +0000
Subject: [issue28190] Cross-build _curses failed if host ncurses headers and
 target ncurses headers have different layouts
In-Reply-To: <1474132808.23.0.788365161086.issue28190@psf.upfronthosting.co.za>
Message-ID: <1481455489.55.0.66058312408.issue28190@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

Sorry I didn't read your patch carefully and it's surprising for me that you didn't remove/modify this line in configure.ac:

CPPFLAGS="$CPPFLAGS -I/usr/include/ncursesw"

With this line left there, feature detections for _curses are broken as ./configure check against native (/usr/include) headers, whose results make little sense for cross-builds.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28190>
_______________________________________

From report at bugs.python.org  Sun Dec 11 07:33:10 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Dec 2016 12:33:10 +0000
Subject: [issue28936] test_global_err_then_warn in test_syntax is no longer
 valid
Message-ID: <1481459590.71.0.768888502862.issue28936@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Issue27999 invalidated test_global_err_then_warn in Lib/test/test_syntax.py:567. That test was added in issue763201 for testing that SyntaxWarning emitted in symtable_global() doesn't clobber a SyntaxError. In issue27999 a SyntaxWarning was converted to SyntaxError, and the test no longer serves its purpose.

Issue28512 makes tests more strong (it tests the position of SyntaxError), but it can't be applied in 3.6, because _check_error() catches different SyntaxError.

----------
components: Tests
keywords: 3.6regression
messages: 282916
nosy: Jeremy.Hylton, gvanrossum, levkivskyi, serhiy.storchaka
priority: normal
severity: normal
status: open
title: test_global_err_then_warn in test_syntax is no longer valid
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28936>
_______________________________________

From report at bugs.python.org  Sun Dec 11 07:34:16 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Dec 2016 12:34:16 +0000
Subject: [issue28512] PyErr_SyntaxLocationEx() and
 PyErr_SyntaxLocationObject() always set the offset attribute to None
In-Reply-To: <1477173007.35.0.842183977255.issue28512@psf.upfronthosting.co.za>
Message-ID: <1481459656.24.0.528480271826.issue28512@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Good catch Martin! Opened issue28936 for that quirky test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28512>
_______________________________________

From report at bugs.python.org  Sun Dec 11 07:44:52 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 11 Dec 2016 12:44:52 +0000
Subject: [issue28512] PyErr_SyntaxLocationEx() and
 PyErr_SyntaxLocationObject() always set the offset attribute to None
In-Reply-To: <1477173007.35.0.842183977255.issue28512@psf.upfronthosting.co.za>
Message-ID: <20161211124449.15068.80167.61BF8582@psf.io>


Roundup Robot added the comment:

New changeset ea1c49ea8136 by Serhiy Storchaka in branch '3.5':
Issue #28512: Fixed setting the offset attribute of SyntaxError by
https://hg.python.org/cpython/rev/ea1c49ea8136

New changeset df59faf7fa59 by Serhiy Storchaka in branch '3.6':
Issue #28512: Fixed setting the offset attribute of SyntaxError by
https://hg.python.org/cpython/rev/df59faf7fa59

New changeset 72aaef2d144b by Serhiy Storchaka in branch 'default':
Issue #28512: Fixed setting the offset attribute of SyntaxError by
https://hg.python.org/cpython/rev/72aaef2d144b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28512>
_______________________________________

From report at bugs.python.org  Sun Dec 11 08:53:57 2016
From: report at bugs.python.org (Steve Dower)
Date: Sun, 11 Dec 2016 13:53:57 +0000
Subject: [issue28924] Inline PyEval_EvalFrameEx() in callers
In-Reply-To: <1481306450.73.0.124326033178.issue28924@psf.upfronthosting.co.za>
Message-ID: <1481464437.91.0.265741274421.issue28924@psf.upfronthosting.co.za>


Steve Dower added the comment:

MSVC automatically inlines it on Windows (and yes, it broke some of our debugging support in Visual Studio, but we can fix it by setting the eval func).

IMHO, inlining is best left to profiling optimizers. If you notice a regression, add a test case that drives it to the point where it gets inlined. But it's not worth reducing maintainability of the code base for this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28924>
_______________________________________

From report at bugs.python.org  Sun Dec 11 09:15:15 2016
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sun, 11 Dec 2016 14:15:15 +0000
Subject: [issue28936] test_global_err_then_warn in test_syntax is no longer
 valid
In-Reply-To: <1481459590.71.0.768888502862.issue28936@psf.upfronthosting.co.za>
Message-ID: <1481465715.65.0.0411693345921.issue28936@psf.upfronthosting.co.za>


Ivan Levkivskyi added the comment:

Serhiy, here is a patch that might be helpful. It detects global-and-parameter errors sooner (when possible). This will cause the following:

>>> if 1:
...     def error(a):
...         global a
...     def error2():
...         b = 1
...         global b
... 
  File "<stdin>", line 3
SyntaxError: name 'a' is parameter and global

However, in more complex (nested) cases, the global-after-assign will still be detected sooner:

>>> def error(a):
...     def inner():
...         global a
...     def inner2():
...         b = 1
...         global b
... 
  File "<stdin>", line 6
SyntaxError: name 'b' is assigned to before global declaration

Maybe there is a way to delay the detection of this error until second pass in symtable.c, but don't see now how to do this.

----------
keywords: +patch
Added file: http://bugs.python.org/file45849/syntax-error-order.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28936>
_______________________________________

From report at bugs.python.org  Sun Dec 11 09:27:10 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 11 Dec 2016 14:27:10 +0000
Subject: [issue28190] Cross-build _curses failed if host ncurses headers and
 target ncurses headers have different layouts
In-Reply-To: <1474132808.23.0.788365161086.issue28190@psf.upfronthosting.co.za>
Message-ID: <1481466430.2.0.692513038953.issue28190@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Hum, I did miss that line in configure.ac, thanks for pointing that out.
New patch.

----------
Added file: http://bugs.python.org/file45850/no-path-to-ncursesw_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28190>
_______________________________________

From report at bugs.python.org  Sun Dec 11 09:55:27 2016
From: report at bugs.python.org (Matt Joiner)
Date: Sun, 11 Dec 2016 14:55:27 +0000
Subject: [issue14156] argparse.FileType for '-' doesn't work for a mode of 'rb'
In-Reply-To: <1330513271.31.0.437438851478.issue14156@psf.upfronthosting.co.za>
Message-ID: <1481468127.87.0.819196230497.issue14156@psf.upfronthosting.co.za>


Matt Joiner added the comment:

This is why I stopped contributing to Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14156>
_______________________________________

From report at bugs.python.org  Sun Dec 11 10:11:42 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 11 Dec 2016 15:11:42 +0000
Subject: [issue28937] str.split(): remove empty strings when sep is not None
Message-ID: <1481469102.15.0.255147638686.issue28937@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw:

This has finally bugged me enough to file an issue, although I wouldn't be able to use it until Python 3.7.  There's a subtle but documented difference in str.split() when sep=None:

>>> help(''.split)
Help on built-in function split:

split(...) method of builtins.str instance
    S.split(sep=None, maxsplit=-1) -> list of strings
    
    Return a list of the words in S, using sep as the
    delimiter string.  If maxsplit is given, at most maxsplit
    splits are done. If sep is not specified or is None, any
    whitespace string is a separator and empty strings are
    removed from the result.

I.e., that empty strings are removed from the result.  This does not happen when sep is given, leading to this type of unfortunate code:

>>> 'foo,bar,baz'.split(',')
['foo', 'bar', 'baz']
>>> 'foo,bar,baz'.replace(',', ' ').split()
['foo', 'bar', 'baz']
>>> ''.split(',')
['']
>>> ''.replace(',', ' ').split()
[]

Specifically, code that wants to split on say commas, but has to handle the case where the source string is empty, shouldn't have to also filter out the single empty string item.

Obviously we can't change existing behavior, so I propose to add a keyword argument `prune` that would make these two bits of code identical:

>>> ''.split()
[]
>>> ''.split(' ', prune=True)
[]

and would handle the case of ''.split(',') without having to resort to creating an ephemeral intermediate string.

`prune` should be a keyword-only argument, defaulting to False.

----------
components: Library (Lib)
messages: 282923
nosy: barry
priority: normal
severity: normal
status: open
title: str.split(): remove empty strings when sep is not None
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28937>
_______________________________________

From report at bugs.python.org  Sun Dec 11 10:20:02 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 11 Dec 2016 15:20:02 +0000
Subject: [issue28739] PEP 498: docstrings as f-strings
In-Reply-To: <1479501831.35.0.531195928426.issue28739@psf.upfronthosting.co.za>
Message-ID: <1481469602.83.0.0289010699554.issue28739@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

It looks good to me, save for one tiny issue. I left a review comment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28739>
_______________________________________

From report at bugs.python.org  Sun Dec 11 10:26:42 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Sun, 11 Dec 2016 15:26:42 +0000
Subject: [issue28937] str.split(): remove empty strings when sep is not None
In-Reply-To: <1481469102.15.0.255147638686.issue28937@psf.upfronthosting.co.za>
Message-ID: <1481470002.63.0.941465466898.issue28937@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

I understand the feeling. However, in a project I maintain, we want the other way around - to be able to never have an empty list, even if the string is empty (we resorted to using re.split in the end, which has this behaviour). Consider:

rest = re.split(" +", rest)[0].strip()

This gives us None-like behaviour in splitting, at the cost of not actually using str.split.

I'm +1 on the idea, but I'd like some way to better generalize str.split use (not everyone knows you can pass None and/or an integer).

(At the same time, the counter arguments where str has too many methods, or that methods shouldn't do too much, also apply here.)

But I don't like bikeshedding too much, so let's just count me as +1 for your way, if there's no strong momentum for mine :)

----------
nosy: +ebarry
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28937>
_______________________________________

From report at bugs.python.org  Sun Dec 11 10:32:40 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Dec 2016 15:32:40 +0000
Subject: [issue28937] str.split(): remove empty strings when sep is not None
In-Reply-To: <1481469102.15.0.255147638686.issue28937@psf.upfronthosting.co.za>
Message-ID: <1481470360.74.0.839213636317.issue28937@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Current behavior is consistent with str.count():

    len(string.split(sep)) == string.count(sep) + 1

and re.split():

    re.split(re.escape(sep), string) == string.split(sep)

May be the behavior when sep is None should be changed for consistency with the behavior when sep is not None?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28937>
_______________________________________

From report at bugs.python.org  Sun Dec 11 10:35:54 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 11 Dec 2016 15:35:54 +0000
Subject: [issue28937] str.split(): remove empty strings when sep is not None
In-Reply-To: <1481470360.74.0.839213636317.issue28937@psf.upfronthosting.co.za>
Message-ID: <20161211103550.48ccb30b@subdivisions.wooz.org>


Barry A. Warsaw added the comment:

On Dec 11, 2016, at 03:32 PM, Serhiy Storchaka wrote:

>Current behavior is consistent with str.count():
>
>    len(string.split(sep)) == string.count(sep) + 1
>
>and re.split():
>
>    re.split(re.escape(sep), string) == string.split(sep)

Yep.  My suggestion is a straight up 'practicality beats purity' request.

>May be the behavior when sep is None should be changed for consistency with
>the behavior when sep is not None?

I'm very strongly -1 on changing any existing behavior.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28937>
_______________________________________

From report at bugs.python.org  Sun Dec 11 10:38:20 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Sun, 11 Dec 2016 15:38:20 +0000
Subject: [issue28937] str.split(): remove empty strings when sep is not None
In-Reply-To: <1481469102.15.0.255147638686.issue28937@psf.upfronthosting.co.za>
Message-ID: <1481470700.12.0.701741077441.issue28937@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

Changing the behaviour when sep is None is a big backwards-compatibility break, and I'm not sure we'd even want that. It's logical to allow passing None to mean the same thing as NULL (i.e. no arguments), and the behaviour in that case has been like that for... well, long enough that changing it isn't really feasible.

I agree with Barry here, especially since this is a completely opt-in feature, and existing behaviour isn't changed without the user's knowledge.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28937>
_______________________________________

From report at bugs.python.org  Sun Dec 11 10:57:39 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Dec 2016 15:57:39 +0000
Subject: [issue28937] str.split(): remove empty strings when sep is not None
In-Reply-To: <1481469102.15.0.255147638686.issue28937@psf.upfronthosting.co.za>
Message-ID: <1481471859.68.0.534946006522.issue28937@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I meant adding boolean argument that changes the behavior when sep is None, not when it is not None.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28937>
_______________________________________

From report at bugs.python.org  Sun Dec 11 11:01:56 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Sun, 11 Dec 2016 16:01:56 +0000
Subject: [issue28937] str.split(): remove empty strings when sep is not None
In-Reply-To: <1481469102.15.0.255147638686.issue28937@psf.upfronthosting.co.za>
Message-ID: <1481472116.69.0.270529880188.issue28937@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

That would work for my case, but it wouldn't for Barry's (unless I missed something). He wants a non-None argument to not leave empty strings, but I want a None argument to leave empty strings... I don't think there's a one-size-fits-all solution in this case, but feel free to prove me wrong :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28937>
_______________________________________

From report at bugs.python.org  Sun Dec 11 11:03:13 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 11 Dec 2016 16:03:13 +0000
Subject: [issue28937] str.split(): remove empty strings when sep is not None
In-Reply-To: <1481471859.68.0.534946006522.issue28937@psf.upfronthosting.co.za>
Message-ID: <20161211110310.35f62fdb@subdivisions.wooz.org>


Barry A. Warsaw added the comment:

On Dec 11, 2016, at 03:57 PM, Serhiy Storchaka wrote:

>I meant adding boolean argument that changes the behavior when sep is None,
>not when it is not None.

Ah, I understand now, thanks.  However, I'm not sure that addresses my
particular use case.  It's actually kind of handy to filter out the empty
strings.  But I'm open to counter arguments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28937>
_______________________________________

From report at bugs.python.org  Sun Dec 11 11:23:21 2016
From: report at bugs.python.org (INADA Naoki)
Date: Sun, 11 Dec 2016 16:23:21 +0000
Subject: [issue28818] simplify lookdict functions
In-Reply-To: <1480331020.89.0.515440713784.issue28818@psf.upfronthosting.co.za>
Message-ID: <1481473401.26.0.0201434791041.issue28818@psf.upfronthosting.co.za>


Changes by INADA Naoki <songofacandy at gmail.com>:


----------
stage: patch review -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28818>
_______________________________________

From report at bugs.python.org  Sun Dec 11 11:29:47 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Sun, 11 Dec 2016 16:29:47 +0000
Subject: [issue28937] str.split(): remove empty strings when sep is not None
In-Reply-To: <1481469102.15.0.255147638686.issue28937@psf.upfronthosting.co.za>
Message-ID: <1481473787.47.0.659388827852.issue28937@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

Actually, there might be a way. We could make prune default to True if sep is None, and default to False if sep is not None. That way, we get to keep the existing behaviour for either case, while satisfying both of our use cases :)

If that's a bad idea (and it quite probably is), I'll retract it. But it's an interesting possibility to at least consider.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28937>
_______________________________________

From report at bugs.python.org  Sun Dec 11 11:53:55 2016
From: report at bugs.python.org (Jon Dufresne)
Date: Sun, 11 Dec 2016 16:53:55 +0000
Subject: [issue28867] NamedTemporaryFile does not generate a ResourceWarning
 for unclosed files (unlike TemporaryFile)
In-Reply-To: <1480873647.39.0.877280517926.issue28867@psf.upfronthosting.co.za>
Message-ID: <1481475235.98.0.373109963092.issue28867@psf.upfronthosting.co.za>


Jon Dufresne added the comment:

I've taken a new approach to resolve the urllib issues.

I believe HTTPError _should not_ warn when __del__ is called as HTTPError wraps an existing resource instead of generating its own. IIUC, in this case, I believe it falls to the responsibility of code generating the resource to properly close and manage the resource (or pass that responsibility along). If I misunderstood, please let me know.

All feedback on the patch is welcome, thanks.

----------
Added file: http://bugs.python.org/file45851/namedtemporaryfile-resourcewarning-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28867>
_______________________________________

From report at bugs.python.org  Sun Dec 11 12:39:56 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 11 Dec 2016 17:39:56 +0000
Subject: [issue28739] PEP 498: docstrings as f-strings
In-Reply-To: <1479501831.35.0.531195928426.issue28739@psf.upfronthosting.co.za>
Message-ID: <20161211173952.117097.37964.3F5B0A89@psf.io>


Roundup Robot added the comment:

New changeset 30341d5c1423 by Serhiy Storchaka in branch '3.6':
Issue #28739: f-string expressions no longer accepted as docstrings and
https://hg.python.org/cpython/rev/30341d5c1423

New changeset 8e0f147dfa3d by Serhiy Storchaka in branch 'default':
Issue #28739: f-string expressions no longer accepted as docstrings and
https://hg.python.org/cpython/rev/8e0f147dfa3d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28739>
_______________________________________

From report at bugs.python.org  Sun Dec 11 12:41:59 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 11 Dec 2016 17:41:59 +0000
Subject: [issue28739] PEP 498: docstrings as f-strings
In-Reply-To: <1479501831.35.0.531195928426.issue28739@psf.upfronthosting.co.za>
Message-ID: <1481478119.38.0.361729649166.issue28739@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation -Interpreter Core
keywords:  -patch
nosy: +docs at python
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28739>
_______________________________________

From report at bugs.python.org  Sun Dec 11 13:17:02 2016
From: report at bugs.python.org (Matthew Barnett)
Date: Sun, 11 Dec 2016 18:17:02 +0000
Subject: [issue28937] str.split(): remove empty strings when sep is not None
In-Reply-To: <1481469102.15.0.255147638686.issue28937@psf.upfronthosting.co.za>
Message-ID: <1481480222.94.0.358147102504.issue28937@psf.upfronthosting.co.za>


Matthew Barnett added the comment:

So prune would default to None?

None means current behaviour (prune if sep is None else don't prune)
True means prune empty strings
False means don't prune empty string

----------
nosy: +mrabarnett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28937>
_______________________________________

From report at bugs.python.org  Sun Dec 11 14:00:22 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 11 Dec 2016 19:00:22 +0000
Subject: [issue28937] str.split(): remove empty strings when sep is not None
In-Reply-To: <1481469102.15.0.255147638686.issue28937@psf.upfronthosting.co.za>
Message-ID: <1481482822.84.0.045866357928.issue28937@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

A few randomly ordered thoughts about splitting:

* The best general purpose text splitter I've ever seen is in MS Excel and is called "Text to Columns".  It has a boolean flag, "treat consecutive delimiters as one" which is off by default.

* There is a nice discussion on the complexities of the current design on StackOverflow:  http://stackoverflow.com/questions/16645083  In addition, there are many other SO questions about the behavior of str.split().

* The learning curve for str.split() is already high.  The doc entry for it has been revised many times to try and explain what it does.  I'm concerned that adding another algorithmic option to it may make it more difficult to learn and use in the common cases (API design principle:  giving users more options can impair usability).  Usually in Python courses, I recommend using str.split() for the simple, common cases and using regex when you need more control.

* What I do like about the proposal is that that there is no clean way to take the default whitespace splitting algorithm and customize to a particular subset of whitespace (i.e. tabs only).

* A tangential issue is that it was a mistake to expose the maxsplit=-1 implementation detail.   In Python 2.7, the help was "S.split([sep [,maxsplit]])".  But folks implementing the argument clinic have no way of coping with optional arguments that don't have a default value (like dict.pop), so they changed the API so that the implementation detail was exposed, "S.split(sep=None, maxsplit=-1)".   IMO, this is an API regression.  We really don't want people passing in -1 to indicate that there are no limits.  The Python way would have been to use None as a default or to stick with the existing API where the number of arguments supplied is part of the API (much like type() has two different meanings depending on whether it has an arity of 1 or 3).

Overall, I'm +0 on the proposal but there should be good consideration given to 1) whether there is a sufficient need to warrant increasing API complexity, making split() more difficult to learn and remember, 2) considering whether "prune" is the right word (can someone who didn't write the code read it clearly afterwards), 3) or addressing this through documentation (i.e. showing the simple regexes needed for cases not covered by str.split).

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28937>
_______________________________________

From report at bugs.python.org  Sun Dec 11 14:01:25 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 11 Dec 2016 19:01:25 +0000
Subject: [issue28929] Provide a link from documentation back to its source file
In-Reply-To: <1481331536.86.0.539237207001.issue28929@psf.upfronthosting.co.za>
Message-ID: <1481482885.09.0.710575093877.issue28929@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Thanks for the patch, Mariatta! Once we have migrated to GitHub we can apply the patch (don't let me forget :) ).

Any version still under active maintenance should probably be updated, so that would probably mean 2.7 but not the other versions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28929>
_______________________________________

From report at bugs.python.org  Sun Dec 11 14:06:14 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 11 Dec 2016 19:06:14 +0000
Subject: [issue25711] Rewrite zipimport from scratch
In-Reply-To: <1448296120.48.0.872112518039.issue25711@psf.upfronthosting.co.za>
Message-ID: <1481483174.47.0.538745871869.issue25711@psf.upfronthosting.co.za>


Brett Cannon added the comment:

And having a private copy of os.fsdecode() isn't difficult as os.fspath() is in posix and after that it's four lines that only need access to the sys module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25711>
_______________________________________

From report at bugs.python.org  Sun Dec 11 14:23:50 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 11 Dec 2016 19:23:50 +0000
Subject: [issue16737] Different behaviours in script run directly and via
 runpy.run_module
In-Reply-To: <1356010622.32.0.479096681415.issue16737@psf.upfronthosting.co.za>
Message-ID: <1481484230.82.0.331673613299.issue16737@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Maybe we just need to clarify some documentation at this point? All of the differences in semantics make total sense when you realize `-m pkg` is really conceptually shorthand for `import pkg.__main__` (w/ the appropriate __name__ flourishes). When you begin to view it that way then specifying the file path starts to look like the odd way by bypassing import and simply running open() on a file and passing the result to exec() (once again, with the appropriate __name__ flourishes). It also makes the point that -m isn't really shorthand for specifying a script which seems to be where people are getting tripped up by the differences.

So instead of selling `-m` as a way to run a module/package as a script, I say we change the message/documentation to say it does an import with __name__ changed and make specifying a script as the weird reading-a-file-directly thing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16737>
_______________________________________

From report at bugs.python.org  Sun Dec 11 14:26:14 2016
From: report at bugs.python.org (Julien Palard)
Date: Sun, 11 Dec 2016 19:26:14 +0000
Subject: [issue28753] Clinic: Converting Your First Function is not up to date
In-Reply-To: <1479660244.5.0.379774731624.issue28753@psf.upfronthosting.co.za>
Message-ID: <1481484374.59.0.585250912063.issue28753@psf.upfronthosting.co.za>


Changes by Julien Palard <julien+python at palard.fr>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28753>
_______________________________________

From report at bugs.python.org  Sun Dec 11 14:30:08 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 11 Dec 2016 19:30:08 +0000
Subject: [issue28849] do not define sys.implementation._multiarch on Android
In-Reply-To: <1480579567.9.0.848858013461.issue28849@psf.upfronthosting.co.za>
Message-ID: <1481484608.91.0.276254739139.issue28849@psf.upfronthosting.co.za>


Changes by Xavier de Gaye <xdegaye at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28849>
_______________________________________

From report at bugs.python.org  Sun Dec 11 14:30:35 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 11 Dec 2016 19:30:35 +0000
Subject: [issue28918] cross compiling xxlimited fails with "Py_LIMITED_API is
 incompatible with Py_DEBUG"
In-Reply-To: <1481273483.19.0.548102187262.issue28918@psf.upfronthosting.co.za>
Message-ID: <1481484635.5.0.907825287235.issue28918@psf.upfronthosting.co.za>


Changes by Xavier de Gaye <xdegaye at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28918>
_______________________________________

From report at bugs.python.org  Sun Dec 11 15:14:26 2016
From: report at bugs.python.org (Steffen Ullrich)
Date: Sun, 11 Dec 2016 20:14:26 +0000
Subject: [issue28938] match_hostname treats SAN IP address as DNS name and
 fails to check CN then
Message-ID: <1481487266.54.0.545771157838.issue28938@psf.upfronthosting.co.za>


New submission from Steffen Ullrich:

from Lib/ssl.py

303        elif key == 'IP Address':
304            if host_ip is not None and _ipaddress_match(value, host_ip):
305                return
306            dnsnames.append(value)
307    if not dnsnames:
308        # The subject is only checked when there is no dNSName entry
309        # in subjectAltName

RFC 2818 and RFC 6125 say that CN should not be used if subjectAltNames contains DNS names. This means CN should still be checked if SAN contains only IP addresses. By appending IP address to dnsnames in line 306 it will not check the CN if there are no DNS names in SAN but only IP address.

See also http://stackoverflow.com/questions/41089539/authentication-issue-with-ssl-certificate-using-python-requests-lib/41090559#41090559

----------
messages: 282940
nosy: noxxi
priority: normal
severity: normal
status: open
title: match_hostname treats SAN IP address as DNS name and fails to check CN then
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28938>
_______________________________________

From report at bugs.python.org  Sun Dec 11 15:14:50 2016
From: report at bugs.python.org (Ned Deily)
Date: Sun, 11 Dec 2016 20:14:50 +0000
Subject: [issue28783] Embedded/nuget packages incorrectly reference
 bdist_wininst
In-Reply-To: <1479925784.02.0.834073933599.issue28783@psf.upfronthosting.co.za>
Message-ID: <1481487290.06.0.249801047063.issue28783@psf.upfronthosting.co.za>


Ned Deily added the comment:

I agree that the risk if this is applied appears to be minimal.  If Paul or Zack are OK with it and your testing is successful, I'll plan on cherrypicking it for 3.6.0 final.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28783>
_______________________________________

From report at bugs.python.org  Sun Dec 11 15:15:32 2016
From: report at bugs.python.org (Ned Deily)
Date: Sun, 11 Dec 2016 20:15:32 +0000
Subject: [issue28938] match_hostname treats SAN IP address as DNS name and
 fails to check CN then
In-Reply-To: <1481487266.54.0.545771157838.issue28938@psf.upfronthosting.co.za>
Message-ID: <1481487332.57.0.928440402605.issue28938@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
nosy: +alex, christian.heimes, dstufft, janssen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28938>
_______________________________________

From report at bugs.python.org  Sun Dec 11 15:15:48 2016
From: report at bugs.python.org (Jeroen Demeyer)
Date: Sun, 11 Dec 2016 20:15:48 +0000
Subject: [issue5322] Python 2.6 object.__new__ argument calling autodetection
 faulty
In-Reply-To: <1235075665.37.0.301694124748.issue5322@psf.upfronthosting.co.za>
Message-ID: <1481487348.2.0.231736540645.issue5322@psf.upfronthosting.co.za>


Jeroen Demeyer added the comment:

Here is more minimal breaking example. This clearly shows that this patch breaks backwards compatibility.

```
$ cat obj.pyx
cdef class OBJ(object):
    pass

$ ipython
Python 2.7.13rc1 (default, Dec 11 2016, 14:21:24) 
Type "copyright", "credits" or "license" for more information.

IPython 5.1.0 -- An enhanced Interactive Python.
?         -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help      -> Python's own help system.
object?   -> Details about 'object', use 'object??' for extra details.

In [1]: import pyximport; pyximport.install()
Out[1]: (None, <pyximport.pyximport.PyxImporter at 0x7f8e8c585910>)

In [2]: import obj

In [3]: class X(obj.OBJ, dict):
   ...:     pass
   ...: 

In [4]: X()
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-4-a7d4f7b89654> in <module>()
----> 1 X()

TypeError: obj.OBJ.__new__(X) is not safe, use dict.__new__()
```

----------
nosy: +jdemeyer

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5322>
_______________________________________

From report at bugs.python.org  Sun Dec 11 15:16:23 2016
From: report at bugs.python.org (Greg Solomon)
Date: Sun, 11 Dec 2016 20:16:23 +0000
Subject: [issue28939] Groupby Is Roughly Equivalent To ...
Message-ID: <1481487383.57.0.242190046836.issue28939@psf.upfronthosting.co.za>


New submission from Greg Solomon:

https://docs.python.org/3/library/itertools.html#itertools.groupby

I found the "equivalent" code a bit hard to read. Is there any merit in changing it to something a bit like the following ?

Kind Rgds, Greg

class groupby:
    def __init__( self , iterable , key_function = ( lambda x: x ) ):
        self.iterable = iter( iterable )
        self.key_function = key_function
        self.FINISHED = object()
        try:
            self.next_value = next( self.iterable )
        except StopIteration: 
            self.next_value = self.FINISHED
    def __iter__( self ):
        return self
    def __next__( self ):
        if self.next_value == self.FINISHED:
            raise StopIteration
        self.group_key_value = self.key_function( self.next_value )
        return ( self.group_key_value , self._group() )
    def _group( self ):
        while self.next_value != self.FINISHED \
          and self.group_key_value == self.key_function( self.next_value ):
            yield self.next_value
            try:
                self.next_value = next( self.iterable )
            except StopIteration:
                self.next_value = self.FINISHED 
        return

----------
assignee: docs at python
components: Documentation
messages: 282943
nosy: docs at python, greg.solomon
priority: normal
severity: normal
status: open
title: Groupby Is Roughly Equivalent To ...
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28939>
_______________________________________

From report at bugs.python.org  Sun Dec 11 15:17:51 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 11 Dec 2016 20:17:51 +0000
Subject: [issue5322] Python 2.6 object.__new__ argument calling autodetection
 faulty
In-Reply-To: <1235075665.37.0.301694124748.issue5322@psf.upfronthosting.co.za>
Message-ID: <1481487471.03.0.681338727182.issue5322@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy:  -pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5322>
_______________________________________

From report at bugs.python.org  Sun Dec 11 15:23:40 2016
From: report at bugs.python.org (Paul Moore)
Date: Sun, 11 Dec 2016 20:23:40 +0000
Subject: [issue28783] Embedded/nuget packages incorrectly reference
 bdist_wininst
In-Reply-To: <1479925784.02.0.834073933599.issue28783@psf.upfronthosting.co.za>
Message-ID: <1481487820.82.0.656525846931.issue28783@psf.upfronthosting.co.za>


Paul Moore added the comment:

I'm OK for this to go in.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28783>
_______________________________________

From report at bugs.python.org  Sun Dec 11 15:26:32 2016
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 11 Dec 2016 20:26:32 +0000
Subject: [issue28938] match_hostname treats SAN IP address as DNS name and
 fails to check CN then
In-Reply-To: <1481487266.54.0.545771157838.issue28938@psf.upfronthosting.co.za>
Message-ID: <1481487992.63.0.371073571396.issue28938@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Python's implementation of host name verification conforms to RFC 6125, section 6.4.4. The CN check is optional (MAY). Python treats the presence of an IP Address as indicator that CN check should not be performed. 

In fact hostname verification code should be more strict and not fall back to CN when a SRV-ID or URI is present. But the ssl module lacks support to fetch SRV-ID, see #28191. Since public CAs and members of the CAB forum are not yet allowed to issue certificates with SRV-ID, it's not a security issue.


https://tools.ietf.org/html/rfc6125#section-6.4.4

6.4.4.  Checking of Common Names

   As noted, a client MUST NOT seek a match for a reference identifier
   of CN-ID if the presented identifiers include a DNS-ID, SRV-ID,
   URI-ID, or any application-specific identifier types supported by the
   client.

   Therefore, if and only if the presented identifiers do not include a
   DNS-ID, SRV-ID, URI-ID, or any application-specific identifier types
   supported by the client, then the client MAY as a last resort check
   for a string whose form matches that of a fully qualified DNS domain
   name in a Common Name field of the subject field (i.e., a CN-ID).

----------
assignee:  -> christian.heimes
components: +SSL
resolution:  -> not a bug
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28938>
_______________________________________

From report at bugs.python.org  Sun Dec 11 15:53:16 2016
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 11 Dec 2016 20:53:16 +0000
Subject: [issue28940] __length_hint__ isn't a hint for list()
Message-ID: <1481489596.88.0.223371500433.issue28940@psf.upfronthosting.co.za>


New submission from Ronald Oussoren:

The following code raises MemoryError instead of creating an empty list:

# START
import sys

class CustomIter:
    def __iter__(self):
        return self
    def __next__(self):
        raise StopIteration
    def __length_hint__(self):
        return sys.maxsize

l = list(CustomIter())
#END

That's because this empty iterator has a __length_hint__ that claims it returns a very large number of methods. 

The function listextend in Objects/listobject.c already ignores __length_hint__() when using it would overflow the size of the list, it would IMHO also be better to ignore the length hint when the attempt to resize fails as __length_hint__() is documented as a hint that may be incorrect.

----------
components: Interpreter Core
messages: 282946
nosy: ronaldoussoren
priority: normal
severity: normal
status: open
title: __length_hint__ isn't a hint for list()
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28940>
_______________________________________

From report at bugs.python.org  Sun Dec 11 15:54:02 2016
From: report at bugs.python.org (Julien Palard)
Date: Sun, 11 Dec 2016 20:54:02 +0000
Subject: [issue28939] Groupby Is Roughly Equivalent To ...
In-Reply-To: <1481487383.57.0.242190046836.issue28939@psf.upfronthosting.co.za>
Message-ID: <1481489642.34.0.864343374701.issue28939@psf.upfronthosting.co.za>


Julien Palard added the comment:

I renamed your function groupby2 to compare it with itertools.groupby and tested but:

>>> print(list(groupby2(['A', 'B'])))

does not returns, looks like your implementation have a bug, so I tried:

>>> for k in groupby2(['A', 'B']):
...     print(k)

and I'm getting loads of:

('A', <generator object groupby2._group at 0x7f0476809f10>)
('A', <generator object groupby2._group at 0x7f0476851f68>)
('A', <generator object groupby2._group at 0x7f0476809f10>)
('A', <generator object groupby2._group at 0x7f0476851f68>)
('A', <generator object groupby2._group at 0x7f0476809f10>)
('A', <generator object groupby2._group at 0x7f0476851f68>)
('A', <generator object groupby2._group at 0x7f0476809f10>)
('A', <generator object groupby2._group at 0x7f0476851f68>)
('A', <generator object groupby2._group at 0x7f0476809f10>)
('A', <generator object groupby2._group at 0x7f0476851f68>)

You may also want to test your implementation against https://github.com/python/cpython/blob/master/Lib/test/test_itertools.py#L699

----------
nosy: +mdk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28939>
_______________________________________

From report at bugs.python.org  Sun Dec 11 15:57:41 2016
From: report at bugs.python.org (Cory Benfield)
Date: Sun, 11 Dec 2016 20:57:41 +0000
Subject: [issue28938] match_hostname treats SAN IP address as DNS name and
 fails to check CN then
In-Reply-To: <1481487266.54.0.545771157838.issue28938@psf.upfronthosting.co.za>
Message-ID: <1481489861.04.0.740571199207.issue28938@psf.upfronthosting.co.za>


Changes by Cory Benfield <cory at lukasa.co.uk>:


----------
nosy: +Lukasa
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28938>
_______________________________________

From report at bugs.python.org  Sun Dec 11 16:21:20 2016
From: report at bugs.python.org (paul j3)
Date: Sun, 11 Dec 2016 21:21:20 +0000
Subject: [issue14156] argparse.FileType for '-' doesn't work for a mode of 'rb'
In-Reply-To: <1330513271.31.0.437438851478.issue14156@psf.upfronthosting.co.za>
Message-ID: <1481491280.73.0.0830813906503.issue14156@psf.upfronthosting.co.za>


paul j3 added the comment:

The problem with the argparse backlog is that the original author of the module is too busy with other things.  And no one has stepped into his shoes.  There are people with experience in apply patches, and people who know the argparse code well, but few, if any with both skills (and/or the time to invest in this module).  

In addition the module has some serious backward compatibility issues.  I know of several patches that were applied, and then withdrawn because of unforseen (or at least untested) compatibility problems.  

While I commented earlier, I don't recall testing it.  I just tried it now, and ran into problems - until I realized this isn't compatible with Python2.7.  Py3 is the development world, but there's still a lot of PY2 use (e.g look at Stackoverflow argparse questions).  On SO if people have problems with FileType, I often recommend that they just accept the filename, and take care of opening it themselves.  

To raise the attention to this patch I'd suggest 

- making the case that it is really needed

- demonstrating that it has been field tested, and is free of backward compatibility issues.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14156>
_______________________________________

From report at bugs.python.org  Sun Dec 11 16:32:24 2016
From: report at bugs.python.org (Steve Dower)
Date: Sun, 11 Dec 2016 21:32:24 +0000
Subject: [issue28783] Embedded/nuget packages incorrectly reference
 bdist_wininst
In-Reply-To: <1479925784.02.0.834073933599.issue28783@psf.upfronthosting.co.za>
Message-ID: <1481491944.71.0.562035382298.issue28783@psf.upfronthosting.co.za>


Steve Dower added the comment:

Is it easy to cherry pick a merge commit? This will go into 3.5 first, but I can null merge and then clean commit it if that's easier?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28783>
_______________________________________

From report at bugs.python.org  Sun Dec 11 16:39:39 2016
From: report at bugs.python.org (Steffen Ullrich)
Date: Sun, 11 Dec 2016 21:39:39 +0000
Subject: [issue28938] match_hostname treats SAN IP address as DNS name and
 fails to check CN then
In-Reply-To: <1481487992.63.0.371073571396.issue28938@psf.upfronthosting.co.za>
Message-ID: <20161211213937.GA30708@chksum.de>


Steffen Ullrich added the comment:

On Sun, Dec 11, 2016 at 08:26:32PM +0000, Christian Heimes <report at bugs.python.org> wrote:
> 
> Christian Heimes added the comment:
> 
> Python's implementation of host name verification conforms to RFC 6125, section 6.4.4. The CN check is optional (MAY). Python treats the presence of an IP Address as indicator that CN check should not be performed. 

RFC 6125 does not obsolete RFC 2818. In fact it says in section 1.4:

   This document also does not supersede the rules for verifying service
   identity provided in specifications for existing application
   protocols published prior to this document, such as those excerpted
   under Appendix B...

Where Appendix B.2 explicitly cites the relevant parts from RFC 2818 like this
in section 3.1:

  If a subjectAltName extension of type dNSName is present, that MUST
  be used as the identity. Otherwise, the (most specific) Common Name
  field in the Subject field of the certificate MUST be used.

Thus while RFC 6125 might say MAY for checking the CN the more specific RFC
2818 says clearly MUST. Also, the intention of RFC 6125 in 6.4.4 is in my
opinion to distinguish between applications never checking the CN and
applications which check the CN, while addressing the last ones that CN
should not be checked for specific SAN record types. iPAddress is not a type
which is considered for this special treatment.

Regards,
Steffen

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28938>
_______________________________________

From report at bugs.python.org  Sun Dec 11 16:39:56 2016
From: report at bugs.python.org (Ned Deily)
Date: Sun, 11 Dec 2016 21:39:56 +0000
Subject: [issue28783] Embedded/nuget packages incorrectly reference
 bdist_wininst
In-Reply-To: <1479925784.02.0.834073933599.issue28783@psf.upfronthosting.co.za>
Message-ID: <1481492396.08.0.705655949661.issue28783@psf.upfronthosting.co.za>


Ned Deily added the comment:

Just do your normal thing.  I'll make it work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28783>
_______________________________________

From report at bugs.python.org  Sun Dec 11 17:48:55 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 11 Dec 2016 22:48:55 +0000
Subject: [issue28783] Embedded/nuget packages incorrectly reference
 bdist_wininst
In-Reply-To: <1479925784.02.0.834073933599.issue28783@psf.upfronthosting.co.za>
Message-ID: <20161211224852.117179.96833.0B8A3BAC@psf.io>


Roundup Robot added the comment:

New changeset 47bf09270027 by Steve Dower in branch '3.5':
Issue #28783: Replaces bdist_wininst in nuget packages with stub
https://hg.python.org/cpython/rev/47bf09270027

New changeset b8b1ad21e073 by Steve Dower in branch '3.6':
Issue #28783: Replaces bdist_wininst in nuget packages with stub
https://hg.python.org/cpython/rev/b8b1ad21e073

New changeset 402a227564f5 by Steve Dower in branch 'default':
Issue #28783: Replaces bdist_wininst in nuget packages with stub
https://hg.python.org/cpython/rev/402a227564f5

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28783>
_______________________________________

From report at bugs.python.org  Sun Dec 11 17:49:44 2016
From: report at bugs.python.org (Steve Dower)
Date: Sun, 11 Dec 2016 22:49:44 +0000
Subject: [issue28783] Embedded/nuget packages incorrectly reference
 bdist_wininst
In-Reply-To: <1479925784.02.0.834073933599.issue28783@psf.upfronthosting.co.za>
Message-ID: <1481496584.71.0.146448866572.issue28783@psf.upfronthosting.co.za>


Steve Dower added the comment:

Thanks Ned, it's all yours.

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28783>
_______________________________________

From report at bugs.python.org  Sun Dec 11 18:50:58 2016
From: report at bugs.python.org (Ray Satiro)
Date: Sun, 11 Dec 2016 23:50:58 +0000
Subject: [issue28938] match_hostname treats SAN IP address as DNS name and
 fails to check CN then
In-Reply-To: <1481487266.54.0.545771157838.issue28938@psf.upfronthosting.co.za>
Message-ID: <1481500258.28.0.779300634635.issue28938@psf.upfronthosting.co.za>


Changes by Ray Satiro <raysatiro at yahoo.com>:


----------
nosy: +raysatiro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28938>
_______________________________________

From report at bugs.python.org  Sun Dec 11 18:58:37 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Sun, 11 Dec 2016 23:58:37 +0000
Subject: [issue28937] str.split(): remove empty strings when sep is not None
In-Reply-To: <1481469102.15.0.255147638686.issue28937@psf.upfronthosting.co.za>
Message-ID: <1481500717.29.0.664650266744.issue28937@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

Matthew: Yes, that's exactly the way I was going about it.

Thank you Raymond for your comments (and your informative answer on that SO question).

I think that part of the problem is that no delimiter (or None) behaves differently than with a delimiter. If we wanted proper consistency, we would have needed to make passing None (or nothing) the same as passing whitespace, but alas, we have to work with what we have.

As you said, API complexity is a concern that needs to be addressed. I think that the most important part is how it's documented, and, if phrased correctly (which is non-trivial), could actually simplify the explanation.

Consider this draft:

***

The value of the `prune` keyword argument determines whether or not consecutive delimiters should be grouped together. If `prune` is not given or None, it defaults to True if sep is None or not given, and False otherwise.

If `prune` is True, consecutive delimiters (all whitespace if None or not given) are regarded as a single separator, and the result will not contain any empty string. The resulting list may be empty.

Otherwise, if `prune` is False, consecutive delimiters are not grouped together, and the result may contain one or more empty string. The resulting list will never be empty.

***

I may be oversimplifying this, but it seems to me that this might help some people by hopefully streamlining the explanation.

This still doesn't solve the issue where a user can't say "split on a space or a tab, but not newlines", which IMO is lacking in the design, but that may be for another issue ;)

I've wrapped up a basic patch which probably doesn't work at all; I'll put it up when it's at least partly working for everyone to look at.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28937>
_______________________________________

From report at bugs.python.org  Sun Dec 11 19:46:07 2016
From: report at bugs.python.org (Jon Dufresne)
Date: Mon, 12 Dec 2016 00:46:07 +0000
Subject: [issue28867] NamedTemporaryFile does not generate a ResourceWarning
 for unclosed files (unlike TemporaryFile)
In-Reply-To: <1480873647.39.0.877280517926.issue28867@psf.upfronthosting.co.za>
Message-ID: <1481503567.16.0.0975103570553.issue28867@psf.upfronthosting.co.za>


Jon Dufresne added the comment:

I decided to try a new direction.

Instead of modifying _TemporaryFileCloser to handle urllib, I've changed urllib classes to not inherit from _TemporaryFileCloser. The urllib classes are not temporary files as built by tempfile, so I believe this makes more sense. There is a small amount of code copied to the existing class, but I believe this cleans up the inheritance in a way that makes more sense for the given objects and requires fewer workarounds.

All feedback on this alternative approach is welcome. Thanks.

----------
Added file: http://bugs.python.org/file45852/namedtemporaryfile-resourcewarning-4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28867>
_______________________________________

From report at bugs.python.org  Sun Dec 11 20:42:04 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 12 Dec 2016 01:42:04 +0000
Subject: [issue16737] Different behaviours in script run directly and via
 runpy.run_module
In-Reply-To: <1356010622.32.0.479096681415.issue16737@psf.upfronthosting.co.za>
Message-ID: <1481506924.94.0.769855159834.issue16737@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Something we don't really have anywhere is a short summary of how sys.path[0] gets initialised - it's scattered through the descriptions of the various invocation options in https://docs.python.org/3/using/cmdline.html#interface-options

I figure it's also worth mentioning https://bugs.python.org/issue13475 where we discussed the idea of a "--nopath0" option so folks could easily disable imports from the current directory (-c, -m) or from the script directory (direct execution) without otherwise impacting startup behaviour. (Specifying --nopath0, and then requesting execution of a directory or zipfile would necessarily be an error, since modifying sys.path[0] is an essential part of making those work)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16737>
_______________________________________

From report at bugs.python.org  Sun Dec 11 21:13:07 2016
From: report at bugs.python.org (John Huang)
Date: Mon, 12 Dec 2016 02:13:07 +0000
Subject: [issue28444] Missing extensions modules when cross compiling python
 3.5.2 for arm on Linux
In-Reply-To: <1476459283.66.0.870064519048.issue28444@psf.upfronthosting.co.za>
Message-ID: <1481508787.68.0.424224602601.issue28444@psf.upfronthosting.co.za>


John Huang added the comment:

The same issue in Python 2.7.12. Some extensions modules are not built if cross-compiling.

----------
nosy: +John Huang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28444>
_______________________________________

From report at bugs.python.org  Sun Dec 11 21:31:57 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Mon, 12 Dec 2016 02:31:57 +0000
Subject: [issue28937] str.split(): remove empty strings when sep is not None
In-Reply-To: <1481469102.15.0.255147638686.issue28937@psf.upfronthosting.co.za>
Message-ID: <1481509917.71.0.687144588462.issue28937@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

Here's an initial patch. It works exactly as discussed earlier, doesn't break any tests, and retains full backwards compatibility. No doc changes (except for the docstrings of str.[r]split) and no tests, as this is just a preliminary patch to see if there's any merit to the idea.

----------
keywords: +patch
stage:  -> test needed
Added file: http://bugs.python.org/file45853/split_prune_1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28937>
_______________________________________

From report at bugs.python.org  Sun Dec 11 21:58:11 2016
From: report at bugs.python.org (Mariatta Wijaya)
Date: Mon, 12 Dec 2016 02:58:11 +0000
Subject: [issue28929] Provide a link from documentation back to its source file
In-Reply-To: <1481331536.86.0.539237207001.issue28929@psf.upfronthosting.co.za>
Message-ID: <1481511491.57.0.385093873644.issue28929@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

Thanks, Brett.

Here's the patch that will work for the 2.7 branch.

----------
Added file: http://bugs.python.org/file45854/issue28929-v27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28929>
_______________________________________

From report at bugs.python.org  Sun Dec 11 22:03:28 2016
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 12 Dec 2016 03:03:28 +0000
Subject: [issue26546] Provide translated french translation on docs.python.org
In-Reply-To: <1457794223.79.0.618185263259.issue26546@psf.upfronthosting.co.za>
Message-ID: <1481511808.8.0.485045149853.issue26546@psf.upfronthosting.co.za>


Changes by INADA Naoki <songofacandy at gmail.com>:


----------
dependencies: +"CPython implementation detail:" removed when content translated

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26546>
_______________________________________

From report at bugs.python.org  Sun Dec 11 22:36:59 2016
From: report at bugs.python.org (Mariatta Wijaya)
Date: Mon, 12 Dec 2016 03:36:59 +0000
Subject: [issue28941] Update the link to Source Code in Python Docs from hg to
 github
Message-ID: <1481513819.65.0.156579360966.issue28941@psf.upfronthosting.co.za>


New submission from Mariatta Wijaya:

Some Python docs include a link to the Source Code, for example: https://docs.python.org/3.6/library/abc.html

Once the repo is moved to github, the link should probably be updated to point to github:
https://github.com/python/cpython/blob/master/Lib/abc.py

----------
assignee: docs at python
components: Documentation
messages: 282960
nosy: Mariatta, docs at python
priority: normal
severity: normal
status: open
title: Update the link to Source Code in Python Docs from hg to github
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28941>
_______________________________________

From report at bugs.python.org  Sun Dec 11 22:39:08 2016
From: report at bugs.python.org (Mariatta Wijaya)
Date: Mon, 12 Dec 2016 03:39:08 +0000
Subject: [issue28941] Update the link to Source Code in Python Docs from hg to
 github
In-Reply-To: <1481513819.65.0.156579360966.issue28941@psf.upfronthosting.co.za>
Message-ID: <1481513948.6.0.597355957266.issue28941@psf.upfronthosting.co.za>


Changes by Mariatta Wijaya <mariatta.wijaya at gmail.com>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28941>
_______________________________________

From report at bugs.python.org  Sun Dec 11 23:22:01 2016
From: report at bugs.python.org (Sye van der Veen)
Date: Mon, 12 Dec 2016 04:22:01 +0000
Subject: [issue28937] str.split(): remove empty strings when sep is not None
In-Reply-To: <1481469102.15.0.255147638686.issue28937@psf.upfronthosting.co.za>
Message-ID: <1481516521.19.0.168126027781.issue28937@psf.upfronthosting.co.za>


Sye van der Veen added the comment:

In the sep!=None case, there are existing alternatives to prune=True that aren't many more keystrokes:

>>> ''.split(' ', prune=True)
[]
>>> [x for x in ''.split(' ') if x]
[]
>>> list(filter(bool, ''.split(' '))) # or drop list() and use the iterator directly
[]

This becomes even fewer keystrokes for users that create a prune() or split_prune() function.

For the sep==None case, I agree there are no alternatives to prune=False (aside from rolling your own split function).  However, instead of prune, what if sep accepted a tuple of strings, similar to startswith.  In this case, each string would be considered one possible, yet distinct, delimiter:

>> ''.split(prune=False)
['']
>> ''.split((' ', '\t')) # typical whitespace
['']
>> ''.split(tuple(string.whitespace)) # ASCII whitespace
['']

Once again, this becomes even easier for users that create a split_no_prune() function, or that assign tuple(string.whitespace) to a variable.  It would also nicely handle strings with non-homogeneous delimiters:

>>> '1?2,,3;'.split((',', ';', '?'))
['1', '2', '', '3', '']

I personally find the 0-argument str.split() one of the great joys of Python.  It's common to have to split out words from a sentence, and having that functionality just 8 characters away at all times has been very useful.

----------
nosy: +syeberman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28937>
_______________________________________

From report at bugs.python.org  Sun Dec 11 23:38:29 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Mon, 12 Dec 2016 04:38:29 +0000
Subject: [issue28937] str.split(): remove empty strings when sep is not None
In-Reply-To: <1481469102.15.0.255147638686.issue28937@psf.upfronthosting.co.za>
Message-ID: <1481517509.13.0.608232130107.issue28937@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

Yes, I agree that being able to pass in a tuple would be really useful. As far as rolling out a custom function goes, I'd sooner reach for re.split than do that, so I don't really have a strong argument for either side. Feel free to play with the patch or make an entirely new one, though! I mainly submitted the patch to keep the discussion going, and eventually come to a concensus, but I don't have a strong opinion either way :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28937>
_______________________________________

From report at bugs.python.org  Mon Dec 12 00:09:27 2016
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Mon, 12 Dec 2016 05:09:27 +0000
Subject: [issue28937] str.split(): remove empty strings when sep is not None
In-Reply-To: <1481469102.15.0.255147638686.issue28937@psf.upfronthosting.co.za>
Message-ID: <1481519367.31.0.393972221.issue28937@psf.upfronthosting.co.za>


Vedran ?a?i? added the comment:

The problem with .split is its split (pun intended) personality: it really is two functions that have separate use cases, and have different algorithms; and people think about them as separate functions. In that view, we have just fallen afoul of Guido's rule of no literal passing bool arguments. The true solution would probably be to bite the bullet and have two separate methods. After all, .splitlines is a separate method for precisely such a reason.

----------
nosy: +veky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28937>
_______________________________________

From report at bugs.python.org  Mon Dec 12 00:26:55 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 12 Dec 2016 05:26:55 +0000
Subject: [issue28180] sys.getfilesystemencoding() should default to utf-8
In-Reply-To: <1474024622.65.0.838685461995.issue28180@psf.upfronthosting.co.za>
Message-ID: <1481520415.25.0.991854549409.issue28180@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I think we're genuinely getting to the point now where the majority of "LANG=C" cases are misconfigurations rather than intended behaviour. We're also to the point where:

- on Mac OS X, binary system interfaces have been handled as UTF-8 by default since 3.0
- on Windows, as of 3.6, the OS native binary system interfaces are now bypassed entirely in favour of transcoding from UTF-8 to UTF-16-LE 

So I think for Python 3.7 it makes sense to do the following on other *nix systems:

- very early in CPython startup (even before argument processing), if the detected locale is "C", force it to "C.UTF-8" if possible, and print a warning either way
- add a PYTHONKEEPASCIILOCALE environment variable to turn that behaviour off

I do think we actually want to *change* the C level locale in the process though, as otherwise we can expect to see weird interactions where CPython and extension modules disagree about the default text encoding.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28180>
_______________________________________

From report at bugs.python.org  Mon Dec 12 00:29:16 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 12 Dec 2016 05:29:16 +0000
Subject: [issue28180] sys.getfilesystemencoding() should default to utf-8
In-Reply-To: <1474024622.65.0.838685461995.issue28180@psf.upfronthosting.co.za>
Message-ID: <1481520556.3.0.640346525497.issue28180@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Note also that if we say we're going to do this for 3.7, *and* go ahead and implement it, then distros may be more inclined to incorporate the same behavioural changes into distro-provided releases of 3.6, providing real world testing of the concept before we make it the default behaviour.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28180>
_______________________________________

From report at bugs.python.org  Mon Dec 12 01:02:41 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 12 Dec 2016 06:02:41 +0000
Subject: [issue28939] Groupby Is Roughly Equivalent To ...
In-Reply-To: <1481487383.57.0.242190046836.issue28939@psf.upfronthosting.co.za>
Message-ID: <1481522561.64.0.618591687364.issue28939@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee: docs at python -> rhettinger
nosy: +rhettinger
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28939>
_______________________________________

From report at bugs.python.org  Mon Dec 12 01:06:04 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 12 Dec 2016 06:06:04 +0000
Subject: [issue25035] Getter/setter for argparse keys
In-Reply-To: <1441753315.66.0.921652253193.issue25035@psf.upfronthosting.co.za>
Message-ID: <1481522764.84.0.684949612824.issue25035@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +bethard, docs at python
versions: +Python 3.7 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25035>
_______________________________________

From report at bugs.python.org  Mon Dec 12 01:18:21 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 12 Dec 2016 06:18:21 +0000
Subject: [issue28937] str.split(): remove empty strings when sep is not None
In-Reply-To: <1481469102.15.0.255147638686.issue28937@psf.upfronthosting.co.za>
Message-ID: <1481523500.99.0.428915472374.issue28937@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Guido, do you have an option on this?  IIRC, this was an API you created.

Nick's thought (posted on twitter) is that 'filter(None, sep.split(input)' already covers the "drop the empty values" case. 

My feelings are mixed.  Though I've never needed in practice, it would be nice if the whitespace removal algorithm could be customized to just a space or just a tab.   On the other hand, I think the new parameter would make the API more confusing and harder to learn.  It might be better to just document either the filter(None) approach or a simple regex for the less common cases.

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28937>
_______________________________________

From report at bugs.python.org  Mon Dec 12 02:39:16 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 12 Dec 2016 07:39:16 +0000
Subject: [issue28444] Missing extensions modules when cross compiling python
 3.5.2 for arm on Linux
In-Reply-To: <1476459283.66.0.870064519048.issue28444@psf.upfronthosting.co.za>
Message-ID: <1481528356.9.0.157463502834.issue28444@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

AFAIK many changes that have been made in Python 3 for the support of the cross compilation have not been backported to 2.7, including this one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28444>
_______________________________________

From report at bugs.python.org  Mon Dec 12 02:52:05 2016
From: report at bugs.python.org (Greg Solomon)
Date: Mon, 12 Dec 2016 07:52:05 +0000
Subject: [issue28939] Groupby Is Roughly Equivalent To ...
In-Reply-To: <1481487383.57.0.242190046836.issue28939@psf.upfronthosting.co.za>
Message-ID: <1481529125.54.0.68804116851.issue28939@psf.upfronthosting.co.za>


Greg Solomon added the comment:

Oh, I get it. There needs to be a next(self.it) loop in __next__ as well as in _grouper in case the user doesn't call _grouper.

My test was 
for ( k , g ) in groupby( L ):
    print ( k , len( list( g ) ) )
so I was executing _grouper on every row.

Thanks !!!

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28939>
_______________________________________

From report at bugs.python.org  Mon Dec 12 02:59:43 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 12 Dec 2016 07:59:43 +0000
Subject: [issue5322] Python 2.6 object.__new__ argument calling autodetection
 faulty
In-Reply-To: <1235075665.37.0.301694124748.issue5322@psf.upfronthosting.co.za>
Message-ID: <1481529583.65.0.492637218585.issue5322@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Does changing the order of base classes help or there is an unavoidable conflict?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5322>
_______________________________________

From report at bugs.python.org  Mon Dec 12 03:00:17 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 12 Dec 2016 08:00:17 +0000
Subject: [issue5322] Python 2.6 object.__new__ argument calling autodetection
 faulty
In-Reply-To: <1235075665.37.0.301694124748.issue5322@psf.upfronthosting.co.za>
Message-ID: <1481529617.02.0.44875664145.issue5322@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords:  -patch
stage: patch review -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5322>
_______________________________________

From report at bugs.python.org  Mon Dec 12 03:00:28 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 12 Dec 2016 08:00:28 +0000
Subject: [issue5322] Python 2.6 object.__new__ argument calling autodetection
 faulty
In-Reply-To: <1235075665.37.0.301694124748.issue5322@psf.upfronthosting.co.za>
Message-ID: <1481529628.03.0.213224599672.issue5322@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5322>
_______________________________________

From report at bugs.python.org  Mon Dec 12 03:03:12 2016
From: report at bugs.python.org (Jan Niklas Hasse)
Date: Mon, 12 Dec 2016 08:03:12 +0000
Subject: [issue28180] sys.getfilesystemencoding() should default to utf-8
In-Reply-To: <1474024622.65.0.838685461995.issue28180@psf.upfronthosting.co.za>
Message-ID: <1481529792.51.0.60884284585.issue28180@psf.upfronthosting.co.za>


Jan Niklas Hasse added the comment:

Actually in a new Docker container, the LANG variable isn't set at all. Defaulting to UTF-8 in that case should be easier to reason about, shouldn't it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28180>
_______________________________________

From report at bugs.python.org  Mon Dec 12 03:10:30 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 12 Dec 2016 08:10:30 +0000
Subject: [issue28180] sys.getfilesystemencoding() should default to utf-8
In-Reply-To: <1474024622.65.0.838685461995.issue28180@psf.upfronthosting.co.za>
Message-ID: <1481530230.01.0.696935180359.issue28180@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

>From CPython's point of view, glibc behaves the same way (i.e. reporting `ascii` as the preferred encoding for operating system interfaces) regardless of whether the cause is the locale not being set at all, or due to it being explicitly set to the legacy POSIX locale via `LANG=C`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28180>
_______________________________________

From report at bugs.python.org  Mon Dec 12 03:45:01 2016
From: report at bugs.python.org (Jan Niklas Hasse)
Date: Mon, 12 Dec 2016 08:45:01 +0000
Subject: [issue28180] sys.getfilesystemencoding() should default to utf-8
In-Reply-To: <1474024622.65.0.838685461995.issue28180@psf.upfronthosting.co.za>
Message-ID: <1481532301.33.0.738650555786.issue28180@psf.upfronthosting.co.za>


Jan Niklas Hasse added the comment:

https://sourceware.org/glibc/wiki/Proposals/C.UTF-8#Defaults mentions that C.UTF-8 should be glibc's default.

This bug report also mentions Python: https://sourceware.org/bugzilla/show_bug.cgi?id=17318
It hasn't been fixed yet, though :/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28180>
_______________________________________

From report at bugs.python.org  Mon Dec 12 03:57:31 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 12 Dec 2016 08:57:31 +0000
Subject: [issue28764] test_mailbox fails when run as a non-root user on
 Android API 24
In-Reply-To: <1479741722.73.0.770267227494.issue28764@psf.upfronthosting.co.za>
Message-ID: <20161212085728.32461.77392.254256E0@psf.io>


Roundup Robot added the comment:

New changeset 51573ef25903 by Xavier de Gaye in branch '3.6':
Issue #28764: Fix a test_mailbox failure on Android API 24 when run as a non-root user.
https://hg.python.org/cpython/rev/51573ef25903

New changeset 3a451c67008d by Xavier de Gaye in branch 'default':
Issue #28764: Merge 3.6.
https://hg.python.org/cpython/rev/3a451c67008d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28764>
_______________________________________

From report at bugs.python.org  Mon Dec 12 04:03:32 2016
From: report at bugs.python.org (Matthias Klose)
Date: Mon, 12 Dec 2016 09:03:32 +0000
Subject: [issue5322] Python 2.6 object.__new__ argument calling autodetection
 faulty
In-Reply-To: <1235075665.37.0.301694124748.issue5322@psf.upfronthosting.co.za>
Message-ID: <1481533412.1.0.342418141777.issue5322@psf.upfronthosting.co.za>


Matthias Klose added the comment:

https://trac.sagemath.org/ticket/22037 reports about another regression.

----------
nosy: +doko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5322>
_______________________________________

From report at bugs.python.org  Mon Dec 12 04:22:06 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 12 Dec 2016 09:22:06 +0000
Subject: [issue26856] android does not have pwd.getpwall()
In-Reply-To: <1461677345.21.0.582848799296.issue26856@psf.upfronthosting.co.za>
Message-ID: <1481534526.31.0.960944304858.issue26856@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Patch updated to the current head of the default branch.

----------
stage: patch review -> commit review
Added file: http://bugs.python.org/file45855/pwd_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26856>
_______________________________________

From report at bugs.python.org  Mon Dec 12 04:32:12 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 12 Dec 2016 09:32:12 +0000
Subject: [issue28764] test_mailbox fails when run as a non-root user on
 Android API 24
In-Reply-To: <1479741722.73.0.770267227494.issue28764@psf.upfronthosting.co.za>
Message-ID: <1481535132.28.0.11702466104.issue28764@psf.upfronthosting.co.za>


Changes by Xavier de Gaye <xdegaye at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28764>
_______________________________________

From report at bugs.python.org  Mon Dec 12 04:42:34 2016
From: report at bugs.python.org (Jeroen Demeyer)
Date: Mon, 12 Dec 2016 09:42:34 +0000
Subject: [issue5322] Python 2.6 object.__new__ argument calling autodetection
 faulty
In-Reply-To: <1235075665.37.0.301694124748.issue5322@psf.upfronthosting.co.za>
Message-ID: <1481535754.27.0.013632245314.issue5322@psf.upfronthosting.co.za>


Jeroen Demeyer added the comment:

@serhiy.storchaka: yes, changing the order of the base classes fixes the issue with __new__. Also manually assigning __new__ works, like

class C(A, B):
    __new__ = B.__new__

What is broken by this patch is only the auto-detection of which __new__ (really, which tp_new) should be called.

@doko: not "another regression", it's exactly the one that we are talking about.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5322>
_______________________________________

From report at bugs.python.org  Mon Dec 12 05:17:21 2016
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 12 Dec 2016 10:17:21 +0000
Subject: [issue28180] sys.getfilesystemencoding() should default to utf-8
In-Reply-To: <1474024622.65.0.838685461995.issue28180@psf.upfronthosting.co.za>
Message-ID: <1481537841.02.0.0649446920941.issue28180@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

If we just restrict this to the file system encoding (and not the whole LANG setting), how about:

 * default the file system encoding to 'utf-8' and use the surrogate escape handler as default error handler
 * add a PYTHONFSENCODING env var to set the file system encoding to something else (*)

(*) I believe we discussed this at some point already, but don't remember the outcome.

Regarding the questions of defaulting to LANG=C.UTF-8: I think this needs some more thought, since it would also affect many C locale aware functions. To make this work, Python would have to call setlocale() early on in the startup phase to adjust the C lib accordingly.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28180>
_______________________________________

From report at bugs.python.org  Mon Dec 12 05:26:47 2016
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 12 Dec 2016 10:26:47 +0000
Subject: [issue28180] sys.getfilesystemencoding() should default to utf-8
In-Reply-To: <1474024622.65.0.838685461995.issue28180@psf.upfronthosting.co.za>
Message-ID: <1481538407.38.0.855995380818.issue28180@psf.upfronthosting.co.za>


INADA Naoki added the comment:

Sorry for confusing.
I didn't meant defaulting LANG=C.UTF-8.

I meant use UTF-8 as default fsencoding, stdioencoding regardless locale,
and locale.getpreferredencoding() returns 'utf-8' when LC_CTYPE is ascii.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28180>
_______________________________________

From report at bugs.python.org  Mon Dec 12 05:52:32 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 12 Dec 2016 10:52:32 +0000
Subject: [issue5322] Python 2.6 object.__new__ argument calling autodetection
 faulty
In-Reply-To: <1235075665.37.0.301694124748.issue5322@psf.upfronthosting.co.za>
Message-ID: <1481539952.52.0.0240789167185.issue5322@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Jeroen. It looks to me that all problems can be resolved by reordering base classes and making Cython not generating trivial __new__. But that is possible only in new Python version. In maintained versions we should keep the old behavior for backward compatibility even if it contradicts normal rules for method resolution and the behavior of Python classes. We should find other solution for making explicit __new__ assigning working.

----------
nosy: +larry, ned.deily
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5322>
_______________________________________

From report at bugs.python.org  Mon Dec 12 06:12:02 2016
From: report at bugs.python.org (Adam Gregory)
Date: Mon, 12 Dec 2016 11:12:02 +0000
Subject: [issue28942] await expressions in f-strings
Message-ID: <1481541122.12.0.429355486169.issue28942@psf.upfronthosting.co.za>


New submission from Adam Gregory:

Hi,

I've been playing with f-strings, which seem like a great addition to the language. I noticed in the definition of f_expression that it can include any or_expr. As far as I understand, this includes "await" expressions, so I tried using await inside an f-string in a coroutine with CPython 3.6.0b4. This produces a SyntaxError.

Should await be allowed in f-strings? I don't know if this is a bug or a documentation issue. Personally, I think it would be an occasionally useful feature - more so than yield, at least, which does work.

Ref: https://docs.python.org/3.6/reference/lexical_analysis.html#formatted-string-literals

----------
assignee: docs at python
components: Documentation, asyncio
messages: 282980
nosy: Adam Gregory, docs at python, gvanrossum, yselivanov
priority: normal
severity: normal
status: open
title: await expressions in f-strings
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28942>
_______________________________________

From report at bugs.python.org  Mon Dec 12 06:20:29 2016
From: report at bugs.python.org (Adam Gregory)
Date: Mon, 12 Dec 2016 11:20:29 +0000
Subject: [issue28942] await expressions in f-strings
In-Reply-To: <1481541122.12.0.429355486169.issue28942@psf.upfronthosting.co.za>
Message-ID: <1481541629.98.0.490829707912.issue28942@psf.upfronthosting.co.za>


Adam Gregory added the comment:

Replicated in CPython 3.6.0rc1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28942>
_______________________________________

From report at bugs.python.org  Mon Dec 12 06:22:10 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 12 Dec 2016 11:22:10 +0000
Subject: [issue28943] Use PyUnicode_MAX_CHAR_VALUE instead of PyUnicode_KIND
 in some API's short path
Message-ID: <1481541730.48.0.478924248348.issue28943@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

Some unicode APIs like PyUnicode_Contains get a short path comparing kinds. But this get a problem cannot apply to ascii and latin1. PyUnicode_MAX_CHAR_VALUE could be used instead to make the short path also apply to ascii and latin1. This skill is already used in PyUnicode_Replace.

----------
components: Interpreter Core
files: short-path.patch
keywords: patch
messages: 282982
nosy: serhiy.storchaka, xiang.zhang
priority: normal
severity: normal
stage: patch review
status: open
title: Use PyUnicode_MAX_CHAR_VALUE instead of PyUnicode_KIND in some API's short path
type: enhancement
versions: Python 3.7
Added file: http://bugs.python.org/file45856/short-path.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28943>
_______________________________________

From report at bugs.python.org  Mon Dec 12 06:37:38 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 12 Dec 2016 11:37:38 +0000
Subject: [issue28943] Use PyUnicode_MAX_CHAR_VALUE instead of PyUnicode_KIND
 in some API's short path
In-Reply-To: <1481541730.48.0.478924248348.issue28943@psf.upfronthosting.co.za>
Message-ID: <1481542658.98.0.062656231101.issue28943@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

PyUnicode_KIND() just extracts three bits from the state word. PyUnicode_MAX_CHAR_VALUE() extracts bits multiple times and does few conditional branching. I think it is much slower that PyUnicode_KIND(). In common case you search ASCII needle or the needle of the same kind as a string, therefore checking for fast path just adds the overhead. It is appropriate while the overhead is tiny.

Optimize common cases, not rare and obscure cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28943>
_______________________________________

From report at bugs.python.org  Mon Dec 12 06:42:03 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 12 Dec 2016 11:42:03 +0000
Subject: [issue28942] await expressions in f-strings
In-Reply-To: <1481541122.12.0.429355486169.issue28942@psf.upfronthosting.co.za>
Message-ID: <1481542923.98.0.314757938072.issue28942@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28942>
_______________________________________

From report at bugs.python.org  Mon Dec 12 06:49:23 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 12 Dec 2016 11:49:23 +0000
Subject: [issue28180] sys.getfilesystemencoding() should default to utf-8
In-Reply-To: <1474024622.65.0.838685461995.issue28180@psf.upfronthosting.co.za>
Message-ID: <1481543363.76.0.276824936753.issue28180@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

The challenge that arises in being selective about this is that "sys.getfilesystemencoding()" is actually a misnomer, and some of the things we use it for (like decoding command line arguments and environment variables) necessarily happen *really* early in the interpreter bootstrapping process. The bugs that arise from being internally inconsistent are then even harder to debug than those that arise from believing the OS when it says the right encoding to use is ASCII - the latter at least don't tend to be subtle, and are amenable to being resolved via "LC_ALL=C.UTF-8" and "LANG=C.UTF-8".

I believe Victor put quite a bit of time into trying to get more selective approaches to work reliably and eventually gave up.

For Fedora 26, I'm going to explore the feasibility of patching our system 3.6 installation such that the python3 command itself (rather than the shared library) checks for "LC_CTYPE=C" as almost the first thing it does, and forcibly sets LANG and LC_ALL to C.UTF-8 if it gets an answer it doesn't like. If we're able to do that successfully in the more constrained environment of a specific recent Fedora release, then I think it will bode well for doing something similar by default in CPython 3.7

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28180>
_______________________________________

From report at bugs.python.org  Mon Dec 12 06:51:23 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 12 Dec 2016 11:51:23 +0000
Subject: [issue21368] Check for systemd locale on startup if current locale is
 set to POSIX
In-Reply-To: <1398627025.84.0.804520187603.issue21368@psf.upfronthosting.co.za>
Message-ID: <1481543483.86.0.336121581537.issue21368@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

While this is still a problem I'm interested in solving, I no longer think reading the systemd locale config file would be a good way to address it.

See issue 28180 for a more recent discussion of some other alternatives.

----------
resolution:  -> rejected
status: open -> closed
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21368>
_______________________________________

From report at bugs.python.org  Mon Dec 12 07:01:53 2016
From: report at bugs.python.org (bpoaugust)
Date: Mon, 12 Dec 2016 12:01:53 +0000
Subject: [issue795081] email.Message param parsing problem II
Message-ID: <1481544113.29.0.670589248058.issue795081@psf.upfronthosting.co.za>


bpoaugust added the comment:

Rather that change unquote to deal with such malformed input, why not just enhance get/set boundary? That would reduce the impact of any changes.

Also it should be easier to detect trailing rubbish in the value if you know it is a boundary value.

----------
nosy: +bpoaugust

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue795081>
_______________________________________

From report at bugs.python.org  Mon Dec 12 07:10:28 2016
From: report at bugs.python.org (woo yoo)
Date: Mon, 12 Dec 2016 12:10:28 +0000
Subject: [issue28944] A lack of comma within EBNF rule of keywords_arguments
Message-ID: <1481544628.07.0.0933253462311.issue28944@psf.upfronthosting.co.za>


New submission from woo yoo:

This is the documented rule, which lacks a comma within the last line.
keywords_arguments   ::=  (keyword_item | "**" expression)
                          ("," keyword_item | "**" expression)*
The correct form should be:
keywords_arguments   ::=  (keyword_item | "**" expression)
                          ("," keyword_item |",""**" expression)*

The original documentation is https://docs.python.org/3/reference/expressions.html#calls

----------
assignee: docs at python
components: Documentation
messages: 282987
nosy: docs at python, woo yoo
priority: normal
severity: normal
status: open
title: A lack of comma within EBNF rule of keywords_arguments
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28944>
_______________________________________

From report at bugs.python.org  Mon Dec 12 07:13:05 2016
From: report at bugs.python.org (woo yoo)
Date: Mon, 12 Dec 2016 12:13:05 +0000
Subject: [issue28944] A lack of line 6
In-Reply-To: <1481544628.07.0.0933253462311.issue28944@psf.upfronthosting.co.za>
Message-ID: <1481544785.86.0.252284253208.issue28944@psf.upfronthosting.co.za>


woo yoo added the comment:

There is no line 6 between line 7 and line 5.
Here is the original documentationhttps://docs.python.org/3/library/stdtypes.html#old-string-formatting

----------
title: A lack of comma within EBNF rule of keywords_arguments -> A lack of line 6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28944>
_______________________________________

From report at bugs.python.org  Mon Dec 12 07:13:40 2016
From: report at bugs.python.org (Marco Buttu)
Date: Mon, 12 Dec 2016 12:13:40 +0000
Subject: [issue26683] Questionable terminology for describing what locals()
 does
In-Reply-To: <1459474292.87.0.515226107717.issue26683@psf.upfronthosting.co.za>
Message-ID: <1481544820.9.0.447638033341.issue26683@psf.upfronthosting.co.za>


Marco Buttu added the comment:

Another point in the doc, where the meaning of "free variable" is inconsistent with the ``locals()`` and ``code.co_freevars`` meaning:

https://docs.python.org/3/reference/executionmodel.html#interaction-with-dynamic-features

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26683>
_______________________________________

From report at bugs.python.org  Mon Dec 12 07:44:42 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 12 Dec 2016 12:44:42 +0000
Subject: [issue28943] Use PyUnicode_MAX_CHAR_VALUE instead of PyUnicode_KIND
 in some API's short path
In-Reply-To: <1481541730.48.0.478924248348.issue28943@psf.upfronthosting.co.za>
Message-ID: <1481546682.7.0.389868133707.issue28943@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

I know the difference and thought the overhead should be tiny (not in a critical part). But benchmarks show it's not. :-(

----------
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28943>
_______________________________________

From report at bugs.python.org  Mon Dec 12 07:45:04 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 12 Dec 2016 12:45:04 +0000
Subject: [issue28943] Use PyUnicode_MAX_CHAR_VALUE instead of PyUnicode_KIND
 in some API's short path
In-Reply-To: <1481541730.48.0.478924248348.issue28943@psf.upfronthosting.co.za>
Message-ID: <1481546704.98.0.247726254263.issue28943@psf.upfronthosting.co.za>


Changes by Xiang Zhang <angwerzx at 126.com>:


----------
resolution:  -> rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28943>
_______________________________________

From report at bugs.python.org  Mon Dec 12 07:54:57 2016
From: report at bugs.python.org (bpoaugust)
Date: Mon, 12 Dec 2016 12:54:57 +0000
Subject: [issue28945] get_boundary invokes unquote twice
Message-ID: <1481547297.88.0.91240101349.issue28945@psf.upfronthosting.co.za>


New submission from bpoaugust:

get_boundary calls get_param('boundary') which unquotes the value.
It then calls utils.collapse_rfc2231_value which also calls unquote.

This causes problems for boundaries that have two sets of quotes.
For example, I have seen the following in the wild:

Content-Type: multipart/mixed; boundary="<<001-3e1dcd5a-119e>>"

Both "" and <> are treated as quotes by unquote.

The result is that both "< and >" are stripped off.
This means that the boundaries no longer match.

----------
components: email
messages: 282991
nosy: barry, bpoaugust, r.david.murray
priority: normal
severity: normal
status: open
title: get_boundary invokes unquote twice
type: behavior
versions: Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28945>
_______________________________________

From report at bugs.python.org  Mon Dec 12 08:00:56 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 12 Dec 2016 13:00:56 +0000
Subject: [issue28935] distutils use ConfigParser in Python 3.x and fails to
 parse setup.cfg with percent sign
In-Reply-To: <1481397140.66.0.236784364676.issue28935@psf.upfronthosting.co.za>
Message-ID: <1481547656.65.0.917747578255.issue28935@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the report! This looks similar to issue 20754.

Disabling string interpolation would break existing code (but probably just Python 3 only code)

Would using %% instead of % be possible for you?

(3.3 and 3.4 are in security-fix-only mode so I removed them from the versions field.)

----------
nosy: +berker.peksag, jason.coombs
type: crash -> behavior
versions:  -Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28935>
_______________________________________

From report at bugs.python.org  Mon Dec 12 08:27:27 2016
From: report at bugs.python.org (dd)
Date: Mon, 12 Dec 2016 13:27:27 +0000
Subject: [issue28946] AttributeError: module 'signal' has no attribute
 'SIGALRM'
Message-ID: <1481549247.36.0.982629771207.issue28946@psf.upfronthosting.co.za>


New submission from dd:

When I try to run the example at the very end of the signal documentation page [https://docs.python.org/3/library/signal.html#example] I get the error from the title: 
AttributeError: module 'signal' has no attribute 'SIGALRM'

The same thing happens for SIGINT, which is what I was trying to use in the first place.

I found the comment that many things in signal have been turned to enums [https://docs.python.org/3/library/signal.html#module-contents] but they don't seem to be documented anywhere.

I'm not sure if this is an actual bug or if these enums are just not documented, but It would be great if someone could look into this.

I run an up-to-date Manjaro Linux (an Arch-based distro) and Python 3.5.2 (default, Nov  7 2016, 11:31:36) 
[GCC 6.2.1 20160830]

Let me know if anything is unclear.

----------
messages: 282993
nosy: dd
priority: normal
severity: normal
status: open
title: AttributeError: module 'signal' has no attribute 'SIGALRM'
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28946>
_______________________________________

From report at bugs.python.org  Mon Dec 12 08:34:47 2016
From: report at bugs.python.org (arpit arora)
Date: Mon, 12 Dec 2016 13:34:47 +0000
Subject: [issue28947] Facing issue while running Python 3.6.0rc1 windows
 x86-64 web based installer
Message-ID: <1481549687.21.0.953592088628.issue28947@psf.upfronthosting.co.za>


New submission from arpit arora:

Hi,

Post installing 'Python 3.6.0rc1 windows x86-64 web based installer' on my Windows 7 64 bit system, i am not able to start python. Each time i start it, i get a pop up saying that "the program can't start because 'api-ms-win-crt-runtime-|1-1-0.dll' is missing from your computer. Try reinstalling this program to fix this problem."
I have reinstalled Python but still i get the same error message while starting it. I am stuck here. Please help me with this. Thanks in advance.

Regards
Arpit Arora

----------
components: Windows
messages: 282994
nosy: arpit arora, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Facing issue while running Python 3.6.0rc1 windows x86-64 web based installer
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28947>
_______________________________________

From report at bugs.python.org  Mon Dec 12 08:35:06 2016
From: report at bugs.python.org (arpit arora)
Date: Mon, 12 Dec 2016 13:35:06 +0000
Subject: [issue28948] Facing issue while running Python 3.6.0rc1 windows
 x86-64 web based installer
Message-ID: <1481549706.57.0.80853202455.issue28948@psf.upfronthosting.co.za>


New submission from arpit arora:

Hi,

Post installing 'Python 3.6.0rc1 windows x86-64 web based installer' on my Windows 7 64 bit system, i am not able to start python. Each time i start it, i get a pop up saying that "the program can't start because 'api-ms-win-crt-runtime-|1-1-0.dll' is missing from your computer. Try reinstalling this program to fix this problem."
I have reinstalled Python but still i get the same error message while starting it. I am stuck here. Please help me with this. Thanks in advance.

Regards
Arpit Arora

----------
components: Windows
messages: 282995
nosy: arpit arora, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Facing issue while running Python 3.6.0rc1 windows x86-64 web based installer
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28948>
_______________________________________

From report at bugs.python.org  Mon Dec 12 08:37:35 2016
From: report at bugs.python.org (Axel Haustant)
Date: Mon, 12 Dec 2016 13:37:35 +0000
Subject: [issue28935] distutils use ConfigParser in Python 3.x and fails to
 parse setup.cfg with percent sign
In-Reply-To: <1481397140.66.0.236784364676.issue28935@psf.upfronthosting.co.za>
Message-ID: <1481549855.39.0.78730318043.issue28935@psf.upfronthosting.co.za>


Axel Haustant added the comment:

You're welcome.

I understand the backward compatibility point. But I think that the current state is breaking existing code as it's not documented anywhere and it's a side-effect of another change, not something intentionnal.
(this is why I submitted this issue because I'm developing a tool which use the setup.cfg file to store data and it is broken in Python 3. I saw a lot of bug reports on different tools with the same issue (ex: nosetest configuration)

I cannot use %% for many reason:
- it will not work with Python 2.x (problematic for 2/3 cross compatibility)
- it needs every tools to know that in Python 3, they have to change their parser

Right now, I'm supporting configuration into an external file for Python 3.x

Thanks for your response ! I hope that it can be integrated into future releases (noted the point on 3.3/3.4).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28935>
_______________________________________

From report at bugs.python.org  Mon Dec 12 08:47:02 2016
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 12 Dec 2016 13:47:02 +0000
Subject: [issue28948] Facing issue while running Python 3.6.0rc1 windows
 x86-64 web based installer
In-Reply-To: <1481549706.57.0.80853202455.issue28948@psf.upfronthosting.co.za>
Message-ID: <1481550422.91.0.465549628017.issue28948@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

Please try to install this update from MS:

https://support.microsoft.com/en-us/kb/2999226

it includes the missing DLL.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28948>
_______________________________________

From report at bugs.python.org  Mon Dec 12 08:53:09 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Mon, 12 Dec 2016 13:53:09 +0000
Subject: [issue28946] AttributeError: module 'signal' has no attribute
 'SIGALRM'
In-Reply-To: <1481549247.36.0.982629771207.issue28946@psf.upfronthosting.co.za>
Message-ID: <1481550789.39.0.29422444972.issue28946@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

Can you import _signal? And what's the output of dir(_signal)?

Another possibility is that there's another signal.py in the search path. Could you also paste the output of repr(signal)?

By the way, here on Arch Linux, both signal.SIGINT and signal.SIGALRM are there.

----------
nosy: +Chi Hsuan Yen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28946>
_______________________________________

From report at bugs.python.org  Mon Dec 12 08:53:09 2016
From: report at bugs.python.org (Jeroen Demeyer)
Date: Mon, 12 Dec 2016 13:53:09 +0000
Subject: [issue5322] Python 2.6 object.__new__ argument calling autodetection
 faulty
In-Reply-To: <1235075665.37.0.301694124748.issue5322@psf.upfronthosting.co.za>
Message-ID: <1481550789.83.0.768598248167.issue5322@psf.upfronthosting.co.za>


Jeroen Demeyer added the comment:

Wouldn't it be possible to fix assignment of __new__ without breaking backwards compatibility (and then apply the same patch for all Python versions)? I have a feeling that breaking the auto-detection of tp_new is a new bug introduced by this patch and not a fundamental feature needed to fix assignment of __new__.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5322>
_______________________________________

From report at bugs.python.org  Mon Dec 12 08:58:58 2016
From: report at bugs.python.org (dd)
Date: Mon, 12 Dec 2016 13:58:58 +0000
Subject: [issue28946] AttributeError: module 'signal' has no attribute
 'SIGALRM'
In-Reply-To: <1481549247.36.0.982629771207.issue28946@psf.upfronthosting.co.za>
Message-ID: <1481551138.17.0.315803220959.issue28946@psf.upfronthosting.co.za>


dd added the comment:

Yeah, I'm stupid. I named my file signal.py?

Sorry for the trouble and thanks for your help!

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28946>
_______________________________________

From report at bugs.python.org  Mon Dec 12 09:03:37 2016
From: report at bugs.python.org (arpit arora)
Date: Mon, 12 Dec 2016 14:03:37 +0000
Subject: [issue28948] Facing issue while running Python 3.6.0rc1 windows
 x86-64 web based installer
In-Reply-To: <1481549706.57.0.80853202455.issue28948@psf.upfronthosting.co.za>
Message-ID: <1481551417.87.0.795373175006.issue28948@psf.upfronthosting.co.za>


arpit arora added the comment:

Hi Marc,

It worked. Thanks a lot :)

Regards
Arpit Arora

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28948>
_______________________________________

From report at bugs.python.org  Mon Dec 12 09:05:47 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 12 Dec 2016 14:05:47 +0000
Subject: [issue28946] AttributeError: module 'signal' has no attribute
 'SIGALRM'
In-Reply-To: <1481549247.36.0.982629771207.issue28946@psf.upfronthosting.co.za>
Message-ID: <1481551547.71.0.68564052339.issue28946@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
stage:  -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28946>
_______________________________________

From report at bugs.python.org  Mon Dec 12 09:12:35 2016
From: report at bugs.python.org (Steve Dower)
Date: Mon, 12 Dec 2016 14:12:35 +0000
Subject: [issue28948] Facing issue while running Python 3.6.0rc1 windows
 x86-64 web based installer
In-Reply-To: <1481549706.57.0.80853202455.issue28948@psf.upfronthosting.co.za>
Message-ID: <1481551955.57.0.221212929002.issue28948@psf.upfronthosting.co.za>


Steve Dower added the comment:

Arpit, could you look in your %TEMP% directory for the Python logs when you originally installed it? There may be some information in those about why the update didn't install properly the first time, and I'd like to fix it.

You can just zip up all the logs you find and attach here. I know how to read them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28948>
_______________________________________

From report at bugs.python.org  Mon Dec 12 09:19:37 2016
From: report at bugs.python.org (Whitequill Riclo)
Date: Mon, 12 Dec 2016 14:19:37 +0000
Subject: [issue28874] test_logging fails and freezes
In-Reply-To: <1481248533.54.0.704931665676.issue28874@psf.upfronthosting.co.za>
Message-ID: <CAEWBzXNPsyAZAjFz5WPPNa9pDfYfMX5yfXc45OrPzkJ46dnkZA@mail.gmail.com>


Whitequill Riclo added the comment:

my OS is Ubuntu on Windows 10
<https://msdn.microsoft.com/en-us/commandline/wsl/about>. The new Linux
subsystem for Windows 10
Linux version 3.4.0-Microsoft (Microsoft at Microsoft.com) (gcc version 4.7
(GCC) ) #1 SMP PREEMPT Wed Dec 31 14:42:53 PST 2014

Distributor ID: Ubuntu
Description:    Ubuntu 14.04.5 LTS
Release:        14.04
Codename:       trusty

ldd (Ubuntu EGLIBC 2.19-0ubuntu6.9) 2.19

Windows 10 is running on bare metal.
I have included a log file with the results from the test.

On Thu, Dec 8, 2016 at 8:55 PM, STINNER Victor <report at bugs.python.org>
wrote:

>
> STINNER Victor added the comment:
>
> What is your OS? A Linux on bare metal? Or a container? What are versions
> of Linux kernel, libc and C compiler? Or more generally the name and
> verison of your Linux distro?
>
> There are many errors:
>
> * test_fcntl failed
> * test_import failed
> * test_epoll failed
>
> Can you please run only these tests in verbose mode, and attach the output?
>
> Example:
>
> ./python -m test -v test_fcntl test_import test_epolls
>
> ----------
> nosy: +haypo
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue28874>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file45857/python37err.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28874>
_______________________________________
-------------- next part --------------
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Traceback (most recent call last):
  File "/home/brazg/py3/lib/python3.7/runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "/home/brazg/py3/lib/python3.7/runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "/home/brazg/py3/lib/python3.7/test/__main__.py", line 1, in <module>
    from test.libregrtest import main
  File "/home/brazg/py3/lib/python3.7/test/libregrtest/__init__.py", line 4, in <module>
    from test.libregrtest.cmdline import _parse_args, RESOURCE_NAMES
  File "/home/brazg/py3/lib/python3.7/test/libregrtest/cmdline.py", line 1, in <module>
    import argparse
  File "/home/brazg/py3/lib/python3.7/argparse.py", line 93, in <module>
    from gettext import gettext as _, ngettext
  File "/home/brazg/py3/lib/python3.7/gettext.py", line 49, in <module>
    import locale, copy, io, os, re, struct, sys
  File "/home/brazg/py3/lib/python3.7/struct.py", line 13, in <module>
    from _struct import *
ModuleNotFoundError: No module named '_struct'

From report at bugs.python.org  Mon Dec 12 09:22:12 2016
From: report at bugs.python.org (S Safihre)
Date: Mon, 12 Dec 2016 14:22:12 +0000
Subject: [issue28248] Upgrade installers to OpenSSL 1.0.2j
In-Reply-To: <1474552584.95.0.0318594270303.issue28248@psf.upfronthosting.co.za>
Message-ID: <1481552532.61.0.120883490116.issue28248@psf.upfronthosting.co.za>


S Safihre added the comment:

>From the changelog I interpreted this to mean that Python would now use OpenSSL 1.0.2j on macOS for it's ssl module.
But this is not the case?
On a fresh macOS Sierra VM I get:

Python 2.7.13rc1 (v2.7.13rc1:4d6fd49eeb14, Dec  3 2016, 13:01:23) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import ssl
>>> ssl.OPENSSL_VERSION
'OpenSSL 0.9.8zh 14 Jan 2016'

----------
nosy: +S Safihre

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28248>
_______________________________________

From report at bugs.python.org  Mon Dec 12 09:29:34 2016
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 12 Dec 2016 14:29:34 +0000
Subject: [issue28935] distutils use ConfigParser in Python 3.x and fails to
 parse setup.cfg with percent sign
In-Reply-To: <1481397140.66.0.236784364676.issue28935@psf.upfronthosting.co.za>
Message-ID: <1481552974.43.0.00286218803177.issue28935@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

This looks to be another manifestation of issue20120 and is a duplicate of issue20754.

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28935>
_______________________________________

From report at bugs.python.org  Mon Dec 12 09:34:21 2016
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 12 Dec 2016 14:34:21 +0000
Subject: [issue20754] Distribution.parse_config_files uses interpolation since
 Python 3
In-Reply-To: <1393201670.58.0.749043113933.issue20754@psf.upfronthosting.co.za>
Message-ID: <1481553261.6.0.435744636118.issue20754@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

Looking more closely now and as a result of the report in issue28935, I see that this issue is another separate manifestation of the issue addressed in issue20120.

----------
resolution: out of date -> 
status: closed -> open
title: distutils should use SafeConfigParser -> Distribution.parse_config_files uses interpolation since Python 3
versions: +Python 3.5, Python 3.6, Python 3.7 -Python 2.7, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20754>
_______________________________________

From report at bugs.python.org  Mon Dec 12 09:40:20 2016
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 12 Dec 2016 14:40:20 +0000
Subject: [issue28949] Unable to launch Python interpreter
Message-ID: <1481553619.84.0.343525103437.issue28949@psf.upfronthosting.co.za>


New submission from Jason R. Coombs:

I recently upgraded Python 3.6.0rc1 over 3.6.0b4. Python would invoke just fine after the update, but following a system restart, I'm experiencing crashes on any invocation of Python. I suspect it's just a bad/corrupted install. I will do more investigation, but here's the report from MacOS.

Process:               Python [3211]
Path:                  /Library/Frameworks/Python.framework/Versions/3.6/Resources/Python.app/Contents/MacOS/Python
Identifier:            Python
Version:               3.6.0rc1 (3.6.0rc1)
Code Type:             X86-64 (Native)
Parent Process:        zsh [990]
Responsible:           Python [3211]
User ID:               501

Date/Time:             2016-12-12 09:36:50.115 -0500
OS Version:            Mac OS X 10.12.1 (16B2657)
Report Version:        12
Anonymous UUID:        31F72BE9-33AC-23C5-6CC1-DA2C20DDA3B2


Time Awake Since Boot: 1400 seconds

System Integrity Protection: enabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Application Specific Information:
abort() called

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	0x00007fffc65e0dda __pthread_kill + 10
1   libsystem_pthread.dylib       	0x00007fffc66cc787 pthread_kill + 90
2   libsystem_c.dylib             	0x00007fffc6546420 abort + 129
3   org.python.python             	0x00000001001280d1 Py_FatalError + 65
4   org.python.python             	0x0000000100129e21 _Py_InitializeEx_Private + 1377
5   org.python.python             	0x0000000100146c60 Py_Main + 1376
6   org.python.python             	0x0000000100000dfe 0x100000000 + 3582
7   org.python.python             	0x0000000100000c34 0x100000000 + 3124

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x0000000000000000  rbx: 0x0000000000000006  rcx: 0x00007fff5bfff448  rdx: 0x0000000000000000
  rdi: 0x0000000000000307  rsi: 0x0000000000000006  rbp: 0x00007fff5bfff470  rsp: 0x00007fff5bfff448
   r8: 0x0000000000000000   r9: 0x0000000000000006  r10: 0x0000000008000000  r11: 0x0000000000000206
  r12: 0x00007fffcf286a20  r13: 0x0000000000000002  r14: 0x00007fffcf2a23c0  r15: 0x00007fff5bfff4d0
  rip: 0x00007fffc65e0dda  rfl: 0x0000000000000206  cr2: 0x00007fffcf284128
  
Logical CPU:     0
Error Code:      0x02000148
Trap Number:     133


Binary Images:
       0x100000000 -        0x100000ff7 +org.python.python (3.6.0rc1 - 3.6.0rc1) <581ACC12-D39B-9ED6-E4C0-DC4709F9A849> /Library/Frameworks/Python.framework/Versions/3.6/Resources/Python.app/Contents/MacOS/Python
       0x100003000 -        0x100225ff7 +org.python.python (3.6.0rc1, [c] 2001-2016 Python Software Foundation. - 3.6.0rc1) <57D55331-6C7E-012A-47A2-5CA85BB2ECAC> /Library/Frameworks/Python.framework/Versions/3.6/Python
    0x7fff60b9d000 -     0x7fff60bda287  dyld (421.2) <F5F79617-5669-3424-A2CF-18B23BB0C0C7> /usr/lib/dyld
    0x7fffb11c3000 -     0x7fffb165cff7  com.apple.CoreFoundation (6.9 - 1348.15) <C25C6FB8-E934-349C-952C-26CF913BAC33> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
    0x7fffc4cdc000 -     0x7fffc4cddff3  libDiagnosticMessagesClient.dylib (102) <422911A4-E273-3E88-BFC4-DF6470E48242> /usr/lib/libDiagnosticMessagesClient.dylib
    0x7fffc4f1b000 -     0x7fffc4f1cff3  libSystem.B.dylib (1238) <F62ED8CF-37FB-30E3-A453-C62BA28CAA07> /usr/lib/libSystem.B.dylib
    0x7fffc502c000 -     0x7fffc502cff3  libauto.dylib (187) <5BBF6A00-CC76-389D-84E7-CA88EDADE683> /usr/lib/libauto.dylib
    0x7fffc504d000 -     0x7fffc50a3ff7  libc++.1.dylib (307.4) <BEE86868-F831-384C-919E-2B286ACFE87C> /usr/lib/libc++.1.dylib
    0x7fffc50a4000 -     0x7fffc50cefff  libc++abi.dylib (307.2) <1CEF8ABB-7E6D-3C2F-8E0A-E7884478DD23> /usr/lib/libc++abi.dylib
    0x7fffc560a000 -     0x7fffc582ffff  libicucore.A.dylib (57132.0.1) <063DBF01-CEF8-3C2E-9917-A08358BB006D> /usr/lib/libicucore.A.dylib
    0x7fffc5bbf000 -     0x7fffc5f8fd97  libobjc.A.dylib (706) <F9AFE665-A3A2-3285-9495-19803A565861> /usr/lib/libobjc.A.dylib
    0x7fffc63b6000 -     0x7fffc63c7ff3  libz.1.dylib (67) <46E3FFA2-4328-327A-8D34-A03E20BFFB8E> /usr/lib/libz.1.dylib
    0x7fffc63d6000 -     0x7fffc63daff7  libcache.dylib (79) <84E55656-FDA9-3B29-9E4F-BE31B2C0AA3C> /usr/lib/system/libcache.dylib
    0x7fffc63db000 -     0x7fffc63e5fff  libcommonCrypto.dylib (60092.20.1) <D2711CB2-2D9A-3238-8082-CDB8AE60017F> /usr/lib/system/libcommonCrypto.dylib
    0x7fffc63e6000 -     0x7fffc63edfff  libcompiler_rt.dylib (62) <486BDE52-81B4-3446-BD72-23977CAE556F> /usr/lib/system/libcompiler_rt.dylib
    0x7fffc63ee000 -     0x7fffc63f6fff  libcopyfile.dylib (138) <0DA49B77-56EC-362D-98FF-FA78CFD986D6> /usr/lib/system/libcopyfile.dylib
    0x7fffc63f7000 -     0x7fffc6479fdb  libcorecrypto.dylib (442.20.2) <9846F683-6CED-3CE5-AE8A-B0A681F7FEEF> /usr/lib/system/libcorecrypto.dylib
    0x7fffc647a000 -     0x7fffc64acfff  libdispatch.dylib (703.20.1) <FDC0F71D-A415-306A-ABE8-CA21E25A55BB> /usr/lib/system/libdispatch.dylib
    0x7fffc64ad000 -     0x7fffc64b2ff3  libdyld.dylib (421.2) <7BFA3476-6210-3BCB-8CE8-9B952F87BD84> /usr/lib/system/libdyld.dylib
    0x7fffc64b3000 -     0x7fffc64b3ffb  libkeymgr.dylib (28) <09CD7CA6-46D2-3A9F-B9F1-7C4CA5CA0D68> /usr/lib/system/libkeymgr.dylib
    0x7fffc64c1000 -     0x7fffc64c1fff  liblaunch.dylib (972.20.3) <7AB2E2EA-8B47-3420-87CE-5EE18A4EEE49> /usr/lib/system/liblaunch.dylib
    0x7fffc64c2000 -     0x7fffc64c7fff  libmacho.dylib (894) <1EAE5ADD-490C-3B1F-9F97-447BA8E0E90F> /usr/lib/system/libmacho.dylib
    0x7fffc64c8000 -     0x7fffc64caff3  libquarantine.dylib (85) <78EF62D8-C890-3FC0-937A-C2FD8CEF8992> /usr/lib/system/libquarantine.dylib
    0x7fffc64cb000 -     0x7fffc64ccffb  libremovefile.dylib (45) <C4FC07FF-ED86-382E-B06F-33C34718080C> /usr/lib/system/libremovefile.dylib
    0x7fffc64cd000 -     0x7fffc64e5ff7  libsystem_asl.dylib (349.1.1) <2217DE86-0635-393E-93DD-A1344EC0EF4B> /usr/lib/system/libsystem_asl.dylib
    0x7fffc64e6000 -     0x7fffc64e6ff7  libsystem_blocks.dylib (67) <B8C3701D-5A91-3D35-999D-2DC8D5393525> /usr/lib/system/libsystem_blocks.dylib
    0x7fffc64e7000 -     0x7fffc6574fef  libsystem_c.dylib (1158.20.4) <FB1702C3-C521-37BD-91CB-559168785D22> /usr/lib/system/libsystem_c.dylib
    0x7fffc6575000 -     0x7fffc6578ffb  libsystem_configuration.dylib (888.20.5) <D7FC38C6-794C-3C26-AE4F-020A72E1BB79> /usr/lib/system/libsystem_configuration.dylib
    0x7fffc6579000 -     0x7fffc657cfff  libsystem_coreservices.dylib (41.2) <ADE57FD1-AFEB-3E86-820D-E4F28330F76A> /usr/lib/system/libsystem_coreservices.dylib
    0x7fffc657d000 -     0x7fffc6595ffb  libsystem_coretls.dylib (121.1.1) <8F7E9B12-400D-3276-A9C5-4546B0258554> /usr/lib/system/libsystem_coretls.dylib
    0x7fffc6596000 -     0x7fffc659cfff  libsystem_dnssd.dylib (765.20.4) <49E37AB9-776C-3F84-8AC2-9BDD0438ED9D> /usr/lib/system/libsystem_dnssd.dylib
    0x7fffc659d000 -     0x7fffc65c6fff  libsystem_info.dylib (503) <C686B834-5E7D-382C-AF6E-44AB78EE83E2> /usr/lib/system/libsystem_info.dylib
    0x7fffc65c7000 -     0x7fffc65e9ff7  libsystem_kernel.dylib (3789.21.4) <651F249F-D797-3FBD-A66F-66DFB48FCF38> /usr/lib/system/libsystem_kernel.dylib
    0x7fffc65ea000 -     0x7fffc6631fe7  libsystem_m.dylib (3121.4) <E3370D16-EBAA-3C7F-AC56-2D6EAD7DB0A4> /usr/lib/system/libsystem_m.dylib
    0x7fffc6632000 -     0x7fffc6650ff7  libsystem_malloc.dylib (116) <3DD17B88-B7A4-38B9-9E95-AB88E1C3B647> /usr/lib/system/libsystem_malloc.dylib
    0x7fffc6651000 -     0x7fffc66a8ff3  libsystem_network.dylib (856.20.4) <0F16BBE0-3092-390E-96D9-0B5DCC97B317> /usr/lib/system/libsystem_network.dylib
    0x7fffc66a9000 -     0x7fffc66b2ff3  libsystem_networkextension.dylib (563.20.3) <C8C8807B-F5C1-307E-8D67-02793B62E9ED> /usr/lib/system/libsystem_networkextension.dylib
    0x7fffc66b3000 -     0x7fffc66bcff3  libsystem_notify.dylib (165.20.1) <D38E3A3C-AEEE-321A-861E-160ABE4B20B4> /usr/lib/system/libsystem_notify.dylib
    0x7fffc66bd000 -     0x7fffc66c5fe7  libsystem_platform.dylib (126.1.2) <884DDF42-3CAE-334A-82CE-965617130FB1> /usr/lib/system/libsystem_platform.dylib
    0x7fffc66c6000 -     0x7fffc66d0ff7  libsystem_pthread.dylib (218.20.1) <F35891AC-CA82-3F97-9BE6-15EC3B4C36F6> /usr/lib/system/libsystem_pthread.dylib
    0x7fffc66d1000 -     0x7fffc66d4ff7  libsystem_sandbox.dylib (592.21.2) <FCF7F7C2-79B5-321F-901D-A190CD3D22A2> /usr/lib/system/libsystem_sandbox.dylib
    0x7fffc66d5000 -     0x7fffc66d6fff  libsystem_secinit.dylib (24) <A54B8FEF-E792-3C54-8E0B-E80A376662F2> /usr/lib/system/libsystem_secinit.dylib
    0x7fffc66d7000 -     0x7fffc66defff  libsystem_symptoms.dylib (532.1.1) <B26F656E-94F9-3834-9B03-51C4FF11D1BF> /usr/lib/system/libsystem_symptoms.dylib
    0x7fffc66df000 -     0x7fffc66ffff7  libsystem_trace.dylib (518.20.8) <046443DA-0474-3A73-A69F-1DC21C49B8AD> /usr/lib/system/libsystem_trace.dylib
    0x7fffc6700000 -     0x7fffc6705ffb  libunwind.dylib (35.3) <9F7C2AD8-A9A7-3DE4-828D-B0F0F166AAA0> /usr/lib/system/libunwind.dylib
    0x7fffc6706000 -     0x7fffc672fff7  libxpc.dylib (972.20.3) <CE86F4BA-EF31-33BD-8AC3-7BF25F632FA9> /usr/lib/system/libxpc.dylib

External Modification Summary:
  Calls made by other processes targeting this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by all processes on this machine:
    task_for_pid: 1016
    thread_create: 0
    thread_set_state: 0

VM Region Summary:
ReadOnly portion of Libraries: Total=130.3M resident=0K(0%) swapped_out_or_unallocated=130.3M(100%)
Writable regions: Total=35.7M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=35.7M(100%)
 
                                VIRTUAL   REGION 
REGION TYPE                        SIZE    COUNT (non-coalesced) 
===========                     =======  ======= 
Kernel Alloc Once                    8K        2 
MALLOC                            19.3M       11 
MALLOC guard page                   16K        4 
VM_ALLOCATE                          4K        2 
__DATA                            3452K       49 
__LINKEDIT                       113.4M        5 
__TEXT                            16.8M       47 
__UNICODE                          556K        2 
__UNIXSTACK                       16.0M        2 
shared memory                        8K        3 
===========                     =======  ======= 
TOTAL                            169.5M      117 

Model: MacBookPro13,2, BootROM MBP132.0226.B00, 2 processors, Intel Core i7, 3.3 GHz, 16 GB, SMC 2.37f18
Graphics: kHW_IntelIrisGraphics550Item, Intel Iris Graphics 550, Built-In
Memory Module: BANK 0/DIMM0, 8 GB, LPDDR3, 2133 MHz, 0x802C, 0x4D5435324C31473332443450472D30393320
Memory Module: BANK 1/DIMM0, 8 GB, LPDDR3, 2133 MHz, 0x802C, 0x4D5435324C31473332443450472D30393320
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x157), Broadcom BCM43xx 1.0 (7.21.171.47.1a8)
Bluetooth: Version 5.0.1f7, 3 services, 27 devices, 1 incoming serial ports
Network Service: Wi-Fi, AirPort, en0
PCI Card: pci1b21,1142, USB eXtensible Host Controller, Thunderbolt at 195,0,0
USB Device: USB 3.0 Bus
USB Device: iBridge
USB Device: USB 3.0 Bus
USB Device: ASM107x
USB Device: TUSB3410 Boot Device
USB Device: Microsoft? LifeCam Cinema(TM)
USB Device: ASM107x
Thunderbolt Bus: MacBook Pro, Apple Inc., 11.9
Thunderbolt Bus: MacBook Pro, Apple Inc., 11.9
Thunderbolt Device: 34UM95, LG Electronics, 3, 24.1

----------
messages: 283007
nosy: jason.coombs
priority: normal
severity: normal
status: open
title: Unable to launch Python interpreter
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28949>
_______________________________________

From report at bugs.python.org  Mon Dec 12 09:47:02 2016
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 12 Dec 2016 14:47:02 +0000
Subject: [issue28949] Unable to launch Python interpreter
In-Reply-To: <1481553619.84.0.343525103437.issue28949@psf.upfronthosting.co.za>
Message-ID: <1481554022.76.0.492280337214.issue28949@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

A simple re-install corrected the issue and survived a restart. I suspect one or more components weren't properly upgraded or were corrupted for unrelated reasons. I suspect that it was an environmental issue and not an issue with the package itself.

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28949>
_______________________________________

From report at bugs.python.org  Mon Dec 12 10:08:48 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 12 Dec 2016 15:08:48 +0000
Subject: [issue5322] Python 2.6 object.__new__ argument calling autodetection
 faulty
In-Reply-To: <1235075665.37.0.301694124748.issue5322@psf.upfronthosting.co.za>
Message-ID: <1481555328.45.0.219607722899.issue5322@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
nosy:  -gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5322>
_______________________________________

From report at bugs.python.org  Mon Dec 12 10:16:10 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 12 Dec 2016 15:16:10 +0000
Subject: [issue26936] android: test_socket fails
In-Reply-To: <1462288246.37.0.495121419926.issue26936@psf.upfronthosting.co.za>
Message-ID: <1481555770.72.0.350037729296.issue26936@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

New patch using sys.getandroidapilevel().
getandroidapilevel() is only available in 3.7, so only 3.7 is being fixed.

----------
stage: commit review -> patch review
versions:  -Python 3.6
Added file: http://bugs.python.org/file45858/test_socket_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26936>
_______________________________________

From report at bugs.python.org  Mon Dec 12 10:19:54 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 12 Dec 2016 15:19:54 +0000
Subject: [issue28942] await expressions in f-strings
In-Reply-To: <1481542924.02.0.218814637413.issue28942@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJLmeG_X18hyz=PH6iRXLy_JWZRA15MRNtEvDwpE1Gjbkg@mail.gmail.com>


Guido van Rossum added the comment:

I was going to say "no", but given that "yield" works, I think it is
reasonable to allow "await" as well. (And what about "yield from"?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28942>
_______________________________________

From report at bugs.python.org  Mon Dec 12 10:31:00 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 12 Dec 2016 15:31:00 +0000
Subject: [issue28759] access to mkfifo,
 mknod and hard links is controled by SELinux MAC on Android
In-Reply-To: <1479715975.06.0.930254771903.issue28759@psf.upfronthosting.co.za>
Message-ID: <1481556660.9.0.122513788026.issue28759@psf.upfronthosting.co.za>


Changes by Xavier de Gaye <xdegaye at gmail.com>:


----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28759>
_______________________________________

From report at bugs.python.org  Mon Dec 12 10:32:35 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 12 Dec 2016 15:32:35 +0000
Subject: [issue28937] str.split(): remove empty strings when sep is not None
In-Reply-To: <1481523500.99.0.428915472374.issue28937@psf.upfronthosting.co.za>
Message-ID: <20161212103232.3848855f@subdivisions.wooz.org>


Barry A. Warsaw added the comment:

I really appreciate all the feedback.  Here are some thoughts.

I'm well aware of the filter(), re, and other options, and certainly those can
be made to work, but they're non-obvious.  The reason I suggested an
enhancement to str.split() is because I've seen the replace().split() being used
far too often, and what I think is happening is that people take the most
natural path to accomplish their goals: they know they just want to do a
simple string split on a token (usually one character) so they start out with
the obvious str.split(',') or whatever.  Then they notice that it doesn't work
consistent with their mental model in some corner cases.

The next common step isn't from there to filter() or re.  The former isn't a
well-known API and the latter is viewed as "too complex".  Their next mental
step is "oh, so providing a sep has different behavior that I don't want, so
I'll just replace the comma with a space and now don't have to provide sep".
And now str.split() does what they want.  Done.  Move along.

I do wish the str.split() API was consistent w.r.t. to sep=None, but it's what
we have and is a very well known API.

@rhettinger: I'm of mixed opinion on it too!  I really wanted to get this in
the tracker and see if we could come up with something better, but so far I
still like `prune` the best.

@ebarry: Thanks for the draft docs, but that's not how I think about this.
I'd be utilitarian and get right to the point, e.g.:

"""
The value of `prune` controls whether empty strings are removed from the
resulting list.  The default value (None) says to use the default behavior,
which for backward compatibility reasons is different whether sep is None or
not (see above).  Regardless of the value of sep, when prune is True empty
strings are removed and when prune is False they are not.
"""

So @mrabarnett, +1 on the suggested defaults.

Lastly, as for Guido's admonition against boolean arguments, I would make
prune a keyword-only argument, so that forces the code to be readable and
should alleviate those concerns.  The trade-off is the extra typing, but
that's actually besides the point.  The win here is that the solution is
easily discoverable and avoids the intermediate string object.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28937>
_______________________________________

From report at bugs.python.org  Mon Dec 12 10:42:27 2016
From: report at bugs.python.org (Axel Haustant)
Date: Mon, 12 Dec 2016 15:42:27 +0000
Subject: [issue28935] distutils use ConfigParser in Python 3.x and fails to
 parse setup.cfg with percent sign
In-Reply-To: <1481397140.66.0.236784364676.issue28935@psf.upfronthosting.co.za>
Message-ID: <1481557347.63.0.0404516763159.issue28935@psf.upfronthosting.co.za>


Axel Haustant added the comment:

No it's not. Same problem but on a different part: the two cited issues are about the .pypirc file not the setup.cfg.
The parsing does not occurs at the same place and the fix does not works for setup.cfg (I tried before submitting this issue).

In this specific case, setuptools calls distutils to parse the file so the fix has to be in distutils not setuptools (whereas for .pypirc, this is setuptools which is parsing the file)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28935>
_______________________________________

From report at bugs.python.org  Mon Dec 12 10:46:11 2016
From: report at bugs.python.org (Axel Haustant)
Date: Mon, 12 Dec 2016 15:46:11 +0000
Subject: [issue28935] distutils use ConfigParser in Python 3.x and fails to
 parse setup.cfg with percent sign
In-Reply-To: <1481397140.66.0.236784364676.issue28935@psf.upfronthosting.co.za>
Message-ID: <1481557571.74.0.458200127217.issue28935@psf.upfronthosting.co.za>


Axel Haustant added the comment:

Sorry, it is effectively a duplicate of the second one.
But I submitted a patch which is not present in the other.
What should I do ? (I'll attach the patch to the other one instead)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28935>
_______________________________________

From report at bugs.python.org  Mon Dec 12 10:49:31 2016
From: report at bugs.python.org (Axel Haustant)
Date: Mon, 12 Dec 2016 15:49:31 +0000
Subject: [issue20754] Distribution.parse_config_files uses interpolation since
 Python 3
In-Reply-To: <1393201670.58.0.749043113933.issue20754@psf.upfronthosting.co.za>
Message-ID: <1481557771.72.0.777712069149.issue20754@psf.upfronthosting.co.za>


Axel Haustant added the comment:

I just attached the patch submitted on issue28935.

The fix is to simply give interpolation=None as ConfigParser parameter (as documented in the official Python 3.x ConfigParser documentation)

----------
keywords: +patch
nosy: +noirbizarre
Added file: http://bugs.python.org/file45859/disable-distutils-string-interpolation.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20754>
_______________________________________

From report at bugs.python.org  Mon Dec 12 10:51:56 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 12 Dec 2016 15:51:56 +0000
Subject: [issue28942] await expressions in f-strings
In-Reply-To: <1481541122.12.0.429355486169.issue28942@psf.upfronthosting.co.za>
Message-ID: <1481557916.39.0.499284976156.issue28942@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> I was going to say "no", but given that "yield" works, I think it is
reasonable to allow "await" as well. (And what about "yield from"?)

Agree.

I suspect the reason is that async/await aren't proper keywords in 3.5/3.6, and the hacks we have in tokenizer to recognize them aren't working in f-strings.

I'll assign this issue to myself to make sure it's resolved in 3.7 once we make async/await keywords.

----------
assignee: docs at python -> yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28942>
_______________________________________

From report at bugs.python.org  Mon Dec 12 10:54:18 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 12 Dec 2016 15:54:18 +0000
Subject: [issue28091] Document PEP 525
In-Reply-To: <1480969186.28.0.879526881588.issue28091@psf.upfronthosting.co.za>
Message-ID: <1481558058.63.0.264137824365.issue28091@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Guido, Nick,  

OK, let's keep using the current terminology.

Eric,

Will you have time to make a new version of the patch (addressing the review comments)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28091>
_______________________________________

From report at bugs.python.org  Mon Dec 12 11:00:24 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 12 Dec 2016 16:00:24 +0000
Subject: [issue16255] subrocess.Popen needs /bin/sh but Android only has
 /system/bin/sh
In-Reply-To: <1350421202.49.0.905467284446.issue16255@psf.upfronthosting.co.za>
Message-ID: <1481558424.67.0.639350811971.issue16255@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

New patch using sys.getandroidapilevel() that is only defined for Android.
getandroidapilevel() is only available in 3.7, so only 3.7 is being fixed.

----------
assignee:  -> xdegaye
dependencies:  -add function to os module for getting path to default shell
versions: +Python 3.7 -Python 3.6
Added file: http://bugs.python.org/file45860/unix_shell_16255_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16255>
_______________________________________

From report at bugs.python.org  Mon Dec 12 11:13:50 2016
From: report at bugs.python.org (arpit arora)
Date: Mon, 12 Dec 2016 16:13:50 +0000
Subject: [issue28948] Facing issue while running Python 3.6.0rc1 windows
 x86-64 web based installer
In-Reply-To: <1481549706.57.0.80853202455.issue28948@psf.upfronthosting.co.za>
Message-ID: <1481559230.44.0.854804200553.issue28948@psf.upfronthosting.co.za>


arpit arora added the comment:

Hi Steve,

Please find attached the required logs along with this message.

Thanks
Arpit Arora

----------
Added file: http://bugs.python.org/file45861/Python 3.6.0rc1 (64-bit)_20161212154459_010_path_JustForMe.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28948>
_______________________________________

From report at bugs.python.org  Mon Dec 12 11:16:06 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 12 Dec 2016 16:16:06 +0000
Subject: [issue28937] str.split(): remove empty strings when sep is not None
In-Reply-To: <1481469102.15.0.255147638686.issue28937@psf.upfronthosting.co.za>
Message-ID: <1481559366.77.0.00847882011175.issue28937@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I like the proposal. I agree that filter(None, ...) is not discoverable (and has its own magic).

So the proposal would be: prune=False -> empty strings stay, prune=True, empty strings are dropped, prune=None (default) use True if sep is None, False otherwise. Right?

Some end cases:

- ''.split(None, prune=True) -> ['']
- 'x  x'.split(None, prune=True) -> ['x', '', 'x']

Right?

While we're here I wish there was a specific argument we could translate .split(None) into, e.g. x.split() == x.split((' ', '\t', '\n', '\r', '\f')) # or whatever set of strings

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28937>
_______________________________________

From report at bugs.python.org  Mon Dec 12 11:16:13 2016
From: report at bugs.python.org (arpit arora)
Date: Mon, 12 Dec 2016 16:16:13 +0000
Subject: [issue28948] Facing issue while running Python 3.6.0rc1 windows
 x86-64 web based installer
In-Reply-To: <1481549706.57.0.80853202455.issue28948@psf.upfronthosting.co.za>
Message-ID: <1481559373.56.0.0909077177588.issue28948@psf.upfronthosting.co.za>


arpit arora added the comment:

Hi Steve,

Please neglect my last message, find the zip attached with this message.

Thanks
Arpit Arora

----------
Added file: http://bugs.python.org/file45862/Python 3.6.0rc1 (64-bit)_zip.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28948>
_______________________________________

From report at bugs.python.org  Mon Dec 12 11:26:08 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 12 Dec 2016 16:26:08 +0000
Subject: [issue28937] str.split(): remove empty strings when sep is not None
In-Reply-To: <1481559366.77.0.00847882011175.issue28937@psf.upfronthosting.co.za>
Message-ID: <20161212112604.36731825@subdivisions.wooz.org>


Barry A. Warsaw added the comment:

On Dec 12, 2016, at 04:16 PM, Guido van Rossum wrote:

>So the proposal would be: prune=False -> empty strings stay, prune=True,
>empty strings are dropped, prune=None (default) use True if sep is None,
>False otherwise. Right?

Yep!

>Some end cases:
>
>- ''.split(None, prune=True) -> ['']
>- 'x  x'.split(None, prune=True) -> ['x', '', 'x']
>
>Right?

Isn't that what you'd expect if prune=False instead?  (i.e. prune=True always
drops empty strings from the results)

>While we're here I wish there was a specific argument we could translate
>.split(None) into, e.g. x.split() == x.split((' ', '\t', '\n', '\r', '\f')) #
>or whatever set of strings

Is that the sep=<some tuple> idea that @syeberman suggested earlier?  If so,
then you could do:

>>> x.split(tuple(string.whitespace))

Would that suffice?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28937>
_______________________________________

From report at bugs.python.org  Mon Dec 12 11:33:17 2016
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 12 Dec 2016 16:33:17 +0000
Subject: [issue28949] Unable to launch Python interpreter
In-Reply-To: <1481553619.84.0.343525103437.issue28949@psf.upfronthosting.co.za>
Message-ID: <1481560397.35.0.416796889138.issue28949@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

Spontaneously, this issue has arisen again. Without a system restart or any system-level configuration changes, launching the interpreter is once again causing crashes. In addition to the crash log I pasted earlier, I see this in the console when launching the interpreter:

$ python3.6
Fatal Python error: Py_Initialize: unable to load the file system codec
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/encodings/__init__.py", line 33, in <module>
ImportError: cannot import name 'aliases'
zsh: abort      python3.6

----------
resolution: works for me -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28949>
_______________________________________

From report at bugs.python.org  Mon Dec 12 11:34:26 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 12 Dec 2016 16:34:26 +0000
Subject: [issue28935] distutils use ConfigParser in Python 3.x and fails to
 parse setup.cfg with percent sign
In-Reply-To: <1481397140.66.0.236784364676.issue28935@psf.upfronthosting.co.za>
Message-ID: <1481560466.61.0.105853879065.issue28935@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
stage:  -> resolved
superseder:  -> Distribution.parse_config_files uses interpolation since Python 3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28935>
_______________________________________

From report at bugs.python.org  Mon Dec 12 11:37:40 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 12 Dec 2016 16:37:40 +0000
Subject: [issue20754] Distribution.parse_config_files uses interpolation since
 Python 3
In-Reply-To: <1393201670.58.0.749043113933.issue20754@psf.upfronthosting.co.za>
Message-ID: <1481560660.34.0.53262902865.issue20754@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks! We also need a test case for the new behavior.

----------
stage: resolved -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20754>
_______________________________________

From report at bugs.python.org  Mon Dec 12 11:37:56 2016
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 12 Dec 2016 16:37:56 +0000
Subject: [issue28949] Unable to launch Python interpreter
In-Reply-To: <1481553619.84.0.343525103437.issue28949@psf.upfronthosting.co.za>
Message-ID: <1481560676.7.0.158039971192.issue28949@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

Indeed it seems that aliases.py is missing.

$ ls /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/encodings/a*
/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/encodings/ascii.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28949>
_______________________________________

From report at bugs.python.org  Mon Dec 12 11:41:55 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Mon, 12 Dec 2016 16:41:55 +0000
Subject: [issue28937] str.split(): remove empty strings when sep is not None
In-Reply-To: <1481469102.15.0.255147638686.issue28937@psf.upfronthosting.co.za>
Message-ID: <1481560915.52.0.391110438593.issue28937@psf.upfronthosting.co.za>


Changes by Emanuel Barry <barry at dadadata.net>:


Removed file: http://bugs.python.org/file45853/split_prune_1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28937>
_______________________________________

From report at bugs.python.org  Mon Dec 12 11:42:20 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Mon, 12 Dec 2016 16:42:20 +0000
Subject: [issue28937] str.split(): remove empty strings when sep is not None
In-Reply-To: <1481469102.15.0.255147638686.issue28937@psf.upfronthosting.co.za>
Message-ID: <1481560940.28.0.137174209097.issue28937@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

Barry: Sure, the docs example was just a quick write-up, you can word it however you want!

Guido: Pretty much, except the other way around (when prune is False, i.e. "don't remove empty strings").

The attached patch exposes the behaviour (it's identical to last night's, but I'm re-uploading it as an unrelated file went in), except that the `prune` argument isn't keyword-only (I didn't know how to do this, and didn't bother searching for just a proof-of-concept).

----------
Added file: http://bugs.python.org/file45863/split_prune_1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28937>
_______________________________________

From report at bugs.python.org  Mon Dec 12 11:47:44 2016
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 12 Dec 2016 16:47:44 +0000
Subject: [issue28949] Unable to launch Python interpreter
In-Reply-To: <1481553619.84.0.343525103437.issue28949@psf.upfronthosting.co.za>
Message-ID: <1481561264.44.0.356676640576.issue28949@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

Hmm. Looks like I may [have a trojan](http://stackoverflow.com/a/4707258).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28949>
_______________________________________

From report at bugs.python.org  Mon Dec 12 11:49:06 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 12 Dec 2016 16:49:06 +0000
Subject: [issue28921] Make str.count one character for latin1 string faster
In-Reply-To: <1481294304.37.0.437308839314.issue28921@psf.upfronthosting.co.za>
Message-ID: <1481561346.89.0.745268220078.issue28921@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

> The code looks too complex.

It is if looking at the patch alone. But the skill is used across stringlib and the only thing new is the bitwise operation.

str/bytes.count is not critical but not bad if it could be optimized and especially the effect is significant for long data.

I am not favour of rejecting it now but set priority to low.

----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28921>
_______________________________________

From report at bugs.python.org  Mon Dec 12 12:11:27 2016
From: report at bugs.python.org (Ned Deily)
Date: Mon, 12 Dec 2016 17:11:27 +0000
Subject: [issue28248] Upgrade installers to OpenSSL 1.0.2j
In-Reply-To: <1474552584.95.0.0318594270303.issue28248@psf.upfronthosting.co.za>
Message-ID: <1481562687.12.0.776123917513.issue28248@psf.upfronthosting.co.za>


Ned Deily added the comment:

@S Safihre. See the ReadMe included with the python.org 2.7.x installers.  (It is displayed at installation and a copy is installed to /Applications/Python 2.7/ReadMe.rtf)  As explained there, for 2.7.13rc1 as in recent previous 2.7.x releases, only the 10.5+ installer variant is linked with the private copy of OpenSSL; the 10.6+ installer uses the Apple-supplied system version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28248>
_______________________________________

From report at bugs.python.org  Mon Dec 12 12:12:14 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 12 Dec 2016 17:12:14 +0000
Subject: [issue28937] str.split(): remove empty strings when sep is not None
In-Reply-To: <1481560940.28.0.137174209097.issue28937@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJ+jJw2N=O1aMxxQyL1wiJ2a5+5u7OTBOzGemocUBVfWzQ@mail.gmail.com>


Guido van Rossum added the comment:

> except the other way around

Whoops. Indeed. So all's well here.

> x.split(tuple(string.whitespace))

Yes, that's what I was after. (But it can be a separate PR.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28937>
_______________________________________

From report at bugs.python.org  Mon Dec 12 12:16:51 2016
From: report at bugs.python.org (Ned Deily)
Date: Mon, 12 Dec 2016 17:16:51 +0000
Subject: [issue28949] Unable to launch Python interpreter
In-Reply-To: <1481553619.84.0.343525103437.issue28949@psf.upfronthosting.co.za>
Message-ID: <1481563011.16.0.877619335394.issue28949@psf.upfronthosting.co.za>


Ned Deily added the comment:

Jason, assuming you are using the python.org 3.6.0r1 installer, let us know what you find out!

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28949>
_______________________________________

From report at bugs.python.org  Mon Dec 12 12:28:41 2016
From: report at bugs.python.org (=?utf-8?b?VmVkcmFuIMSMYcSNacSH?=)
Date: Mon, 12 Dec 2016 17:28:41 +0000
Subject: [issue28937] str.split(): remove empty strings when sep is not None
In-Reply-To: <1481469102.15.0.255147638686.issue28937@psf.upfronthosting.co.za>
Message-ID: <1481563721.02.0.410353468205.issue28937@psf.upfronthosting.co.za>


Vedran ?a?i? added the comment:

I think Guido's mistake is relevant here. It tripped me too. Too much negatives, and "prune" is not really well-known verb. Besides, we already have str.splitlines' keepends, which works the opposite way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28937>
_______________________________________

From report at bugs.python.org  Mon Dec 12 13:11:31 2016
From: report at bugs.python.org (Steve Dower)
Date: Mon, 12 Dec 2016 18:11:31 +0000
Subject: [issue28947] Facing issue while running Python 3.6.0rc1 windows
 x86-64 web based installer
In-Reply-To: <1481549687.21.0.953592088628.issue28947@psf.upfronthosting.co.za>
Message-ID: <1481566291.94.0.230430341404.issue28947@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Facing issue while running Python 3.6.0rc1 windows x86-64 web based installer

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28947>
_______________________________________

From report at bugs.python.org  Mon Dec 12 13:15:13 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 12 Dec 2016 18:15:13 +0000
Subject: [issue28950] -j0 fails the check -j are not allowed together with
 -T/-l
Message-ID: <1481566513.26.0.47817718709.issue28950@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

For python test command line arguments, -j is not allowed together with -T/-l (don't know why):

[cpython]$ ./python -m test -j4 -T
usage: python -m test [options] [test_name1 [test_name2 ...]]
python path/to/Lib/test/regrtest.py [options] [test_name1 [test_name2 ...]]
regrtest.py: error: -T and -j don't go together!
Pass -h or --help for complete help.
[cpython]$ ./python -m test -j4 -l
usage: python -m test [options] [test_name1 [test_name2 ...]]
python path/to/Lib/test/regrtest.py [options] [test_name1 [test_name2 ...]]
regrtest.py: error: -l and -j don't go together!
Pass -h or --help for complete help.

But -j0 which also spawns multiple progresses fails the check.

----------
components: Tests
files: test-command-line-j0.patch
keywords: patch
messages: 283032
nosy: xiang.zhang
priority: normal
severity: normal
stage: patch review
status: open
title: -j0 fails the check -j are not allowed together with -T/-l
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45864/test-command-line-j0.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28950>
_______________________________________

From report at bugs.python.org  Mon Dec 12 13:20:00 2016
From: report at bugs.python.org (Steve Dower)
Date: Mon, 12 Dec 2016 18:20:00 +0000
Subject: [issue28948] Facing issue while running Python 3.6.0rc1 windows
 x86-64 web based installer
In-Reply-To: <1481549706.57.0.80853202455.issue28948@psf.upfronthosting.co.za>
Message-ID: <1481566800.09.0.846031343986.issue28948@psf.upfronthosting.co.za>


Steve Dower added the comment:

I don't support you have a file named "ucrtbase.dll" in your downloads directory? That would be a really simple explanation, and I'd know how to fix it.

If not, I don't have enough information from the logs to guess what the problem may be. For some reason, we thought you had already installed that update and so didn't try to install it again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28948>
_______________________________________

From report at bugs.python.org  Mon Dec 12 13:21:03 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 12 Dec 2016 18:21:03 +0000
Subject: [issue28950] regrtest: -j0 fails the check -j are not allowed
 together with -T/-l
In-Reply-To: <1481566513.26.0.47817718709.issue28950@psf.upfronthosting.co.za>
Message-ID: <1481566863.22.0.429524358699.issue28950@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +haypo
title: -j0 fails the check -j are not allowed together with -T/-l -> regrtest: -j0 fails the check -j are not allowed together with -T/-l

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28950>
_______________________________________

From report at bugs.python.org  Mon Dec 12 13:21:48 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 12 Dec 2016 18:21:48 +0000
Subject: [issue28950] regrtest: -j0 fails the check -j is not allowed together
 with -T/-l
In-Reply-To: <1481566513.26.0.47817718709.issue28950@psf.upfronthosting.co.za>
Message-ID: <1481566908.34.0.455143068393.issue28950@psf.upfronthosting.co.za>


Changes by Xiang Zhang <angwerzx at 126.com>:


----------
title: regrtest: -j0 fails the check -j are not allowed together with -T/-l -> regrtest: -j0 fails the check -j is not allowed together with -T/-l

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28950>
_______________________________________

From report at bugs.python.org  Mon Dec 12 13:57:28 2016
From: report at bugs.python.org (kevin)
Date: Mon, 12 Dec 2016 18:57:28 +0000
Subject: [issue28951] re.flags not documented in Module Contents as promised.
Message-ID: <1481569048.46.0.00215126822864.issue28951@psf.upfronthosting.co.za>


New submission from kevin:

In the online documentation of module re 
  (https://docs.python.org/3.5/library/re.html) 
under 
  6.2.1. Regular Expression Syntax
for item
  (?aiLmsux)
we are promised "The flags are described in Module Contents"
but no description is found there.  In fact a number of other references are found to flags, but no description of the individual flags.  AFAICT the closest thing to a description is found at the original reference -- at least it gives a code and name for each one.

----------
assignee: docs at python
components: Documentation
messages: 283034
nosy: 4Dummies, docs at python
priority: normal
severity: normal
status: open
title: re.flags not documented in Module Contents as promised.
type: enhancement
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28951>
_______________________________________

From report at bugs.python.org  Mon Dec 12 13:59:27 2016
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 12 Dec 2016 18:59:27 +0000
Subject: [issue28941] Update the link to Source Code in Python Docs from hg to
 github
In-Reply-To: <1481513819.65.0.156579360966.issue28941@psf.upfronthosting.co.za>
Message-ID: <1481569167.34.0.315902124315.issue28941@psf.upfronthosting.co.za>


Brett Cannon added the comment:

How is this different from issue #28929?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28941>
_______________________________________

From report at bugs.python.org  Mon Dec 12 14:03:00 2016
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 12 Dec 2016 19:03:00 +0000
Subject: [issue26876] Extend MSVCCompiler class to respect environment
 variables
In-Reply-To: <1461866719.82.0.2605655084.issue26876@psf.upfronthosting.co.za>
Message-ID: <1481569380.84.0.303502434154.issue26876@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Steve, does the latest patch look good to you?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26876>
_______________________________________

From report at bugs.python.org  Mon Dec 12 14:03:22 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 12 Dec 2016 19:03:22 +0000
Subject: [issue28951] re.flags not documented in Module Contents as promised.
In-Reply-To: <1481569048.46.0.00215126822864.issue28951@psf.upfronthosting.co.za>
Message-ID: <1481569402.68.0.145626334512.issue28951@psf.upfronthosting.co.za>


R. David Murray added the comment:

When I follow the link to module contents, I find a list of the flags with their descriptions.  (re.A, re.I, etc, etc).  Perhaps you are confusing the letters used in the regular expression to represent the flags with the flags themselves?  I'm not sure how we could make that clearer.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28951>
_______________________________________

From report at bugs.python.org  Mon Dec 12 14:04:22 2016
From: report at bugs.python.org (Mariatta Wijaya)
Date: Mon, 12 Dec 2016 19:04:22 +0000
Subject: [issue28941] Update the link to Source Code in Python Docs from hg to
 github
In-Reply-To: <1481513819.65.0.156579360966.issue28941@psf.upfronthosting.co.za>
Message-ID: <1481569462.03.0.892797284656.issue28941@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

There's source code of the documentation itself 
https://github.com/python/cpython/blob/master/Doc/library/abc.rst ) for 

and source code of abc.py 
https://github.com/python/cpython/blob/master/Lib/abc.py

Maybe I misunderstood, I figured issue #28929 is for fixing the docs url only.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28941>
_______________________________________

From report at bugs.python.org  Mon Dec 12 14:17:31 2016
From: report at bugs.python.org (paul j3)
Date: Mon, 12 Dec 2016 19:17:31 +0000
Subject: [issue11874] argparse assertion failure with brackets in metavars
In-Reply-To: <1303201252.58.0.236363581255.issue11874@psf.upfronthosting.co.za>
Message-ID: <1481570251.82.0.461365611192.issue11874@psf.upfronthosting.co.za>


Changes by paul j3 <ajipanca at gmail.com>:


----------
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11874>
_______________________________________

From report at bugs.python.org  Mon Dec 12 14:20:38 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 12 Dec 2016 19:20:38 +0000
Subject: [issue28896] Embeddable zip allows Windows registry to override
 module location
In-Reply-To: <1481128708.35.0.521458556277.issue28896@psf.upfronthosting.co.za>
Message-ID: <20161212192035.12742.45493.8FB67B74@psf.io>


Roundup Robot added the comment:

New changeset 5bd248c2cc75 by Steve Dower in branch '3.6':
Issue #28896: Disable WindowsRegistryFinder by default.
https://hg.python.org/cpython/rev/5bd248c2cc75

New changeset 4bd131b028ce by Steve Dower in branch 'default':
Issue #28896: Disable WindowsRegistryFinder by default.
https://hg.python.org/cpython/rev/4bd131b028ce

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28896>
_______________________________________

From report at bugs.python.org  Mon Dec 12 14:21:48 2016
From: report at bugs.python.org (Steve Dower)
Date: Mon, 12 Dec 2016 19:21:48 +0000
Subject: [issue28896] Embeddable zip allows Windows registry to override
 module location
In-Reply-To: <1481128708.35.0.521458556277.issue28896@psf.upfronthosting.co.za>
Message-ID: <1481570508.05.0.16213486083.issue28896@psf.upfronthosting.co.za>


Steve Dower added the comment:

And that commit removes WindowsRegistryFinder from sys.meta_path on startup (as well as fixing regeneration of importlib when building on Windows).

It should *not* be cherry picked for 3.6.0.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28896>
_______________________________________

From report at bugs.python.org  Mon Dec 12 14:38:54 2016
From: report at bugs.python.org (kevin)
Date: Mon, 12 Dec 2016 19:38:54 +0000
Subject: [issue28952] csv.Sniffer().sniff(0 returns a value without the
 "strict" attribute
Message-ID: <1481571534.8.0.412951784743.issue28952@psf.upfronthosting.co.za>


New submission from kevin:

In 
  https://docs.python.org/3.5/library/csv.html#dialects-and-formatting-parameters 

the Dialect objects are described as supporting, among others, the Dialect.strict attribute, with a default value of False.  However, the
sniff() returns an object lacking this attribute entirely, not even with the value None.  At least on my inputs, which I'd include but they have personnel information.  I can redact it if required.

----------
components: Library (Lib)
messages: 283041
nosy: 4Dummies
priority: normal
severity: normal
status: open
title: csv.Sniffer().sniff(0 returns a value without the "strict" attribute
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28952>
_______________________________________

From report at bugs.python.org  Mon Dec 12 14:57:06 2016
From: report at bugs.python.org (Julien Palard)
Date: Mon, 12 Dec 2016 19:57:06 +0000
Subject: [issue28933] AC: Accept None as a Py_ssize_t default value
In-Reply-To: <1481389976.88.0.777049011956.issue28933@psf.upfronthosting.co.za>
Message-ID: <1481572626.22.0.47181700033.issue28933@psf.upfronthosting.co.za>


Julien Palard added the comment:

Hi Larry,

Did you take more time to review this patch and my last comments? I don't think it that awful as it does _not_ apply until explicitly asked for, but I'm open to discuss it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28933>
_______________________________________

From report at bugs.python.org  Mon Dec 12 15:10:29 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 12 Dec 2016 20:10:29 +0000
Subject: [issue28933] AC: Accept None as a Py_ssize_t default value
In-Reply-To: <1481389976.88.0.777049011956.issue28933@psf.upfronthosting.co.za>
Message-ID: <1481573429.89.0.61699074019.issue28933@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Agreed with Larry. "Special cases aren't special enough to break the rules." General converter shouldn't be changed for just one use case. Write your own special converter. Or just use the "O" converter and manually convert Python object to C value. That can be simpler and more readable.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28933>
_______________________________________

From report at bugs.python.org  Mon Dec 12 15:17:00 2016
From: report at bugs.python.org (Julien Palard)
Date: Mon, 12 Dec 2016 20:17:00 +0000
Subject: [issue28845] Clean up known issues for AIX
In-Reply-To: <1480542032.97.0.55863701863.issue28845@psf.upfronthosting.co.za>
Message-ID: <1481573820.52.0.0772875601704.issue28845@psf.upfronthosting.co.za>


Julien Palard added the comment:

LGTM but no AIX to test it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28845>
_______________________________________

From report at bugs.python.org  Mon Dec 12 15:57:23 2016
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 12 Dec 2016 20:57:23 +0000
Subject: [issue28949] Unable to launch Python interpreter
In-Reply-To: <1481553619.84.0.343525103437.issue28949@psf.upfronthosting.co.za>
Message-ID: <1481576243.74.0.0615328881142.issue28949@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

I am using the python.org rc1 installer, confirmed to match the public md5 sum:

$ md5 ~/Downloads/python-3.6.0rc1-macosx10.6.pkg 
MD5 (/Users/jaraco/Downloads/python-3.6.0rc1-macosx10.6.pkg) = 404c390ae27f067aaab34f168cf913eb

I downloaded ClamXav and had it scan my entire system. It found nothing of interest, only two Windows exploits, one in a driver from Asus and another in an attachment to an e-mail that was already filed as junk. It also found two "Eicar-Test-Signature" hits in old IRC logs.

So if my Mac has a virus, it's new enough that it's not being detected by ClamXav.

I'm going to continue to investigate and see if I can detect what event triggers the removal of that file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28949>
_______________________________________

From report at bugs.python.org  Mon Dec 12 16:18:59 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 12 Dec 2016 21:18:59 +0000
Subject: [issue28919] Simplify `_copy_func_details` in unittest.mock
Message-ID: <1481577539.0.0.478814731257.issue28919@psf.upfronthosting.co.za>


New submission from Berker Peksag:

Thanks for the patch. I only did a quick review, but it looks good to me.

----------
nosy: +berker.peksag, michael.foord
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28919>
_______________________________________

From report at bugs.python.org  Mon Dec 12 16:19:08 2016
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 12 Dec 2016 21:19:08 +0000
Subject: [issue28949] Unable to launch Python interpreter
In-Reply-To: <1481553619.84.0.343525103437.issue28949@psf.upfronthosting.co.za>
Message-ID: <1481577548.75.0.840410769991.issue28949@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

I thought I was on to something when I found this technique for using dtrace to detect a file deletion: https://blogs.oracle.com/zoneszone/entry/who_keeps_removing_that_file

However, I don't seem to have privilege to run it.

$ cat trap-aliases-delete 
#! /usr/sbin/dtrace -wqs

syscall::unlinkat:entry
/cleanpath(copyinstr(arg1)) == "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/encodings/aliases.py"/
{
        stop();
        printf("%s[%d] caught removing aliases.py\n", execname, pid);
        system("ptree %d; pstack %d; prun %d", pid, pid, pid);
}
$ sudo ./trap-aliases-delete
dtrace: system integrity protection is on, some features will not be available

dtrace: could not enable tracing: Permission denied

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28949>
_______________________________________

From report at bugs.python.org  Mon Dec 12 16:23:07 2016
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 12 Dec 2016 21:23:07 +0000
Subject: [issue28949] Unable to launch Python interpreter
In-Reply-To: <1481553619.84.0.343525103437.issue28949@psf.upfronthosting.co.za>
Message-ID: <1481577787.86.0.213458877635.issue28949@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

Looks like I can [disable SIP](http://internals.exposed/blog/dtrace-vs-sip.html) and dtrace will be viable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28949>
_______________________________________

From report at bugs.python.org  Mon Dec 12 16:27:46 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 12 Dec 2016 21:27:46 +0000
Subject: [issue28923] Nonexisting encoding specified in Tix.py
In-Reply-To: <1481304070.27.0.11719456506.issue28923@psf.upfronthosting.co.za>
Message-ID: <1481578066.78.0.241727412808.issue28923@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +serhiy.storchaka, terry.reedy
stage:  -> patch review
type: compile error -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28923>
_______________________________________

From report at bugs.python.org  Mon Dec 12 16:31:39 2016
From: report at bugs.python.org (Julien Palard)
Date: Mon, 12 Dec 2016 21:31:39 +0000
Subject: [issue28933] AC: Accept None as a Py_ssize_t default value
In-Reply-To: <1481389976.88.0.777049011956.issue28933@psf.upfronthosting.co.za>
Message-ID: <1481578299.06.0.453947702378.issue28933@psf.upfronthosting.co.za>


Julien Palard added the comment:

> for just one use case

I don't think that using None in a default argument is "one use case", nor a "special case" it's more like a "widly used pattern" that I'd like to make simple to implement (also see http://bugs.python.org/issue28754#msg282891).

I'm not sure you're against my idea of accepting None like:

    something: Py_ssize_t(c_default="-1") = None

Or you're against my implementation, which I can understand, I'm not a fan of modifying getargs.c for this, it may be doable by implementing a new converter in clinic.py like "Py_ssize_t_optional", and it may not require more work than modifying getargs.c.

But AC is already defining 4 different "default values", counting the "= value" from the AC DSL, I'm not sure that adding the "optional" string somewhere make any of this clearer, typically what about the semantic difference between:

    something: Py_ssize_t_optional()

and

    something: Py_ssize_t() = None

So my original idea was to accept "= None" indistinctly of the used type, I mean allowing:

    something: Py_ssize_t(c_default=?) = None
    something: float(c_default=?) = None
    something: double(c_default=?) = None
    ?
    ?

Which is, I think, one of the clearest way to express "It's an optional parameter, on the Python side the default value is None, but c-side the default value is of the right type an is ?".

In other words, I'm proposing to optionally extend the "c_default" usage from "not given" to "not given or given None".

I failed to implement if for any types, mainly because AC is delegating to getargs for Py_ssize_t, so I though starting with my specific need (Py_ssize_t for issue28754) was a good start and POC.

Another solution may be to change the Py_ssize_t_converter to drop the format_unit, allowing us to implement the converter in clinic instead of getargs.c. It's opening a long term door of completly dropping non-"O" format units. I mean, if we drop every non-"O" format units in clinic we'll be able to use a faster implementation of _PyArg_ParseStack, one not parsing a mini-arg-definition-language at runtime (the "OO|nO&:").

I'm willing to implement something clean for this but please be more precise in your feedback.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28933>
_______________________________________

From report at bugs.python.org  Mon Dec 12 16:37:21 2016
From: report at bugs.python.org (Ned Deily)
Date: Mon, 12 Dec 2016 21:37:21 +0000
Subject: [issue28089] asyncio: Document that TCP_NODELAY is now used by default
In-Reply-To: <1480969004.54.0.512137578278.issue28089@psf.upfronthosting.co.za>
Message-ID: <1481578641.41.0.491252991759.issue28089@psf.upfronthosting.co.za>


Ned Deily added the comment:

Yury, look good to you?

----------
stage: patch review -> commit review
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28089>
_______________________________________

From report at bugs.python.org  Mon Dec 12 16:38:19 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 12 Dec 2016 21:38:19 +0000
Subject: [issue28932] Fail compile Python 3.6.0rc1 on OpenBSD 6.0
In-Reply-To: <1481388547.33.0.916805591486.issue28932@psf.upfronthosting.co.za>
Message-ID: <1481578699.92.0.626102259099.issue28932@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +haypo
stage:  -> patch review
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28932>
_______________________________________

From report at bugs.python.org  Mon Dec 12 16:42:24 2016
From: report at bugs.python.org (Michael Foord)
Date: Mon, 12 Dec 2016 21:42:24 +0000
Subject: [issue28919] Simplify `_copy_func_details` in unittest.mock
In-Reply-To: <1481577539.0.0.478814731257.issue28919@psf.upfronthosting.co.za>
Message-ID: <1481578944.14.0.255843902483.issue28919@psf.upfronthosting.co.za>


Michael Foord added the comment:

Yep, looks good to me to.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28919>
_______________________________________

From report at bugs.python.org  Mon Dec 12 16:43:13 2016
From: report at bugs.python.org (Ram Rachum)
Date: Mon, 12 Dec 2016 21:43:13 +0000
Subject: [issue28953] Use `raise from` when raising new IncompleteRead
Message-ID: <1481578993.98.0.52471260982.issue28953@psf.upfronthosting.co.za>


New submission from Ram Rachum:

I had this error come up in my code, and because it doesn't use `raise ... from` I thought that the second error was unexpected, while in fact it wasn't. This patch should fix that.

----------
components: Library (Lib)
files: 1.patch
keywords: patch
messages: 283052
nosy: cool-RR
priority: normal
severity: normal
status: open
title: Use `raise from` when raising new IncompleteRead
versions: Python 3.7
Added file: http://bugs.python.org/file45865/1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28953>
_______________________________________

From report at bugs.python.org  Mon Dec 12 16:43:40 2016
From: report at bugs.python.org (Ram Rachum)
Date: Mon, 12 Dec 2016 21:43:40 +0000
Subject: [issue28953] Use `raise from` when raising new IncompleteRead
In-Reply-To: <1481578993.98.0.52471260982.issue28953@psf.upfronthosting.co.za>
Message-ID: <1481579020.09.0.519694488556.issue28953@psf.upfronthosting.co.za>


Changes by Ram Rachum <ram at rachum.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28953>
_______________________________________

From report at bugs.python.org  Mon Dec 12 16:45:29 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 12 Dec 2016 21:45:29 +0000
Subject: [issue28089] asyncio: Document that TCP_NODELAY is now used by default
In-Reply-To: <1480969004.54.0.512137578278.issue28089@psf.upfronthosting.co.za>
Message-ID: <20161212214526.99657.39161.2BD0FA45@psf.io>


Roundup Robot added the comment:

New changeset 853e3f4d6cd9 by Yury Selivanov in branch '3.6':
Issue #28089: Document TCP_NODELAY in asyncio
https://hg.python.org/cpython/rev/853e3f4d6cd9

New changeset 0d209cc7ffdc by Yury Selivanov in branch 'default':
Merge 3.6 (issue #28089)
https://hg.python.org/cpython/rev/0d209cc7ffdc

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28089>
_______________________________________

From report at bugs.python.org  Mon Dec 12 16:46:32 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 12 Dec 2016 21:46:32 +0000
Subject: [issue28089] asyncio: Document that TCP_NODELAY is now used by default
In-Reply-To: <1480969004.54.0.512137578278.issue28089@psf.upfronthosting.co.za>
Message-ID: <1481579192.53.0.309935515709.issue28089@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> Yury, look good to you?

Yes; committed the patch with a small addition.  Thanks, Mariatta!

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28089>
_______________________________________

From report at bugs.python.org  Mon Dec 12 16:57:43 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 12 Dec 2016 21:57:43 +0000
Subject: [issue28512] PyErr_SyntaxLocationEx() and
 PyErr_SyntaxLocationObject() always set the offset attribute to None
In-Reply-To: <1477173007.35.0.842183977255.issue28512@psf.upfronthosting.co.za>
Message-ID: <1481579863.37.0.604831291338.issue28512@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Hi Serhiy, there are two commented-out lines in https://hg.python.org/cpython/rev/ea1c49ea8136#l3.10 (only in 3.5)


+        #with self.assertRaises(AssertionError):
+            #support.check_syntax_error(self, "x=1")

----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28512>
_______________________________________

From report at bugs.python.org  Mon Dec 12 16:58:51 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 12 Dec 2016 21:58:51 +0000
Subject: [issue28933] AC: Accept None as a Py_ssize_t default value
In-Reply-To: <1481389976.88.0.777049011956.issue28933@psf.upfronthosting.co.za>
Message-ID: <1481579931.3.0.708585461473.issue28933@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

First, it looks weird if the default value affects accepted types. Second, how many use cases for your converter besides the bisect module?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28933>
_______________________________________

From report at bugs.python.org  Mon Dec 12 17:12:15 2016
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 12 Dec 2016 22:12:15 +0000
Subject: [issue28949] Unable to launch Python interpreter
In-Reply-To: <1481553619.84.0.343525103437.issue28949@psf.upfronthosting.co.za>
Message-ID: <1481580735.44.0.913938455981.issue28949@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

Before disabling SIP, I found I could use fs_usage to get some visibility into fs changes:

sudo fs_usage -w -f filesys | grep aliases.py

To test my understanding of fs_usage, I deleted aliases.py (also confirming that triggers the error). When I did so, I noticed something interesting - my Dropbox account detected deletion of 34 instances of a file called aliases.py. A quick search reveals that I have about 34 virtualenvs created by tox, each of which links .tox/python/lib/python3.6/encodings to /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/encodings.

Now I'm suspecting that there's a race condition where Dropbox ends up deleting the system file. Either that, or there's a buggy piece of code somewhere that's deleting encodings/aliases.py (and possibly other files) in one of these virtualenvs, causing the file to be deleted in the system.

I'm using Dropbox v16.3.27 (https://www.dropboxforum.com/t5/Desktop-client-builds/Beta-Build-16-3-27/td-p/197057).

I'll continue to investigate, but I'm becoming increasingly suspicious of this being an environmental problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28949>
_______________________________________

From report at bugs.python.org  Mon Dec 12 17:21:52 2016
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 12 Dec 2016 22:21:52 +0000
Subject: [issue28949] Stdlib modules disappear from file system
In-Reply-To: <1481553619.84.0.343525103437.issue28949@psf.upfronthosting.co.za>
Message-ID: <1481581312.96.0.730458414025.issue28949@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

I've just encountered what appears to be a different manifestation of the same issue. I unlinked the .tox directory and that rendered importlib broken.

$ pwd
/Users/jaraco/yg/queso
$ rm -R .tox
$ python
Python 3.6.0rc1 (v3.6.0rc1:29a273eee9a5, Dec  6 2016, 16:24:13) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> ^D
$ python -m tox
Could not import runpy module
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/runpy.py", line 15, in <module>
    import importlib.util
ModuleNotFoundError: No module named 'importlib.util'
$ ls /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/importlib
__init__.py		__pycache__		_bootstrap.py		_bootstrap_external.py	abc.py			machinery.py

Although I'm not certain that another process wasn't involved, I'm confident that it was the removal of the .tox directory (and interaction with Dropbox) that caused the corruption.

----------
title: Unable to launch Python interpreter -> Stdlib modules disappear from file system

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28949>
_______________________________________

From report at bugs.python.org  Mon Dec 12 17:24:43 2016
From: report at bugs.python.org (Eric Appelt)
Date: Mon, 12 Dec 2016 22:24:43 +0000
Subject: [issue28091] Document PEP 525
In-Reply-To: <1480969186.28.0.879526881588.issue28091@psf.upfronthosting.co.za>
Message-ID: <1481581483.76.0.641314599804.issue28091@psf.upfronthosting.co.za>


Eric Appelt added the comment:

Yes - I'll work on the patch tonight.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28091>
_______________________________________

From report at bugs.python.org  Mon Dec 12 17:25:45 2016
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 12 Dec 2016 22:25:45 +0000
Subject: [issue28933] AC: Accept None as a Py_ssize_t default value
In-Reply-To: <1481389976.88.0.777049011956.issue28933@psf.upfronthosting.co.za>
Message-ID: <1481581545.12.0.653957858024.issue28933@psf.upfronthosting.co.za>


Larry Hastings added the comment:

I don't want this change committed to CPython, you can do what you need with a converter so do that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28933>
_______________________________________

From report at bugs.python.org  Mon Dec 12 17:33:24 2016
From: report at bugs.python.org (Ned Deily)
Date: Mon, 12 Dec 2016 22:33:24 +0000
Subject: [issue28949] Stdlib modules disappear from file system
In-Reply-To: <1481553619.84.0.343525103437.issue28949@psf.upfronthosting.co.za>
Message-ID: <1481582004.19.0.407124445604.issue28949@psf.upfronthosting.co.za>


Ned Deily added the comment:

That's sounding better, thanks.  Out of curiosity, are there hard links involved?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28949>
_______________________________________

From report at bugs.python.org  Mon Dec 12 17:49:15 2016
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 12 Dec 2016 22:49:15 +0000
Subject: [issue28949] Stdlib modules disappear from file system
In-Reply-To: <1481553619.84.0.343525103437.issue28949@psf.upfronthosting.co.za>
Message-ID: <1481582955.85.0.270827338244.issue28949@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

I don't think hard links are involved. I see symlinks in the .tox/python virutalenv, and virtualenv defaults to creating symlinks (https://github.com/pypa/virtualenv/blob/master/virtualenv.py#L565-L570) and falls back to copying files rather than hard linking.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28949>
_______________________________________

From report at bugs.python.org  Mon Dec 12 17:56:21 2016
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 12 Dec 2016 22:56:21 +0000
Subject: [issue28949] Stdlib modules disappear from file system
In-Reply-To: <1481553619.84.0.343525103437.issue28949@psf.upfronthosting.co.za>
Message-ID: <1481583381.13.0.051790594112.issue28949@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

I've reinstalled Dropbox, downgrading to 15.4.22. I'll see if that helps.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28949>
_______________________________________

From report at bugs.python.org  Mon Dec 12 18:05:58 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 12 Dec 2016 23:05:58 +0000
Subject: [issue28923] Nonexisting encoding specified in Tix.py
In-Reply-To: <1481304070.27.0.11719456506.issue28923@psf.upfronthosting.co.za>
Message-ID: <1481583958.74.0.367063937029.issue28923@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I am a little puzzled as to how a file rename changed the content, but the annotation history seems to show that.  Anyway, ...

When I load the file in IDLE 2.7, I get a warning.  I am a bit surprised as this is not a proper encoding declaration.  IDLE's re must be a bit loose.

In 3.x, the file starts with

# -*-mode: python; fill-column: 75; tab-width: 8 -*-
#
# $Id$
#

This is all ancient, obsolete, junk specific to some editor.  (The file itself not used 4 space indents.) I think it should be removed from all current versions.  As near as I can tell, there are no non-ascii chars in the file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28923>
_______________________________________

From report at bugs.python.org  Mon Dec 12 19:24:07 2016
From: report at bugs.python.org (Steve Dower)
Date: Tue, 13 Dec 2016 00:24:07 +0000
Subject: [issue26876] Extend MSVCCompiler class to respect environment
 variables
In-Reply-To: <1461866719.82.0.2605655084.issue26876@psf.upfronthosting.co.za>
Message-ID: <1481588647.57.0.422296290166.issue26876@psf.upfronthosting.co.za>


Steve Dower added the comment:

I'd rather only take the change to _msvccompiler and not the ones that are there for historical interest (a.k.a. backwards compatibility with people who never expect internal implementation details to change).

If any tools break because they're using the wrong compiler class, please file a bug against them.

I didn't check the 2.7 file, but the one for master is fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26876>
_______________________________________

From report at bugs.python.org  Mon Dec 12 20:03:37 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Tue, 13 Dec 2016 01:03:37 +0000
Subject: [issue28944] A lack of line 6
In-Reply-To: <1481544628.07.0.0933253462311.issue28944@psf.upfronthosting.co.za>
Message-ID: <1481591017.68.0.594481593523.issue28944@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

You're reusing the same issue for completely different things. Make a separate issue for separate docs issues.

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28944>
_______________________________________

From report at bugs.python.org  Mon Dec 12 21:22:46 2016
From: report at bugs.python.org (woo yoo)
Date: Tue, 13 Dec 2016 02:22:46 +0000
Subject: [issue28954] Incorrect EBNF rule of keywords_arguments
Message-ID: <1481595766.74.0.577639992265.issue28954@psf.upfronthosting.co.za>


New submission from woo yoo:

This is the documented rule, which lacks a comma within the last line.
keywords_arguments   ::=  (keyword_item | "**" expression)
                          ("," keyword_item | "**" expression)*
The correct form should be:
keywords_arguments   ::=  (keyword_item | "**" expression)
                          ("," keyword_item |",""**" expression)*

The original documentation is https://docs.python.org/3/reference/expressions.html#calls

----------
assignee: docs at python
components: Documentation
messages: 283067
nosy: docs at python, woo yoo
priority: normal
severity: normal
status: open
title: Incorrect EBNF rule of keywords_arguments
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28954>
_______________________________________

From report at bugs.python.org  Mon Dec 12 21:41:55 2016
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 13 Dec 2016 02:41:55 +0000
Subject: [issue26110] Speedup method calls 1.2x
In-Reply-To: <1452791347.05.0.923215900831.issue26110@psf.upfronthosting.co.za>
Message-ID: <1481596915.73.0.5555892616.issue26110@psf.upfronthosting.co.za>


Changes by INADA Naoki <songofacandy at gmail.com>:


Added file: http://bugs.python.org/file45866/call_method_5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26110>
_______________________________________

From report at bugs.python.org  Mon Dec 12 22:15:07 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 13 Dec 2016 03:15:07 +0000
Subject: [issue28950] regrtest: -j0 fails the check -j is not allowed together
 with -T/-l
In-Reply-To: <1481566513.26.0.47817718709.issue28950@psf.upfronthosting.co.za>
Message-ID: <1481598907.64.0.667821836508.issue28950@psf.upfronthosting.co.za>


Changes by Xiang Zhang <angwerzx at 126.com>:


----------
versions: +Python 2.7
Added file: http://bugs.python.org/file45867/test-command-line-j0-with-test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28950>
_______________________________________

From report at bugs.python.org  Mon Dec 12 22:17:30 2016
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 13 Dec 2016 03:17:30 +0000
Subject: [issue20754] Distribution.parse_config_files uses interpolation since
 Python 3
In-Reply-To: <1393201670.58.0.749043113933.issue20754@psf.upfronthosting.co.za>
Message-ID: <1481599050.34.0.495331898168.issue20754@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

I forget if there was a reason for choosing RawConfigParser over ConfigParaer with interpolation=None. I'd like to know that before choosing the latter. I'd also like to see if appropriate the implementation patched in Setuptools, providing compatibility for older Pythons. 

Also, +1 for a test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20754>
_______________________________________

From report at bugs.python.org  Mon Dec 12 23:09:31 2016
From: report at bugs.python.org (woo yoo)
Date: Tue, 13 Dec 2016 04:09:31 +0000
Subject: [issue28955] Not matched behavior of numeric comparison with the
 documentation
Message-ID: <1481602171.57.0.675005739221.issue28955@psf.upfronthosting.co.za>


New submission from woo yoo:

According to the documentation, which said "Additionally, comparing any number to a not-a-number value will return False. ",the comparison of `float('nan')!= 1`should yield False, while the result is True.

Small errors like this in documentation should be corrected?

The related link https://docs.python.org/3/reference/expressions.html#value-comparisons

----------
assignee: docs at python
components: Documentation
messages: 283069
nosy: docs at python, woo yoo
priority: normal
severity: normal
status: open
title: Not matched behavior of numeric comparison with the documentation
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28955>
_______________________________________

From report at bugs.python.org  Mon Dec 12 23:13:08 2016
From: report at bugs.python.org (woo yoo)
Date: Tue, 13 Dec 2016 04:13:08 +0000
Subject: [issue28955] Not matched behavior of numeric comparison with the
 documentation
In-Reply-To: <1481602171.57.0.675005739221.issue28955@psf.upfronthosting.co.za>
Message-ID: <1481602388.0.0.456050183433.issue28955@psf.upfronthosting.co.za>


woo yoo added the comment:

Maybe the description should be changed into "all order comparisons of not-a-number and any number will return False"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28955>
_______________________________________

From report at bugs.python.org  Mon Dec 12 23:21:41 2016
From: report at bugs.python.org (Srikanth Anantharam)
Date: Tue, 13 Dec 2016 04:21:41 +0000
Subject: [issue28956] return minimum of modes for a multimodal distribution
 instead of raising a StatisticsError
Message-ID: <1481602901.85.0.570887953824.issue28956@psf.upfronthosting.co.za>


New submission from Srikanth Anantharam:

return minimum of modes for a multimodal distribution

instead of raising a StatisticsError

----------
components: Library (Lib)
messages: 283071
nosy: Srikanth Anantharam
priority: normal
pull_requests: 3
severity: normal
status: open
title: return minimum of modes for a multimodal distribution instead of raising a StatisticsError
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28956>
_______________________________________

From report at bugs.python.org  Mon Dec 12 23:24:44 2016
From: report at bugs.python.org (Eric Appelt)
Date: Tue, 13 Dec 2016 04:24:44 +0000
Subject: [issue28091] Document PEP 525
In-Reply-To: <1480969186.28.0.879526881588.issue28091@psf.upfronthosting.co.za>
Message-ID: <1481603084.45.0.987191520388.issue28091@psf.upfronthosting.co.za>


Eric Appelt added the comment:

I believe that I addressed all the comments in the previous review (although its always possible I missed something), and have a new patch with the improvements and fixes.

I also noticed that in asyncio, loop.shutdown_asyncgens() is a coroutinemethod and fixed the markup to reflect that as I previously labeled it a method. The example I added here is as suggested, but it differs from the example in PEP525 in that shutdown_asyncgens() is run in a finally clause, which makes sense to me.

When applying the comments to sys.set_asyncgen_hooks() I verified that the keywords are optional but it is apparently not keyword only. I couldn't find many good examples of referencing source, so you may want to closely check how I linked to the shutdown_asyncgens() implementation.

----------
Added file: http://bugs.python.org/file45868/pep525_pep530_docs_v1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28091>
_______________________________________

From report at bugs.python.org  Mon Dec 12 23:42:38 2016
From: report at bugs.python.org (Ivan Pozdeev)
Date: Tue, 13 Dec 2016 04:42:38 +0000
Subject: [issue25458] ftplib: command response shift - mismatch
In-Reply-To: <1445510152.74.0.829316001802.issue25458@psf.upfronthosting.co.za>
Message-ID: <1481604158.32.0.0301798814159.issue25458@psf.upfronthosting.co.za>


Ivan Pozdeev added the comment:

I tried to fix `urllib' and ultimately failed. In a nutshell, handling of the aftermath of an `ntransfercmd' is broken.

Since `ntransfercmd'/`transfercmd' returns a socket, handling of an end-of-transmission response is done in independently invoked code - upon the socket's close. So, if any other operation on the command connection is attempted before that, `ftplib's handling of the session breaks.

The plan to fix follows, but first, some background:

According to http://stackoverflow.com/questions/2549829/using-ftplib-for-multithread-uploads , FTP actually doesn't, and is not designed to, handle transfers in "background". In that you surely can send a further command on the socket, but the server won't actually read it until it's done with the transfer.

According to http://stackoverflow.com/questions/31560701/ftp-data-connections-reuse , data connections cannot be reused.

(RFC959 is vague on both points)

Now, the proposed fix design:

* upon starting a transfer, an FTP object sets a flag, `transfer_in_progress'.
* any public subroutine that would send a further command checks the flag. Then, there are a few options:
    a) refuse any further commands outright until the user explicitly closes the socket (whose close handler would also handle the end-of-transfer response)
    b) check the wire for an end-of-transfer response and if it's there, handle it and allow the command. Closing the socket may or may not handle the response in its own right.
    c) allow the command even if there's no end-of-transfer response. Then handling of the transfer response is done with the function parsing the response for the new command - which will hang until the transfer is complete.
* the code handling the end-of-transfer response clears the flag.

Each option has drawbacks, so I'm not sure which one is the most pythonic.
I would go with b) because it would allow syntax like urllib.urlopen(<...>).read() which it does allow for HTTP.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25458>
_______________________________________

From report at bugs.python.org  Tue Dec 13 01:07:33 2016
From: report at bugs.python.org (Ramakrishna Kommineni)
Date: Tue, 13 Dec 2016 06:07:33 +0000
Subject: [issue28957] undefined symbol: PyUnicodeUCS2_FromUnicode when
 executing any command with pip2.7
Message-ID: <1481609253.38.0.127310652457.issue28957@psf.upfronthosting.co.za>


New submission from Ramakrishna Kommineni:

Hi,

I have installed python from source in the directory /home/rkommine/software/python2.7.
During installation there are no errors seen.
I have added the below environment variables to my bashrc

export PATH=/home/rkommine/software/python2.7.12/bin:/home/rkommine/software/tcltk8.6.6/bin:$PATH
export LD_LIBBRARY_PATH=/home/rkommine/software/python2.7.12/lib:$LD_LIBBRARY_PATH

rkommine at rubuntu:~/Downloads$ which python2.7
/home/rkommine/software/python2.7.12/bin/python2.7
rkommine at rubuntu:~/Downloads$ python2.7 --version
Python 2.7.12
rkommine at rubuntu:~/Downloads$ which pip2.7
/home/rkommine/software/python2.7.12/bin/pip2.7

But when I execute any command with pip2.7 I am getting the below errors

rkommine at rubuntu:~/Downloads$ pip2.7 --version
Traceback (most recent call last):
  File "/home/rkommine/software/python2.7.12/bin/pip2.7", line 7, in <module>
    from pip import main
  File "/home/rkommine/software/python2.7.12/lib/python2.7/site-packages/pip/__init__.py", line 16, in <module>
    from pip.vcs import git, mercurial, subversion, bazaar  # noqa
  File "/home/rkommine/software/python2.7.12/lib/python2.7/site-packages/pip/vcs/subversion.py", line 9, in <module>
    from pip.index import Link
  File "/home/rkommine/software/python2.7.12/lib/python2.7/site-packages/pip/index.py", line 30, in <module>
    from pip.wheel import Wheel, wheel_ext
  File "/home/rkommine/software/python2.7.12/lib/python2.7/site-packages/pip/wheel.py", line 32, in <module>
    from pip import pep425tags
  File "/home/rkommine/software/python2.7.12/lib/python2.7/site-packages/pip/pep425tags.py", line 9, in <module>
    import ctypes
  File "/home/rkommine/software/python2.7.12/lib/python2.7/ctypes/__init__.py", line 7, in <module>
    from _ctypes import Union, Structure, Array
ImportError: /home/rkommine/software/python2.7.12/lib/python2.7/lib-dynload/_ctypes.so: undefined symbol: PyUnicodeUCS2_FromUnicode
rkommine at rubuntu:~/Downloads$ pip2.7 install robotframework
Traceback (most recent call last):
  File "/home/rkommine/software/python2.7.12/bin/pip2.7", line 7, in <module>
    from pip import main
  File "/home/rkommine/software/python2.7.12/lib/python2.7/site-packages/pip/__init__.py", line 16, in <module>
    from pip.vcs import git, mercurial, subversion, bazaar  # noqa
  File "/home/rkommine/software/python2.7.12/lib/python2.7/site-packages/pip/vcs/subversion.py", line 9, in <module>
    from pip.index import Link
  File "/home/rkommine/software/python2.7.12/lib/python2.7/site-packages/pip/index.py", line 30, in <module>
    from pip.wheel import Wheel, wheel_ext
  File "/home/rkommine/software/python2.7.12/lib/python2.7/site-packages/pip/wheel.py", line 32, in <module>
    from pip import pep425tags
  File "/home/rkommine/software/python2.7.12/lib/python2.7/site-packages/pip/pep425tags.py", line 9, in <module>
    import ctypes
  File "/home/rkommine/software/python2.7.12/lib/python2.7/ctypes/__init__.py", line 7, in <module>
    from _ctypes import Union, Structure, Array
ImportError: /home/rkommine/software/python2.7.12/lib/python2.7/lib-dynload/_ctypes.so: undefined symbol: PyUnicodeUCS2_FromUnicode
rkommine at rubuntu:~/Downloads$ 

Could you please help to fix this error?
Thanks in advance.

----------
components: ctypes
files: Installation.Log.txt
messages: 283074
nosy: Ramakrishna Kommineni
priority: normal
severity: normal
status: open
title: undefined symbol: PyUnicodeUCS2_FromUnicode when executing any command with pip2.7
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file45869/Installation.Log.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28957>
_______________________________________

From report at bugs.python.org  Tue Dec 13 01:09:21 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 13 Dec 2016 06:09:21 +0000
Subject: [issue26110] Speedup method calls 1.2x
In-Reply-To: <1452791347.05.0.923215900831.issue26110@psf.upfronthosting.co.za>
Message-ID: <1481609361.63.0.101388249985.issue26110@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Technically the patch LGTM. But we should find the cause of the regression in some benchmarks.

And would be nice to extend the optimization to C functions.

In any case this optimization is worth mentioning in What's New.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26110>
_______________________________________

From report at bugs.python.org  Tue Dec 13 01:27:05 2016
From: report at bugs.python.org (Julien Palard)
Date: Tue, 13 Dec 2016 06:27:05 +0000
Subject: [issue28933] AC: Accept None as a Py_ssize_t default value
In-Reply-To: <1481389976.88.0.777049011956.issue28933@psf.upfronthosting.co.za>
Message-ID: <1481610425.88.0.59617310805.issue28933@psf.upfronthosting.co.za>


Julien Palard added the comment:

Hi Larry,

Do you mean a new converter in clinic.py like Nullable_Py_ssizze_t, or a converter that I copy/paste every time I need it like http://bugs.python.org/review/28754/patch/19417/76440 ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28933>
_______________________________________

From report at bugs.python.org  Tue Dec 13 01:36:04 2016
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 13 Dec 2016 06:36:04 +0000
Subject: [issue26110] Speedup method calls 1.2x
In-Reply-To: <1452791347.05.0.923215900831.issue26110@psf.upfronthosting.co.za>
Message-ID: <1481610964.32.0.631172527736.issue26110@psf.upfronthosting.co.za>


INADA Naoki added the comment:

> Technically the patch LGTM. But we should find the cause of the regression in some benchmarks.

The benchmark is on Sandy Bridge (Core i5 2400) and I didn't use PGO build.
perf_event reported branch-miss rate increase at cpickle's save function.

I'll rerun benchmark with PGO build. I hope PGO is friendly with CPU branch
prediction, like L1/L2 cache.

Anyway, recent amd64 CPUs have more large branch history.

> And would be nice to extend the optimization to C functions.
> In any case this optimization is worth mentioning in What's New.

I'll do them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26110>
_______________________________________

From report at bugs.python.org  Tue Dec 13 01:55:01 2016
From: report at bugs.python.org (Ilya Kulakov)
Date: Tue, 13 Dec 2016 06:55:01 +0000
Subject: [issue28958] Python should return comperhansive error when SSLContext
 cannot be created
Message-ID: <1481612101.72.0.228099199654.issue28958@psf.upfronthosting.co.za>


New submission from Ilya Kulakov:

When SSLContext cannot be created, python raises an SSLError exception with "failed to allocate SSL context".

https://hg.python.org/cpython/file/4def2a2901a5/Modules/_ssl.c#l2260

This is completely useless to debug the error. In fact many errors raised from _ssl.c are non-helpful.

Python's SSLError should be extended to include comprehensive information about OpenSSL's error stack which can be extracted with `ERR_get_error_line`.

----------
assignee: christian.heimes
components: SSL
messages: 283078
nosy: Ilya.Kulakov, christian.heimes
priority: normal
severity: normal
status: open
title: Python should return comperhansive error when SSLContext cannot be created
type: enhancement
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28958>
_______________________________________

From report at bugs.python.org  Tue Dec 13 01:59:59 2016
From: report at bugs.python.org (arpit arora)
Date: Tue, 13 Dec 2016 06:59:59 +0000
Subject: [issue28948] Facing issue while running Python 3.6.0rc1 windows
 x86-64 web based installer
In-Reply-To: <1481549706.57.0.80853202455.issue28948@psf.upfronthosting.co.za>
Message-ID: <1481612399.6.0.932245167889.issue28948@psf.upfronthosting.co.za>


arpit arora added the comment:

Hi Steve,

I only installed the mentioned version and if there is any update for the same then i may not be aware of that.

Thanks & Regards
Arpit Arora

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28948>
_______________________________________

From report at bugs.python.org  Tue Dec 13 02:35:55 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 13 Dec 2016 07:35:55 +0000
Subject: [issue28512] PyErr_SyntaxLocationEx() and
 PyErr_SyntaxLocationObject() always set the offset attribute to None
In-Reply-To: <1477173007.35.0.842183977255.issue28512@psf.upfronthosting.co.za>
Message-ID: <1481614555.85.0.911405367035.issue28512@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Ah, it was a remnants of backporting to 3.5. Commented-out lines are used in 3.6. The line above these lines was used in 3.5. Test is passed with both variants. I commented out the 3.6 variant, but forgot to remove it (or remove old 3.5 variant and keep 3.6 variant). Do you think I should remove commented out lines, or left the code as is?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28512>
_______________________________________

From report at bugs.python.org  Tue Dec 13 03:01:16 2016
From: report at bugs.python.org (Jelle Zijlstra)
Date: Tue, 13 Dec 2016 08:01:16 +0000
Subject: [issue28603] traceback module can't format/print unhashable exceptions
In-Reply-To: <1478208134.4.0.220857012408.issue28603@psf.upfronthosting.co.za>
Message-ID: <1481616076.84.0.641714376017.issue28603@psf.upfronthosting.co.za>


Jelle Zijlstra added the comment:

I ran into this bug through Thrift-generated exception classes (also reported there as https://issues.apache.org/jira/browse/THRIFT-4002).

I've added a few potential solutions:
- issue28603-listset.patch turns the seen set into a list if hashing fails. However, this adds a lot of complexity, especially in C, and because seen is changed halfway through the recursion, we may end up showing an exception twice.
- issue28603-list.patch uses a list instead of a set for seen. This is theoretically slower, but in practice it seems unlikely that exception __cause__ and __context__ would nest deep enough for this to be an issue.
- issue28603-ignore.patch takes a similar approach to Trundle's patch and just gives up when the value is not hashable. This means we lose cause/context information for these exceptions.

I prefer issue28603-list.patch.

----------
nosy: +Jelle Zijlstra
Added file: http://bugs.python.org/file45870/issue28603-list.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28603>
_______________________________________

From report at bugs.python.org  Tue Dec 13 03:01:37 2016
From: report at bugs.python.org (Jelle Zijlstra)
Date: Tue, 13 Dec 2016 08:01:37 +0000
Subject: [issue28603] traceback module can't format/print unhashable exceptions
In-Reply-To: <1478208134.4.0.220857012408.issue28603@psf.upfronthosting.co.za>
Message-ID: <1481616097.06.0.794994139835.issue28603@psf.upfronthosting.co.za>


Changes by Jelle Zijlstra <jelle.zijlstra at gmail.com>:


Added file: http://bugs.python.org/file45871/issue28603-ignore.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28603>
_______________________________________

From report at bugs.python.org  Tue Dec 13 03:01:49 2016
From: report at bugs.python.org (Jelle Zijlstra)
Date: Tue, 13 Dec 2016 08:01:49 +0000
Subject: [issue28603] traceback module can't format/print unhashable exceptions
In-Reply-To: <1478208134.4.0.220857012408.issue28603@psf.upfronthosting.co.za>
Message-ID: <1481616109.28.0.205138198397.issue28603@psf.upfronthosting.co.za>


Changes by Jelle Zijlstra <jelle.zijlstra at gmail.com>:


Added file: http://bugs.python.org/file45872/issue28603-list.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28603>
_______________________________________

From report at bugs.python.org  Tue Dec 13 03:13:26 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 13 Dec 2016 08:13:26 +0000
Subject: [issue26856] android does not have pwd.getpwall()
In-Reply-To: <1461677345.21.0.582848799296.issue26856@psf.upfronthosting.co.za>
Message-ID: <20161213081323.100042.15289.AC99D2EA@psf.io>


Roundup Robot added the comment:

New changeset e89c9ab46d77 by Xavier de Gaye in branch '3.6':
Issue #26856: Fix the tests assuming that the pwd module has getpwall() and
https://hg.python.org/cpython/rev/e89c9ab46d77

New changeset 692083f85981 by Xavier de Gaye in branch 'default':
Issue #26856: Merge 3.6.
https://hg.python.org/cpython/rev/692083f85981

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26856>
_______________________________________

From report at bugs.python.org  Tue Dec 13 03:13:42 2016
From: report at bugs.python.org (Christoph Gohlke)
Date: Tue, 13 Dec 2016 08:13:42 +0000
Subject: [issue28680] bdist_wininst generated 64-bit executable looks for
 3.5-32
In-Reply-To: <1479004752.08.0.80929351166.issue28680@psf.upfronthosting.co.za>
Message-ID: <1481616822.18.0.258635467458.issue28680@psf.upfronthosting.co.za>


Christoph Gohlke added the comment:

Pillow-3.4.2.win-amd64-py3.5.exe fails to install due to this. See <https://github.com/python-pillow/Pillow/issues/2285>.

`MS_WIN64` is never defined at <https://hg.python.org/cpython/file/v3.5.2/PC/bdist_wininst/install.c#l157> because bdist_wininst does not depend on the Python headers. A possible fix is to use `_WIN64` instead of `MS_WIN64`.

----------
nosy: +cgohlke
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28680>
_______________________________________

From report at bugs.python.org  Tue Dec 13 03:22:44 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 13 Dec 2016 08:22:44 +0000
Subject: [issue26936] android: test_socket fails
In-Reply-To: <1462288246.37.0.495121419926.issue26936@psf.upfronthosting.co.za>
Message-ID: <20161213082241.15265.40285.076B6CE1@psf.io>


Roundup Robot added the comment:

New changeset 95140ff32239 by Xavier de Gaye in branch 'default':
Issue #26936: Fix the test_socket failures on Android - getservbyname(),
https://hg.python.org/cpython/rev/95140ff32239

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26936>
_______________________________________

From report at bugs.python.org  Tue Dec 13 03:50:12 2016
From: report at bugs.python.org (Wolfgang Maier)
Date: Tue, 13 Dec 2016 08:50:12 +0000
Subject: [issue28956] return minimum of modes for a multimodal distribution
 instead of raising a StatisticsError
In-Reply-To: <1481602901.85.0.570887953824.issue28956@psf.upfronthosting.co.za>
Message-ID: <1481619012.84.0.304104166848.issue28956@psf.upfronthosting.co.za>


Wolfgang Maier added the comment:

What's the justification for this proposed change? Isn't it better to report the fact that there isn't an unambiguous result instead of returning a rather arbitrary one?

----------
nosy: +steven.daprano, wolma
versions: +Python 3.7 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28956>
_______________________________________

From report at bugs.python.org  Tue Dec 13 03:55:00 2016
From: report at bugs.python.org (Christoph Gohlke)
Date: Tue, 13 Dec 2016 08:55:00 +0000
Subject: [issue28680] bdist_wininst generated 64-bit executable looks for
 3.5-32
In-Reply-To: <1479004752.08.0.80929351166.issue28680@psf.upfronthosting.co.za>
Message-ID: <1481619300.57.0.601060612254.issue28680@psf.upfronthosting.co.za>


Christoph Gohlke added the comment:

The attached patch was tested with Pillow-3.4.2 on Python 3.6.0rc1, 32-bit and 64-bit.

It would be nice to get this fixed in Python 3.5.3 and 3.6.0.

----------
components: +Windows
keywords: +patch
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
Added file: http://bugs.python.org/file45873/fix_issue28680.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28680>
_______________________________________

From report at bugs.python.org  Tue Dec 13 04:00:28 2016
From: report at bugs.python.org (Christoph Gohlke)
Date: Tue, 13 Dec 2016 09:00:28 +0000
Subject: [issue26071] bdist_wininst created binaries fail to start and find
 32bit Pythons
In-Reply-To: <1452388008.63.0.0329055331541.issue26071@psf.upfronthosting.co.za>
Message-ID: <1481619628.4.0.432626561755.issue26071@psf.upfronthosting.co.za>


Christoph Gohlke added the comment:

The applied patch breaks bdist_wininst installers for 64-bit Python. See <http://bugs.python.org/issue28680>.

----------
nosy: +cgohlke

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26071>
_______________________________________

From report at bugs.python.org  Tue Dec 13 04:04:11 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 13 Dec 2016 09:04:11 +0000
Subject: [issue28759] access to mkfifo,
 mknod and hard links is controled by SELinux MAC on Android
In-Reply-To: <1479715975.06.0.930254771903.issue28759@psf.upfronthosting.co.za>
Message-ID: <20161213090406.15341.72367.731F5FC5@psf.io>


Roundup Robot added the comment:

New changeset 43f9366d8883 by Xavier de Gaye in branch '3.6':
Issue #28759: Fix the tests that fail with PermissionError when run as
https://hg.python.org/cpython/rev/43f9366d8883

New changeset db1d20825d71 by Xavier de Gaye in branch 'default':
Issue #28759: Merge 3.6.
https://hg.python.org/cpython/rev/db1d20825d71

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28759>
_______________________________________

From report at bugs.python.org  Tue Dec 13 04:12:35 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 13 Dec 2016 09:12:35 +0000
Subject: [issue26856] android does not have pwd.getpwall()
In-Reply-To: <1461677345.21.0.582848799296.issue26856@psf.upfronthosting.co.za>
Message-ID: <1481620355.19.0.460970498848.issue26856@psf.upfronthosting.co.za>


Changes by Xavier de Gaye <xdegaye at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26856>
_______________________________________

From report at bugs.python.org  Tue Dec 13 04:12:57 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 13 Dec 2016 09:12:57 +0000
Subject: [issue26936] android: test_socket fails
In-Reply-To: <1462288246.37.0.495121419926.issue26936@psf.upfronthosting.co.za>
Message-ID: <1481620377.29.0.648069080247.issue26936@psf.upfronthosting.co.za>


Changes by Xavier de Gaye <xdegaye at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26936>
_______________________________________

From report at bugs.python.org  Tue Dec 13 04:35:22 2016
From: report at bugs.python.org (Srikanth Anantharam)
Date: Tue, 13 Dec 2016 09:35:22 +0000
Subject: [issue28956] return minimum of modes for a multimodal distribution
 instead of raising a StatisticsError
In-Reply-To: <1481619012.84.0.304104166848.issue28956@psf.upfronthosting.co.za>
Message-ID: <CAN3Ck4Aw12W1iFaR3ddvak+UaNAewVyP0GgPKseBzvNCpDKFUQ@mail.gmail.com>


Srikanth Anantharam added the comment:

A better choice would be to return a tuple of values (sliced from the
table). And let the user decide which one to use.

Hope that's justifiable...

Thanks & Regards
Srikanth Anantharam
+91 7204 350429
https://sria91.github.io/

Sent from Android

On 13-Dec-2016 2:20 PM, "Wolfgang Maier" <report at bugs.python.org> wrote:

>
> Wolfgang Maier added the comment:
>
> What's the justification for this proposed change? Isn't it better to
> report the fact that there isn't an unambiguous result instead of returning
> a rather arbitrary one?
>
> ----------
> nosy: +steven.daprano, wolma
> versions: +Python 3.7 -Python 3.5
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue28956>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28956>
_______________________________________

From report at bugs.python.org  Tue Dec 13 04:49:43 2016
From: report at bugs.python.org (Frazer McLean)
Date: Tue, 13 Dec 2016 09:49:43 +0000
Subject: [issue7434] general pprint rewrite
In-Reply-To: <1259944363.21.0.149882342014.issue7434@psf.upfronthosting.co.za>
Message-ID: <1481622583.83.0.554722213904.issue7434@psf.upfronthosting.co.za>


Changes by Frazer McLean <frazer at frazermclean.co.uk>:


----------
nosy: +RazerM

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7434>
_______________________________________

From report at bugs.python.org  Tue Dec 13 04:54:04 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 13 Dec 2016 09:54:04 +0000
Subject: [issue28956] return minimum of modes for a multimodal distribution
 instead of raising a StatisticsError
In-Reply-To: <CAN3Ck4Aw12W1iFaR3ddvak+UaNAewVyP0GgPKseBzvNCpDKFUQ@mail.gmail.com>
Message-ID: <20161213095356.GB3365@ando.pearwood.info>


Steven D'Aprano added the comment:

On Tue, Dec 13, 2016 at 09:35:22AM +0000, Srikanth Anantharam wrote:
> 
> Srikanth Anantharam added the comment:
> 
> A better choice would be to return a tuple of values (sliced from the
> table). And let the user decide which one to use.

The current mode() function is designed for a very basic use-case, where 
you have an obvious single mode from discrete data.

The problem with dealing with multiple modes is that its not easy to 
tell the difference between a genuinely multi-modal sample and one which 
just happens to have a few samples with the same value:

data = [1, 2, 3, 4, 4, 4, 5, 6, 7, 7, 8, 8, 8, 8, 8, 8, 8, 9, 9]

Assuming the sampling is fair, 8 is clearly the mode; but is it bimodal 
with 4 the second mode? Or perhaps even four modes, 8, 4, 7 and 9?

I have plans for introducing a binning function to collect data into 
bins and run statistics on the bins. That might be a better way to deal 
with multi-modal samples: if you bin the data (for discrete data, use a 
bin size of 1) and then look at the frequencies, you can decide how many 
modes there are.

Thanks for the suggestion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28956>
_______________________________________

From report at bugs.python.org  Tue Dec 13 04:56:46 2016
From: report at bugs.python.org (Srikanth Anantharam)
Date: Tue, 13 Dec 2016 09:56:46 +0000
Subject: [issue28956] return minimum of modes for a multimodal distribution
 instead of raising a StatisticsError
In-Reply-To: <1481602901.85.0.570887953824.issue28956@psf.upfronthosting.co.za>
Message-ID: <1481623006.26.0.855193479581.issue28956@psf.upfronthosting.co.za>


Changes by Srikanth Anantharam <sria91 at gmail.com>:


----------
pull_requests: +4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28956>
_______________________________________

From report at bugs.python.org  Tue Dec 13 05:08:10 2016
From: report at bugs.python.org (Srikanth Anantharam)
Date: Tue, 13 Dec 2016 10:08:10 +0000
Subject: [issue28956] return minimum of modes for a multimodal distribution
 instead of raising a StatisticsError
In-Reply-To: <1481623006.28.0.807845747498.issue28956@psf.upfronthosting.co.za>
Message-ID: <CAN3Ck4Dr6nr_EsUyOyVnUWPpsuhzgt47_t7PLOgtXjvsEynmXg@mail.gmail.com>


Srikanth Anantharam added the comment:

Please see the updated pull request PR 50, with the changes.

Thanks & Regards
Srikanth Anantharam
+91 7204 350429
https://sria91.github.io/

Sent from Android

On 13-Dec-2016 3:26 PM, "Srikanth Anantharam" <report at bugs.python.org>
wrote:

>
> Changes by Srikanth Anantharam <sria91 at gmail.com>:
>
>
> ----------
> pull_requests: +4
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue28956>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28956>
_______________________________________

From report at bugs.python.org  Tue Dec 13 05:17:21 2016
From: report at bugs.python.org (Srikanth Anantharam)
Date: Tue, 13 Dec 2016 10:17:21 +0000
Subject: [issue28956] return minimum of modes for a multimodal distribution
 instead of raising a StatisticsError
In-Reply-To: <CAN3Ck4CZWhxkdxSWwmDQT_922Weqgw_6U6SCRvDbugY1hNNt8w@mail.gmail.com>
Message-ID: <CAN3Ck4AF0b4JQ4iJ1hcg7vhJEbJf1yncZFnofpw1hwW760XcNw@mail.gmail.com>


Srikanth Anantharam added the comment:

@steven:

data = [1, 2, 3, 4, 4, 4, 5, 6, 7, 7, 8, 8, 8, 8, 8, 8, 8, 9, 9]
is clearly unimodal with mode 8

data would have been bimodal if 4 repeated exactly the same (7) number of
times as 8, like this:
data = [1, 2, 3, 4, 4, 4, 4, 4, 4, 4, 5, 6, 7, 7, 8, 8, 8, 8, 8, 8, 8, 9, 9]

in which case the new patch in PR 50 would return a tuple
(4, 8)

Thanks & Regards
Srikanth Anantharam
+91 7204 350429
https://sria91.github.io/

Sent from Android

On 13-Dec-2016 3:24 PM, "Steven D'Aprano" <report at bugs.python.org> wrote:

Steven D'Aprano added the comment:

On Tue, Dec 13, 2016 at 09:35:22AM +0000, Srikanth Anantharam wrote:
>
> Srikanth Anantharam added the comment:
>
> A better choice would be to return a tuple of values (sliced from the
> table). And let the user decide which one to use.

The current mode() function is designed for a very basic use-case, where
you have an obvious single mode from discrete data.

The problem with dealing with multiple modes is that its not easy to
tell the difference between a genuinely multi-modal sample and one which
just happens to have a few samples with the same value:

data = [1, 2, 3, 4, 4, 4, 5, 6, 7, 7, 8, 8, 8, 8, 8, 8, 8, 9, 9]

Assuming the sampling is fair, 8 is clearly the mode; but is it bimodal
with 4 the second mode? Or perhaps even four modes, 8, 4, 7 and 9?

I have plans for introducing a binning function to collect data into
bins and run statistics on the bins. That might be a better way to deal
with multi-modal samples: if you bin the data (for discrete data, use a
bin size of 1) and then look at the frequencies, you can decide how many
modes there are.

Thanks for the suggestion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28956>
_______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28956>
_______________________________________

From report at bugs.python.org  Tue Dec 13 05:41:51 2016
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 13 Dec 2016 10:41:51 +0000
Subject: [issue26110] Speedup method calls 1.2x
In-Reply-To: <1452791347.05.0.923215900831.issue26110@psf.upfronthosting.co.za>
Message-ID: <1481625711.38.0.197530632679.issue26110@psf.upfronthosting.co.za>


INADA Naoki added the comment:

> And would be nice to extend the optimization to C functions.

I tried it but skipping creating PyCFunction seems impossible for now.

My current idea is adding new `tp_fastcall` slot which has same signature
to _PyFunction_FastCallDict or _PyCFunction_FastCallDict.

If MethodDescrObject implement it, we can skip temporary PyCFunction object and
argument tuple.

But I think it should be separated issue. Patch is large enough already.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26110>
_______________________________________

From report at bugs.python.org  Tue Dec 13 06:08:58 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 13 Dec 2016 11:08:58 +0000
Subject: [issue26110] Speedup method calls 1.2x
In-Reply-To: <1452791347.05.0.923215900831.issue26110@psf.upfronthosting.co.za>
Message-ID: <1481627338.16.0.524293043149.issue26110@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> But I think it should be separated issue.

Agreed if that so hard.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26110>
_______________________________________

From report at bugs.python.org  Tue Dec 13 06:15:56 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 13 Dec 2016 11:15:56 +0000
Subject: [issue28603] traceback module can't format/print unhashable exceptions
In-Reply-To: <1478208134.4.0.220857012408.issue28603@psf.upfronthosting.co.za>
Message-ID: <1481627756.61.0.0376681431252.issue28603@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There is no issue28603-listset.patch.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28603>
_______________________________________

From report at bugs.python.org  Tue Dec 13 06:45:13 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 13 Dec 2016 11:45:13 +0000
Subject: [issue28955] Not matched behavior of numeric comparison with the
 documentation
In-Reply-To: <1481602171.57.0.675005739221.issue28955@psf.upfronthosting.co.za>
Message-ID: <1481629513.84.0.298336057294.issue28955@psf.upfronthosting.co.za>


R. David Murray added the comment:

Sure, we like to make the docs more precise when it doesn't interfere with the presentation.  Perhaps something like:  "Additionally, ordering comparisions involving not-a-number values will always return False."

I wonder if we should also mention here that this follows the IEEE standard.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28955>
_______________________________________

From report at bugs.python.org  Tue Dec 13 06:53:14 2016
From: report at bugs.python.org (Mantas Zimnickas)
Date: Tue, 13 Dec 2016 11:53:14 +0000
Subject: [issue15873] datetime: add ability to parse RFC 3339 dates and times
In-Reply-To: <1346965730.56.0.810546720554.issue15873@psf.upfronthosting.co.za>
Message-ID: <1481629994.5.0.937197310805.issue15873@psf.upfronthosting.co.za>


Changes by Mantas Zimnickas <sirexas at gmail.com>:


----------
nosy: +Mantas Zimnickas

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15873>
_______________________________________

From report at bugs.python.org  Tue Dec 13 06:56:22 2016
From: report at bugs.python.org (kumaar.nd)
Date: Tue, 13 Dec 2016 11:56:22 +0000
Subject: [issue28950] regrtest: -j0 fails the check -j is not allowed together
 with -T/-l
In-Reply-To: <1481566513.26.0.47817718709.issue28950@psf.upfronthosting.co.za>
Message-ID: <1481630182.24.0.926010500735.issue28950@psf.upfronthosting.co.za>


kumaar.nd added the comment:

hi,
I reviewed the changes of patch set-2.
In the test_regrtest.py, instead of adding new condition
229:self.checkError([opt, '0', '-T'], "don't go together")
230:self.checkError([opt, '0', '-l'], "don't go together")
isnt it easier to just tweak and replace the existing 
227:self.checkError([opt, '2', '-T'], "don't go together")
228:self.checkError([opt, '2', '-l'], "don't go together")
with teh above changes?

If the suggestion sound naive, this is my first developer review and am new to python too.

----------
nosy: +kumaar.nd

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28950>
_______________________________________

From report at bugs.python.org  Tue Dec 13 06:58:44 2016
From: report at bugs.python.org (Mantas Zimnickas)
Date: Tue, 13 Dec 2016 11:58:44 +0000
Subject: [issue24954] No way to generate or parse timezone as produced by
 datetime.isoformat()
In-Reply-To: <1440801281.72.0.545558404714.issue24954@psf.upfronthosting.co.za>
Message-ID: <1481630324.12.0.751053805984.issue24954@psf.upfronthosting.co.za>


Changes by Mantas Zimnickas <sirexas at gmail.com>:


----------
nosy: +sirex

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24954>
_______________________________________

From report at bugs.python.org  Tue Dec 13 07:18:34 2016
From: report at bugs.python.org (Larry Hastings)
Date: Tue, 13 Dec 2016 12:18:34 +0000
Subject: [issue28933] AC: Accept None as a Py_ssize_t default value
In-Reply-To: <1481389976.88.0.777049011956.issue28933@psf.upfronthosting.co.za>
Message-ID: <1481631514.92.0.96752309229.issue28933@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Since this is the first time anybody has needed it, I suggest the latter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28933>
_______________________________________

From report at bugs.python.org  Tue Dec 13 08:02:11 2016
From: report at bugs.python.org (Mateusz Loskot)
Date: Tue, 13 Dec 2016 13:02:11 +0000
Subject: [issue14597] Cannot unload dll in ctypes until script exits
In-Reply-To: <1334581773.77.0.209505875468.issue14597@psf.upfronthosting.co.za>
Message-ID: <1481634131.12.0.499289584915.issue14597@psf.upfronthosting.co.za>


Changes by Mateusz Loskot <mateusz at loskot.net>:


----------
nosy: +mloskot

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14597>
_______________________________________

From report at bugs.python.org  Tue Dec 13 08:07:02 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 13 Dec 2016 13:07:02 +0000
Subject: [issue28959] Add a macro for dict size
Message-ID: <1481634421.56.0.985862767516.issue28959@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

In additional to C API functions PyTuple_Size() and PyList_Size() there are fast macros PyTuple_GET_SIZE() and PyList_GET_SIZE() for getting the size of a tuple or a list. But for dicts there is just PyDict_Size(). It is not just slower than a macro, but can return an error (actually this never happens in CPython core and extensions).

Proposed patch adds new private macro _PyDict_GET_SIZE() and makes the code using it instead of PyDict_Size(). I don't expect significant performance gain except perhaps few checks that a dict is empty. The main advantage to me is that not checking the result for error no longer looks as potential bug.

----------
components: Interpreter Core
files: _PyDict_GET_SIZE.patch
keywords: patch
messages: 283099
nosy: haypo, inada.naoki, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Add a macro for dict size
type: enhancement
versions: Python 3.7
Added file: http://bugs.python.org/file45874/_PyDict_GET_SIZE.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28959>
_______________________________________

From report at bugs.python.org  Tue Dec 13 08:30:22 2016
From: report at bugs.python.org (Julien Palard)
Date: Tue, 13 Dec 2016 13:30:22 +0000
Subject: [issue28933] AC: Accept None as a Py_ssize_t default value
In-Reply-To: <1481389976.88.0.777049011956.issue28933@psf.upfronthosting.co.za>
Message-ID: <1481635822.03.0.664489584023.issue28933@psf.upfronthosting.co.za>


Changes by Julien Palard <julien+python at palard.fr>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28933>
_______________________________________

From report at bugs.python.org  Tue Dec 13 08:31:45 2016
From: report at bugs.python.org (Julien Palard)
Date: Tue, 13 Dec 2016 13:31:45 +0000
Subject: [issue28754] Argument Clinic for bisect.bisect_left
In-Reply-To: <1479660719.6.0.85429244405.issue28754@psf.upfronthosting.co.za>
Message-ID: <1481635905.65.0.126506053804.issue28754@psf.upfronthosting.co.za>


Julien Palard added the comment:

As the pattern of this converter is not widely used, I'll let it in the code of _bisect for the moment, see: http://bugs.python.org/issue28933.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28754>
_______________________________________

From report at bugs.python.org  Tue Dec 13 08:37:19 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 13 Dec 2016 13:37:19 +0000
Subject: [issue28933] AC: Accept None as a Py_ssize_t default value
In-Reply-To: <1481389976.88.0.777049011956.issue28933@psf.upfronthosting.co.za>
Message-ID: <1481636239.83.0.0644469677684.issue28933@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> rejected
stage:  -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28933>
_______________________________________

From report at bugs.python.org  Tue Dec 13 08:37:28 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 13 Dec 2016 13:37:28 +0000
Subject: [issue28759] access to mkfifo,
 mknod and hard links is controled by SELinux MAC on Android
In-Reply-To: <1479715975.06.0.930254771903.issue28759@psf.upfronthosting.co.za>
Message-ID: <1481636248.07.0.580521228404.issue28759@psf.upfronthosting.co.za>


Changes by Xavier de Gaye <xdegaye at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28759>
_______________________________________

From report at bugs.python.org  Tue Dec 13 08:38:04 2016
From: report at bugs.python.org (Ryan)
Date: Tue, 13 Dec 2016 13:38:04 +0000
Subject: [issue28960] Small typo in Thread.join docs
Message-ID: <1481636284.79.0.913462681395.issue28960@psf.upfronthosting.co.za>


New submission from Ryan:

There is a '--' before a ',' that doesn't make sense here: https://docs.python.org/3/library/threading.html#threading.Thread.join

----------
assignee: docs at python
components: Documentation
files: fixdoc.patch
keywords: patch
messages: 283101
nosy: docs at python, rcorre
priority: normal
severity: normal
status: open
title: Small typo in Thread.join docs
type: enhancement
versions: Python 3.7
Added file: http://bugs.python.org/file45875/fixdoc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28960>
_______________________________________

From report at bugs.python.org  Tue Dec 13 08:39:29 2016
From: report at bugs.python.org (Jiajun Huang)
Date: Tue, 13 Dec 2016 13:39:29 +0000
Subject: [issue28919] Simplify `_copy_func_details` in unittest.mock
In-Reply-To: <1481577539.0.0.478814731257.issue28919@psf.upfronthosting.co.za>
Message-ID: <1481636369.94.0.009573143152.issue28919@psf.upfronthosting.co.za>


Jiajun Huang added the comment:

So what should I do next to make the code being merged into CPython? I am new to mercurial(or just wait for it?).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28919>
_______________________________________

From report at bugs.python.org  Tue Dec 13 08:43:32 2016
From: report at bugs.python.org (David Edelsohn)
Date: Tue, 13 Dec 2016 13:43:32 +0000
Subject: [issue28845] Clean up known issues for AIX
In-Reply-To: <1480542032.97.0.55863701863.issue28845@psf.upfronthosting.co.za>
Message-ID: <1481636612.49.0.271361384141.issue28845@psf.upfronthosting.co.za>


David Edelsohn added the comment:

There is an AIX system in the Python buildbot farm. Why do you say no AIX to test?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28845>
_______________________________________

From report at bugs.python.org  Tue Dec 13 08:47:48 2016
From: report at bugs.python.org (Jiajun Huang)
Date: Tue, 13 Dec 2016 13:47:48 +0000
Subject: [issue28961] Is it a bug(method `_Call.__new__` in unittest.mock)?
Message-ID: <1481636868.17.0.0411235027553.issue28961@psf.upfronthosting.co.za>


New submission from Jiajun Huang:

code in `_Call.__new__`:

      def __new__(cls, value=(), name=None, parent=None, two=False,                                                                    
      ?   ?   ?   from_kall=True):                                                                                                     
      ?   name = ''                                                                                                                    
      ?   args = ()                                                                                                                    
      ?   kwargs = {}                                                                                                                  
      ?   _len = len(value)                                                                                                            
      ?   if _len == 3:                                                                                                                
              ...

the parameter `name` had been override since the function starts. so whatever name is, it's been ignored. Is it a bug? or something else?

----------
components: Library (Lib)
messages: 283104
nosy: Jiajun Huang
priority: normal
severity: normal
status: open
title: Is it a bug(method `_Call.__new__` in unittest.mock)?
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28961>
_______________________________________

From report at bugs.python.org  Tue Dec 13 09:23:29 2016
From: report at bugs.python.org (Steve Dower)
Date: Tue, 13 Dec 2016 14:23:29 +0000
Subject: [issue26071] bdist_wininst created binaries fail to start and find
 32bit Pythons
In-Reply-To: <1452388008.63.0.0329055331541.issue26071@psf.upfronthosting.co.za>
Message-ID: <1481639009.43.0.934105701318.issue26071@psf.upfronthosting.co.za>


Steve Dower added the comment:

Looks like I acknowledged the error in the patch and then didn't fix it when I applied it.

The change needed here is what Mark describes above, plus recompiling the executable stubs. Or alternatively, I can probably just edit out the bytes in the existing stub for 3.6.0 and fix it properly for 3.6.1.

Ned - thoughts? This regressed from 3.4 and has not worked properly for both architectures (simultaneously) since 3.5.

----------
keywords: +3.4regression
nosy: +larry, ned.deily
priority: normal -> release blocker
resolution: fixed -> 
status: closed -> open
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26071>
_______________________________________

From report at bugs.python.org  Tue Dec 13 09:26:26 2016
From: report at bugs.python.org (Steve Dower)
Date: Tue, 13 Dec 2016 14:26:26 +0000
Subject: [issue28680] bdist_wininst generated 64-bit executable looks for
 3.5-32
In-Reply-To: <1479004752.08.0.80929351166.issue28680@psf.upfronthosting.co.za>
Message-ID: <1481639186.15.0.618886830095.issue28680@psf.upfronthosting.co.za>


Steve Dower added the comment:

Thanks. 3.5.3 is definite, I've pinged the release manage on the original bug to see about 3.6.0, but definitely 3.6.1.

Considering we've gone through all of 3.5 and 3.6 with very few people noticing (and as far as I'm aware, completely able to fix it themselves), it may not make the initial 3.6 release.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28680>
_______________________________________

From report at bugs.python.org  Tue Dec 13 09:26:42 2016
From: report at bugs.python.org (Steve Dower)
Date: Tue, 13 Dec 2016 14:26:42 +0000
Subject: [issue28680] bdist_wininst generated 64-bit executable looks for
 3.5-32
In-Reply-To: <1479004752.08.0.80929351166.issue28680@psf.upfronthosting.co.za>
Message-ID: <1481639202.88.0.00740888533607.issue28680@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at python.org>:


----------
assignee:  -> steve.dower
keywords: +3.4regression
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28680>
_______________________________________

From report at bugs.python.org  Tue Dec 13 09:28:24 2016
From: report at bugs.python.org (Steve Dower)
Date: Tue, 13 Dec 2016 14:28:24 +0000
Subject: [issue28948] Facing issue while running Python 3.6.0rc1 windows
 x86-64 web based installer
In-Reply-To: <1481549706.57.0.80853202455.issue28948@psf.upfronthosting.co.za>
Message-ID: <1481639304.43.0.0438399138085.issue28948@psf.upfronthosting.co.za>


Steve Dower added the comment:

What about the file, ucrtbase.dll? Do you have another file by that name somewhere?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28948>
_______________________________________

From report at bugs.python.org  Tue Dec 13 09:28:36 2016
From: report at bugs.python.org (Ivan Pozdeev)
Date: Tue, 13 Dec 2016 14:28:36 +0000
Subject: [issue28923] Nonexisting encoding specified in Tix.py
In-Reply-To: <1481304070.27.0.11719456506.issue28923@psf.upfronthosting.co.za>
Message-ID: <1481639316.09.0.950573997998.issue28923@psf.upfronthosting.co.za>


Ivan Pozdeev added the comment:

I'm more puzzled how noone has noticed this until now if it's supposed to produce an error upon compilation. (Well, it doesn't. I couldn't quite figure out how the encoding declaration is parsed, but it's clear the line _isn't_ matched as a regex like the docs say.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28923>
_______________________________________

From report at bugs.python.org  Tue Dec 13 09:48:11 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 13 Dec 2016 14:48:11 +0000
Subject: [issue28919] Simplify `_copy_func_details` in unittest.mock
In-Reply-To: <1481577539.0.0.478814731257.issue28919@psf.upfronthosting.co.za>
Message-ID: <1481640491.89.0.633230968082.issue28919@psf.upfronthosting.co.za>


Berker Peksag added the comment:

I will commit your patch today if Michael doesn't beat me to it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28919>
_______________________________________

From report at bugs.python.org  Tue Dec 13 10:04:53 2016
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 13 Dec 2016 15:04:53 +0000
Subject: [issue28949] Stdlib modules disappear from file system
In-Reply-To: <1481553619.84.0.343525103437.issue28949@psf.upfronthosting.co.za>
Message-ID: <1481641493.34.0.859376564311.issue28949@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

Downgrading Dropbox did not help. This morning I woke up to `importlib.abc` missing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28949>
_______________________________________

From report at bugs.python.org  Tue Dec 13 10:06:29 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 13 Dec 2016 15:06:29 +0000
Subject: [issue28190] Cross-build _curses failed if host ncurses headers and
 target ncurses headers have different layouts
In-Reply-To: <1474132808.23.0.788365161086.issue28190@psf.upfronthosting.co.za>
Message-ID: <20161213150604.99377.34223.62FE42C8@psf.io>


Roundup Robot added the comment:

New changeset 8c78d844d6f0 by Xavier de Gaye in branch '3.6':
Issue #28190: Cross compiling the _curses module does not use anymore
https://hg.python.org/cpython/rev/8c78d844d6f0

New changeset bdf92b4e02f2 by Xavier de Gaye in branch 'default':
Issue #28190: Merge 3.6.
https://hg.python.org/cpython/rev/bdf92b4e02f2

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28190>
_______________________________________

From report at bugs.python.org  Tue Dec 13 10:07:58 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 13 Dec 2016 15:07:58 +0000
Subject: [issue28190] Cross-build _curses failed if host ncurses headers and
 target ncurses headers have different layouts
In-Reply-To: <1474132808.23.0.788365161086.issue28190@psf.upfronthosting.co.za>
Message-ID: <1481641678.75.0.695004514163.issue28190@psf.upfronthosting.co.za>


Changes by Xavier de Gaye <xdegaye at gmail.com>:


----------
assignee: xdegaye -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28190>
_______________________________________

From report at bugs.python.org  Tue Dec 13 10:11:40 2016
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 13 Dec 2016 15:11:40 +0000
Subject: [issue28949] Stdlib modules disappear from file system
In-Reply-To: <1481553619.84.0.343525103437.issue28949@psf.upfronthosting.co.za>
Message-ID: <1481641900.79.0.64157169833.issue28949@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

I'm getting good at reinstalling Python, though. Now I'm invoking it with this single command-line:

sudo installer -verboseR -pkg ~/Downloads/python-3.6.0rc1-macosx10.6.pkg -target /

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28949>
_______________________________________

From report at bugs.python.org  Tue Dec 13 10:11:44 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 13 Dec 2016 15:11:44 +0000
Subject: [issue26865] Meta-issue: support of the android platform
In-Reply-To: <1461685011.99.0.617135447086.issue26865@psf.upfronthosting.co.za>
Message-ID: <1481641904.53.0.968093797139.issue26865@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Removing from the dependencies some issues that have become out of scope.

----------
dependencies:  -Cross-build _curses failed if host ncurses headers and target ncurses headers have different layouts, add function to os module for getting path to default shell

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26865>
_______________________________________

From report at bugs.python.org  Tue Dec 13 10:23:35 2016
From: report at bugs.python.org (Ned Deily)
Date: Tue, 13 Dec 2016 15:23:35 +0000
Subject: [issue26071] bdist_wininst created binaries fail to start and find
 32bit Pythons
In-Reply-To: <1452388008.63.0.0329055331541.issue26071@psf.upfronthosting.co.za>
Message-ID: <1481642615.83.0.105590024504.issue26071@psf.upfronthosting.co.za>


Ned Deily added the comment:

Since we are two days from the final release, the fix requires rebuilding and replacing a binary file in the source repo, and you state (in related Issue28680): "Considering we've gone through all of 3.5 and 3.6 with very few people noticing (and as far as I'm aware, completely able to fix it themselves), it may not make the initial 3.6 release.", I would prefer to hold this for 3.6.1.

----------
priority: release blocker -> deferred blocker
stage: resolved -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26071>
_______________________________________

From report at bugs.python.org  Tue Dec 13 10:33:21 2016
From: report at bugs.python.org (Ned Deily)
Date: Tue, 13 Dec 2016 15:33:21 +0000
Subject: [issue28949] Stdlib modules disappear from file system
In-Reply-To: <1481553619.84.0.343525103437.issue28949@psf.upfronthosting.co.za>
Message-ID: <1481643201.83.0.0890359623416.issue28949@psf.upfronthosting.co.za>


Ned Deily added the comment:

Have you verified that the problem no longer occurs if the virtualenvs are not in a Dropbox directory?  (And these are virtualenvs, not venvs?)  In any case, at this point it seems pretty clear that we're not dealing with a problem with Python 3.6.0 nor with the python.org installer, no?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28949>
_______________________________________

From report at bugs.python.org  Tue Dec 13 10:40:14 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 13 Dec 2016 15:40:14 +0000
Subject: [issue26110] Speedup method calls 1.2x
In-Reply-To: <1452791347.05.0.923215900831.issue26110@psf.upfronthosting.co.za>
Message-ID: <1481643614.89.0.266603142892.issue26110@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
nosy:  -gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26110>
_______________________________________

From report at bugs.python.org  Tue Dec 13 11:16:50 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 13 Dec 2016 16:16:50 +0000
Subject: [issue16255] subrocess.Popen needs /bin/sh but Android only has
 /system/bin/sh
In-Reply-To: <1350421202.49.0.905467284446.issue16255@psf.upfronthosting.co.za>
Message-ID: <1481645810.97.0.813920212647.issue16255@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

For some reason the following notifications have not all been received (yet):
    remote: added 1 changesets with 2 changes to 2 files
    remote: buildbot: change(s) sent successfully
    remote: sent email to roundup at report at bugs.python.org
    remote: notified python-checkins at python.org of incoming changeset 96a9992d1003

But the buildbots have processed the build request.
Closing the issue.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16255>
_______________________________________

From report at bugs.python.org  Tue Dec 13 11:20:30 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 13 Dec 2016 16:20:30 +0000
Subject: [issue16255] subrocess.Popen needs /bin/sh but Android only has
 /system/bin/sh
In-Reply-To: <1350421202.49.0.905467284446.issue16255@psf.upfronthosting.co.za>
Message-ID: <20161213153252.23031.29995.D6B8E5B1@psf.io>


Roundup Robot added the comment:

New changeset 96a9992d1003 by Xavier de Gaye in branch 'default':
Issue #16255: subrocess.Popen uses /system/bin/sh on Android as the shell,
https://hg.python.org/cpython/rev/96a9992d1003

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16255>
_______________________________________

From report at bugs.python.org  Tue Dec 13 11:28:07 2016
From: report at bugs.python.org (Jelle Zijlstra)
Date: Tue, 13 Dec 2016 16:28:07 +0000
Subject: [issue28962] Crash when throwing an exception with a malicious
 __hash__ override
Message-ID: <1481646487.87.0.692050241508.issue28962@psf.upfronthosting.co.za>


New submission from Jelle Zijlstra:

$ cat baderror.py 
class BadError(Exception):
    def __init__(self):
        self.i = 0

    def __hash__(self):
        self.i += 1
        return self.i


e = BadError()
raise e from e
$ ./python.exe -V
Python 3.5.2+
$ ./python.exe baderror.py 
Segmentation fault: 11

I have reproduced this with Python 3.3, 3.4, 3.5, and 3.6; I assume it's been present throughout the 3 series.

This is because print_exception_recursive in pythonrun.c keeps following the __cause__ chain, and here the exception is its own __cause__. It uses a set to ensure that it breaks cycles, but that doesn't help here because of the exception's incorrect __hash__ method.

----------
components: Interpreter Core
files: baderror.py
messages: 283118
nosy: Jelle Zijlstra
priority: normal
severity: normal
status: open
title: Crash when throwing an exception with a malicious __hash__ override
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45876/baderror.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28962>
_______________________________________

From report at bugs.python.org  Tue Dec 13 11:35:05 2016
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 13 Dec 2016 16:35:05 +0000
Subject: [issue28949] Stdlib modules disappear from file system
In-Reply-To: <1481553619.84.0.343525103437.issue28949@psf.upfronthosting.co.za>
Message-ID: <1481646905.51.0.300362786937.issue28949@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

This morning, I noticed my Mercurial install isn't working either - failing with this error message:

$ hg pull
abort: couldn't find mercurial libraries in [/usr/local/Cellar/mercurial/4.0.1/lib/python2.7/site-packages /usr/local/Cellar/mercurial/4.0.1/bin /usr/local/Cellar/python/2.7.12_2/Frameworks/Python.framework/Versions/2.7/lib/python27.zip /usr/local/Cellar/python/2.7.12_2/Frameworks/Python.framework/Versions/2.7/lib/python2.7 /usr/local/Cellar/python/2.7.12_2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-darwin /usr/local/Cellar/python/2.7.12_2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac /usr/local/Cellar/python/2.7.12_2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/plat-mac/lib-scriptpackages /usr/local/Cellar/python/2.7.12_2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-tk /usr/local/Cellar/python/2.7.12_2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-old /usr/local/Cellar/python/2.7.12_2/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload /Users/jaraco/Library/Python/2.7/lib/python/site-packages /usr/local/lib/python2.7/site-packages /Library/Python/2.7/site-packages]
(check your install and PYTHONPATH)

That happens even though I was still able to "import mercurial" in my Python environment. I uninstalled and reinstalled the Mercurial (using Homebrew) and it failed to reinstall with the same error, suggesting strongly that it was the Python environment that was corrupted. I then uninstalled and reinstalled the Homebrew Python 2.7, and the problem was solved. I think this points to another manifestation of something deleting files that were symlinked by directories in the virtualenv.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28949>
_______________________________________

From report at bugs.python.org  Tue Dec 13 11:38:15 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Tue, 13 Dec 2016 16:38:15 +0000
Subject: [issue28961] unittest.mock._Call ignores `name` parameter
In-Reply-To: <1481636868.17.0.0411235027553.issue28961@psf.upfronthosting.co.za>
Message-ID: <1481647095.57.0.828700244422.issue28961@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

That indeed looks like a bug. Well spotted :)

That code has been there since unittest.mock was added back in March 2012. If I were to guess, I'd say that it should be `if name is None: name = ''`. Care to submit a patch?

----------
nosy: +ebarry, michael.foord
stage:  -> needs patch
title: Is it a bug(method `_Call.__new__` in unittest.mock)? -> unittest.mock._Call ignores `name` parameter
type: enhancement -> behavior
versions: +Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28961>
_______________________________________

From report at bugs.python.org  Tue Dec 13 11:38:22 2016
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 13 Dec 2016 16:38:22 +0000
Subject: [issue28949] Stdlib modules disappear from file system
In-Reply-To: <1481553619.84.0.343525103437.issue28949@psf.upfronthosting.co.za>
Message-ID: <1481647102.75.0.536389499423.issue28949@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


----------
versions:  -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28949>
_______________________________________

From report at bugs.python.org  Tue Dec 13 11:40:03 2016
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 13 Dec 2016 16:40:03 +0000
Subject: [issue28949] Stdlib modules disappear from file system
In-Reply-To: <1481553619.84.0.343525103437.issue28949@psf.upfronthosting.co.za>
Message-ID: <1481647203.57.0.859420132869.issue28949@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

> virtualenvs and not venvs? 

Correct.

> In any case, at this point it seems pretty clear that we're not dealing with a problem with Python 3.6.0 nor with the python.org installer, no?

Also correct.

If you don't mind, I'd like to continue to document and log this issue here. I've removed Python 3.6 as implicated and I'll remove you as nosy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28949>
_______________________________________

From report at bugs.python.org  Tue Dec 13 11:40:11 2016
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 13 Dec 2016 16:40:11 +0000
Subject: [issue28949] Stdlib modules disappear from file system
In-Reply-To: <1481553619.84.0.343525103437.issue28949@psf.upfronthosting.co.za>
Message-ID: <1481647211.66.0.582957211633.issue28949@psf.upfronthosting.co.za>


Changes by Jason R. Coombs <jaraco at jaraco.com>:


----------
nosy:  -ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28949>
_______________________________________

From report at bugs.python.org  Tue Dec 13 11:50:25 2016
From: report at bugs.python.org (Ned Deily)
Date: Tue, 13 Dec 2016 16:50:25 +0000
Subject: [issue28949] Stdlib modules disappear from file system
In-Reply-To: <1481553619.84.0.343525103437.issue28949@psf.upfronthosting.co.za>
Message-ID: <1481647825.58.0.0442257843394.issue28949@psf.upfronthosting.co.za>


Ned Deily added the comment:

Thanks.  I'm still interested in the outcome but my immediate concern was whether this was a showstopper problem for 3.6.0.  Good luck!

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28949>
_______________________________________

From report at bugs.python.org  Tue Dec 13 11:56:40 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 13 Dec 2016 16:56:40 +0000
Subject: [issue28959] Add a macro for dict size
In-Reply-To: <1481634421.56.0.985862767516.issue28959@psf.upfronthosting.co.za>
Message-ID: <1481648200.75.0.158069932816.issue28959@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

It looks like the struct of a dict is already arranged in a way that it could switch to PyObject_VAR_HEAD which would let you use Py_SIZE everywhere.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28959>
_______________________________________

From report at bugs.python.org  Tue Dec 13 12:07:24 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 13 Dec 2016 17:07:24 +0000
Subject: [issue26071] bdist_wininst created binaries fail to start and find
 32bit Pythons
In-Reply-To: <1452388008.63.0.0329055331541.issue26071@psf.upfronthosting.co.za>
Message-ID: <20161213170721.117171.57886.0AD4C838@psf.io>


Roundup Robot added the comment:

New changeset c3da1ee47e6b by Steve Dower in branch '3.5':
Issue #26071: Fixes preprocessor definition and rebuilds wininst-14.0[-amd64].exe
https://hg.python.org/cpython/rev/c3da1ee47e6b

New changeset 0528a6743018 by Steve Dower in branch '3.6':
Issue #26071: Fixes preprocessor definition and rebuilds wininst-14.0[-amd64].exe
https://hg.python.org/cpython/rev/0528a6743018

New changeset 4e9d899fcb65 by Steve Dower in branch 'default':
Issue #26071: Fixes preprocessor definition and rebuilds wininst-14.0[-amd64].exe
https://hg.python.org/cpython/rev/4e9d899fcb65

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26071>
_______________________________________

From report at bugs.python.org  Tue Dec 13 12:11:25 2016
From: report at bugs.python.org (Ivan Pozdeev)
Date: Tue, 13 Dec 2016 17:11:25 +0000
Subject: [issue25458] ftplib: command response shift - mismatch
In-Reply-To: <1445510152.74.0.829316001802.issue25458@psf.upfronthosting.co.za>
Message-ID: <1481649085.59.0.249542983723.issue25458@psf.upfronthosting.co.za>


Ivan Pozdeev added the comment:

One more concern about the fix (so that you don't assume I didn't think of this ;) ) - handling of errors signified by the end-of-transfer response.

Handling a response in a close handler prevents us from actually checking its code:
* destructors like a close handler cannot raise exceptions because that would disrupt the resource release process
* and they're routinely called from `finally', so an exception would mask the current one if there's any (it's impossible to check within a finally block if it was was called as a result of an exception - http://stackoverflow.com/questions/1611561/can-i-get-the-exception-from-the-finally-block-in-python).

Now,
* The errors where the transfer never starts are detected by `ntransfercmd' either when opening the socket (425) or checking the first response (55x)
  * an exception when opening the socket would result in the response not being read.
* The errors when the transfer ends prematurely
  * are either handled by the socket (connection reset/timeout)
  * or can be detected by checking data length against the real one if it's available <- these are not currently handled
    * if it results from the user closing the socket prematurely (426), it _should_ be ignored
    * otherwise, we can wrap recv(), too, and check the response if the underlying fn returns ''
* If the error is local (an exception is raised in other code), the server's response doesn't matter

Looks like fixing this part warrants a separate ticket, though it does affect which option to take at this step - it speaks in favor of wrapping the data socket.

I'll ask at python-dev for some feedback before I go any way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25458>
_______________________________________

From report at bugs.python.org  Tue Dec 13 12:17:25 2016
From: report at bugs.python.org (Julien Palard)
Date: Tue, 13 Dec 2016 17:17:25 +0000
Subject: [issue26546] Provide translated french translation on docs.python.org
In-Reply-To: <1457794223.79.0.618185263259.issue26546@psf.upfronthosting.co.za>
Message-ID: <1481649445.84.0.380378122713.issue26546@psf.upfronthosting.co.za>


Julien Palard added the comment:

For the record, I opened a WIP pull request here: https://github.com/python/docsbuild-scripts/pull/8

Feedback is welcome.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26546>
_______________________________________

From report at bugs.python.org  Tue Dec 13 12:20:42 2016
From: report at bugs.python.org (Steve Dower)
Date: Tue, 13 Dec 2016 17:20:42 +0000
Subject: [issue26071] bdist_wininst created binaries fail to start and find
 32bit Pythons
In-Reply-To: <1452388008.63.0.0329055331541.issue26071@psf.upfronthosting.co.za>
Message-ID: <1481649642.45.0.691566185938.issue26071@psf.upfronthosting.co.za>


Steve Dower added the comment:

Fixed for 3.5.3, 3.6.1 and default.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26071>
_______________________________________

From report at bugs.python.org  Tue Dec 13 12:21:55 2016
From: report at bugs.python.org (Steve Dower)
Date: Tue, 13 Dec 2016 17:21:55 +0000
Subject: [issue28680] bdist_wininst generated 64-bit executable looks for
 3.5-32
In-Reply-To: <1479004752.08.0.80929351166.issue28680@psf.upfronthosting.co.za>
Message-ID: <1481649715.13.0.539305647266.issue28680@psf.upfronthosting.co.za>


Steve Dower added the comment:

Fixed for 3.5.3, 3.6.1 and default against the original issue26071

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> bdist_wininst created binaries fail to start and find 32bit Pythons

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28680>
_______________________________________

From report at bugs.python.org  Tue Dec 13 12:48:45 2016
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 13 Dec 2016 17:48:45 +0000
Subject: [issue28941] Update the link to Source Code in Python Docs from hg to
 github
In-Reply-To: <1481513819.65.0.156579360966.issue28941@psf.upfronthosting.co.za>
Message-ID: <1481651325.28.0.645488834502.issue28941@psf.upfronthosting.co.za>


Brett Cannon added the comment:

No, I'm the one who misunderstood; I read the title of the issue too quickly after reading the doc source link issue and my brain didn't pick up on the "source code" part of the title. Sorry about that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28941>
_______________________________________

From report at bugs.python.org  Tue Dec 13 12:51:29 2016
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 13 Dec 2016 17:51:29 +0000
Subject: [issue25711] Rewrite zipimport from scratch
In-Reply-To: <1448296120.48.0.872112518039.issue25711@psf.upfronthosting.co.za>
Message-ID: <1481651489.42.0.125973682598.issue25711@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Just FYI, if this lands I will probably try to build off of it to make a pathlib-like zip module to eventually replace zipfile. So if there's any API design decisions that need to be made, it would be great if we try to keep the zip-specific bits separate and generic enough to work with in other future libraries.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25711>
_______________________________________

From report at bugs.python.org  Tue Dec 13 13:56:46 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 13 Dec 2016 18:56:46 +0000
Subject: [issue28959] Add a macro for dict size
In-Reply-To: <1481634421.56.0.985862767516.issue28959@psf.upfronthosting.co.za>
Message-ID: <1481655406.62.0.20937378003.issue28959@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Following patch also switches the struct of a dict to PyObject_VAR_HEAD.

Should we use Py_SIZE or _PyDict_GET_SIZE? It is easier to replace _PyDict_GET_SIZE with Py_SIZE than restore dict-specific name from some of Py_SIZE-s.

----------
Added file: http://bugs.python.org/file45877/_PyDict_GET_SIZE-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28959>
_______________________________________

From report at bugs.python.org  Tue Dec 13 14:05:06 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 13 Dec 2016 19:05:06 +0000
Subject: [issue28923] Nonexisting encoding specified in Tix.py
In-Reply-To: <1481304070.27.0.11719456506.issue28923@psf.upfronthosting.co.za>
Message-ID: <1481655906.71.0.387962225031.issue28923@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I reread
https://docs.python.org/27/reference/lexical_analysis.html#encoding-declarations
A first or second line must be a comment matching "coding[=:]\s*([-\w.]+)" (which IDLE uses) and the captured name "must be recognized by Python".

I also did some experiments.  Apparently, "iso-latin-1-unix" is recognized by Python.  On Windows, from an IDLE editor,
  # coding: iso-latin-1-unix
runs, while 
  # coding: xiso-latin-1-unix
raises, during the compile(..., 'file', 'exec') call:
  SyntaxError: unknown encoding: xiso-latin-1-unix

Since codecs.lookup() returns the same error for both lines:
  LookupError: unknown encoding: iso-latin-1-unix
compile() must be doing something other than simply calling codecs.lookup.  I suspect it somehow recognizes 'iso', 'latin-1', and 'unix' as valid chunks of an ecoding name.  (The last might even be an obsolete legacy item.)  Whatever it is, it is not obviously available to tools written in Python.

Note that 'recognized as a legitimate encoding name' and 'available on a particular installation' are different concepts. I believe codecs.lookup implements the latter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28923>
_______________________________________

From report at bugs.python.org  Tue Dec 13 14:06:32 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 13 Dec 2016 19:06:32 +0000
Subject: [issue28923] Nonexisting encoding specified in Tix.py
In-Reply-To: <1481304070.27.0.11719456506.issue28923@psf.upfronthosting.co.za>
Message-ID: <1481655992.1.0.353291312506.issue28923@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Serhiy, if you agree with the proposed removal, but want me to do it, I will.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28923>
_______________________________________

From report at bugs.python.org  Tue Dec 13 14:24:27 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 13 Dec 2016 19:24:27 +0000
Subject: [issue28960] Small typo in Thread.join docs
In-Reply-To: <1481636284.79.0.913462681395.issue28960@psf.upfronthosting.co.za>
Message-ID: <1481657067.71.0.654307377387.issue28960@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
stage:  -> commit review
versions: +Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28960>
_______________________________________

From report at bugs.python.org  Tue Dec 13 14:26:41 2016
From: report at bugs.python.org (Ned Williamson)
Date: Tue, 13 Dec 2016 19:26:41 +0000
Subject: [issue28963] Use-after-free in _asynciomodule.c
Message-ID: <1481657201.46.0.37032067172.issue28963@psf.upfronthosting.co.za>


New submission from Ned Williamson:

There are two cases of use-after-free in the new Modules/_asynciomodule.c in the release candidate for Python 3.6, but I'm filing these together because it's the same underlying issue.

In both cases in this file where the unsafe `PyList_GET_ITEM` is called, `_asyncio_Future_remove_done_callback` and `future_schedule_callbacks`, there is a function called on the fetched item that allows the user to mutate the callbacks list (`PyObject_RichCompareBool` and `_PyObject_CallMethodId`), which then leads to OOB access on subsequent iterations.

For example, this script can trigger the vulnerability for `remove_done_callback`:
```
import asyncio

fut = asyncio.Future()
fut.add_done_callback(str)

for _ in range(63):
    fut.add_done_callback(id)

class evil:
    def __eq__(self, other):
        fut.remove_done_callback(id)
        return False

fut.remove_done_callback(evil())
```

On an ASAN build we can see that there is indeed a UAF occurring:
```
=================================================================
==19239==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60300000e7f0 at pc 0x000106fe6704 bp 0x7fff5cda09c0 sp 0x7fff5cda09b8
READ of size 8 at 0x60300000e7f0 thread T0
    #0 0x106fe6703 in _asyncio_Future_remove_done_callback _asynciomodule.c:526
    #1 0x102f5af35 in _PyCFunction_FastCallDict methodobject.c:192
    #2 0x1030e9044 in call_function ceval.c:4788
    #3 0x1030da2f0 in _PyEval_EvalFrameDefault ceval.c:3275
    #4 0x1030eb09b in _PyEval_EvalCodeWithName ceval.c:718
    #5 0x1030ced53 in PyEval_EvalCode ceval.c:4140
    #6 0x10317da47 in PyRun_FileExFlags pythonrun.c:980
    #7 0x10317c110 in PyRun_SimpleFileExFlags pythonrun.c:396
    #8 0x1031c76b8 in Py_Main main.c:320
    #9 0x102e5ed40 in main python.c:69
    #10 0x7fffc9bd8254 in start (libdyld.dylib+0x5254)

0x60300000e7f0 is located 0 bytes to the right of 32-byte region [0x60300000e7d0,0x60300000e7f0)
allocated by thread T0 here:
    #0 0x1039d5f87 in wrap_realloc (libclang_rt.asan_osx_dynamic.dylib+0x4af87)
    #1 0x102efb089 in list_ass_slice listobject.c:63
    #2 0x106fe6605 in _asyncio_Future_remove_done_callback _asynciomodule.c:541
    #3 0x102f5af35 in _PyCFunction_FastCallDict methodobject.c:192
    #4 0x1030e9044 in call_function ceval.c:4788
    #5 0x1030da2f0 in _PyEval_EvalFrameDefault ceval.c:3275
    #6 0x1030ed94a in _PyFunction_FastCallDict ceval.c:718
    #7 0x102e81308 in _PyObject_FastCallDict abstract.c:2295
    #8 0x102e816b1 in _PyObject_Call_Prepend abstract.c:2358
    #9 0x102e81286 in _PyObject_FastCallDict abstract.c:2316
    #10 0x102fa125a in slot_tp_richcompare typeobject.c:6287
    #11 0x102f61f66 in PyObject_RichCompare object.c:671
    #12 0x102f62421 in PyObject_RichCompareBool object.c:741
    #13 0x106fe6544 in _asyncio_Future_remove_done_callback _asynciomodule.c:528
    #14 0x102f5af35 in _PyCFunction_FastCallDict methodobject.c:192
    #15 0x1030e9044 in call_function ceval.c:4788
    #16 0x1030da2f0 in _PyEval_EvalFrameDefault ceval.c:3275
    #17 0x1030eb09b in _PyEval_EvalCodeWithName ceval.c:718
    #18 0x1030ced53 in PyEval_EvalCode ceval.c:4140
    #19 0x10317da47 in PyRun_FileExFlags pythonrun.c:980
    #20 0x10317c110 in PyRun_SimpleFileExFlags pythonrun.c:396
    #21 0x1031c76b8 in Py_Main main.c:320
    #22 0x102e5ed40 in main python.c:69
    #23 0x7fffc9bd8254 in start (libdyld.dylib+0x5254)

SUMMARY: AddressSanitizer: heap-buffer-overflow _asynciomodule.c:526 in _asyncio_Future_remove_done_callback
Shadow bytes around the buggy address:
  0x1c0600001ca0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c0600001cb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c0600001cc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c0600001cd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c0600001ce0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x1c0600001cf0: fa fa fa fa fa fa fa fa fa fa 00 00 00 00[fa]fa
  0x1c0600001d00: 00 00 00 fa fa fa 00 00 00 fa fa fa 00 00 00 02
  0x1c0600001d10: fa fa fd fd fd fd fa fa fd fd fd fd fa fa fd fd
  0x1c0600001d20: fd fd fa fa fd fd fd fd fa fa fd fd fd fd fa fa
  0x1c0600001d30: fd fd fd fd fa fa fd fd fd fd fa fa fd fd fd fd
  0x1c0600001d40: fa fa fd fd fd fd fa fa 00 00 00 00 fa fa 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:       fa
  Heap right redzone:      fb
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack partial redzone:   f4
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==19239==ABORTING
[1]    19239 abort      ASAN_OPTIONS=halt_on_error=0 ./python.exe test.py
```

----------
messages: 283134
nosy: Ned Williamson
priority: normal
severity: normal
status: open
title: Use-after-free in _asynciomodule.c
type: crash
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28963>
_______________________________________

From report at bugs.python.org  Tue Dec 13 14:27:33 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 13 Dec 2016 19:27:33 +0000
Subject: [issue28923] Nonexisting encoding specified in Tix.py
In-Reply-To: <1481304070.27.0.11719456506.issue28923@psf.upfronthosting.co.za>
Message-ID: <1481657253.98.0.384193008359.issue28923@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Yes, CPython tokenizer recognizes encoding starting with "iso-latin-1-" as "iso-8859-1" (see get_normal_name() in Parser/tokenizer.c:228).

I agreed that coding cookie or all line can be removed from Tix.py. Please do that.

----------
assignee:  -> terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28923>
_______________________________________

From report at bugs.python.org  Tue Dec 13 14:34:21 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 13 Dec 2016 19:34:21 +0000
Subject: [issue28963] Use-after-free in _asynciomodule.c
In-Reply-To: <1481657201.46.0.37032067172.issue28963@psf.upfronthosting.co.za>
Message-ID: <1481657661.43.0.263311084531.issue28963@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28963>
_______________________________________

From report at bugs.python.org  Tue Dec 13 14:44:51 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 13 Dec 2016 19:44:51 +0000
Subject: [issue28683] bind() on a unix socket raises PermissionError on
 Android for a non-root user
In-Reply-To: <1479065524.08.0.12999801833.issue28683@psf.upfronthosting.co.za>
Message-ID: <1481658291.52.0.118257480748.issue28683@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

test_pathlib must also be fixed for this same problem.
New patch.

----------
Added file: http://bugs.python.org/file45878/bind_unix_socket_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28683>
_______________________________________

From report at bugs.python.org  Tue Dec 13 14:46:41 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 13 Dec 2016 19:46:41 +0000
Subject: [issue28876] bool of large range raises OverflowError
In-Reply-To: <1480930662.45.0.497603219066.issue28876@psf.upfronthosting.co.za>
Message-ID: <1481658401.06.0.93151750161.issue28876@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Patch LGTM. You could safely drop the initialisers beyond `nb_bool` in the `range_as_number` struct (per C99 6.7.8p21), but it's fine as it is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28876>
_______________________________________

From report at bugs.python.org  Tue Dec 13 15:02:30 2016
From: report at bugs.python.org (Ned Deily)
Date: Tue, 13 Dec 2016 20:02:30 +0000
Subject: [issue28963] Use-after-free in _asynciomodule.c
In-Reply-To: <1481657201.46.0.37032067172.issue28963@psf.upfronthosting.co.za>
Message-ID: <1481659350.3.0.0956229805328.issue28963@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
nosy: +giampaolo.rodola, gvanrossum, haypo, yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28963>
_______________________________________

From report at bugs.python.org  Tue Dec 13 15:06:46 2016
From: report at bugs.python.org (Camilla Montonen)
Date: Tue, 13 Dec 2016 20:06:46 +0000
Subject: [issue11007] stack tracebacks should give the relevant class name
In-Reply-To: <1295968345.3.0.31737747868.issue11007@psf.upfronthosting.co.za>
Message-ID: <1481659606.95.0.652410605705.issue11007@psf.upfronthosting.co.za>


Camilla Montonen added the comment:

Reproduced original issue in 3.5.1.

----------
nosy: +Winterflower
versions: +Python 3.5 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11007>
_______________________________________

From report at bugs.python.org  Tue Dec 13 15:11:37 2016
From: report at bugs.python.org (Camilla Montonen)
Date: Tue, 13 Dec 2016 20:11:37 +0000
Subject: [issue16058] ConfigParser no longer deepcopy compatible in 2.7
In-Reply-To: <1348705133.3.0.138375656992.issue16058@psf.upfronthosting.co.za>
Message-ID: <1481659897.02.0.54761123331.issue16058@psf.upfronthosting.co.za>


Changes by Camilla Montonen <camillamon at gmail.com>:


----------
nosy: +Winterflower

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16058>
_______________________________________

From report at bugs.python.org  Tue Dec 13 15:15:24 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Tue, 13 Dec 2016 20:15:24 +0000
Subject: [issue28962] Crash when throwing an exception with a malicious
 __hash__ override
In-Reply-To: <1481646487.87.0.692050241508.issue28962@psf.upfronthosting.co.za>
Message-ID: <1481660124.15.0.847913130244.issue28962@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

Is this something that needs to be defended against? My understanding is that it's pretty easy to segfault CPython in a number of ways if you can execute 100% arbitrary code. The only way to cause this problem is if you can define malicious exceptions and cause one to be raised from itself, neither of which occurs in reasonable code.

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28962>
_______________________________________

From report at bugs.python.org  Tue Dec 13 15:16:22 2016
From: report at bugs.python.org (Camilla Montonen)
Date: Tue, 13 Dec 2016 20:16:22 +0000
Subject: [issue17430] missed peephole optimization
In-Reply-To: <1363372721.86.0.440516031889.issue17430@psf.upfronthosting.co.za>
Message-ID: <1481660182.22.0.687530114651.issue17430@psf.upfronthosting.co.za>


Changes by Camilla Montonen <camillamon at gmail.com>:


----------
nosy: +Winterflower

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17430>
_______________________________________

From report at bugs.python.org  Tue Dec 13 15:17:16 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Tue, 13 Dec 2016 20:17:16 +0000
Subject: [issue28944] A lack of line 6
In-Reply-To: <1481544628.07.0.0933253462311.issue28944@psf.upfronthosting.co.za>
Message-ID: <1481660236.99.0.722476016772.issue28944@psf.upfronthosting.co.za>


Changes by Josh Rosenberg <shadowranger+python at gmail.com>:


----------
nosy:  -josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28944>
_______________________________________

From report at bugs.python.org  Tue Dec 13 15:37:36 2016
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 13 Dec 2016 20:37:36 +0000
Subject: [issue11007] stack tracebacks should give the relevant class name
In-Reply-To: <1295968345.3.0.31737747868.issue11007@psf.upfronthosting.co.za>
Message-ID: <1481661456.81.0.53193386174.issue11007@psf.upfronthosting.co.za>


Zachary Ware added the comment:

__qualname__ has become a thing since this issue was opened, it may make implementation of this feature significantly easier.

----------
nosy: +zach.ware
versions: +Python 3.7 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11007>
_______________________________________

From report at bugs.python.org  Tue Dec 13 15:42:48 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 13 Dec 2016 20:42:48 +0000
Subject: [issue17430] missed peephole optimization
In-Reply-To: <1363372721.86.0.440516031889.issue17430@psf.upfronthosting.co.za>
Message-ID: <1481661768.97.0.424675161523.issue17430@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

FYI this optimization is already implemented in 3.5+.

>>> def fo():
...   if a:
...     if b:
...      if c:
...        print()
... 
>>> import dis
>>> dis.dis(fo)
  2           0 LOAD_GLOBAL              0 (a)
              2 POP_JUMP_IF_FALSE       18

  3           4 LOAD_GLOBAL              1 (b)
              6 POP_JUMP_IF_FALSE       18

  4           8 LOAD_GLOBAL              2 (c)
             10 POP_JUMP_IF_FALSE       18

  5          12 LOAD_GLOBAL              3 (print)
             14 CALL_FUNCTION            0
             16 POP_TOP
        >>   18 LOAD_CONST               0 (None)
             20 RETURN_VALUE

----------
nosy: +serhiy.storchaka
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17430>
_______________________________________

From report at bugs.python.org  Tue Dec 13 15:47:06 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 13 Dec 2016 20:47:06 +0000
Subject: [issue28962] Crash when throwing an exception with a malicious
 __hash__ override
In-Reply-To: <1481646487.87.0.692050241508.issue28962@psf.upfronthosting.co.za>
Message-ID: <1481662026.48.0.977434030248.issue28962@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
dependencies: +CPython hangs on error __context__ set to the error itself

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28962>
_______________________________________

From report at bugs.python.org  Tue Dec 13 15:52:23 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 13 Dec 2016 20:52:23 +0000
Subject: [issue16058] ConfigParser no longer deepcopy compatible in 2.7
In-Reply-To: <1348705133.3.0.138375656992.issue16058@psf.upfronthosting.co.za>
Message-ID: <1481662343.23.0.285643156813.issue16058@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
dependencies: +Regex objects became uncopyable in 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16058>
_______________________________________

From report at bugs.python.org  Tue Dec 13 16:47:44 2016
From: report at bugs.python.org (Steve Merritt)
Date: Tue, 13 Dec 2016 21:47:44 +0000
Subject: [issue28964] AST literal_eval exceptions provide no information about
 line number
Message-ID: <1481665664.26.0.256194535172.issue28964@psf.upfronthosting.co.za>


New submission from Steve Merritt:

Without line numbers, debugging syntax errors in large documents is a tedious and painful process.

----------
components: Library (Lib)
files: mywork.patch
keywords: patch
messages: 283142
nosy: stevemerritt
priority: normal
severity: normal
status: open
title: AST literal_eval exceptions provide no information about line number
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file45879/mywork.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28964>
_______________________________________

From report at bugs.python.org  Tue Dec 13 17:30:03 2016
From: report at bugs.python.org (Rohit Jamuar)
Date: Tue, 13 Dec 2016 22:30:03 +0000
Subject: [issue26876] Extend MSVCCompiler class to respect environment
 variables
In-Reply-To: <1461866719.82.0.2605655084.issue26876@psf.upfronthosting.co.za>
Message-ID: <1481668203.18.0.384015792981.issue26876@psf.upfronthosting.co.za>


Changes by Rohit Jamuar <rohit.jamuar at intel.com>:


Removed file: http://bugs.python.org/file42725/distutils_patch_master.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26876>
_______________________________________

From report at bugs.python.org  Tue Dec 13 17:30:51 2016
From: report at bugs.python.org (Rohit Jamuar)
Date: Tue, 13 Dec 2016 22:30:51 +0000
Subject: [issue26876] Extend MSVCCompiler class to respect environment
 variables
In-Reply-To: <1461866719.82.0.2605655084.issue26876@psf.upfronthosting.co.za>
Message-ID: <1481668251.01.0.878710900306.issue26876@psf.upfronthosting.co.za>


Changes by Rohit Jamuar <rohit.jamuar at intel.com>:


Added file: http://bugs.python.org/file45880/distutils_patch_master.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26876>
_______________________________________

From report at bugs.python.org  Tue Dec 13 17:57:54 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 13 Dec 2016 22:57:54 +0000
Subject: [issue28963] Use-after-free in _asynciomodule.c
In-Reply-To: <1481659350.32.0.0409551264253.issue28963@psf.upfronthosting.co.za>
Message-ID: <97DC0788-A55F-4EE9-8163-36115B935FC9@gmail.com>


Yury Selivanov added the comment:

Oh, this is a release blocker. I'll take a look later today.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28963>
_______________________________________

From report at bugs.python.org  Tue Dec 13 18:15:45 2016
From: report at bugs.python.org (Rohit Jamuar)
Date: Tue, 13 Dec 2016 23:15:45 +0000
Subject: [issue26876] Extend MSVCCompiler class to respect environment
 variables
In-Reply-To: <1461866719.82.0.2605655084.issue26876@psf.upfronthosting.co.za>
Message-ID: <1481670945.45.0.995224448181.issue26876@psf.upfronthosting.co.za>


Changes by Rohit Jamuar <rohit.jamuar at intel.com>:


Removed file: http://bugs.python.org/file45880/distutils_patch_master.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26876>
_______________________________________

From report at bugs.python.org  Tue Dec 13 18:16:45 2016
From: report at bugs.python.org (Rohit Jamuar)
Date: Tue, 13 Dec 2016 23:16:45 +0000
Subject: [issue26876] Extend MSVCCompiler class to respect environment
 variables
In-Reply-To: <1461866719.82.0.2605655084.issue26876@psf.upfronthosting.co.za>
Message-ID: <1481671005.96.0.0848560808402.issue26876@psf.upfronthosting.co.za>


Changes by Rohit Jamuar <rohit.jamuar at intel.com>:


Added file: http://bugs.python.org/file45881/distutils_patch_master.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26876>
_______________________________________

From report at bugs.python.org  Tue Dec 13 18:30:51 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Tue, 13 Dec 2016 23:30:51 +0000
Subject: [issue13290] get vars for object with __slots__
In-Reply-To: <1319871850.77.0.869546838833.issue13290@psf.upfronthosting.co.za>
Message-ID: <1481671851.03.0.281554055419.issue13290@psf.upfronthosting.co.za>


Steven D'Aprano added the comment:

I independently raised this on Python-Ideas and the initial responses are that vars() should support objects with slots too.

https://mail.python.org/pipermail/python-ideas/2016-December/043965.html

----------
nosy: +steven.daprano
versions: +Python 3.7 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13290>
_______________________________________

From report at bugs.python.org  Tue Dec 13 18:31:55 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 13 Dec 2016 23:31:55 +0000
Subject: [issue28963] Use-after-free in _asynciomodule.c
In-Reply-To: <1481657201.46.0.37032067172.issue28963@psf.upfronthosting.co.za>
Message-ID: <1481671915.52.0.600278111495.issue28963@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

I think the bug is only in _asyncio_Future_remove_done_callback, since future_schedule_callbacks makes a slice first, which cannot be mutated.

I'm attaching a patch.  Inada, would you be able to take a look?

----------
keywords: +patch
nosy: +ned.deily
priority: normal -> release blocker
Added file: http://bugs.python.org/file45882/Issue28963.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28963>
_______________________________________

From report at bugs.python.org  Tue Dec 13 18:36:17 2016
From: report at bugs.python.org (Ned Williamson)
Date: Tue, 13 Dec 2016 23:36:17 +0000
Subject: [issue28963] Use-after-free in _asynciomodule.c
In-Reply-To: <1481657201.46.0.37032067172.issue28963@psf.upfronthosting.co.za>
Message-ID: <1481672177.78.0.260399053029.issue28963@psf.upfronthosting.co.za>


Ned Williamson added the comment:

yselivanov, ah I think you're right. I misread that function after I noticed the issue in the first one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28963>
_______________________________________

From report at bugs.python.org  Tue Dec 13 18:40:53 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 13 Dec 2016 23:40:53 +0000
Subject: [issue26110] Speedup method calls 1.2x
In-Reply-To: <1452791347.05.0.923215900831.issue26110@psf.upfronthosting.co.za>
Message-ID: <1481672453.26.0.278193340412.issue26110@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Inada-san, when I tested the patch last time, I think there was a regression somewhere, related to the descriptor protocol.  Have you fixed that one?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26110>
_______________________________________

From report at bugs.python.org  Tue Dec 13 19:04:22 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 14 Dec 2016 00:04:22 +0000
Subject: [issue26110] Speedup method calls 1.2x
In-Reply-To: <1452791347.05.0.923215900831.issue26110@psf.upfronthosting.co.za>
Message-ID: <20161214000419.117305.77862.ECFDD9E2@psf.io>


Roundup Robot added the comment:

New changeset 64afd5cab40a by Yury Selivanov in branch 'default':
Issue #26110: Add LOAD_METHOD/CALL_METHOD opcodes.
https://hg.python.org/cpython/rev/64afd5cab40a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26110>
_______________________________________

From report at bugs.python.org  Tue Dec 13 19:07:43 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 14 Dec 2016 00:07:43 +0000
Subject: [issue26110] Speedup method calls 1.2x
In-Reply-To: <1452791347.05.0.923215900831.issue26110@psf.upfronthosting.co.za>
Message-ID: <1481674063.64.0.657287667408.issue26110@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> Inada-san, when I tested the patch last time, I think there was a regression somewhere, related to the descriptor protocol.  Have you fixed that one?

Seems to be either fixed, or maybe those bugs were related to my opcode cache patch.  Anyways, I decided to commit the patch to 3.7, otherwise it might miss the commit window as it did for 3.6.  Let's fix any regressions right in the repo now.

> My current idea is adding new `tp_fastcall` slot which has same signature
to _PyFunction_FastCallDict or _PyCFunction_FastCallDict.

I like this idea!

Thanks Inada-san for pushing this patch through, and thanks to Serhiy for reviewing it.

----------
resolution:  -> fixed
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26110>
_______________________________________

From report at bugs.python.org  Tue Dec 13 19:51:48 2016
From: report at bugs.python.org (Sean Murphy)
Date: Wed, 14 Dec 2016 00:51:48 +0000
Subject: [issue28965] Multiprocessing spawn/forkserver fails to pass Queues
Message-ID: <1481676708.34.0.90034781132.issue28965@psf.upfronthosting.co.za>


New submission from Sean Murphy:

Python fails to pass a Queue when calling Process with multiprocessing.set_start_method set to "spawn" or "forkserver".

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python3.5/multiprocessing/spawn.py", line 106, in spawn_main
    exitcode = _main(fd)
  File "/usr/lib/python3.5/multiprocessing/spawn.py", line 116, in _main
    self = pickle.load(from_parent)
  File "/usr/lib/python3.5/multiprocessing/synchronize.py", line 111, in __setstate__
    self._semlock = _multiprocessing.SemLock._rebuild(*state)
FileNotFoundError: [Errno 2] No such file or directory


Here is a minimized example:
```
#!/usr/bin/env python3

import multiprocessing

def check_child(q):
    print("Queue", q)


if __name__ == '__main__':
    multiprocessing.set_start_method('spawn')
    # multiprocessing.set_start_method('fork')
    # multiprocessing.set_start_method('forkserver')

    q = multiprocessing.Queue(-1)
    print("q", q)

    proc = multiprocessing.Process(target=check_child, args=(q,))
    proc.start()
```

Also, this fails when the Queue is implicitly passed to the child.
```
class Blerg():
    def __init__(self):
        self.q = multiprocessing.Queue(-1)

    def print_queue(self):
        print("Queue", self.q)


if __name__ == '__main__':
    multiprocessing.set_start_method('spawn')

    blerg = Blerg()

    blerg.print_queue()

    proc = multiprocessing.Process(target=blerg.print_queue)
    proc.start()
```

$ python3 --version
Python 3.5.2

Windows (which defaults to "spawn" style multiprocessing) does not seem to have this issue (at least in 2.7.12).

----------
components: Library (Lib)
messages: 283150
nosy: Sean Murphy
priority: normal
severity: normal
status: open
title: Multiprocessing spawn/forkserver fails to pass Queues
type: crash
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28965>
_______________________________________

From report at bugs.python.org  Tue Dec 13 20:05:32 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 14 Dec 2016 01:05:32 +0000
Subject: [issue28091] Document PEP 525
In-Reply-To: <1480969186.28.0.879526881588.issue28091@psf.upfronthosting.co.za>
Message-ID: <1481677532.01.0.818815777257.issue28091@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> I believe that I addressed all the comments in the previous review (although its always possible I missed something), and have a new patch with the improvements and fixes.

Thanks Eric!  I've left a few more comments in the review.  Almost there!

> I also noticed that in asyncio, loop.shutdown_asyncgens() is a coroutinemethod and fixed the markup to reflect that as I previously labeled it a method. The example I added here is as suggested, but it differs from the example in PEP525 in that shutdown_asyncgens() is run in a finally clause, which makes sense to me.

Right, I'll fix the PEP. Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28091>
_______________________________________

From report at bugs.python.org  Tue Dec 13 20:43:54 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 14 Dec 2016 01:43:54 +0000
Subject: [issue13290] get vars for object with __slots__
In-Reply-To: <1319871850.77.0.869546838833.issue13290@psf.upfronthosting.co.za>
Message-ID: <1481679834.65.0.170602521612.issue13290@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Michelle (maker)'s patch was reviewed by Serhiy and Richard in msg171867 and following.  It appears that stage should be 'needs revised patch'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13290>
_______________________________________

From report at bugs.python.org  Tue Dec 13 20:45:53 2016
From: report at bugs.python.org (Victor Sergienko)
Date: Wed, 14 Dec 2016 01:45:53 +0000
Subject: [issue28966] Menu.add_checkbutton has no checkmark on OS X
Message-ID: <1481679953.88.0.548860195336.issue28966@psf.upfronthosting.co.za>


New submission from Victor Sergienko:

On Linux, this code toggles the checkmark on a checkbutton in right-click menu. On OS X 10.12 it doesn't.

OS X 10.12, python 3.6.0b4.

#!/usr/bin/env python3
import tkinter as tk


class NodePopup(tk.Menu):
    def __init__(self, master):
        super().__init__(master, tearoff=0)

        self.send_disabled = tk.BooleanVar()

        self.add_checkbutton(label="Disable sending",
                             variable=self.send_disabled, command=self.toggle_send)

    def popup(self, event):
        print('send_disabled before:', self.send_disabled.get())
        self.post(event.x_root, event.y_root)

    def toggle_send(self):
        print('send_disabled after:', self.send_disabled.get())


def change():
    state = not menu.send_disabled.get()
    menu.send_disabled.set(state)

root = tk.Tk()
root.pack_propagate(0)

menu = NodePopup(root)
root.bind('<Button-2>', menu.popup)

root.mainloop()

----------
components: Tkinter
messages: 283153
nosy: Victor Sergienko
priority: normal
severity: normal
status: open
title: Menu.add_checkbutton has no checkmark on OS X
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28966>
_______________________________________

From report at bugs.python.org  Tue Dec 13 20:55:37 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 14 Dec 2016 01:55:37 +0000
Subject: [issue28956] return minimum of modes for a multimodal distribution
 instead of raising a StatisticsError
In-Reply-To: <CAN3Ck4Dr6nr_EsUyOyVnUWPpsuhzgt47_t7PLOgtXjvsEynmXg@mail.gmail.com>
Message-ID: <20161214015401.GI3365@ando.pearwood.info>


Steven D'Aprano added the comment:

On Tue, Dec 13, 2016 at 10:08:10AM +0000, Srikanth Anantharam wrote:
> Please see the updated pull request PR 50, with the changes.

I'm rejecting that pull request. As I said, mode() intentionally 
returns only the single, unique mode. I may add a more advanced API or a 
second function for dealing with multi-modal samples, but even if I do, 
your suggestion wouldn't be sufficient. Your pull request merely returns 
the entire list of unique values:

    return tuple(value for value, frequency in table)

with no way for the caller to tell which values might be a mode and 
which are not.

(By the way, even if this function behaviour was acceptible, which I 
stress it is not, this would not be sufficient for me to accept as a 
patch. You should preferably update the documentation and the tests as 
well. At the very least, you should update the function's docstring to 
explain the changed return value.)

I'm sorry that I have to reject this, I am interested in having better 
support for multiple modes. I'm not closing this issue just yet, if you 
are interested in continuing the discussion, what would be *VERY* 
valuable for me would be for you or some other volunteer to do some 
research into numerical techniques for objectively determining the 
number and value of modes, rather than just plotting a graph and 
subjectively deciding whether a value is a peak or not.

Thanks for your interest.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28956>
_______________________________________

From report at bugs.python.org  Tue Dec 13 21:00:57 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 14 Dec 2016 02:00:57 +0000
Subject: [issue28956] return minimum of modes for a multimodal distribution
 instead of raising a StatisticsError
In-Reply-To: <CAN3Ck4AF0b4JQ4iJ1hcg7vhJEbJf1yncZFnofpw1hwW760XcNw@mail.gmail.com>
Message-ID: <20161214020048.GJ3365@ando.pearwood.info>


Steven D'Aprano added the comment:

On Tue, Dec 13, 2016 at 10:17:21AM +0000, Srikanth Anantharam wrote:
> 
> Srikanth Anantharam added the comment:
> 
> @steven:
> 
> data = [1, 2, 3, 4, 4, 4, 5, 6, 7, 7, 8, 8, 8, 8, 8, 8, 8, 9, 9]
> is clearly unimodal with mode 8
> 
> data would have been bimodal if 4 repeated exactly the same (7) number of
> times as 8, like this:
> data = [1, 2, 3, 4, 4, 4, 4, 4, 4, 4, 5, 6, 7, 7, 8, 8, 8, 8, 8, 8, 8, 9, 9]

Bimodal distributions do not require both modes to be exactly the same 
height. And certainly when you have a sample from a bimodal 
distribution, you should not expect exactly the same frequency for the 
two modes. Just from random sampling error you will expect one or the 
other to have a larger frequency.

You shouldn't take my example too literally. With such a small sample of 
discrete values, it becomes a (hard) matter of personal judgement. The 
point I was attempting to make was that identifying sample modes outside 
of the simplest unimodal case is tricky and requires much thought.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28956>
_______________________________________

From report at bugs.python.org  Tue Dec 13 21:04:47 2016
From: report at bugs.python.org (Ned Deily)
Date: Wed, 14 Dec 2016 02:04:47 +0000
Subject: [issue28966] Menu.add_checkbutton has no checkmark on OS X
In-Reply-To: <1481679953.88.0.548860195336.issue28966@psf.upfronthosting.co.za>
Message-ID: <1481681087.61.0.927058294976.issue28966@psf.upfronthosting.co.za>


Ned Deily added the comment:

I'm not totally sure what behavior you expect but it *seems* to work OK for me using the current Python 3.5.2 or the pre-release 3.6.0rc1 from python.org OS X installers and with current ActiveTcl 8.5.18 installed as suggested (https://www.python.org/download/mac/tcltk/).  If you default to using the very out-of-date and buggy Apple-supplied system Tcl/Tk 8.5.9, the checkmark does not appear.

----------
nosy: +ned.deily
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28966>
_______________________________________

From report at bugs.python.org  Tue Dec 13 21:15:27 2016
From: report at bugs.python.org (Jiajun Huang)
Date: Wed, 14 Dec 2016 02:15:27 +0000
Subject: [issue28961] unittest.mock._Call ignores `name` parameter
In-Reply-To: <1481636868.17.0.0411235027553.issue28961@psf.upfronthosting.co.za>
Message-ID: <1481681727.16.0.893572970349.issue28961@psf.upfronthosting.co.za>


Jiajun Huang added the comment:

Thanks for reply :) the patch has been uploaded.

----------
keywords: +patch
Added file: http://bugs.python.org/file45883/mock_class_call.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28961>
_______________________________________

From report at bugs.python.org  Tue Dec 13 21:20:16 2016
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 14 Dec 2016 02:20:16 +0000
Subject: [issue28959] Add a macro for dict size
In-Reply-To: <1481634421.56.0.985862767516.issue28959@psf.upfronthosting.co.za>
Message-ID: <1481682016.24.0.30118250635.issue28959@psf.upfronthosting.co.za>


INADA Naoki added the comment:

I didn't know about PyObject_VAR_HEAD much.
The comment of the macro says:

/* PyObject_VAR_HEAD defines the initial segment of all variable-size
 * container objects.  These end with a declaration of an array with 1
 * element, but enough space is malloc'ed so that the array actually
 * has room for ob_size elements.  Note that ob_size is an element count,
 * not necessarily a byte count.
 */

dict doesn't end with array.
Does Py_SIZE() support recommended, like Python's len()?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28959>
_______________________________________

From report at bugs.python.org  Tue Dec 13 21:41:35 2016
From: report at bugs.python.org (Jiajun Huang)
Date: Wed, 14 Dec 2016 02:41:35 +0000
Subject: [issue28961] unittest.mock._Call ignores `name` parameter
In-Reply-To: <1481636868.17.0.0411235027553.issue28961@psf.upfronthosting.co.za>
Message-ID: <1481683295.97.0.437677826834.issue28961@psf.upfronthosting.co.za>


Jiajun Huang added the comment:

update the patch file follow the doc(https://docs.python.org/devguide/gitdevs.html)

----------
Added file: http://bugs.python.org/file45884/mock.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28961>
_______________________________________

From report at bugs.python.org  Tue Dec 13 22:50:49 2016
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 14 Dec 2016 03:50:49 +0000
Subject: [issue26110] Speedup method calls 1.2x
In-Reply-To: <1452791347.05.0.923215900831.issue26110@psf.upfronthosting.co.za>
Message-ID: <1481687449.62.0.436678011714.issue26110@psf.upfronthosting.co.za>


INADA Naoki added the comment:

I'm working on changing stack layout slightly

current patch: callable | NULL | arg1 | ...argN
next patch will: NULL | callable | arg1 | ...argN

After benchmark with PGO build, I'll post it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26110>
_______________________________________

From report at bugs.python.org  Tue Dec 13 23:02:31 2016
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 14 Dec 2016 04:02:31 +0000
Subject: [issue26110] Speedup method calls 1.2x
In-Reply-To: <1452791347.05.0.923215900831.issue26110@psf.upfronthosting.co.za>
Message-ID: <1481688151.47.0.294541850171.issue26110@psf.upfronthosting.co.za>


INADA Naoki added the comment:

I haven't noticed the patch is committed already.

Changing stack layout slightly is for easy to document, not for performance.
Please don't close this issue until adding document in Doc/library/dis.rst

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26110>
_______________________________________

From report at bugs.python.org  Tue Dec 13 23:27:33 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 14 Dec 2016 04:27:33 +0000
Subject: [issue28950] regrtest: -j0 fails the check -j is not allowed together
 with -T/-l
In-Reply-To: <1481566513.26.0.47817718709.issue28950@psf.upfronthosting.co.za>
Message-ID: <1481689653.29.0.143408080524.issue28950@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Thanks for your review kumaar.nd. :-)

As for your suggestion, in this case adding can not be any harder than replacing. And the old cases could represent the truth value.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28950>
_______________________________________

From report at bugs.python.org  Wed Dec 14 00:40:03 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 14 Dec 2016 05:40:03 +0000
Subject: [issue28959] Add a macro for dict size
In-Reply-To: <1481634421.56.0.985862767516.issue28959@psf.upfronthosting.co.za>
Message-ID: <1481694003.0.0.976908544535.issue28959@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

list doesn't end with array too, but uses PyObject_VAR_HEAD. tp_itemsize is 0, therefore no additional space at the end is allocated.

Maybe this is overuse of PyObject_VAR_HEAD.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28959>
_______________________________________

From report at bugs.python.org  Wed Dec 14 00:46:47 2016
From: report at bugs.python.org (Jiajun Huang)
Date: Wed, 14 Dec 2016 05:46:47 +0000
Subject: [issue28961] unittest.mock._Call ignores `name` parameter
In-Reply-To: <1481636868.17.0.0411235027553.issue28961@psf.upfronthosting.co.za>
Message-ID: <1481694407.08.0.102744700025.issue28961@psf.upfronthosting.co.za>


Jiajun Huang added the comment:

The new patch has been updated. :)

----------
Added file: http://bugs.python.org/file45885/mock.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28961>
_______________________________________

From report at bugs.python.org  Wed Dec 14 01:09:48 2016
From: report at bugs.python.org (Jelle Zijlstra)
Date: Wed, 14 Dec 2016 06:09:48 +0000
Subject: [issue28967] copy.copy fails on threading.local subclass
Message-ID: <1481695788.41.0.793591769474.issue28967@psf.upfronthosting.co.za>


New submission from Jelle Zijlstra:

Calling copy.copy on a threading.local subclass copies attributes over correctly in Python 2.7, but creates an empty object in Python 3.3-3.5 and fails with a pickle-related error in 3.6.

Marking this as a release blocker and assigning to Ned because this appears to be a regression in 3.6. However, given that the behavior in previous Python 3 versions isn't very useful either, I'd personally not want to block 3.6 on it.

I haven't yet looked at code to figure out what is causing the differences in behavior. I couldn't find any tracker issues related to copying or pickling threading.local objects, but may have missed something.

$ cat thread_local_copy.py 
import copy
import threading

class Obj(threading.local):
    def __init__(self):
        self.x = 3

o = Obj()
o2 = copy.copy(o)
assert hasattr(o2, 'x')
$ python2.7 thread_local_copy.py 
$ python3.3 thread_local_copy.py 
Traceback (most recent call last):
  File "thread_local_copy.py", line 10, in <module>
    assert hasattr(o2, 'x')
AssertionError
$ python3.4 thread_local_copy.py 
Traceback (most recent call last):
  File "thread_local_copy.py", line 10, in <module>
    assert hasattr(o2, 'x')
AssertionError
$ python3.5 thread_local_copy.py 
Traceback (most recent call last):
  File "thread_local_copy.py", line 10, in <module>
    assert hasattr(o2, 'x')
AssertionError
$ ./python.exe -V
Python 3.6.0+
$ ./python.exe thread_local_copy.py 
Traceback (most recent call last):
  File "thread_local_copy.py", line 9, in <module>
    o2 = copy.copy(o)
  File "/Users/Jelle/code/cpython/Lib/copy.py", line 96, in copy
    rv = reductor(4)
TypeError: can't pickle Obj objects

----------
assignee: ned.deily
files: thread_local_copy.py
keywords: 3.6regression
messages: 283165
nosy: Jelle Zijlstra, ned.deily
priority: release blocker
severity: normal
status: open
title: copy.copy fails on threading.local subclass
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file45886/thread_local_copy.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28967>
_______________________________________

From report at bugs.python.org  Wed Dec 14 01:26:46 2016
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 14 Dec 2016 06:26:46 +0000
Subject: [issue26110] Speedup method calls 1.2x
In-Reply-To: <1452791347.05.0.923215900831.issue26110@psf.upfronthosting.co.za>
Message-ID: <1481696806.29.0.711335181931.issue26110@psf.upfronthosting.co.za>


INADA Naoki added the comment:

PGO benchmark result
https://gist.github.com/methane/64ab60c38324423ef27af70cc6db1dfd

----------
Added file: http://bugs.python.org/file45887/default.json.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26110>
_______________________________________

From report at bugs.python.org  Wed Dec 14 01:26:46 2016
From: report at bugs.python.org (Jelle Zijlstra)
Date: Wed, 14 Dec 2016 06:26:46 +0000
Subject: [issue28967] copy.copy fails on threading.local subclass
In-Reply-To: <1481695788.41.0.793591769474.issue28967@psf.upfronthosting.co.za>
Message-ID: <1481696806.98.0.957342518239.issue28967@psf.upfronthosting.co.za>


Jelle Zijlstra added the comment:

This might be due to issue22995.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28967>
_______________________________________

From report at bugs.python.org  Wed Dec 14 01:26:55 2016
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 14 Dec 2016 06:26:55 +0000
Subject: [issue26110] Speedup method calls 1.2x
In-Reply-To: <1452791347.05.0.923215900831.issue26110@psf.upfronthosting.co.za>
Message-ID: <1481696815.67.0.779885612172.issue26110@psf.upfronthosting.co.za>


Changes by INADA Naoki <songofacandy at gmail.com>:


Added file: http://bugs.python.org/file45888/patched.json.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26110>
_______________________________________

From report at bugs.python.org  Wed Dec 14 01:45:40 2016
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 14 Dec 2016 06:45:40 +0000
Subject: [issue26110] Speedup method calls 1.2x
In-Reply-To: <1452791347.05.0.923215900831.issue26110@psf.upfronthosting.co.za>
Message-ID: <1481697940.37.0.61900613737.issue26110@psf.upfronthosting.co.za>


INADA Naoki added the comment:

This patch modify stack layout slightly and adds document in Doc/library/dis.rst

----------
Added file: http://bugs.python.org/file45889/callmethod-doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26110>
_______________________________________

From report at bugs.python.org  Wed Dec 14 02:11:42 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 14 Dec 2016 07:11:42 +0000
Subject: [issue28967] copy.copy fails on threading.local subclass
In-Reply-To: <1481695788.41.0.793591769474.issue28967@psf.upfronthosting.co.za>
Message-ID: <1481699502.15.0.259826188888.issue28967@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

copy.copy() didn't work correctly with threading.local in 3.x. It just silently created an empty instance (even not properly initialized, since __init__ is bypassed). Now it correctly raises TypeError.

copy.copy() looks working in 2.7 because it copied the instance __dict__. But the internal state can be lost. There are no tests.

Definitely this is not 3.6 regression. And it is questionable that it is 3.x regression, because it is questionable that copying worked in 2.x.

I would consider making threading.local copyable a new feature. But it is questionable that this feature is useful.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28967>
_______________________________________

From report at bugs.python.org  Wed Dec 14 02:33:48 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 14 Dec 2016 07:33:48 +0000
Subject: [issue5322] Python 2.6 object.__new__ argument calling autodetection
 faulty
In-Reply-To: <1235075665.37.0.301694124748.issue5322@psf.upfronthosting.co.za>
Message-ID: <20161214073345.32704.88650.0BD0A374@psf.io>


Roundup Robot added the comment:

New changeset 5315db3171b0 by Benjamin Peterson in branch '2.7':
revert a37cc3d926ec (#5322)
https://hg.python.org/cpython/rev/5315db3171b0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5322>
_______________________________________

From report at bugs.python.org  Wed Dec 14 03:09:15 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Dec 2016 08:09:15 +0000
Subject: [issue28963] Use-after-free in _asynciomodule.c
In-Reply-To: <1481657201.46.0.37032067172.issue28963@psf.upfronthosting.co.za>
Message-ID: <1481702955.69.0.690294352935.issue28963@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Oh, this is a release blocker. I'll take a look later today.

The bug requires to have an "evil" class which is unlikely in an application. I don't think that it's a release blocker.

----------
priority: release blocker -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28963>
_______________________________________

From report at bugs.python.org  Wed Dec 14 03:12:58 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Dec 2016 08:12:58 +0000
Subject: [issue28963] Use-after-free in _asynciomodule.c
In-Reply-To: <1481657201.46.0.37032067172.issue28963@psf.upfronthosting.co.za>
Message-ID: <1481703178.75.0.715803169353.issue28963@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I see three options:

* avoid PyObject_RichCompareBool() which can run arbitrary Python code: this can be complicated since callbacks can be proxies, functools.partial, lambda, and other funny callable objects
* reimplement the same algorithm than the Python implementation: create a new list.
* do nothing: if you do weird things, it's your fault :-)

My favorite option is to work on a new list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28963>
_______________________________________

From report at bugs.python.org  Wed Dec 14 03:14:11 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Dec 2016 08:14:11 +0000
Subject: [issue28963] Use-after-free in _asyncio_Future_remove_done_callback()
 of _asynciomodule.c
In-Reply-To: <1481657201.46.0.37032067172.issue28963@psf.upfronthosting.co.za>
Message-ID: <1481703251.51.0.541586660274.issue28963@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
title: Use-after-free in _asynciomodule.c -> Use-after-free in _asyncio_Future_remove_done_callback() of _asynciomodule.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28963>
_______________________________________

From report at bugs.python.org  Wed Dec 14 03:47:14 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 14 Dec 2016 08:47:14 +0000
Subject: [issue28963] Use-after-free in _asyncio_Future_remove_done_callback()
 of _asynciomodule.c
In-Reply-To: <1481657201.46.0.37032067172.issue28963@psf.upfronthosting.co.za>
Message-ID: <1481705234.65.0.0761834697913.issue28963@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Inada-san, thanks for the review. You're right, we need to fix another edge-case.  I'll upload a new patch tomorrow.

Victor, fourth option we should go with is to commit the attached patch (with Inada-san review comment fixed).

I guess it's up to Ned if he want to cherry-pick the patch to Python 3.6.  I agree that the bug is very unlikely to appear in any real-world code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28963>
_______________________________________

From report at bugs.python.org  Wed Dec 14 03:54:33 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Dec 2016 08:54:33 +0000
Subject: [issue28959] Add a macro for dict size
In-Reply-To: <1481634421.56.0.985862767516.issue28959@psf.upfronthosting.co.za>
Message-ID: <1481705673.81.0.0862712138236.issue28959@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> It looks like the struct of a dict is already arranged in a way that it could switch to PyObject_VAR_HEAD

Can someone check if it has an impact of the size of the structure (because of the complex rules of alignment)? If the structure has the same size, I'm in favor of using PyObject_VAR_HEAD.

I reviewed _PyDict_GET_SIZE-2.patch: I like the overall change, but I added many comments.

When changes are not direct replacement ma_used => _PyDict_GET_SIZE(), please push the changes in a separated commit when you will push the whole change (I'm thinking to a micro-optimization in ceval.c).

In typeobject.c, you added a check to test if *dictptr is a dict or not. This change seems strange to me. I'm not sure about the right behaviour here. You might open a separated issue for this change. I don't know if an exception should be raised or not.

And my comments on the macro itself:

Please add a tiny inline documentation:

   /* Get the number of items of a dictionary. */

I don't think that it's worth it to make the macro private, just name it PyDict_GET_SIZE(). The macro is not defined in the limited API, and we already expose like "everything" in the default API... No need to make the API harder to use. I was always surprised to have to check if the result if PyDict_Size() is negative and that no macro existed.

Your change is a large and so hard to review. I would be more confident if you add an assertion here, as done in crazy macros of unicodeobject.h:

   #define _PyDict_GET_SIZE(mp) (assert(PyDict_Check(mp),Py_SIZE(mp))

We can add such assertion since it's a new macro. I'm not sure that we can do it in existing macros like PyTuple_GET_SIZE(), since these macros may be abused to modify the size, not only get it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28959>
_______________________________________

From report at bugs.python.org  Wed Dec 14 03:57:47 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Dec 2016 08:57:47 +0000
Subject: [issue28959] Add a macro for dict size
In-Reply-To: <1481634421.56.0.985862767516.issue28959@psf.upfronthosting.co.za>
Message-ID: <1481705867.37.0.316969905983.issue28959@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Should we use Py_SIZE or _PyDict_GET_SIZE?

I prefer _PyDict_GET_SIZE() just to make the code more readable: it helps to repeat the type of variables.

Moreover, it can give you a free check on the type if you agree my suggestion to add an assertion into the macro directly.

Technically, it's already possible to use Py_SIZE() on lists and tuples, but PyTuple_GET_SIZE() and PyList_GET_SIZE() are used almost everywhere, again, for readability.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28959>
_______________________________________

From report at bugs.python.org  Wed Dec 14 04:08:18 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Dec 2016 09:08:18 +0000
Subject: [issue28959] Add a macro for dict size
In-Reply-To: <1481634421.56.0.985862767516.issue28959@psf.upfronthosting.co.za>
Message-ID: <1481706498.55.0.609128417985.issue28959@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> dict doesn't end with array.

Right, but...

Recently I looked at dict internals. As a newcomer, I have to confess that it's currently really hard to understand the purpose of each dict field: they are many "sizes": size of the hash table, number of usable entries, number of used entries, number of items in the dictionary, etc.

I like the idea of using the standard ob_size field (PyVarObject) to make it more explicitl that this field is the expected result of len(obj).

Technically, I don't know any function inside Python core which rely on the fact that object data is at the end of the main memory block.

Other builtin Python types:

* tuple: PyVarObject
* list: PyVarObject
* bytes: PyVarObject
* bytearray: PyVarObject
* memoryview: PyVarObject
* set: "used" field
* str: "length" field

The str type is super optimized for memory footprint, there are technical reasons for not used PyVarObject here, like backward compatibility.

It may make sense to modify PySetObject to use PyVarObject as well, but that's a different topic :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28959>
_______________________________________

From report at bugs.python.org  Wed Dec 14 04:11:25 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Dec 2016 09:11:25 +0000
Subject: [issue26110] Speedup method calls 1.2x
In-Reply-To: <1452791347.05.0.923215900831.issue26110@psf.upfronthosting.co.za>
Message-ID: <1481706685.62.0.810812601015.issue26110@psf.upfronthosting.co.za>


STINNER Victor added the comment:

INADA Naoki: "My current idea is adding new `tp_fastcall` slot which has same signature to _PyFunction_FastCallDict or _PyCFunction_FastCallDict."

FYI I'm working on a solution to avoid tuple and dict to pass parameters to tp_new, tp_init and tp_call. I have PoC implementations (yeah, more than one). Please come to me directly if you are interested, this issue is not the right place to discuss.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26110>
_______________________________________

From report at bugs.python.org  Wed Dec 14 04:17:29 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Dec 2016 09:17:29 +0000
Subject: [issue5322] Python 2.6 object.__new__ argument calling autodetection
 faulty
In-Reply-To: <1235075665.37.0.301694124748.issue5322@psf.upfronthosting.co.za>
Message-ID: <1481707049.62.0.726959397933.issue5322@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Since this change seems to break the backward compatibility, is it safe to apply it to Python 3.5.x and Python 3.6.x? The bug was reported in 2009, 7 years ago. Can the fix wait for Python 3.7?

test_file contains code which worked well before the change and started to crash after the change. If it occurs for an application, I expect users to be unhappy of getting such "behaviour change" in a minor release, no?

--

Is it possible to prevent the crash of test_file without modifying its code (without the change 4a610bc8577b "Change order of io.UnsupportedOperation base classes")? Sorry, I didnd't follow this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5322>
_______________________________________

From report at bugs.python.org  Wed Dec 14 04:21:08 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Dec 2016 09:21:08 +0000
Subject: [issue28963] Use-after-free in _asyncio_Future_remove_done_callback()
 of _asynciomodule.c
In-Reply-To: <1481657201.46.0.37032067172.issue28963@psf.upfronthosting.co.za>
Message-ID: <1481707268.5.0.218210702465.issue28963@psf.upfronthosting.co.za>


STINNER Victor added the comment:

_asyncio_Future_remove_done_callback() is still wrong with  Issue28963.patch: what if an evil __eq__() methods inserts or remove directly items of the future callbacks list?

By design, it's not safe to iterate on a list if the body of the list calls arbitrary Python code.

(I don't know how exactly, but everything in Python is possible, see the gc module to retrieve private fields of a C objecct.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28963>
_______________________________________

From report at bugs.python.org  Wed Dec 14 04:47:19 2016
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 14 Dec 2016 09:47:19 +0000
Subject: [issue26110] Speedup method calls 1.2x
In-Reply-To: <1452791347.05.0.923215900831.issue26110@psf.upfronthosting.co.za>
Message-ID: <1481708839.92.0.603905790948.issue26110@psf.upfronthosting.co.za>


Changes by INADA Naoki <songofacandy at gmail.com>:


Added file: http://bugs.python.org/file45890/callmethod-doc2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26110>
_______________________________________

From report at bugs.python.org  Wed Dec 14 04:48:06 2016
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 14 Dec 2016 09:48:06 +0000
Subject: [issue26110] Speedup method calls 1.2x
In-Reply-To: <1452791347.05.0.923215900831.issue26110@psf.upfronthosting.co.za>
Message-ID: <1481708886.39.0.310579461775.issue26110@psf.upfronthosting.co.za>


Changes by INADA Naoki <songofacandy at gmail.com>:


Removed file: http://bugs.python.org/file45890/callmethod-doc2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26110>
_______________________________________

From report at bugs.python.org  Wed Dec 14 04:53:43 2016
From: report at bugs.python.org (Manish Singh)
Date: Wed, 14 Dec 2016 09:53:43 +0000
Subject: [issue28968] xml rpc server fails with connection reset by peer error
 no 104
Message-ID: <1481709223.17.0.559234955094.issue28968@psf.upfronthosting.co.za>


New submission from Manish Singh:

I have used xml rpc library with transport http. My client and server are running on same host.

In normal load scenario(20% cpu usage, 80% memory usage, 18 GB memory free), some request of xml rpc client fails with connection reset by peer error. I have used xmlrpclib.ServerProxy() to call remote method on xml rpc server running on an empherial port.

This issue has happen many times.

log snippet,

  File "/usr/lib64/python2.6/xmlrpclib.py", line 1489, in __request
    verbose=self.__verbose
  File "/usr/lib64/python2.6/xmlrpclib.py", line 1237, in request
    errcode, errmsg, headers = h.getreply()
  File "/usr/lib64/python2.6/httplib.py", line 1064, in getreply
    response = self._conn.getresponse()
  File "/usr/lib64/python2.6/httplib.py", line 990, in getresponse
    response.begin()
  File "/usr/lib64/python2.6/httplib.py", line 391, in begin
    version, status, reason = self._read_status()
  File "/usr/lib64/python2.6/httplib.py", line 349, in _read_status
    line = self.fp.readline()
  File "/usr/lib64/python2.6/socket.py", line 433, in readline
    data = recv(1)
error: [Errno 104] Connection reset by peer

----------
components: Library (Lib)
messages: 283180
nosy: manu
priority: normal
severity: normal
status: open
title: xml rpc server fails with connection reset by peer error no 104
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28968>
_______________________________________

From report at bugs.python.org  Wed Dec 14 04:57:24 2016
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 14 Dec 2016 09:57:24 +0000
Subject: [issue26110] Speedup method calls 1.2x
In-Reply-To: <1452791347.05.0.923215900831.issue26110@psf.upfronthosting.co.za>
Message-ID: <1481709444.05.0.484021949696.issue26110@psf.upfronthosting.co.za>


Changes by INADA Naoki <songofacandy at gmail.com>:


Added file: http://bugs.python.org/file45891/callmethod-doc2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26110>
_______________________________________

From report at bugs.python.org  Wed Dec 14 04:59:13 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 14 Dec 2016 09:59:13 +0000
Subject: [issue28959] Add a macro for dict size
In-Reply-To: <1481634421.56.0.985862767516.issue28959@psf.upfronthosting.co.za>
Message-ID: <1481709553.93.0.476557965241.issue28959@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Updated patch addresses Victor's issue. _PyDict_GET_SIZE is renamed to PyDict_GET_SIZE and now it includes an assertion. This is good argument for introducing this macro against using PyDict_Size (without checking the result for error) and Py_SIZE (which doesn't check the type).

> Can someone check if it has an impact of the size of the structure (because of the complex rules of alignment)?

There are special tests for that.

Actually I think that switching to PyObject_VAR_HEAD is different issue. The patch can be pushed without changes to dictobject.c and the structure of a dict.

----------
Added file: http://bugs.python.org/file45892/PyDict_GET_SIZE-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28959>
_______________________________________

From report at bugs.python.org  Wed Dec 14 05:16:42 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 14 Dec 2016 10:16:42 +0000
Subject: [issue20211] setup.py: do not add system header locations when cross
 compiling
In-Reply-To: <1389308528.92.0.403642458985.issue20211@psf.upfronthosting.co.za>
Message-ID: <20161214101638.117052.98143.0ED1C5A7@psf.io>


Roundup Robot added the comment:

New changeset d1b400943483 by Xavier de Gaye in branch '3.6':
Issue #20211: Do not add the directory for installing C header files and
https://hg.python.org/cpython/rev/d1b400943483

New changeset fcc9f19fcc13 by Xavier de Gaye in branch 'default':
Issue #20211: Merge 3.6.
https://hg.python.org/cpython/rev/fcc9f19fcc13

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20211>
_______________________________________

From report at bugs.python.org  Wed Dec 14 05:19:05 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 14 Dec 2016 10:19:05 +0000
Subject: [issue20211] setup.py: do not add system header locations when cross
 compiling
In-Reply-To: <1389308528.92.0.403642458985.issue20211@psf.upfronthosting.co.za>
Message-ID: <1481710745.29.0.971714566379.issue20211@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

>> this assumption is wrong for the multiarch case.
>
> Please explain why it is wrong.

Sadly no explanations have been given, we have to take Matthias word for it.
This new patch updates the add_multiarch_paths() method and includes LIBDIR and INCLUDEDIR in their corresponding search paths for the multiarch case.

----------
assignee: xdegaye -> 
stage: commit review -> patch review
Added file: http://bugs.python.org/file45893/multiarch.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20211>
_______________________________________

From report at bugs.python.org  Wed Dec 14 05:25:39 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 14 Dec 2016 10:25:39 +0000
Subject: [issue20211] setup.py: do not add system header locations when cross
 compiling
In-Reply-To: <1389308528.92.0.403642458985.issue20211@psf.upfronthosting.co.za>
Message-ID: <1481711139.0.0.360721103602.issue20211@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Same patch, but this one is properly set to be handled by Rietveld.

----------
Added file: http://bugs.python.org/file45894/multiarch_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20211>
_______________________________________

From report at bugs.python.org  Wed Dec 14 05:30:02 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 14 Dec 2016 10:30:02 +0000
Subject: [issue26865] Meta-issue: support of the android platform
In-Reply-To: <1461685011.99.0.617135447086.issue26865@psf.upfronthosting.co.za>
Message-ID: <1481711402.13.0.266861712019.issue26865@psf.upfronthosting.co.za>


Changes by Xavier de Gaye <xdegaye at gmail.com>:


----------
dependencies:  -setup.py: do not add system header locations when cross compiling

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26865>
_______________________________________

From report at bugs.python.org  Wed Dec 14 05:49:24 2016
From: report at bugs.python.org (Nicolas Savoire)
Date: Wed, 14 Dec 2016 10:49:24 +0000
Subject: [issue28969] fnmatch is not threadsafe
Message-ID: <1481712564.52.0.530922236321.issue28969@psf.upfronthosting.co.za>


New submission from Nicolas Savoire:

With python3.5, fnmatch appears not to be thrad safe. It fails with the following exception:

Traceback (most recent call last):
  File "test.py", line 18, in <module>
    f.result()
  File "/opt/anaconda3/lib/python3.5/concurrent/futures/_base.py", line 405, in result
    return self.__get_result()
  File "/opt/anaconda3/lib/python3.5/concurrent/futures/_base.py", line 357, in __get_result
    raise self._exception
  File "/opt/anaconda3/lib/python3.5/concurrent/futures/thread.py", line 55, in run
    result = self.fn(*self.args, **self.kwargs)
  File "test.py", line 12, in foo
    fnmatch(ref, s)
  File "/opt/anaconda3/lib/python3.5/fnmatch.py", line 36, in fnmatch
    return fnmatchcase(name, pat)
  File "/opt/anaconda3/lib/python3.5/fnmatch.py", line 70, in fnmatchcase
    match = _compile_pattern(pat)
KeyError: ('SXJ8WZ9F7Z', <class 'str'>)

Here is a minimal example reproducing the issue:

import concurrent.futures
from fnmatch import fnmatch
import random
import string

def str_generator(size=10, chars=string.ascii_uppercase + string.digits):
   return ''.join(random.choice(chars) for _ in range(size))


def foo(strs, ref):
    for s in strs:
        fnmatch(ref, s)

some_strings = [str_generator() for _ in range(500)]
with concurrent.futures.ThreadPoolExecutor() as executor:
    futures = [executor.submit(foo, some_strings, some_strings[0]) for _ in range(8)]
    for f in futures:
        f.result()



$ python3 --version
Python 3.5.2 :: Anaconda 4.2.0 (64-bit)

----------
components: Library (Lib)
files: test.py
messages: 283185
nosy: Nicolas Savoire
priority: normal
severity: normal
status: open
title: fnmatch is not threadsafe
type: crash
versions: Python 3.5
Added file: http://bugs.python.org/file45895/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28969>
_______________________________________

From report at bugs.python.org  Wed Dec 14 05:55:24 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 14 Dec 2016 10:55:24 +0000
Subject: [issue28683] bind() on a unix socket raises PermissionError on
 Android for a non-root user
In-Reply-To: <1479065524.08.0.12999801833.issue28683@psf.upfronthosting.co.za>
Message-ID: <20161214105521.23031.76201.9D53FAD8@psf.io>


Roundup Robot added the comment:

New changeset b65ae19bc42a by Xavier de Gaye in branch '3.6':
Issue #28683: Fix the tests that bind() a unix socket and raise PermissionError
https://hg.python.org/cpython/rev/b65ae19bc42a

New changeset 0350e0634a4b by Xavier de Gaye in branch 'default':
Issue #28683: Merge 3.6.
https://hg.python.org/cpython/rev/0350e0634a4b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28683>
_______________________________________

From report at bugs.python.org  Wed Dec 14 06:09:40 2016
From: report at bugs.python.org (Evan)
Date: Wed, 14 Dec 2016 11:09:40 +0000
Subject: [issue28960] Small typo in Thread.join docs
In-Reply-To: <1481636284.79.0.913462681395.issue28960@psf.upfronthosting.co.za>
Message-ID: <1481713780.71.0.773713727677.issue28960@psf.upfronthosting.co.za>


Evan added the comment:

I think the patch should remove the comma, not the double dash. This is a parenthetical remark and should end the same way it starts.

See https://www.grammarly.com/handbook/punctuation/dash/2/dash-parenthetical-information/

----------
nosy: +evan_

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28960>
_______________________________________

From report at bugs.python.org  Wed Dec 14 06:16:07 2016
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 14 Dec 2016 11:16:07 +0000
Subject: [issue26110] Speedup method calls 1.2x
In-Reply-To: <1452791347.05.0.923215900831.issue26110@psf.upfronthosting.co.za>
Message-ID: <1481714167.76.0.736377231548.issue26110@psf.upfronthosting.co.za>


Changes by INADA Naoki <songofacandy at gmail.com>:


Added file: http://bugs.python.org/file45896/callmethod-doc3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26110>
_______________________________________

From report at bugs.python.org  Wed Dec 14 06:36:48 2016
From: report at bugs.python.org (Hans-Peter Jansen)
Date: Wed, 14 Dec 2016 11:36:48 +0000
Subject: [issue28970] ctypes.from_buffer counterpart to actively remove the
 mapping
Message-ID: <1481715408.44.0.569114702165.issue28970@psf.upfronthosting.co.za>


New submission from Hans-Peter Jansen:

In an attempt of using ctypes.from_buffer() to map a structure to a memory mapped file, it is important to destroy the mapping after use, because the mmap won't be resizable or freeable correctly until then.

The best approach, I was able to came up with is using a context manager, but calling the dtor of the mapping in __exit__ is not enough, which results to code like this:

with StructMap(ctypes_struct, mm, offest) as smap:
    smap.xxx = 'blabla'
del smap # necessary, but ugly

Without the del, the "with" variable still exist in the local context, hence the mapping still exist, until it is explicitly destroyed.

I hope, that ctypes is able to (or can be made to) actively remove the mapping in the __exit__ part of the context manager.

I've put some code on stackoverflow to play with this:

http://stackoverflow.com/questions/41077696/python-ctypes-from-buffer-mapping-with-context-manager-into-memory-mapped-file

The problem seems to exist with the linux mmap implementation only.

----------
components: ctypes
messages: 283188
nosy: frispete
priority: normal
severity: normal
status: open
title: ctypes.from_buffer counterpart to actively remove the mapping
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28970>
_______________________________________

From report at bugs.python.org  Wed Dec 14 06:54:14 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 14 Dec 2016 11:54:14 +0000
Subject: [issue28971] nntplib fails on all buildbots
Message-ID: <1481716454.12.0.730668429479.issue28971@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

All the buildbots are currently failing at test_nntplib.
See the errors in attached test_nntplib.log.
The same error messages can be reproduced with a 3.5.2 interpreter:

$ python
Python 3.5.2 (default, Nov  7 2016, 11:31:36)
[GCC 6.2.1 20160830] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from nntplib import NNTP_SSL
>>> s = NNTP_SSL('nntp.aioe.org')
>>> resp, count, first, last, name = s.group('comp.lang.python')
>>> resp, overviews = s.over((last - 1, last))                      # does not fail
>>> resp, overviews = s.over((last - 9, last))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.5/nntplib.py", line 831, in over
    resp, lines = self._longcmdstring(cmd, file)
  File "/usr/lib/python3.5/nntplib.py", line 525, in _longcmdstring
    resp, list = self._getlongresp(file)
  File "/usr/lib/python3.5/nntplib.py", line 494, in _getlongresp
    line = self._getline()
  File "/usr/lib/python3.5/nntplib.py", line 434, in _getline
    raise NNTPDataError('line too long')
nntplib.NNTPDataError: line too long
>>> resp, overviews = s.over((last - 1, last))                      # fails now
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.5/nntplib.py", line 831, in over
    resp, lines = self._longcmdstring(cmd, file)
  File "/usr/lib/python3.5/nntplib.py", line 525, in _longcmdstring
    resp, list = self._getlongresp(file)
  File "/usr/lib/python3.5/nntplib.py", line 476, in _getlongresp
    resp = self._getresp()
  File "/usr/lib/python3.5/nntplib.py", line 458, in _getresp
    raise NNTPProtocolError(resp)
nntplib.NNTPProtocolError: a657tKkPSmKkOzCP9RkpDChwanytHhX4XFYLLMWqmA at mail.gmail.com> <CANc-5UxXPRF3qYKEmnyDdANoN-5GLiRXDrOU6E=R-8N8ZV2UdQ at mail.gmail.com> <CANc-5UwNFgS4aFN5qbwOPNdTMfXrEpJrv4b00_ycGmwAAoK81Q at mail.gmail.com> <CANc-5UyhtmjE9rXwhMBx=H9tBmYARhfzVjw2O=iKDmyEdCpqSA at mail.gmail.com> <CANc-5UyHLP3W8-_D18f8qE-9z0Y-DMbuHRMLpLY10eA52YZMew at mail.gmail.com> <CANc-5UxQA=-9Q=1GPh+5epX9E3KbAgd6Ye_63=kB55aB-MHqow at mail.gmail.com> <CANc-5UwqKjfxrxS0tvSk6r0kRQbr5kiAyCxJhUT8JPfcySSG2A at mail.gmail.com>
<CANc-5Uyj9VnJbVGSepVLLHeCgoB9uAOD61Ft4b=bdLTQJ5dE=A at mail.gmail.com>    10039   25      Xref: aioe.org comp.lang.python:183369

----------
components: Library (Lib)
files: test_nntplib.log
messages: 283189
nosy: xdegaye, zach.ware
priority: normal
severity: normal
status: open
title: nntplib fails on all buildbots
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45897/test_nntplib.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28971>
_______________________________________

From report at bugs.python.org  Wed Dec 14 08:00:03 2016
From: report at bugs.python.org (Miki Tebeka)
Date: Wed, 14 Dec 2016 13:00:03 +0000
Subject: [issue28972] Document all "python -m" utilities
Message-ID: <1481720403.32.0.43245427479.issue28972@psf.upfronthosting.co.za>


New submission from Miki Tebeka:

Several modules can be invoked with -m and are pretty handy (json.tool, zipfile, tarfile ...).

There should be a section in the documentation that groups all of these "python -m" tools together. Something like http://pythonwise.blogspot.nl/2015/01/python-m.html

----------
assignee: docs at python
components: Documentation
messages: 283190
nosy: docs at python, tebeka
priority: normal
severity: normal
status: open
title: Document all "python -m" utilities
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28972>
_______________________________________

From report at bugs.python.org  Wed Dec 14 08:06:07 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Wed, 14 Dec 2016 13:06:07 +0000
Subject: [issue28961] unittest.mock._Call ignores `name` parameter
In-Reply-To: <1481636868.17.0.0411235027553.issue28961@psf.upfronthosting.co.za>
Message-ID: <1481720767.39.0.768432390483.issue28961@psf.upfronthosting.co.za>


Changes by Emanuel Barry <barry at dadadata.net>:


----------
stage: needs patch -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28961>
_______________________________________

From report at bugs.python.org  Wed Dec 14 08:48:47 2016
From: report at bugs.python.org (Ryan)
Date: Wed, 14 Dec 2016 13:48:47 +0000
Subject: [issue28960] Small typo in Thread.join docs
In-Reply-To: <1481636284.79.0.913462681395.issue28960@psf.upfronthosting.co.za>
Message-ID: <1481723327.7.0.140708899319.issue28960@psf.upfronthosting.co.za>


Ryan added the comment:

Removing the comma instead of the double-dash

----------
Added file: http://bugs.python.org/file45898/fixdoc2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28960>
_______________________________________

From report at bugs.python.org  Wed Dec 14 09:38:29 2016
From: report at bugs.python.org (Bernhard10)
Date: Wed, 14 Dec 2016 14:38:29 +0000
Subject: [issue28973] multiprocess.Queue changes objects identity
Message-ID: <1481726309.53.0.886951264774.issue28973@psf.upfronthosting.co.za>


New submission from Bernhard10:

When I did some tests involving unittest.mock.sentinel and multiprocessing.Queue, I noticed that multiprocessing.Queue changes the id of the sentinel.

This behaviour is definitely surprising and not documented.

----------
files: mwe.py
messages: 283192
nosy: Bernhard10
priority: normal
severity: normal
status: open
title: multiprocess.Queue changes objects identity
type: behavior
versions: Python 2.7, Python 3.5
Added file: http://bugs.python.org/file45899/mwe.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28973>
_______________________________________

From report at bugs.python.org  Wed Dec 14 10:05:57 2016
From: report at bugs.python.org (Bernhard10)
Date: Wed, 14 Dec 2016 15:05:57 +0000
Subject: [issue28973] The fact that multiprocess.Queue uses serialization
 should be documented.
In-Reply-To: <1481726309.53.0.886951264774.issue28973@psf.upfronthosting.co.za>
Message-ID: <1481727957.22.0.301936495254.issue28973@psf.upfronthosting.co.za>


Bernhard10 added the comment:

See http://stackoverflow.com/a/925241/5069869

Apparently multiprocessing.Queue uses pickle to serialize the objects in the queue, which explains the change of identity, but is absolutely unclear from the documentation.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
title: multiprocess.Queue changes objects identity -> The fact that multiprocess.Queue uses serialization should be documented.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28973>
_______________________________________

From report at bugs.python.org  Wed Dec 14 10:06:55 2016
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 14 Dec 2016 15:06:55 +0000
Subject: [issue20754] Distribution.parse_config_files uses interpolation since
 Python 3
In-Reply-To: <1393201670.58.0.749043113933.issue20754@psf.upfronthosting.co.za>
Message-ID: <1481728015.66.0.840648951736.issue20754@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

I reviewed the docs for configparser, and I agree - using ConfigParser(interpolation=None) is preferable to the "legacy" RawConfigParser.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20754>
_______________________________________

From report at bugs.python.org  Wed Dec 14 10:12:31 2016
From: report at bugs.python.org (R. David Murray)
Date: Wed, 14 Dec 2016 15:12:31 +0000
Subject: [issue28973] The fact that multiprocess.Queue uses serialization
 should be documented.
In-Reply-To: <1481726309.53.0.886951264774.issue28973@psf.upfronthosting.co.za>
Message-ID: <1481728351.33.0.596160927506.issue28973@psf.upfronthosting.co.za>


R. David Murray added the comment:

That fact that this is so is implicit in the name multi*process*ing and
the documented restrictions of the id function.  That is, it is the purpose of the module is to manage computation across multiple processes.  Since different processes have distinct memory spaces, you cannot depend on object identity between processes, by the definition of object identity (it is constant only for the lifetime of the object in memory, and the different processes have different memory spaces, therefore the object id may be different in the different processes).  By construction this applies also to any multiprocessing mechanism that is used to transmit objects, even if the transmission turns out to be to the same process in a particular case.  You can't *depend* on the id in that case, because the transmission mechanism must be free to change the object identity in order to work in the general case.

Should we document this explicitly?  Perhaps so.  Maybe in the multiprocessing introduction?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28973>
_______________________________________

From report at bugs.python.org  Wed Dec 14 10:13:26 2016
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 14 Dec 2016 15:13:26 +0000
Subject: [issue28949] Stdlib modules disappear from file system
In-Reply-To: <1481553619.84.0.343525103437.issue28949@psf.upfronthosting.co.za>
Message-ID: <1481728406.24.0.184748391122.issue28949@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

I paused the Dropbox sync and ran the `rm -R .tox; tox` routine many times without incident, which strongly implicates Dropbox. I'm going to now re-enable Dropbox sync and see if I can trigger the behavior.

Now even with Dropbox updated back to the latest version (16.3.27) and performing the same operations I was two days ago, I've been unable to elicit the behavior. I've confirmed I still have access to delete those files that were being deleted, but yet I can't trigger the failure. Perhaps whatever environmental thing that happened on Monday was a fluke and I'll go back not to being bothered ever by this condition.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28949>
_______________________________________

From report at bugs.python.org  Wed Dec 14 10:15:03 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Dec 2016 15:15:03 +0000
Subject: [issue28959] Add a macro for dict size
In-Reply-To: <1481634421.56.0.985862767516.issue28959@psf.upfronthosting.co.za>
Message-ID: <1481728503.16.0.0689923475908.issue28959@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I wrote a short script to check the size of dict:
---
import sys

def size(obj):
    print(sys.getsizeof(obj))

size({})
size({i:i for i in range(3)})
size({i:i for i in range(10)})
size({i:i for i in range(100)})
---

On Linux x86_64, the sizes don't change with the patch:

240
240
368
4704

A size increase would be a regression, but it's not the case, so it's fine ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28959>
_______________________________________

From report at bugs.python.org  Wed Dec 14 10:18:24 2016
From: report at bugs.python.org (Bernhard10)
Date: Wed, 14 Dec 2016 15:18:24 +0000
Subject: [issue28973] The fact that multiprocess.Queue uses serialization
 should be documented.
In-Reply-To: <1481726309.53.0.886951264774.issue28973@psf.upfronthosting.co.za>
Message-ID: <1481728704.19.0.189753520296.issue28973@psf.upfronthosting.co.za>


Bernhard10 added the comment:

My first thought was that Queue was implemented using shared memory.
I guess from the fact that the "Shared memory" section is separate in the multiprocessing documentation I should have known better, though.

So I guess some clarification in the documentation would be helpful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28973>
_______________________________________

From report at bugs.python.org  Wed Dec 14 10:24:00 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 14 Dec 2016 15:24:00 +0000
Subject: [issue28971] nntplib fails on all buildbots
In-Reply-To: <1481716454.12.0.730668429479.issue28971@psf.upfronthosting.co.za>
Message-ID: <1481729040.12.0.813112988007.issue28971@psf.upfronthosting.co.za>


Changes by Xavier de Gaye <xdegaye at gmail.com>:


----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28971>
_______________________________________

From report at bugs.python.org  Wed Dec 14 10:37:09 2016
From: report at bugs.python.org (R. David Murray)
Date: Wed, 14 Dec 2016 15:37:09 +0000
Subject: [issue28973] The fact that multiprocess.Queue uses serialization
 should be documented.
In-Reply-To: <1481726309.53.0.886951264774.issue28973@psf.upfronthosting.co.za>
Message-ID: <1481729829.88.0.0506878492473.issue28973@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yeah, that's why I said "in the general case".  Making it clear in the overview seems reasonable to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28973>
_______________________________________

From report at bugs.python.org  Wed Dec 14 10:37:43 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Dec 2016 15:37:43 +0000
Subject: [issue28959] Add a macro for dict size
In-Reply-To: <1481634421.56.0.985862767516.issue28959@psf.upfronthosting.co.za>
Message-ID: <1481729863.32.0.00951496637355.issue28959@psf.upfronthosting.co.za>


STINNER Victor added the comment:

PyDict_GET_SIZE-3.patch: Except of the changes in _datetimemodule.c and typeobject.c on *dictptr type, the patch LGTM. I suggest to open a new issue for these two specific changes, since it changes the behaviour and it's a weird corner case unrelated to this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28959>
_______________________________________

From report at bugs.python.org  Wed Dec 14 10:59:23 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 14 Dec 2016 15:59:23 +0000
Subject: [issue28959] Add a macro for dict size
In-Reply-To: <1481634421.56.0.985862767516.issue28959@psf.upfronthosting.co.za>
Message-ID: <1481731163.41.0.238439427172.issue28959@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I don't think the changes in _datetimemodule.c and typeobject.c change the behavior.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28959>
_______________________________________

From report at bugs.python.org  Wed Dec 14 11:03:44 2016
From: report at bugs.python.org (Ned Deily)
Date: Wed, 14 Dec 2016 16:03:44 +0000
Subject: [issue28963] Use-after-free in _asyncio_Future_remove_done_callback()
 of _asynciomodule.c
In-Reply-To: <1481657201.46.0.37032067172.issue28963@psf.upfronthosting.co.za>
Message-ID: <1481731424.6.0.865089677443.issue28963@psf.upfronthosting.co.za>


Ned Deily added the comment:

This doesn't sound like a showstopper issue so I think it can wait for 3.6.1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28963>
_______________________________________

From report at bugs.python.org  Wed Dec 14 11:04:10 2016
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 14 Dec 2016 16:04:10 +0000
Subject: [issue28963] Use-after-free in _asyncio_Future_remove_done_callback()
 of _asynciomodule.c
In-Reply-To: <1481657201.46.0.37032067172.issue28963@psf.upfronthosting.co.za>
Message-ID: <1481731450.37.0.315032363335.issue28963@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy:  -giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28963>
_______________________________________

From report at bugs.python.org  Wed Dec 14 11:06:05 2016
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 14 Dec 2016 16:06:05 +0000
Subject: [issue20754] Distribution.parse_config_files uses interpolation since
 Python 3
In-Reply-To: <1393201670.58.0.749043113933.issue20754@psf.upfronthosting.co.za>
Message-ID: <1481731565.63.0.0149283132039.issue20754@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

I've created a backport implementation in https://github.com/pypa/setuptools/issues/889.

All that remains then is to have a test for Python, which can probably borrow from the fix for issue20120. I'll leave it to others to draft the patch for the test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20754>
_______________________________________

From report at bugs.python.org  Wed Dec 14 11:08:41 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 14 Dec 2016 16:08:41 +0000
Subject: [issue28959] Add a macro for dict size
In-Reply-To: <1481634421.56.0.985862767516.issue28959@psf.upfronthosting.co.za>
Message-ID: <1481731721.37.0.860145955607.issue28959@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Ignore my previous comment, PyDict_GET_SIZE-3.patch LGTM.


> I don't think the changes in _datetimemodule.c and typeobject.c change the behavior.

Oh wait, it seems like I misunderstood the new code.

Modules/_datetimemodule.c:

         dictptr = _PyObject_GetDictPtr(self);
-        if (dictptr && *dictptr && PyDict_Size(*dictptr)) {
+        if (dictptr && *dictptr &&
+            (!PyDict_Check(*dictptr) || PyDict_GET_SIZE(*dictptr))) {
             state = *dictptr;

If *dictptr is set and is not a dict, the test is true for the old and new code. Hum, I misunderstood the new code: I understood that (!PyDict_Check(*dictptr) || PyDict_GET_SIZE(*dictptr)) is false is *dictptr is not a dict, but it's true.

Hum, the only difference is that the old code raises an exception (SystemError), the new code doesn't raise an exception.

Since I'm not able to create an object with a __dict__ attribute which is not a dict, I don't really case of the small behaviour change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28959>
_______________________________________

From report at bugs.python.org  Wed Dec 14 11:20:59 2016
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 14 Dec 2016 16:20:59 +0000
Subject: [issue28971] nntplib fails on all buildbots
In-Reply-To: <1481716454.12.0.730668429479.issue28971@psf.upfronthosting.co.za>
Message-ID: <1481732459.92.0.915709840782.issue28971@psf.upfronthosting.co.za>


Zachary Ware added the comment:

This appears to have been a transient failure; all builders are passing a forced build.  I'm no expert on nntplib, but I'm not sure there's much we can do here beyond replacing the outside connection with a mock server.  That pretty much defeats the purpose of the tests, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28971>
_______________________________________

From report at bugs.python.org  Wed Dec 14 11:33:49 2016
From: report at bugs.python.org (Davin Potts)
Date: Wed, 14 Dec 2016 16:33:49 +0000
Subject: [issue28973] The fact that multiprocess.Queue uses serialization
 should be documented.
In-Reply-To: <1481726309.53.0.886951264774.issue28973@psf.upfronthosting.co.za>
Message-ID: <1481733229.41.0.0510367613957.issue28973@psf.upfronthosting.co.za>


Davin Potts added the comment:

All communication between processes in multiprocessing has consistently used pickle to serialize the data being communicated (this includes what is described in the "Shared memory" section of the docs).  The documentation has not done a great job of making this clear, instead only describing the requirement that data be pickleable in select places.  For example, in the section on Queues:
    Note: When an object is put on a queue, the object is pickled and a
    background thread later flushes the pickled data to an underlying pipe.

Though it only applies to 3.6+, issue28053 still needs its own documentation improvement to make clear that the mechanism for communicating data defaults to serialization by pickle but that this can be replaced by alternatives.

I agree that the documentation around the use of pickle in multiprocessing deserves improvement.

----------
nosy: +davin
stage:  -> needs patch
type: behavior -> enhancement
versions: +Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28973>
_______________________________________

From report at bugs.python.org  Wed Dec 14 11:34:44 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 14 Dec 2016 16:34:44 +0000
Subject: [issue28971] nntplib fails on all buildbots
In-Reply-To: <1481716454.12.0.730668429479.issue28971@psf.upfronthosting.co.za>
Message-ID: <1481733284.12.0.367853262606.issue28971@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

The problem is when getting an overview of the following comp.lang.python mail:
    OT - "Soft" ESC key on the new MacBook Pro   Michael Torrie
    Tue Dec 13 21:33:07 EST 2016

This is at index (last - 16) now and that is why the buildbots do not fail anymore.
The response received from the server for this mail in the _getline() function is 2058 bytes long and _getline() raises NNTPDataError because this is greater than _MAXLINE (2048). Setting _MAXLINE to 4096 fixes the problem.

There remains to explain the failures in the other tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28971>
_______________________________________

From report at bugs.python.org  Wed Dec 14 11:44:03 2016
From: report at bugs.python.org (Davin Potts)
Date: Wed, 14 Dec 2016 16:44:03 +0000
Subject: [issue28965] Multiprocessing spawn/forkserver fails to pass Queues
In-Reply-To: <1481676708.34.0.90034781132.issue28965@psf.upfronthosting.co.za>
Message-ID: <1481733843.49.0.429579735684.issue28965@psf.upfronthosting.co.za>


Changes by Davin Potts <python at discontinuity.net>:


----------
nosy: +davin
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28965>
_______________________________________

From report at bugs.python.org  Wed Dec 14 11:57:47 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 14 Dec 2016 16:57:47 +0000
Subject: [issue28971] nntplib fails on all buildbots
In-Reply-To: <1481716454.12.0.730668429479.issue28971@psf.upfronthosting.co.za>
Message-ID: <1481734667.66.0.871422303534.issue28971@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

BTW while searching for this problem, I found that there were three other mails raising this same  NNTPDataError('line too long') in the 40 last mails.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28971>
_______________________________________

From report at bugs.python.org  Wed Dec 14 12:57:20 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 14 Dec 2016 17:57:20 +0000
Subject: [issue5322] Python 2.6 object.__new__ argument calling autodetection
 faulty
In-Reply-To: <1235075665.37.0.301694124748.issue5322@psf.upfronthosting.co.za>
Message-ID: <20161214175714.9667.55639.A6C2AC04@psf.io>


Roundup Robot added the comment:

New changeset f89ef18f9824 by Serhiy Storchaka in branch '2.7':
Issue #5322: Restored tests for __new__.
https://hg.python.org/cpython/rev/f89ef18f9824

New changeset 06e4b9f2e4b0 by Serhiy Storchaka in branch '3.5':
Revert changeset 1f31bf3f76f5 (issue5322) except tests.
https://hg.python.org/cpython/rev/06e4b9f2e4b0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5322>
_______________________________________

From report at bugs.python.org  Wed Dec 14 12:58:15 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 14 Dec 2016 17:58:15 +0000
Subject: [issue5322] Python 2.6 object.__new__ argument calling autodetection
 faulty
In-Reply-To: <1235075665.37.0.301694124748.issue5322@psf.upfronthosting.co.za>
Message-ID: <1481738295.29.0.494569566584.issue5322@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
priority: release blocker -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5322>
_______________________________________

From report at bugs.python.org  Wed Dec 14 13:32:58 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Wed, 14 Dec 2016 18:32:58 +0000
Subject: [issue14156] argparse.FileType for '-' doesn't work for a mode of 'rb'
In-Reply-To: <1330513271.31.0.437438851478.issue14156@psf.upfronthosting.co.za>
Message-ID: <1481740378.79.0.668837069555.issue14156@psf.upfronthosting.co.za>


Aviv Palivoda added the comment:

Hi paul thanks for looking into this. First are you sure this is a bug in python 2? If so I will happily port this patch once it is reviewed.
As for use cases you may look at issue #26488. Although the patch was rejected you can see that I first used argparse.FileType and moved it because of this issue. I can't prove this patch is free of backward's compatibility issue's but there are tests now which should help to avoid problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14156>
_______________________________________

From report at bugs.python.org  Wed Dec 14 13:47:47 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 14 Dec 2016 18:47:47 +0000
Subject: [issue28871] Destructor of ElementTree.Element is recursive
In-Reply-To: <1480892604.34.0.360751620771.issue28871@psf.upfronthosting.co.za>
Message-ID: <1481741267.03.0.844588551109.issue28871@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Proposed patch fixes the crash.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file45900/etree-trashcan.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28871>
_______________________________________

From report at bugs.python.org  Wed Dec 14 13:53:20 2016
From: report at bugs.python.org (Louis Riviere)
Date: Wed, 14 Dec 2016 18:53:20 +0000
Subject: [issue7434] general pprint rewrite
In-Reply-To: <1259944363.21.0.149882342014.issue7434@psf.upfronthosting.co.za>
Message-ID: <1481741600.5.0.84967710466.issue7434@psf.upfronthosting.co.za>


Louis Riviere added the comment:

I've made a Pretty Printer and I'd like to know if anybody thinks it could of some help here. (I do)

It's easily extensible and customizable to support any type in any way. 

https://github.com/louis-riviere-xyz/prettypy.git

----------
nosy: +dugres

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7434>
_______________________________________

From report at bugs.python.org  Wed Dec 14 14:10:41 2016
From: report at bugs.python.org (paul j3)
Date: Wed, 14 Dec 2016 19:10:41 +0000
Subject: [issue14156] argparse.FileType for '-' doesn't work for a mode of 'rb'
In-Reply-To: <1330513271.31.0.437438851478.issue14156@psf.upfronthosting.co.za>
Message-ID: <1481742641.86.0.211507266272.issue14156@psf.upfronthosting.co.za>


paul j3 added the comment:

The problem with Python2.7 is that 'open' does not take 'closefd', or any of the other parameters that were added for Python3.

    open(name[, mode[, buffering]])

'rb' may make a difference on Py2 on Windows, but I haven't done any work in the environment in a long time.

I wasn't aware of that other issue.  Some core Python developers have participated in that one.  I suspect a lot of the discussion is beyond my level of expertise.

I once wrote that I thought 'FileType' was included primarily as an example of a 'type' factory.  Something users could copy and extend for their own use.  Bethard corrected me, saying that it was meant for quick-n-dirty script uses, ones with an input file, output file and a few options.  In a bigger scripts, the users are encouraged to open/close files in 'with' contexts.

See http://bugs.python.org/issue22884 and the issues I reference there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14156>
_______________________________________

From report at bugs.python.org  Wed Dec 14 14:24:08 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 14 Dec 2016 19:24:08 +0000
Subject: [issue28683] bind() on a unix socket raises PermissionError on
 Android for a non-root user
In-Reply-To: <1479065524.08.0.12999801833.issue28683@psf.upfronthosting.co.za>
Message-ID: <1481743448.47.0.552751174267.issue28683@psf.upfronthosting.co.za>


Changes by Xavier de Gaye <xdegaye at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28683>
_______________________________________

From report at bugs.python.org  Wed Dec 14 14:38:34 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 14 Dec 2016 19:38:34 +0000
Subject: [issue28849] do not define sys.implementation._multiarch on Android
In-Reply-To: <1480579567.9.0.848858013461.issue28849@psf.upfronthosting.co.za>
Message-ID: <20161214193830.79670.89714.1F3FDE07@psf.io>


Roundup Robot added the comment:

New changeset ab3d870aa3bc by Xavier de Gaye in branch '3.6':
Issue #28849: Skip test_sysconfig.test_triplet_in_ext_suffix on non linux platforms.
https://hg.python.org/cpython/rev/ab3d870aa3bc

New changeset 0ff181ca7558 by Xavier de Gaye in branch 'default':
Issue #28849: Merge 3.6.
https://hg.python.org/cpython/rev/0ff181ca7558

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28849>
_______________________________________

From report at bugs.python.org  Wed Dec 14 14:57:54 2016
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 14 Dec 2016 19:57:54 +0000
Subject: [issue25458] ftplib: command response shift - mismatch
In-Reply-To: <1445510152.74.0.829316001802.issue25458@psf.upfronthosting.co.za>
Message-ID: <1481745474.18.0.908823611911.issue25458@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

Maybe it's me but I still fail to understand what's the issue here. From what I understand from the last message(s) it seems there is complaint about not being able to use ftplib with threads.
FTP is a "command - response" protocol which is designed to handle one request at a time, meaning you send a command then you are supposed to *wait* to get a response back. 
If you want to do multiple transfers in parallel then you need a separate connection, not a separate thread using the same connection.
ftplib should *not* be thread-safe because of how FTP works.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25458>
_______________________________________

From report at bugs.python.org  Wed Dec 14 15:00:53 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Wed, 14 Dec 2016 20:00:53 +0000
Subject: [issue14156] argparse.FileType for '-' doesn't work for a mode of 'rb'
In-Reply-To: <1330513271.31.0.437438851478.issue14156@psf.upfronthosting.co.za>
Message-ID: <1481745653.19.0.835449240523.issue14156@psf.upfronthosting.co.za>


Aviv Palivoda added the comment:

As we talk here about stdin and stdout which we don't want to close I think this issue is irrelevant to python2. In any case the patch in issue #13824 cover that problem.
I actually write a lot of small scripts and if I need to open the file in binary mode I don't use FileType because of this issue.
Any way I think this discussion is irrelevant because it does not seem like any core developer is currently working on argparse.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14156>
_______________________________________

From report at bugs.python.org  Wed Dec 14 15:30:50 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 14 Dec 2016 20:30:50 +0000
Subject: [issue18896] Remove namedtuple 255 arguments restriction
In-Reply-To: <1377972310.66.0.567176219008.issue18896@psf.upfronthosting.co.za>
Message-ID: <1481747450.59.0.535100924251.issue18896@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18896>
_______________________________________

From report at bugs.python.org  Wed Dec 14 15:49:26 2016
From: report at bugs.python.org (Ivan Pozdeev)
Date: Wed, 14 Dec 2016 20:49:26 +0000
Subject: [issue25458] ftplib: command response shift - mismatch
In-Reply-To: <1445510152.74.0.829316001802.issue25458@psf.upfronthosting.co.za>
Message-ID: <1481748566.65.0.691044551766.issue25458@psf.upfronthosting.co.za>


Ivan Pozdeev added the comment:

* The initial msg253326 has a code snippet using ftplib directly and showing the error.
* The linked issue28931 has another snippet that uses ftplib through urllib and results in the same error.

There isn't a single mention of "thread" in either.
Could you just run either of them and see for yourself?

I can rub your nose in it, but I thought you're better than that :)

Oh well...

C:\Ivan>python
Python 2.7.12 (v2.7.12:d33e0cf91556, Jun 27 2016, 15:19:22) [MSC v.1500 32 bit Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import ftplib
>>> ftp = ftplib.FTP()
>>> ftp.connect('ftp.debian.org', timeout=10)
'220 ftp.debian.org FTP server'
>>> ftp.login('anonymous','user at example.com')
'230 Login successful.'
>>> ftp.sendcmd('TYPE A')
'200 Switching to ASCII mode.'
>>> s = ftp.transfercmd('LIST')
>>> fp = s.makefile('r')
>>> fp.read()
'drwxr-xr-x    9 1176     1176         4096 Dec 14 15:08 debian\r\n'
>>> fp.close()
>>> s.close()
>>> # Now the session is broken:
...
>>> ftp.sendcmd('NOOP')
'226 Directory send OK.'
>>> ftp.dir()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Py\lib\ftplib.py", line 534, in dir
    self.retrlines(cmd, func)
  File "C:\Py\lib\ftplib.py", line 437, in retrlines
    conn = self.transfercmd(cmd)
  File "C:\Py\lib\ftplib.py", line 376, in transfercmd
    return self.ntransfercmd(cmd, rest)[0]
  File "C:\Py\lib\ftplib.py", line 334, in ntransfercmd
    host, port = self.makepasv()
  File "C:\Py\lib\ftplib.py", line 312, in makepasv
    host, port = parse227(self.sendcmd('PASV'))
  File "C:\Py\lib\ftplib.py", line 830, in parse227
    raise error_reply, resp
ftplib.error_reply: 200 Switching to ASCII mode.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25458>
_______________________________________

From report at bugs.python.org  Wed Dec 14 16:12:14 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 14 Dec 2016 21:12:14 +0000
Subject: [issue28971] nntplib is broken when responses are longer than _MAXLINE
In-Reply-To: <1481716454.12.0.730668429479.issue28971@psf.upfronthosting.co.za>
Message-ID: <1481749934.8.0.541056489056.issue28971@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

When the server sends a line longer than _MAXLINE, nntplib reads only _MAXLINE + 1 bytes leaving the remaining bytes left to be processed by the next command that will interpret those bytes as a protocol error. Hence the failing tests that follow the first NNTPDataError exception in the failing test_nntplib.

The patch increases _MAXLINE from 2048 to 4096 and fixes the above problem. It also takes care to read up to (and including) the terminator so that the following lines or the terminator is not interpreted as a protocol error by the next nntp command.

The patch does not include a test case.

----------
keywords: +patch
stage:  -> patch review
title: nntplib fails on all buildbots -> nntplib is broken when responses are longer than _MAXLINE
versions: +Python 2.7
Added file: http://bugs.python.org/file45901/nntplib_maxline.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28971>
_______________________________________

From report at bugs.python.org  Wed Dec 14 16:16:58 2016
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 14 Dec 2016 21:16:58 +0000
Subject: [issue28931] urllib ignores FTP 226 response,
 breaking further FTP requests
In-Reply-To: <1481381673.54.0.845583442328.issue28931@psf.upfronthosting.co.za>
Message-ID: <1481750218.69.0.689474000189.issue28931@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

I can't reproduce the issue on Python 3.5 (but I can on 2.7).

----------
nosy: +giampaolo.rodola
versions:  -Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28931>
_______________________________________

From report at bugs.python.org  Wed Dec 14 16:52:10 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 14 Dec 2016 21:52:10 +0000
Subject: [issue28974] Make default __format__ be equivalent to __str__
Message-ID: <1481752330.56.0.847513688639.issue28974@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Originally PEP 3101 defined the default __format__ implementation, object.__format__ as

     def __format__(self, format_spec):
         return format(str(self), format_spec)

After few changes (issue7994, issue28385) it now looks as

     def __format__(self, format_spec):
         assert format_spec == ''
         return format(str(self), '')

Proposed patch makes it yet simpler:

     def __format__(self, format_spec):
         assert format_spec == ''
         return str(self)

This is equivalent to the previous form except obscure case when str() returns not exact str, but strict subclass with overridden __format__.

The benefit of this change is simpler semantical model of the default implementation.

See the start of the discussion in issue28385 and the discussion on Python-Dev: https://mail.python.org/pipermail/python-dev/2016-October/146765.html.

----------
components: Interpreter Core
files: simpler-object-__format__.patch
keywords: patch
messages: 283220
nosy: eric.smith, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Make default __format__ be equivalent to __str__
type: enhancement
versions: Python 3.7
Added file: http://bugs.python.org/file45902/simpler-object-__format__.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28974>
_______________________________________

From report at bugs.python.org  Wed Dec 14 17:08:39 2016
From: report at bugs.python.org (Colin David Chen)
Date: Wed, 14 Dec 2016 22:08:39 +0000
Subject: [issue28975] os.walk generator vs
Message-ID: <1481753319.18.0.913748060881.issue28975@psf.upfronthosting.co.za>


New submission from Colin David Chen:

os.walk in 3.6rc1 (Windows) appears to generate different output depending on its invocation.

In the first invocation, I use the generator to yield one result at a time:
source = "C:\\cdchen_data\\downloads\\python-xlib-0.18\\"
texasranger = os.walk(Path(source))
roottree = [next(texasranger)]
roottree[0][0]
Output:
'C:\\cdchen_data\\downloads\\python-xlib-0.18'

The same result occurs when using the generator in a for loop.

In the second invocation, I generate the complete list first:
sourcetree = [x for x in os.walk(source)]
sourcetree[0][0]

Output:
'C:\\cdchen_data\\downloads\\python-xlib-0.18\\'

The particular behavior causing me trouble is the omission in the first result of the final '\\'. I checked in 2.7.6 and os.walk is consistent and I believe more correct in that it will yield equivalent results and includes the '\\'.

Not sure if earlier Python 3 implementations have this problem, I couldn't get 3.5 to run this function without failing.

----------
components: Library (Lib)
messages: 283221
nosy: Colin David Chen
priority: normal
severity: normal
status: open
title: os.walk generator vs
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28975>
_______________________________________

From report at bugs.python.org  Wed Dec 14 17:09:03 2016
From: report at bugs.python.org (Colin David Chen)
Date: Wed, 14 Dec 2016 22:09:03 +0000
Subject: [issue28975] os.walk generator giving inconsistent results
In-Reply-To: <1481753319.18.0.913748060881.issue28975@psf.upfronthosting.co.za>
Message-ID: <1481753343.12.0.501212897639.issue28975@psf.upfronthosting.co.za>


Changes by Colin David Chen <madduffy at gmail.com>:


----------
title: os.walk generator vs -> os.walk generator giving inconsistent results

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28975>
_______________________________________

From report at bugs.python.org  Wed Dec 14 17:15:26 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 14 Dec 2016 22:15:26 +0000
Subject: [issue28975] os.walk generator giving inconsistent results
In-Reply-To: <1481753319.18.0.913748060881.issue28975@psf.upfronthosting.co.za>
Message-ID: <1481753726.32.0.249688474198.issue28975@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Isn't the difference that you use os.walk(Path(source)) in the first example, and os.walk(source) in the second one?

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28975>
_______________________________________

From report at bugs.python.org  Wed Dec 14 17:19:52 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 14 Dec 2016 22:19:52 +0000
Subject: [issue28975] os.walk generator giving inconsistent results
In-Reply-To: <1481753319.18.0.913748060881.issue28975@psf.upfronthosting.co.za>
Message-ID: <1481753992.47.0.489002173072.issue28975@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Assuming Path is pathlib.Path, this is equivalent to the difference between:

>>> list(os.walk('/tmp'))
[('/tmp', <other-stuff ...>

and:
>>> list(os.walk('/tmp/'))
[('/tmp/', <other-stuff ...> 

Because:
>>> pathlib.Path('/tmp')
PosixPath('/tmp')
>>> pathlib.Path('/tmp/')
PosixPath('/tmp')

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28975>
_______________________________________

From report at bugs.python.org  Wed Dec 14 17:32:36 2016
From: report at bugs.python.org (Colin David Chen)
Date: Wed, 14 Dec 2016 22:32:36 +0000
Subject: [issue28975] os.walk generator giving inconsistent results
In-Reply-To: <1481753319.18.0.913748060881.issue28975@psf.upfronthosting.co.za>
Message-ID: <1481754756.44.0.471025093435.issue28975@psf.upfronthosting.co.za>


Colin David Chen added the comment:

Ah, you're correct. The behavior is consistent if you use strings in both invocations. The Path conversion strips the final '\\'. Doc examples do use the names of directories rather than a Path object.

I will close the issue. Thanks for the quick response!

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28975>
_______________________________________

From report at bugs.python.org  Wed Dec 14 17:48:22 2016
From: report at bugs.python.org (Ivan Pozdeev)
Date: Wed, 14 Dec 2016 22:48:22 +0000
Subject: [issue25458] ftplib: command response shift - mismatch
In-Reply-To: <1445510152.74.0.829316001802.issue25458@psf.upfronthosting.co.za>
Message-ID: <1481755702.77.0.791921505569.issue25458@psf.upfronthosting.co.za>


Ivan Pozdeev added the comment:

Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:01:18) [MSC v.1900 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import ftplib
<...>
>>> ftp.sendcmd('NOOP')
'226 Directory send OK.'

There are no changes in and `ntransfercmd' between 2.7 and default branches save for cosmetic ones.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25458>
_______________________________________

From report at bugs.python.org  Wed Dec 14 18:05:12 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 14 Dec 2016 23:05:12 +0000
Subject: [issue28971] nntplib is broken when responses are longer than _MAXLINE
In-Reply-To: <1481716454.12.0.730668429479.issue28971@psf.upfronthosting.co.za>
Message-ID: <1481756712.58.0.187859733426.issue28971@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

> I found that there were three other mails raising this same  NNTPDataError('line too long') in the 40 last mails.

Cannot reproduce it. These three exceptions must have been NNTPProtocolError instead, caused by the initial NNTPDataError.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28971>
_______________________________________

From report at bugs.python.org  Wed Dec 14 21:20:55 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 15 Dec 2016 02:20:55 +0000
Subject: [issue28919] Simplify `_copy_func_details` in unittest.mock
In-Reply-To: <1481577539.0.0.478814731257.issue28919@psf.upfronthosting.co.za>
Message-ID: <20161215022051.1766.95475.82783502@psf.io>


Roundup Robot added the comment:

New changeset bbdfde7958a8 by Berker Peksag in branch 'default':
Issue #28919: Simplify _copy_func_details() in unittest.mock
https://hg.python.org/cpython/rev/bbdfde7958a8

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28919>
_______________________________________

From report at bugs.python.org  Wed Dec 14 21:22:01 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 15 Dec 2016 02:22:01 +0000
Subject: [issue28919] Simplify `_copy_func_details` in unittest.mock
In-Reply-To: <1481577539.0.0.478814731257.issue28919@psf.upfronthosting.co.za>
Message-ID: <1481768521.23.0.300722310722.issue28919@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks, Jiajun!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28919>
_______________________________________

From report at bugs.python.org  Wed Dec 14 21:37:57 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 15 Dec 2016 02:37:57 +0000
Subject: [issue28944] A lack of line 6
In-Reply-To: <1481544628.07.0.0933253462311.issue28944@psf.upfronthosting.co.za>
Message-ID: <20161215023753.5114.22277.0FDFFEB5@psf.io>


Roundup Robot added the comment:

New changeset a89469328b78 by Berker Peksag in branch '3.5':
Issue #28944: Fix footnote numbering
https://hg.python.org/cpython/rev/a89469328b78

New changeset 502f5d53fb4a by Berker Peksag in branch '3.6':
Issue #28944: Merge from 3.5
https://hg.python.org/cpython/rev/502f5d53fb4a

New changeset 13b600dc4ee5 by Berker Peksag in branch 'default':
Issue #28944: Merge from 3.6
https://hg.python.org/cpython/rev/13b600dc4ee5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28944>
_______________________________________

From report at bugs.python.org  Wed Dec 14 21:38:41 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 15 Dec 2016 02:38:41 +0000
Subject: [issue28944] A lack of line 6
In-Reply-To: <1481544628.07.0.0933253462311.issue28944@psf.upfronthosting.co.za>
Message-ID: <1481769521.97.0.681095595246.issue28944@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the report, woo woo.

----------
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type:  -> behavior
versions: +Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28944>
_______________________________________

From report at bugs.python.org  Wed Dec 14 21:46:46 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 15 Dec 2016 02:46:46 +0000
Subject: [issue28961] unittest.mock._Call ignores `name` parameter
In-Reply-To: <1481636868.17.0.0411235027553.issue28961@psf.upfronthosting.co.za>
Message-ID: <1481770006.63.0.91580043919.issue28961@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, Jiajun. The _Call class is tested in CallTest (located in Lib/unittest/test/testmock/testhelpers.py) Would it be possible to add a test case to make sure that we actually fixed the bug?

----------
nosy: +berker.peksag
stage: commit review -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28961>
_______________________________________

From report at bugs.python.org  Wed Dec 14 21:49:32 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 15 Dec 2016 02:49:32 +0000
Subject: [issue28954] Incorrect EBNF rule of keywords_arguments
In-Reply-To: <1481595766.74.0.577639992265.issue28954@psf.upfronthosting.co.za>
Message-ID: <1481770172.74.0.621568512925.issue28954@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28954>
_______________________________________

From report at bugs.python.org  Wed Dec 14 22:24:55 2016
From: report at bugs.python.org (woo yoo)
Date: Thu, 15 Dec 2016 03:24:55 +0000
Subject: [issue28976] incorrect description that dose not conform to the
 actual behavior
Message-ID: <1481772295.45.0.836170310477.issue28976@psf.upfronthosting.co.za>


New submission from woo yoo:

The paragraph that describes the precedence of semicolon encounters a minor error, which said :
"Also note that the semicolon binds tighter than the colon in this context, so that in the following example, either all or none of the print() calls are executed:
if x < y < z: print(x); print(y); print(z)" 
However,the series of print function calls could execute partly if the previous ones are legal.

----------
assignee: docs at python
components: Documentation
messages: 283232
nosy: docs at python, woo yoo
priority: normal
severity: normal
status: open
title: incorrect description that dose not conform to the actual behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28976>
_______________________________________

From report at bugs.python.org  Wed Dec 14 22:26:17 2016
From: report at bugs.python.org (woo yoo)
Date: Thu, 15 Dec 2016 03:26:17 +0000
Subject: [issue28976] incorrect description that dose not conform to the
 actual behavior
In-Reply-To: <1481772295.45.0.836170310477.issue28976@psf.upfronthosting.co.za>
Message-ID: <1481772377.01.0.547239394992.issue28976@psf.upfronthosting.co.za>


woo yoo added the comment:

Forget to attach the link https://docs.python.org/3/reference/compound_stmts.html#compound-statements

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28976>
_______________________________________

From report at bugs.python.org  Wed Dec 14 22:39:20 2016
From: report at bugs.python.org (Eric Appelt)
Date: Thu, 15 Dec 2016 03:39:20 +0000
Subject: [issue28091] Document PEP 525
In-Reply-To: <1480969186.28.0.879526881588.issue28091@psf.upfronthosting.co.za>
Message-ID: <1481773160.8.0.971565927329.issue28091@psf.upfronthosting.co.za>


Eric Appelt added the comment:

Thanks for the explanations and example code in the review! Working on this issue is really helping to improve my understanding of a number of tricky things like finalization.

I *think* that I have all the comments implemented in the attached patch.

I also removed a spurious 2-line fragment at the top of the Asynchronous generator-iterator methods section that I had neglected to delete and escaped review.

----------
Added file: http://bugs.python.org/file45903/pep525_pep530_docs_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28091>
_______________________________________

From report at bugs.python.org  Wed Dec 14 22:40:52 2016
From: report at bugs.python.org (Jiajun Huang)
Date: Thu, 15 Dec 2016 03:40:52 +0000
Subject: [issue28961] unittest.mock._Call ignores `name` parameter
In-Reply-To: <1481636868.17.0.0411235027553.issue28961@psf.upfronthosting.co.za>
Message-ID: <1481773252.14.0.64782758389.issue28961@psf.upfronthosting.co.za>


Jiajun Huang added the comment:

I think we can write `_Call.__new__` as:

def __new__(cls, value=(), name='',...)

it's much simpler and readable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28961>
_______________________________________

From report at bugs.python.org  Wed Dec 14 23:07:39 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 15 Dec 2016 04:07:39 +0000
Subject: [issue28971] nntplib is broken when responses are longer than _MAXLINE
In-Reply-To: <1481716454.12.0.730668429479.issue28971@psf.upfronthosting.co.za>
Message-ID: <1481774859.38.0.00949870244615.issue28971@psf.upfronthosting.co.za>


Martin Panter added the comment:

Just a quick note for the moment: It may not be wise to drop the limit to readline(). That is undoing Issue 16040. Maybe we need a better test if this change doesn't fail the test suite.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28971>
_______________________________________

From report at bugs.python.org  Wed Dec 14 23:55:54 2016
From: report at bugs.python.org (Mariatta Wijaya)
Date: Thu, 15 Dec 2016 04:55:54 +0000
Subject: [issue28941] Update the link to Source Code in Python Docs from hg to
 github
In-Reply-To: <1481513819.65.0.156579360966.issue28941@psf.upfronthosting.co.za>
Message-ID: <1481777754.93.0.0800021825104.issue28941@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

Attached is the patch that will work for 3.6 and 3.7 branches.

The url will be changed from
https://hg.python.org/cpython/file/3.6/Lib/abc.py

into 
https://github.com/python/cpython/blob/3.6/Lib/abc.py for python version 3.6,
and 
https://github.com/python/cpython/blob/master/Lib/abc.py for python version 3.7

----------
keywords: +patch
Added file: http://bugs.python.org/file45904/issue28941.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28941>
_______________________________________

From report at bugs.python.org  Wed Dec 14 23:57:22 2016
From: report at bugs.python.org (Mariatta Wijaya)
Date: Thu, 15 Dec 2016 04:57:22 +0000
Subject: [issue28941] Update the link to Source Code in Python Docs from hg to
 github
In-Reply-To: <1481513819.65.0.156579360966.issue28941@psf.upfronthosting.co.za>
Message-ID: <1481777842.39.0.875338602085.issue28941@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

Patch for 3.5 branch.

The url will change from
https://hg.python.org/cpython/file/3.5/Lib/abc.py

into
https://github.com/python/cpython/blob/3.5/Lib/abc.py

----------
Added file: http://bugs.python.org/file45905/issue28941v35.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28941>
_______________________________________

From report at bugs.python.org  Wed Dec 14 23:58:16 2016
From: report at bugs.python.org (Mariatta Wijaya)
Date: Thu, 15 Dec 2016 04:58:16 +0000
Subject: [issue28941] Update the link to Source Code in Python Docs from hg to
 github
In-Reply-To: <1481513819.65.0.156579360966.issue28941@psf.upfronthosting.co.za>
Message-ID: <1481777896.82.0.219383807835.issue28941@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

Patch for 2.7 branch.

The url will change from
https://hg.python.org/cpython/file/2.7/Lib/abc.py

into
https://github.com/python/cpython/blob/2.7/Lib/abc.py

----------
Added file: http://bugs.python.org/file45906/issue28941v27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28941>
_______________________________________

From report at bugs.python.org  Wed Dec 14 23:59:38 2016
From: report at bugs.python.org (Mariatta Wijaya)
Date: Thu, 15 Dec 2016 04:59:38 +0000
Subject: [issue28941] Update the link to Source Code in Python Docs from hg to
 github
In-Reply-To: <1481513819.65.0.156579360966.issue28941@psf.upfronthosting.co.za>
Message-ID: <1481777978.74.0.0819177388511.issue28941@psf.upfronthosting.co.za>


Mariatta Wijaya added the comment:

Please let me know if I'm doing this right :) Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28941>
_______________________________________

From report at bugs.python.org  Thu Dec 15 00:13:53 2016
From: report at bugs.python.org (Ivan Pozdeev)
Date: Thu, 15 Dec 2016 05:13:53 +0000
Subject: [issue28931] urllib ignores FTP 226 response,
 breaking further FTP requests
In-Reply-To: <1481381673.54.0.845583442328.issue28931@psf.upfronthosting.co.za>
Message-ID: <1481778833.22.0.329701668299.issue28931@psf.upfronthosting.co.za>


Ivan Pozdeev added the comment:

Was fixed in c741ba9e37ef (3.2) . urllib gets around the ftplib issue by closing the session after each transfer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28931>
_______________________________________

From report at bugs.python.org  Thu Dec 15 00:19:41 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 15 Dec 2016 05:19:41 +0000
Subject: [issue18896] Remove namedtuple 255 arguments restriction
In-Reply-To: <1377972310.66.0.567176219008.issue18896@psf.upfronthosting.co.za>
Message-ID: <1481779181.67.0.914596924686.issue18896@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Thanks.  The patch looks good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18896>
_______________________________________

From report at bugs.python.org  Thu Dec 15 01:07:36 2016
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 15 Dec 2016 06:07:36 +0000
Subject: [issue5322] Python 2.6 object.__new__ argument calling autodetection
 faulty
In-Reply-To: <1235075665.37.0.301694124748.issue5322@psf.upfronthosting.co.za>
Message-ID: <1481782056.17.0.15918904996.issue5322@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

BTW, at least for #25731, I think the right approach in the MI case is to synthesize a __new__ on the subclass that calls the solid base __new__.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5322>
_______________________________________

From report at bugs.python.org  Thu Dec 15 01:12:40 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Dec 2016 06:12:40 +0000
Subject: [issue28971] nntplib is broken when responses are longer than _MAXLINE
In-Reply-To: <1481716454.12.0.730668429479.issue28971@psf.upfronthosting.co.za>
Message-ID: <1481782360.53.0.538153457303.issue28971@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +christian.heimes, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28971>
_______________________________________

From report at bugs.python.org  Thu Dec 15 01:15:51 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 15 Dec 2016 06:15:51 +0000
Subject: [issue28180] sys.getfilesystemencoding() should default to utf-8
In-Reply-To: <1474024622.65.0.838685461995.issue28180@psf.upfronthosting.co.za>
Message-ID: <1481782551.86.0.000124657269767.issue28180@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Downstream Fedora issue proposing the above idea for F26: https://bugzilla.redhat.com/show_bug.cgi?id=1404918

I've also attached the patch from that issue here.

----------
keywords: +patch
Added file: http://bugs.python.org/file45907/fedora-cpython-force-c-utf-8.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28180>
_______________________________________

From report at bugs.python.org  Thu Dec 15 01:21:03 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Dec 2016 06:21:03 +0000
Subject: [issue5322] Python 2.6 object.__new__ argument calling autodetection
 faulty
In-Reply-To: <1235075665.37.0.301694124748.issue5322@psf.upfronthosting.co.za>
Message-ID: <1481782863.31.0.137504514999.issue5322@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Yes, it was what the patch did by setting tp_new to slot_tp_new. The problem is that the same code is used for inherited __new__ and assigned in class body. It is hard to distinguish between these cases.

In any case I think that Cython shouldn't generate trivial __new__. This will help to change the order of __new__ resolution at least in 3.7.

----------
nosy: +scoder

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5322>
_______________________________________

From report at bugs.python.org  Thu Dec 15 01:54:13 2016
From: report at bugs.python.org (Wenzel Jakob)
Date: Thu, 15 Dec 2016 06:54:13 +0000
Subject: [issue28147] Unbounded memory growth resizing split-table dicts
In-Reply-To: <1473853453.13.0.556951743271.issue28147@psf.upfronthosting.co.za>
Message-ID: <1481784852.99.0.914293419999.issue28147@psf.upfronthosting.co.za>


Wenzel Jakob added the comment:

Hi,

pybind11 (https://github.com/pybind/pybind11) dev here.

We're seeing massive memory increases due to this bug, which completely break our test suite (and likely any use of this library, which is commonly used to bind C++ code to Python).

Please look at the following issue ticket:

https://github.com/pybind/pybind11/issues/558

where RSS goes to 43MB to 4.3GB for the basic set of tests. The fancy fancy test suite which also covers NumPy/SciPy can't even be run anymore. All issues disappear when the dict patch listed here is applied.

We're really concerned that this is not slated to be fixed for 3.6.0. Pybind11 is not doing anything particularly special with dicts -- if this is hitting us, others will likely have issues as well.

-Wenzel

----------
nosy: +wenzel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28147>
_______________________________________

From report at bugs.python.org  Thu Dec 15 02:04:07 2016
From: report at bugs.python.org (Manish Singh)
Date: Thu, 15 Dec 2016 07:04:07 +0000
Subject: [issue28968] xml rpc server fails with connection reset by peer error
 no 104
In-Reply-To: <1481709223.17.0.559234955094.issue28968@psf.upfronthosting.co.za>
Message-ID: <1481785447.41.0.178947650255.issue28968@psf.upfronthosting.co.za>


Manish Singh added the comment:

Hi loewis,

Can you please look into this issue

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28968>
_______________________________________

From report at bugs.python.org  Thu Dec 15 02:05:52 2016
From: report at bugs.python.org (Manish Singh)
Date: Thu, 15 Dec 2016 07:05:52 +0000
Subject: [issue28968] xml rpc server fails with connection reset by peer error
 no 104
In-Reply-To: <1481709223.17.0.559234955094.issue28968@psf.upfronthosting.co.za>
Message-ID: <1481785552.73.0.574858451095.issue28968@psf.upfronthosting.co.za>


Changes by Manish Singh <manish.ciem at gmail.com>:


----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28968>
_______________________________________

From report at bugs.python.org  Thu Dec 15 02:30:10 2016
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 15 Dec 2016 07:30:10 +0000
Subject: [issue28689] OpenSSL 1.1.0c test failures
In-Reply-To: <1479132647.76.0.450425015981.issue28689@psf.upfronthosting.co.za>
Message-ID: <1481787010.76.0.965561335055.issue28689@psf.upfronthosting.co.za>


Matthias Klose added the comment:

Fyi, Debian's 1.1.0c is fixed, so please don't blacklist this version in general.

----------
nosy: +doko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28689>
_______________________________________

From report at bugs.python.org  Thu Dec 15 02:42:40 2016
From: report at bugs.python.org (Andreas Stenberg)
Date: Thu, 15 Dec 2016 07:42:40 +0000
Subject: [issue7434] general pprint rewrite
In-Reply-To: <1259944363.21.0.149882342014.issue7434@psf.upfronthosting.co.za>
Message-ID: <1481787760.96.0.281961484127.issue7434@psf.upfronthosting.co.za>


Changes by Andreas Stenberg <andreas at stenite.com>:


----------
nosy: +astenberg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7434>
_______________________________________

From report at bugs.python.org  Thu Dec 15 03:03:01 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Dec 2016 08:03:01 +0000
Subject: [issue28924] Inline PyEval_EvalFrameEx() in callers
In-Reply-To: <1481306450.73.0.124326033178.issue28924@psf.upfronthosting.co.za>
Message-ID: <1481788981.54.0.907801261417.issue28924@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> It may break other debuggers like Python Tools for Visual Studio, though (+steve.dower for that).

Do you mean debuggers expecting that bytecode is run in PyEval_EvalFrameEx() rather than PyEval_EvalFrameDefault()? Can't we fix these debuggers?


> IMHO, inlining is best left to profiling optimizers.

The problem is that PGO compilation is not used by everyone yet. The patch is a minor enhancement to make sure that regular builds are also fast.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28924>
_______________________________________

From report at bugs.python.org  Thu Dec 15 03:09:39 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 15 Dec 2016 08:09:39 +0000
Subject: [issue28920] Dangerous usage of "O" format string in _asynciomodule.c
In-Reply-To: <1481290693.49.0.157975678284.issue28920@psf.upfronthosting.co.za>
Message-ID: <20161215080936.26558.49066.C7D25335@psf.io>


Roundup Robot added the comment:

New changeset f2745b64d8b7 by Victor Stinner in branch '3.6':
_asyncio uses _PyObject_CallMethodIdObjArgs()
https://hg.python.org/cpython/rev/f2745b64d8b7

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28920>
_______________________________________

From report at bugs.python.org  Thu Dec 15 03:10:13 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Dec 2016 08:10:13 +0000
Subject: [issue28920] Dangerous usage of "O" format string in _asynciomodule.c
In-Reply-To: <1481290693.49.0.157975678284.issue28920@psf.upfronthosting.co.za>
Message-ID: <1481789413.47.0.31806056724.issue28920@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28920>
_______________________________________

From report at bugs.python.org  Thu Dec 15 03:15:28 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 15 Dec 2016 08:15:28 +0000
Subject: [issue28838] Using consistent naming for arguments of "call"
 functions (C API)
In-Reply-To: <1480504437.73.0.907175245586.issue28838@psf.upfronthosting.co.za>
Message-ID: <20161215081525.1475.69101.8099CFA0@psf.io>


Roundup Robot added the comment:

New changeset 654ec6ed3225 by Victor Stinner in branch 'default':
Issue #28838: Cleanup abstract.h
https://hg.python.org/cpython/rev/654ec6ed3225

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28838>
_______________________________________

From report at bugs.python.org  Thu Dec 15 03:27:23 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Dec 2016 08:27:23 +0000
Subject: [issue28924] Inline PyEval_EvalFrameEx() in callers
In-Reply-To: <1481306450.73.0.124326033178.issue28924@psf.upfronthosting.co.za>
Message-ID: <1481790443.85.0.223891357726.issue28924@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

May be just replace inlined call with _PyEval_EvalFrameDefault?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28924>
_______________________________________

From report at bugs.python.org  Thu Dec 15 03:28:41 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Dec 2016 08:28:41 +0000
Subject: [issue28924] Inline PyEval_EvalFrameEx() in callers
In-Reply-To: <1481306450.73.0.124326033178.issue28924@psf.upfronthosting.co.za>
Message-ID: <1481790521.37.0.441080020853.issue28924@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Serhiy: "May be just replace inlined call with _PyEval_EvalFrameDefault?"

Do you mean replacing PyEval_EvalFrameEx() with _PyEval_EvalFrameDefault()? It would defeat the purpose of the PEP 523, no?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28924>
_______________________________________

From report at bugs.python.org  Thu Dec 15 03:28:54 2016
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 15 Dec 2016 08:28:54 +0000
Subject: [issue23971] dict(list) and dict.fromkeys() doesn't account for 2/3
 fill ratio
In-Reply-To: <1429140944.27.0.450320519696.issue23971@psf.upfronthosting.co.za>
Message-ID: <1481790534.74.0.25000367495.issue23971@psf.upfronthosting.co.za>


INADA Naoki added the comment:

> Fixed fromkeys() in Py2.7.  Stills needs to be forward ported to 3.4/3.5.

dict.fromkeys() is fixed already in 3.6+.

dict(l) doesn't presize the dict.  If it's desirable, let's create a new issue.

----------
nosy: +inada.naoki
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23971>
_______________________________________

From report at bugs.python.org  Thu Dec 15 03:29:04 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Dec 2016 08:29:04 +0000
Subject: [issue28838] Using consistent naming for arguments of "call"
 functions (C API)
In-Reply-To: <1480504437.73.0.907175245586.issue28838@psf.upfronthosting.co.za>
Message-ID: <1481790544.4.0.127102641847.issue28838@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Victor, it would be worth to discuss this change on Python-Dev.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28838>
_______________________________________

From report at bugs.python.org  Thu Dec 15 03:36:01 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Dec 2016 08:36:01 +0000
Subject: [issue28977] Document PyObject_CallFunction() special case more
 explicitly
Message-ID: <1481790961.1.0.0700086912401.issue28977@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The PyObject_CallFunction() function has a special case if the format string is "O". See my email thread on python-dev:
https://mail.python.org/pipermail/python-dev/2016-December/146919.html

Serhiy wrote: "It is documented for Py_BuildValue(), and the documentation of PyObject_CallFunction() refers to Py_BuildValue()." which is true, but I would prefer to be more explicit to avoid bad surprises (see issues #21209 and #28920).

Attached patch modifies PyObject_CallFunction() doc to mention the "O" format special case in the .rst doc and the .h comment.

The documentation of PyObject_CallMethod() and _PyObject_CallMethodId() should also be modified, but I would prefer to wait for a first review on the added text before modifying all functions.

I proposed to only modify Python 3.7 because Include/abstract.h was a in a bad shape: I rewrote this file to make it easier to maintain, but only in Python 3.7, see issue #28838.

----------
assignee: docs at python
components: Documentation, Interpreter Core
files: call_doc.patch
keywords: patch
messages: 283256
nosy: docs at python, haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Document PyObject_CallFunction() special case more explicitly
versions: Python 3.7
Added file: http://bugs.python.org/file45908/call_doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28977>
_______________________________________

From report at bugs.python.org  Thu Dec 15 03:37:58 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Dec 2016 08:37:58 +0000
Subject: [issue28838] Using consistent naming for arguments of "call"
 functions (C API)
In-Reply-To: <1480504437.73.0.907175245586.issue28838@psf.upfronthosting.co.za>
Message-ID: <1481791078.4.0.121969963526.issue28838@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I pushed cleanup-2.patch (after a minor rebase). Sorry for breaking "hg annotation" on Include/abstract.h: I hope that it will be less annoying that the giant "replace tabs with space" made by Antoine Pitrou a few years ago which modified almost all .c and .h files (my change only changes a single file, abstract.h). If you have large pending patch series which modify this file, ping me, I will help you to rebase them.

Sorry, I didn't expect this issue to be so painful. I hope that abstract.h is now more readable, easier to maintain (no more surprising indentation!), and have better comments. I now started to cleanup the documentation of functions of the "PyObject_Call() family": see my first issue #28977. I think that we should then synchronize .rst doc and .h comments to make them consistent again (and maybe update the doc).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28838>
_______________________________________

From report at bugs.python.org  Thu Dec 15 03:40:35 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Dec 2016 08:40:35 +0000
Subject: [issue28924] Inline PyEval_EvalFrameEx() in callers
In-Reply-To: <1481306450.73.0.124326033178.issue28924@psf.upfronthosting.co.za>
Message-ID: <1481791235.34.0.0480653532145.issue28924@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Ah, now I see. I was confused by the fact that eval_frame is set only to _PyEval_EvalFrameDefault.

But how large the gain of inlining PyEval_EvalFrameEx()? Is it worth cluttering the code?

Since almost all calls of PyEval_EvalFrameEx() are in the same file as its definition, I suppose the compiler can inline it even without PGO.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28924>
_______________________________________

From report at bugs.python.org  Thu Dec 15 03:41:37 2016
From: report at bugs.python.org (Ned Deily)
Date: Thu, 15 Dec 2016 08:41:37 +0000
Subject: [issue28147] Unbounded memory growth resizing split-table dicts
In-Reply-To: <1473853453.13.0.556951743271.issue28147@psf.upfronthosting.co.za>
Message-ID: <1481791297.34.0.942215325617.issue28147@psf.upfronthosting.co.za>


Ned Deily added the comment:

It appears this issue has stalled again.  Is the most recent patch fix28147-py36-2.patch) ready for review?  If so, can someone please review it?  Then it needs to be pushed to the 3.6 branch for 3.6.1 and exposed to the buildbots.  Only then could we consider cherrypicking for 3.6.0 and a change of the magnitude in the patch would require at least another preview release and delay 3.6.0 final. 3.6.0 is scheduled to be released tomorrow. I am very reluctant to delay now for an issue that has been open now for 3 months throughout the beta phase of the release cycle.  If enough people feel we should delay 3.6.0 to address this, we can.  But without a fix reviewed and committed and without more feedback from other core developers, 3.6.0 is going out without it.  @inada.naoki ? @haypo ? @serhiy.storchaka ?  Others?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28147>
_______________________________________

From report at bugs.python.org  Thu Dec 15 03:54:54 2016
From: report at bugs.python.org (Ned Deily)
Date: Thu, 15 Dec 2016 08:54:54 +0000
Subject: [issue28967] copy.copy fails on threading.local subclass
In-Reply-To: <1481695788.41.0.793591769474.issue28967@psf.upfronthosting.co.za>
Message-ID: <1481792094.58.0.0108146397311.issue28967@psf.upfronthosting.co.za>


Ned Deily added the comment:

Thanks for raising the issue, Jelle.  And thanks for the analysis, Serhiy.  It doesn't sound like a release blocker for 3.6.0.  Is it worth addressing at all?

----------
assignee: ned.deily -> 
priority: release blocker -> normal
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28967>
_______________________________________

From report at bugs.python.org  Thu Dec 15 04:08:10 2016
From: report at bugs.python.org (Ned Deily)
Date: Thu, 15 Dec 2016 09:08:10 +0000
Subject: [issue28147] Unbounded memory growth resizing split-table dicts
In-Reply-To: <1473853453.13.0.556951743271.issue28147@psf.upfronthosting.co.za>
Message-ID: <1481792890.23.0.481770596778.issue28147@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
priority: high -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28147>
_______________________________________

From report at bugs.python.org  Thu Dec 15 04:09:51 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 15 Dec 2016 09:09:51 +0000
Subject: [issue28971] nntplib is broken when responses are longer than _MAXLINE
In-Reply-To: <1481716454.12.0.730668429479.issue28971@psf.upfronthosting.co.za>
Message-ID: <1481792991.67.0.546996586076.issue28971@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

The patch:
1) Increases _MAXLINE to 4096.
2) Reverts issue 16040 and that is not correct, please ignore that part.

The changes made in issue 16040 limit the amount of data read by readline() and does not close the nntp session when the server sends a message whose size is greater than this limit. In that case, should not nntplib close the session as the session has become unusable as shown by the test_nntplib results in test_nntplib.log?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28971>
_______________________________________

From report at bugs.python.org  Thu Dec 15 04:15:47 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 15 Dec 2016 09:15:47 +0000
Subject: [issue28930] bytes_methods.c won't recompile if related stringlib/*
 changed
In-Reply-To: <1481350832.04.0.902172752525.issue28930@psf.upfronthosting.co.za>
Message-ID: <20161215091544.24219.70282.6EE6032D@psf.io>


Roundup Robot added the comment:

New changeset 56a7eb5a0679 by Xiang Zhang in branch '3.6':
Issue #28930: Add a Makefile rule for bytes_methods.c.
https://hg.python.org/cpython/rev/56a7eb5a0679

New changeset c4bcca326c0a by Xiang Zhang in branch 'default':
Issue #28930: Merge from 3.6.
https://hg.python.org/cpython/rev/c4bcca326c0a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28930>
_______________________________________

From report at bugs.python.org  Thu Dec 15 04:17:05 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Dec 2016 09:17:05 +0000
Subject: [issue28924] Inline PyEval_EvalFrameEx() in callers
In-Reply-To: <1481306450.73.0.124326033178.issue28924@psf.upfronthosting.co.za>
Message-ID: <1481793425.53.0.93976785317.issue28924@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Serhiy: "Since almost all calls of PyEval_EvalFrameEx() are in the same file as its definition, I suppose the compiler can inline it even without PGO."

Let me check. My patch changes gen_send_ex() of genobject.c and _PyEval_EvalCodeWithName() of ceval.c. "gcc -O3" is able to inline PyEval_EvalFrameEx() in the same file (ceval.c), but not in a different file (genobject.c).

My patch also avoids an useless call to PyThreadState_GET()... Well, I'm not sure that it's worth it. I propose the change because the indirection now looks completely useless to me, but I didn't expect that it could break anything. With my patch, python-gdb.py is fixed. Steve says that Visual Studio is already fixed as well. So I don't know, it's up to you ;-)

--

gen_send_ex().

C code:
188	    gen->gi_running = 1;
189	    result = PyEval_EvalFrameEx(f, exc);
190	    gen->gi_running = 0;

x86_64 assembler (gcc -03):
=> 0x000000000047fe37 <gen_iternext+103>:	movb   $0x1,0x18(%rbp)
   0x000000000047fe3b <gen_iternext+107>:	callq  0x54b870 <PyEval_EvalFrameEx>
   0x000000000047fe40 <gen_iternext+112>:	movb   $0x0,0x18(%rbp)
   0x000000000047fe44 <gen_iternext+116>:	mov    %rax,%r12
   0x000000000047fe47 <gen_iternext+119>:	mov    0x18(%rbx),%rdi

I still see the call to PyEval_EvalFrameEx().

--

_PyEval_EvalCodeWithName().

C code:
4169        retval = PyEval_EvalFrameEx(f,0);

x86_64 assembler (gcc -03):
=> 0x000000000054ae30 <+2544>:  mov    0x3827f9(%rip),%rax        # 0x8cd630 <_PyThreadState_Current>
   0x000000000054ae37 <+2551>:  xor    %esi,%esi
   0x000000000054ae39 <+2553>:  mov    0x40(%rsp),%rdi
   0x000000000054ae3e <+2558>:  mov    0x10(%rax),%rax
   0x000000000054ae42 <+2562>:  callq  *0x70(%rax)

In this file, PyEval_EvalFrameEx() is inlined. I understand that the first instruction is the PyThreadState_GET() call which is an atomic read (single x86 instruction). My patch avoids the useless PyThreadState_GET(), since tstate must not change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28924>
_______________________________________

From report at bugs.python.org  Thu Dec 15 04:18:41 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 15 Dec 2016 09:18:41 +0000
Subject: [issue28930] bytes_methods.c won't recompile if related stringlib/*
 changed
In-Reply-To: <1481350832.04.0.902172752525.issue28930@psf.upfronthosting.co.za>
Message-ID: <1481793521.58.0.493520442719.issue28930@psf.upfronthosting.co.za>


Changes by Xiang Zhang <angwerzx at 126.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28930>
_______________________________________

From report at bugs.python.org  Thu Dec 15 04:23:57 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Dec 2016 09:23:57 +0000
Subject: [issue28147] Unbounded memory growth resizing split-table dicts
In-Reply-To: <1473853453.13.0.556951743271.issue28147@psf.upfronthosting.co.za>
Message-ID: <1481793836.99.0.376305124536.issue28147@psf.upfronthosting.co.za>


STINNER Victor added the comment:

fix28147-py36-2.patch: test_dict pass with DEBUG_PYDICT defined.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28147>
_______________________________________

From report at bugs.python.org  Thu Dec 15 04:24:30 2016
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 15 Dec 2016 09:24:30 +0000
Subject: [issue11322] encoding package's normalize_encoding() function is
 too	slow
In-Reply-To: <1298649332.11.0.637901441206.issue11322@psf.upfronthosting.co.za>
Message-ID: <1481793870.11.0.639433282729.issue11322@psf.upfronthosting.co.za>


Changes by INADA Naoki <songofacandy at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file45909/encoding_normalize_optimize.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11322>
_______________________________________

From report at bugs.python.org  Thu Dec 15 04:27:10 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 15 Dec 2016 09:27:10 +0000
Subject: [issue11322] encoding package's normalize_encoding() function is
 too	slow
In-Reply-To: <1298649332.11.0.637901441206.issue11322@psf.upfronthosting.co.za>
Message-ID: <1481794030.92.0.562004845768.issue11322@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11322>
_______________________________________

From report at bugs.python.org  Thu Dec 15 04:29:10 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Dec 2016 09:29:10 +0000
Subject: [issue28971] nntplib is broken when responses are longer than _MAXLINE
In-Reply-To: <1481716454.12.0.730668429479.issue28971@psf.upfronthosting.co.za>
Message-ID: <1481794150.95.0.148209654803.issue28971@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

It seems to me there are two issues:

1) The limit of line length is not large enough.
2) After raising an error on too long line the NNTP object is left in broken state.

The first issue can be solved by increasing the default limit or by patching the nntp module in tests.

For the second issue I suggest to open new tracker issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28971>
_______________________________________

From report at bugs.python.org  Thu Dec 15 04:34:52 2016
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 15 Dec 2016 09:34:52 +0000
Subject: [issue11322] encoding package's normalize_encoding() function is
 too	slow
In-Reply-To: <1298649332.11.0.637901441206.issue11322@psf.upfronthosting.co.za>
Message-ID: <1481794492.95.0.291422032392.issue11322@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

Thanks for the patch.

Victor has implemented the function in C, AFAIK, so an even better approach would be to expose that function at the Python level and use it in the encodings package.

----------
versions: +Python 3.7 -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11322>
_______________________________________

From report at bugs.python.org  Thu Dec 15 04:35:10 2016
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 15 Dec 2016 09:35:10 +0000
Subject: [issue28147] Unbounded memory growth resizing split-table dicts
In-Reply-To: <1473853453.13.0.556951743271.issue28147@psf.upfronthosting.co.za>
Message-ID: <1481794510.39.0.520683149175.issue28147@psf.upfronthosting.co.za>


Changes by INADA Naoki <songofacandy at gmail.com>:


Added file: http://bugs.python.org/file45910/fix28147-py36-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28147>
_______________________________________

From report at bugs.python.org  Thu Dec 15 04:36:05 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Dec 2016 09:36:05 +0000
Subject: [issue28147] Unbounded memory growth resizing split-table dicts
In-Reply-To: <1473853453.13.0.556951743271.issue28147@psf.upfronthosting.co.za>
Message-ID: <1481794565.3.0.648051802037.issue28147@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I reviewed fix28147-py36-2.patch, I have some requests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28147>
_______________________________________

From report at bugs.python.org  Thu Dec 15 04:40:18 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Dec 2016 09:40:18 +0000
Subject: [issue28147] Unbounded memory growth resizing split-table dicts
In-Reply-To: <1473853453.13.0.556951743271.issue28147@psf.upfronthosting.co.za>
Message-ID: <1481794818.61.0.678841398421.issue28147@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Ned: "If so, can someone please review it?"

Done.


Ned: "I am very reluctant to delay now for an issue that has been open now for 3 months throughout the beta phase of the release cycle.  If enough people feel we should delay 3.6.0 to address this, we can."

The bug was seen as minor and I didn't expect that anyone would notice it.

Wenzel Jakob wrote "RSS goes to 43MB to 4.3GB": for me, it's a major regression, and it's not possible to work around it. With such bug, Python 3.6 is unusable on such application (pybind11). I easily imagine that such memory leak is a blocker issue for a server running for days.

I now consider that Python 3.6.0 must not be released with such blocker issue.

----------
nosy: +larry
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28147>
_______________________________________

From report at bugs.python.org  Thu Dec 15 04:41:29 2016
From: report at bugs.python.org (Brendan Donegan)
Date: Thu, 15 Dec 2016 09:41:29 +0000
Subject: [issue28976] incorrect description that dose not conform to the
 actual behavior
In-Reply-To: <1481772295.45.0.836170310477.issue28976@psf.upfronthosting.co.za>
Message-ID: <1481794889.72.0.24160212185.issue28976@psf.upfronthosting.co.za>


Brendan Donegan added the comment:

Can you provide a code snippet that demonstrates the actual problem? As far as I can see this code behaves as documented

----------
nosy: +brendan-donegan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28976>
_______________________________________

From report at bugs.python.org  Thu Dec 15 04:42:47 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Dec 2016 09:42:47 +0000
Subject: [issue28147] Unbounded memory growth resizing split-table dicts
In-Reply-To: <1473853453.13.0.556951743271.issue28147@psf.upfronthosting.co.za>
Message-ID: <1481794967.11.0.957769187673.issue28147@psf.upfronthosting.co.za>


STINNER Victor added the comment:

fix28147-py36-3.patch LGTM: Naoki, please push it right now.

But please see also my comments on fix28147-py36-2.patch: I would still apprecicate that we enhance the comment in dictobject.c. The comment is not a blocker issue for 3.6.0, it can be enhanced later :-D

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28147>
_______________________________________

From report at bugs.python.org  Thu Dec 15 04:53:01 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Dec 2016 09:53:01 +0000
Subject: [issue11322] encoding package's normalize_encoding() function is
 too	slow
In-Reply-To: <1298649332.11.0.637901441206.issue11322@psf.upfronthosting.co.za>
Message-ID: <1481795581.59.0.160043064791.issue11322@psf.upfronthosting.co.za>


STINNER Victor added the comment:

It seems like encodings.normalize_encoding() currently has no unit test! Before modifying it, I would prefer to see a few unit tests:

* " utf 8 "
* "UtF 8"
* "utf8\xE9"
* etc.

Since we are talking about an optimmization, I would like to see a benchmark result before/after. I also would like to test Marc-Andre's idea of exposing the C function _Py_normalize_encoding().

_Py_normalize_encoding() works on a byte string encoded to Latin1. To implement encodings.normalize_encoding(), we might rewrite the function to work on Py_UCS4 character, or have a fast version on char*, and a more generic version for UCS2 and UCS4?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11322>
_______________________________________

From report at bugs.python.org  Thu Dec 15 05:00:56 2016
From: report at bugs.python.org (Raoul Gough)
Date: Thu, 15 Dec 2016 10:00:56 +0000
Subject: [issue28925] Confusing exception from cPickle on reduce failure
In-Reply-To: <1481307076.91.0.720116511602.issue28925@psf.upfronthosting.co.za>
Message-ID: <1481796056.19.0.415850604798.issue28925@psf.upfronthosting.co.za>


Raoul Gough added the comment:

Hi Serhiy, thanks very much for looking at this. My only concern with removing the code completely is that it does work (presumably as intended) with at least some of the standard exception types. For example, if you change the demo to raise and catch a RuntimeError instead of MyException, the output looks like this:

INFO:root:Creating BadReduce object
INFO:root:Pickling
INFO:root:Unpickling
INFO:root:Raising exception "BadReduce init failed"
INFO:root:Got RuntimeError "(RuntimeError('BadReduce init failed',), <class '__main__.BadReduce'>, (1123,))"
INFO:root:Done

Where the caught RuntimeError contains the original RuntimeError and some additional information from cPickle.

I also checked that it correctly propagates KeyboardInterrupt by testing manually with a sleep:

INFO:root:Creating BadReduce object
INFO:root:Pickling
INFO:root:Unpickling
INFO:root:Sleeping a while - send keyboard interrupt to test
  C-c C-cTraceback (most recent call last):
  File "/home/zk8ms03/python/cpickle_reduce_failure.py", line 49, in <module>
    main()
  File "/home/zk8ms03/python/cpickle_reduce_failure.py", line 42, in main
    pickler.loads(s1)
  File "/home/zk8ms03/python/cpickle_reduce_failure.py", line 28, in __init__
    time.sleep(5.0)
KeyboardInterrupt: (None, <class '__main__.BadReduce'>, (1123,))


I'm not sure how likely it is that anyone depends on the extra information that cPickle adds in these cases, so I'll leave it up to others to decide what's best.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28925>
_______________________________________

From report at bugs.python.org  Thu Dec 15 05:03:08 2016
From: report at bugs.python.org (woo yoo)
Date: Thu, 15 Dec 2016 10:03:08 +0000
Subject: [issue28976] incorrect description that dose not conform to the
 actual behavior
In-Reply-To: <1481772295.45.0.836170310477.issue28976@psf.upfronthosting.co.za>
Message-ID: <1481796188.95.0.691464598818.issue28976@psf.upfronthosting.co.za>


woo yoo added the comment:

code :
>>> if 1<2<3:print(123);print(op);

Output:
123
Traceback (most recent call last):
.... 
NameError:...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28976>
_______________________________________

From report at bugs.python.org  Thu Dec 15 05:08:03 2016
From: report at bugs.python.org (Brendan Donegan)
Date: Thu, 15 Dec 2016 10:08:03 +0000
Subject: [issue28976] incorrect description that dose not conform to the
 actual behavior
In-Reply-To: <1481772295.45.0.836170310477.issue28976@psf.upfronthosting.co.za>
Message-ID: <1481796483.22.0.275203667989.issue28976@psf.upfronthosting.co.za>


Brendan Donegan added the comment:

How does that contradict the documentation? Both print statements were executed - the second one raised an exception because of 'op' not being defined.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28976>
_______________________________________

From report at bugs.python.org  Thu Dec 15 05:12:22 2016
From: report at bugs.python.org (Maciej Szulik)
Date: Thu, 15 Dec 2016 10:12:22 +0000
Subject: [issue28879] smtplib send_message should add Date header if it is
 missing, per RFC5322
In-Reply-To: <1480952895.22.0.418354723664.issue28879@psf.upfronthosting.co.za>
Message-ID: <1481796742.49.0.579983589931.issue28879@psf.upfronthosting.co.za>


Maciej Szulik added the comment:

I tend to agree with Eric Lafontaine, looking at the quote Henning von Bargen posted the originator address field is also required, but yet we don't explicitly check its presence in the code, but rely on the SMTP server to error out.

----------
nosy: +maciej.szulik

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28879>
_______________________________________

From report at bugs.python.org  Thu Dec 15 05:21:20 2016
From: report at bugs.python.org (woo yoo)
Date: Thu, 15 Dec 2016 10:21:20 +0000
Subject: [issue28976] incorrect description that dose not conform to the
 actual behavior
In-Reply-To: <1481772295.45.0.836170310477.issue28976@psf.upfronthosting.co.za>
Message-ID: <1481797280.02.0.894140192682.issue28976@psf.upfronthosting.co.za>


woo yoo added the comment:

code :
>>> if 1<2<3:print(123);print(op);print(opi);

Output:
123
Traceback (most recent call last):
.... 
NameError:name 'op' is not defined

The third 'print' call hasn't been executed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28976>
_______________________________________

From report at bugs.python.org  Thu Dec 15 05:23:12 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Dec 2016 10:23:12 +0000
Subject: [issue28838] Using consistent naming for arguments of "call"
 functions (C API)
In-Reply-To: <1480504437.73.0.907175245586.issue28838@psf.upfronthosting.co.za>
Message-ID: <1481797392.95.0.490266608315.issue28838@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Serhiy: "Victor, it would be worth to discuss this change on Python-Dev."

Done: https://mail.python.org/pipermail/python-dev/2016-December/146999.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28838>
_______________________________________

From report at bugs.python.org  Thu Dec 15 05:33:46 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Dec 2016 10:33:46 +0000
Subject: [issue28925] Confusing exception from cPickle on reduce failure
In-Reply-To: <1481307076.91.0.720116511602.issue28925@psf.upfronthosting.co.za>
Message-ID: <1481798026.31.0.287641936889.issue28925@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Perhaps it was added for debugging. Exceptions that don't define own __new__ and __init__ inherit them from BaseException. BaseException constructor saves positional arguments as the args attribute. But not all standard exceptions accept arbitrary number of positional arguments. For example UnicodeEncodeError and UnicodeDecodeError don't work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28925>
_______________________________________

From report at bugs.python.org  Thu Dec 15 05:36:25 2016
From: report at bugs.python.org (Peter Otten)
Date: Thu, 15 Dec 2016 10:36:25 +0000
Subject: [issue28969] fnmatch is not threadsafe
In-Reply-To: <1481712564.52.0.530922236321.issue28969@psf.upfronthosting.co.za>
Message-ID: <1481798185.65.0.892419002483.issue28969@psf.upfronthosting.co.za>


Peter Otten added the comment:

Here's another way to reproduce the error. The problem seems to be in the C implementation of _lru_cache_wrapper() / bounded_lru_cache_wrapper().

$ cat test.py
import functools
import threading
import time

@functools.lru_cache(maxsize=2)
def f(v):
    time.sleep(.01)

threads = [threading.Thread(target=f, args=(v,)) for v in [1,2,2,3,2]]
for t in threads:
    t.start()

$ ./python test.py
Exception in thread Thread-5:
Traceback (most recent call last):
  File "/somewhere/Lib/threading.py", line 916, in _bootstrap_inner
    self.run()
  File "/somewhere/Lib/threading.py", line 864, in run
    self._target(*self._args, **self._kwargs)
KeyError: (2,)

$ ./python
Python 3.7.0a0 (default:654ec6ed3225+, Dec 15 2016, 11:24:30) 
[GCC 4.8.4] on linux

----------
nosy: +peter.otten, rhettinger, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28969>
_______________________________________

From report at bugs.python.org  Thu Dec 15 05:37:09 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Thu, 15 Dec 2016 10:37:09 +0000
Subject: [issue27400] Datetime NoneType after calling Py_Finalize and
 Py_Initialize
In-Reply-To: <1467035358.55.0.678180807375.issue27400@psf.upfronthosting.co.za>
Message-ID: <1481798229.19.0.71577615009.issue27400@psf.upfronthosting.co.za>


Changes by Chi Hsuan Yen <yan12125 at gmail.com>:


----------
nosy: +Chi Hsuan Yen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27400>
_______________________________________

From report at bugs.python.org  Thu Dec 15 05:38:54 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Dec 2016 10:38:54 +0000
Subject: [issue28838] Using consistent naming for arguments of "call"
 functions (C API)
In-Reply-To: <1481797392.95.0.490266608315.issue28838@psf.upfronthosting.co.za>
Message-ID: <13982029.i9YWoE9HyT@raxxla>


Serhiy Storchaka added the comment:

Thanks Victor.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28838>
_______________________________________

From report at bugs.python.org  Thu Dec 15 05:55:29 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Dec 2016 10:55:29 +0000
Subject: [issue28969] fnmatch is not threadsafe
In-Reply-To: <1481712564.52.0.530922236321.issue28969@psf.upfronthosting.co.za>
Message-ID: <1481799329.03.0.183900676473.issue28969@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
assignee:  -> serhiy.storchaka
keywords: +3.5regression
stage:  -> needs patch
versions: +Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28969>
_______________________________________

From report at bugs.python.org  Thu Dec 15 05:56:00 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 15 Dec 2016 10:56:00 +0000
Subject: [issue28925] Confusing exception from cPickle on reduce failure
In-Reply-To: <1481307076.91.0.720116511602.issue28925@psf.upfronthosting.co.za>
Message-ID: <20161215105557.1986.70679.B45B6B18@psf.io>


Roundup Robot added the comment:

New changeset eb830f1511ef by Serhiy Storchaka in branch '2.7':
Issue #28925: cPickle now correctly propagates errors when unpickle instances
https://hg.python.org/cpython/rev/eb830f1511ef

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28925>
_______________________________________

From report at bugs.python.org  Thu Dec 15 06:07:28 2016
From: report at bugs.python.org (Brendan Donegan)
Date: Thu, 15 Dec 2016 11:07:28 +0000
Subject: [issue28976] incorrect description that dose not conform to the
 actual behavior
In-Reply-To: <1481772295.45.0.836170310477.issue28976@psf.upfronthosting.co.za>
Message-ID: <1481800048.09.0.167492405171.issue28976@psf.upfronthosting.co.za>


Brendan Donegan added the comment:

Indeed, but that's merely because an exception has been raised. The example given doesn't include any statements that would raise an exception.

I'm not sure it's necessary to re-iterate well known Python behaviour in this section.

Anyway, that's my 2c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28976>
_______________________________________

From report at bugs.python.org  Thu Dec 15 06:08:25 2016
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 15 Dec 2016 11:08:25 +0000
Subject: [issue28147] Unbounded memory growth resizing split-table dicts
In-Reply-To: <1473853453.13.0.556951743271.issue28147@psf.upfronthosting.co.za>
Message-ID: <1481800105.87.0.484335226921.issue28147@psf.upfronthosting.co.za>


INADA Naoki added the comment:

This patch updates the comment.

----------
Added file: http://bugs.python.org/file45911/fix28147-comment-update.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28147>
_______________________________________

From report at bugs.python.org  Thu Dec 15 06:12:33 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Dec 2016 11:12:33 +0000
Subject: [issue28969] lru_cache is not threadsafe
In-Reply-To: <1481712564.52.0.530922236321.issue28969@psf.upfronthosting.co.za>
Message-ID: <1481800353.27.0.833000337811.issue28969@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
title: fnmatch is not threadsafe -> lru_cache is not threadsafe

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28969>
_______________________________________

From report at bugs.python.org  Thu Dec 15 06:17:59 2016
From: report at bugs.python.org (woo yoo)
Date: Thu, 15 Dec 2016 11:17:59 +0000
Subject: [issue28976] incorrect description that dose not conform to the
 actual behavior
In-Reply-To: <1481772295.45.0.836170310477.issue28976@psf.upfronthosting.co.za>
Message-ID: <1481800679.54.0.534873128382.issue28976@psf.upfronthosting.co.za>


woo yoo added the comment:

Thanks for your attention.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28976>
_______________________________________

From report at bugs.python.org  Thu Dec 15 06:41:11 2016
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 15 Dec 2016 11:41:11 +0000
Subject: [issue28689] OpenSSL 1.1.0c test failures
In-Reply-To: <1479132647.76.0.450425015981.issue28689@psf.upfronthosting.co.za>
Message-ID: <1481802071.73.0.453865519322.issue28689@psf.upfronthosting.co.za>


Christian Heimes added the comment:

No blacklisting :)
I don't want to mess with any code prior to the final release of Python 3.6.0. Let's just document that stock 1.1.0c is not compatible.

Ned, I'm setting the release blocker flag as a reminder to add a comment to the release notes of 3.6.0.

----------
nosy: +ned.deily
priority: high -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28689>
_______________________________________

From report at bugs.python.org  Thu Dec 15 06:55:10 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 15 Dec 2016 11:55:10 +0000
Subject: [issue28915] Modify PyObject_CallFunction() to use fast call
 internally
In-Reply-To: <1481245654.11.0.143889949597.issue28915@psf.upfronthosting.co.za>
Message-ID: <20161215115507.2132.71647.0F448B1F@psf.io>


Roundup Robot added the comment:

New changeset bec846dd92e8 by Victor Stinner in branch 'default':
Fix _PyObject_CallFunctionVa(), use the small stack
https://hg.python.org/cpython/rev/bec846dd92e8

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28915>
_______________________________________

From report at bugs.python.org  Thu Dec 15 06:55:10 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 15 Dec 2016 11:55:10 +0000
Subject: [issue28870] Refactor PyObject_CallFunctionObjArgs() and like
In-Reply-To: <1480891813.94.0.54795440575.issue28870@psf.upfronthosting.co.za>
Message-ID: <20161215115507.2132.86904.E09D08CF@psf.io>


Roundup Robot added the comment:

New changeset 71876e4abce4 by Victor Stinner in branch 'default':
Add _PY_FASTCALL_SMALL_STACK constant
https://hg.python.org/cpython/rev/71876e4abce4

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28870>
_______________________________________

From report at bugs.python.org  Thu Dec 15 06:59:34 2016
From: report at bugs.python.org (woo yoo)
Date: Thu, 15 Dec 2016 11:59:34 +0000
Subject: [issue28978] a redundant right parentheses in the EBNF rules of
 parameter_list
Message-ID: <1481803174.61.0.122563860327.issue28978@psf.upfronthosting.co.za>


New submission from woo yoo:

Quote the documentation as below:

> parameter_list ::=  (defparameter ",")*
                    | "*" [parameter] ("," defparameter)* ["," "**" parameter]
                    | "**" parameter
                    | defparameter [","] )

The last right parenthesis is redundant.And the second alternative form is not complete, it does not incorporate a case that only include starred parameter.

----------
assignee: docs at python
components: Documentation
messages: 283288
nosy: docs at python, woo yoo
priority: normal
severity: normal
status: open
title: a redundant right  parentheses in the EBNF rules of parameter_list
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28978>
_______________________________________

From report at bugs.python.org  Thu Dec 15 07:00:22 2016
From: report at bugs.python.org (woo yoo)
Date: Thu, 15 Dec 2016 12:00:22 +0000
Subject: [issue28978] a redundant right parentheses in the EBNF rules of
 parameter_list
In-Reply-To: <1481803174.61.0.122563860327.issue28978@psf.upfronthosting.co.za>
Message-ID: <1481803222.22.0.740914435527.issue28978@psf.upfronthosting.co.za>


woo yoo added the comment:

Here is the link https://docs.python.org/3/reference/compound_stmts.html#function-definitions

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28978>
_______________________________________

From report at bugs.python.org  Thu Dec 15 07:04:20 2016
From: report at bugs.python.org (woo yoo)
Date: Thu, 15 Dec 2016 12:04:20 +0000
Subject: [issue28978] a redundant right parentheses in the EBNF rules of
 parameter_list
In-Reply-To: <1481803174.61.0.122563860327.issue28978@psf.upfronthosting.co.za>
Message-ID: <1481803460.22.0.368768506027.issue28978@psf.upfronthosting.co.za>


woo yoo added the comment:

Just the right parenthesis is redundant, ignore other words.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28978>
_______________________________________

From report at bugs.python.org  Thu Dec 15 07:07:36 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Dec 2016 12:07:36 +0000
Subject: [issue28969] lru_cache is not threadsafe
In-Reply-To: <1481712564.52.0.530922236321.issue28969@psf.upfronthosting.co.za>
Message-ID: <1481803656.17.0.7762993811.issue28969@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your example Peter.

Proposed patch fixes the KeyError. It introduces new private C API _PyDict_Pop_KnownHash(). It is like _PyDict_Pop(), but with precomputed hash.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file45912/lru_cache-dict-pop.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28969>
_______________________________________

From report at bugs.python.org  Thu Dec 15 07:09:30 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Dec 2016 12:09:30 +0000
Subject: [issue28925] Confusing exception from cPickle on reduce failure
In-Reply-To: <1481307076.91.0.720116511602.issue28925@psf.upfronthosting.co.za>
Message-ID: <1481803770.02.0.0510094160383.issue28925@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28925>
_______________________________________

From report at bugs.python.org  Thu Dec 15 07:15:07 2016
From: report at bugs.python.org (Chun-Yu Tseng)
Date: Thu, 15 Dec 2016 12:15:07 +0000
Subject: [issue22135] allow to break into pdb with Ctrl-C for all the commands
 that resume execution
In-Reply-To: <1407185061.52.0.89159247831.issue22135@psf.upfronthosting.co.za>
Message-ID: <1481804107.9.0.926871883552.issue22135@psf.upfronthosting.co.za>


Chun-Yu Tseng added the comment:

Here comes the patch:

1. Let Pdb can also resume from `return`, `until` and `next` commands when receiving Control-C.

2. Explicitly raise `bdb.BdbQuit` when an unexpected exception occurs in `sigint_handler`. See #24283.

3. Add two tests `test_break_during_interactive_input`, `test_resume_from_sigint` and some helper functions to `test_pdb.py` to make sure that Pdb behaves as we expected.
See below, Pdb resumes back in a wrong position when receiving Control-C.  The environment is Python 3.5.2 (Mac).  But Pdb works right in latest 3.5/3.6/default now. So we should have tests here.
(Pdb) list
  1      import time
  2      def f():
  3          import pdb; pdb.Pdb().set_trace();
  4  ->        delay()
  5          print("***** f() done *****")
  6
  7      def delay():
  8          time.sleep(3)
  (Pdb) c
^C
Program interrupted. (Use 'cont' to resume).
--Call--
> /usr/local/var/pyenv/versions/3.5.2/lib/python3.5/signal.py(45)signal()
-> @_wraps(_signal.signal)
(Pdb)



What this patch does NOT do are:

1. Let Pdb can resume from `step` command.
I tried by the same way like what I did for `continue/return/until/next` commands, but Pdb resumed back at the beginning of `sigint_handler`. The user should type in `continue` to go to the right place. I can't find an elegant way to work around it:
-> time.sleep(3)
(Pdb) s
^C--Call--
> /Users/chun-yutseng/Projects/cpython/Lib/pdb.py(189)sigint_handler()
-> def sigint_handler(self, signum, frame):
(Pdb) l
184              self.commands_defining = False # True while in the process of defining
185                                             # a command list
186              self.commands_bnum = None # The breakpoint number for which we are
187                                        # defining a list
188
189  ->        def sigint_handler(self, signum, frame):
190              if self.allow_kbdint:
191                  raise KeyboardInterrupt
192              try:
193                  self.message("\nProgram interrupted.")
194
(Pdb)

2. Let the two added tests can be run on Windows.
I tried, but when I found that I may need to use Windows-specific signals (CTRL_C_EVENT/CTRL_BREAK_EVENT) in `pdb.py` to let automated tests pass, I decided not to introduce such complexity.
So I use `@unittest.skipIf` to skip these two tests and tested the patch on Windows manually.


Call for review/advice/guides, please.

----------
keywords: +patch
nosy: +Chun-Yu Tseng
versions: +Python 3.7 -Python 3.5
Added file: http://bugs.python.org/file45913/fix-cc-and-add-tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22135>
_______________________________________

From report at bugs.python.org  Thu Dec 15 07:16:52 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Dec 2016 12:16:52 +0000
Subject: [issue28969] lru_cache is not threadsafe
In-Reply-To: <1481712564.52.0.530922236321.issue28969@psf.upfronthosting.co.za>
Message-ID: <1481804212.12.0.797807132841.issue28969@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28969>
_______________________________________

From report at bugs.python.org  Thu Dec 15 07:47:52 2016
From: report at bugs.python.org (Matt Joiner)
Date: Thu, 15 Dec 2016 12:47:52 +0000
Subject: [issue14156] argparse.FileType for '-' doesn't work for a mode of 'rb'
In-Reply-To: <1330513271.31.0.437438851478.issue14156@psf.upfronthosting.co.za>
Message-ID: <1481806072.94.0.156700899333.issue14156@psf.upfronthosting.co.za>


Changes by Matt Joiner <anacrolix at gmail.com>:


----------
nosy:  -anacrolix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14156>
_______________________________________

From report at bugs.python.org  Thu Dec 15 07:51:34 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 15 Dec 2016 12:51:34 +0000
Subject: [issue28971] nntplib is broken when responses are longer than _MAXLINE
In-Reply-To: <1481716454.12.0.730668429479.issue28971@psf.upfronthosting.co.za>
Message-ID: <1481806294.67.0.0055580177102.issue28971@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

It seems that the comment placed above the definition of _MAXLINE in the nntplib module is not correct:
    "RFC 3977 limits NNTP line length to 512 characters, including CRLF. We have selected 2048 just to be on the safe side."
The 512 characters limit in RFC 3977 only applies to command lines and to the initial line of a response.

RC 3977 says instead:
    "This document does not place any limit on the length of a line in a multi-line block.  However, the standards that define the format of articles may do so."

So I think _MAXLINE should have a large value (64 K ?) and its semantic is that a line whose length is above that value is considered by nntplib as a Dos attack (and not a protocol violation). In that case nntplib should behave in consequence and prevent any further reads from that connection (either by closing the connection or raising an exception on each of these attempts). IMHO this should be handled in the same issue because it is one single problem, and this may possibly be handled in two different changesets.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28971>
_______________________________________

From report at bugs.python.org  Thu Dec 15 07:51:56 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Dec 2016 12:51:56 +0000
Subject: [issue28969] lru_cache is not threadsafe
In-Reply-To: <1481712564.52.0.530922236321.issue28969@psf.upfronthosting.co.za>
Message-ID: <1481806316.7.0.17374194609.issue28969@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


Removed file: http://bugs.python.org/file45912/lru_cache-dict-pop-3.5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28969>
_______________________________________

From report at bugs.python.org  Thu Dec 15 07:52:25 2016
From: report at bugs.python.org (woo yoo)
Date: Thu, 15 Dec 2016 12:52:25 +0000
Subject: [issue28978] a redundant right parentheses in the EBNF rules of
 parameter_list
In-Reply-To: <1481803174.61.0.122563860327.issue28978@psf.upfronthosting.co.za>
Message-ID: <1481806345.99.0.289474483462.issue28978@psf.upfronthosting.co.za>


woo yoo added the comment:

And i find that the current rules of parameter_list includes a bare '*',which is illegal in practice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28978>
_______________________________________

From report at bugs.python.org  Thu Dec 15 07:52:39 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Dec 2016 12:52:39 +0000
Subject: [issue28969] lru_cache is not threadsafe
In-Reply-To: <1481712564.52.0.530922236321.issue28969@psf.upfronthosting.co.za>
Message-ID: <1481806359.85.0.186775053691.issue28969@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


Added file: http://bugs.python.org/file45914/lru_cache-dict-pop-3.5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28969>
_______________________________________

From report at bugs.python.org  Thu Dec 15 08:07:08 2016
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Thu, 15 Dec 2016 13:07:08 +0000
Subject: [issue28978] a redundant right parentheses in the EBNF rules of
 parameter_list
In-Reply-To: <1481803174.61.0.122563860327.issue28978@psf.upfronthosting.co.za>
Message-ID: <1481807228.94.0.106709639053.issue28978@psf.upfronthosting.co.za>


Jim Fasarakis-Hilliard added the comment:

See issue<9232> that changed the docs on function definitions. These changes aren't reflected in the 3.5 documentation though, you'll find them in the 3.6 docs.

The linked grammar is probably missing an opening parentheses from what I can tell, i.e change | to (:

    ( "*" [parameter] ("," defparameter)* ["," "**" parameter]

----------
nosy: +Jim Fasarakis-Hilliard

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28978>
_______________________________________

From report at bugs.python.org  Thu Dec 15 08:30:48 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Dec 2016 13:30:48 +0000
Subject: [issue28870] Refactor PyObject_CallFunctionObjArgs() and like
In-Reply-To: <1480891813.94.0.54795440575.issue28870@psf.upfronthosting.co.za>
Message-ID: <1481808648.78.0.937955774177.issue28870@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I reworked abstract.c to prepare work for this issue:

* change 455169e87bb3: Add _PyObject_CallFunctionVa() helper
* change 6e748eb79038: Add _PyObject_VaCallFunctionObjArgs() private function
* change 71876e4abce4: Add _PY_FASTCALL_SMALL_STACK constant


I wrote a function _testcapi to measure the consumption of the C code. I was surprised by the results: calling PyObject_CallFunctionObjArgs(func, arg1, arg2, NULL) consumes 560 bytes! I measured on a Python compiled in release mode.

Attached less_stack.patch rewrites _PyObject_VaCallFunctionObjArgs(), it reduces the stack consumption from 560 bytes to 384 bytes (-176 bytes!).

Changes:

* Remove "va_list countva" variable: the va_list variable itself, va_copy(), etc. consume stack memory. First I tried to move code to a subfunction, it helps. With my patch, it's even simpler.

* Reduce _PY_FASTCALL_SMALL_STACK from 5 to 3. Stack usage is not directly _PY_FASTCALL_SMALL_STACK*sizeof(PyObject*), it's much more, probably because of complex memory alignement rules.

* Use Py_LOCAL_INLINE(). It seems like depending on the size of the object_vacall() function body, the function is inlined or not. If it's not inlined, the stack usage increases from 384 bytes to 544 bytes!? Use Py_LOCAL_INLINE() to force inlining.


Effect of _PY_FASTCALL_SMALL_STACK:

* 1: 368 bytes
* 2: 384 bytes
* 3: 384 bytes -- value chosen in my patch
* 4: 400 bytes
* 5: 416 bytes

----------
Added file: http://bugs.python.org/file45915/less_stack.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28870>
_______________________________________

From report at bugs.python.org  Thu Dec 15 08:31:26 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Dec 2016 13:31:26 +0000
Subject: [issue28870] Reduce stack consumption of
 PyObject_CallFunctionObjArgs() and like
In-Reply-To: <1480891813.94.0.54795440575.issue28870@psf.upfronthosting.co.za>
Message-ID: <1481808686.93.0.142428622502.issue28870@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
title: Refactor PyObject_CallFunctionObjArgs() and like -> Reduce stack consumption of PyObject_CallFunctionObjArgs() and like

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28870>
_______________________________________

From report at bugs.python.org  Thu Dec 15 08:34:00 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Dec 2016 13:34:00 +0000
Subject: [issue28870] Reduce stack consumption of
 PyObject_CallFunctionObjArgs() and like
In-Reply-To: <1480891813.94.0.54795440575.issue28870@psf.upfronthosting.co.za>
Message-ID: <1481808840.01.0.586103861189.issue28870@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I don't propose to add _testcapi.pyobjectl_callfunctionobjargs_stacksize(). It's just to test the patch. I'm using it with:

$./python -c 'import _testcapi; n=100; print(_testcapi.pyobjectl_callfunctionobjargs_stacksize(n) / (n+1))'
384.0

The value of n has no impact on the stack, it gives the same value with n=0.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28870>
_______________________________________

From report at bugs.python.org  Thu Dec 15 08:40:20 2016
From: report at bugs.python.org (woo yoo)
Date: Thu, 15 Dec 2016 13:40:20 +0000
Subject: [issue28978] a redundant right parentheses in the EBNF rules of
 parameter_list
In-Reply-To: <1481803174.61.0.122563860327.issue28978@psf.upfronthosting.co.za>
Message-ID: <1481809220.57.0.490397704924.issue28978@psf.upfronthosting.co.za>


woo yoo added the comment:

There is  a few difference between Python-3.5.2 and Python-3.6.2 concerning the EBNF rules even though the parenthesis bug is fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28978>
_______________________________________

From report at bugs.python.org  Thu Dec 15 08:42:34 2016
From: report at bugs.python.org (Matteo Bertini)
Date: Thu, 15 Dec 2016 13:42:34 +0000
Subject: [issue23246] distutils fails to locate vcvarsall with Visual C++
 Compiler for Python
In-Reply-To: <1421377193.75.0.720322416964.issue23246@psf.upfronthosting.co.za>
Message-ID: <1481809354.83.0.793118366994.issue23246@psf.upfronthosting.co.za>


Matteo Bertini added the comment:

I'm back on this issue with a minimal patch, and a longer motivation.

Distutils does not support Visual C++ for Python compiler, but it could, with a one-line patch.

The proposed workaround is to use `setuptools`. But, we are not alone in this World, am I supposed to fork each third party package still using `distutils` and upgrade them to `setuptools`?

No, someone will say, you can "simply" `import setuptools`, and it will monkey-patch `distutils` adding the support for VS for Python.

1) this is implicit, very very against the Python Zen
2) the modifications are not limited and back-compatible. Some packages, say `sip` from `PyQt`, are broken simply adding this `import setuptools`, and other are too.

That said, I think this minimal patch to the `find_vcvarsall` code, can save a lot of time to every Python 2.7 users, time I see better spent upgrading to Python 3.

Sorry for the rant-mode, but I very liked Python, and I still like Python more than other languages, but I don't think that providing half broken solutions and very limited support to all the developer still running Python 2.7 in some big old project is a good strategy to push people to Python 3.

Python 3 is already a better language, but Python as a language can be a better language only if Python 2.7 will be a first class citizen till 2020.

----------
keywords: +patch
nosy: +naufraghi
type:  -> enhancement
Added file: http://bugs.python.org/file45916/vsforpython.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23246>
_______________________________________

From report at bugs.python.org  Thu Dec 15 08:43:12 2016
From: report at bugs.python.org (woo yoo)
Date: Thu, 15 Dec 2016 13:43:12 +0000
Subject: [issue28978] a redundant right parentheses in the EBNF rules of
 parameter_list
In-Reply-To: <1481803174.61.0.122563860327.issue28978@psf.upfronthosting.co.za>
Message-ID: <1481809392.24.0.817587503187.issue28978@psf.upfronthosting.co.za>


woo yoo added the comment:

Nor the rules in Python-3.6.0 excludes the bare '*' following no parameters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28978>
_______________________________________

From report at bugs.python.org  Thu Dec 15 08:45:37 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Dec 2016 13:45:37 +0000
Subject: [issue28870] Reduce stack consumption of
 PyObject_CallFunctionObjArgs() and like
In-Reply-To: <1480891813.94.0.54795440575.issue28870@psf.upfronthosting.co.za>
Message-ID: <1481809537.61.0.487598192134.issue28870@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I also tried to use alloca(): see attached alloca.patch. But the result is quite bad: 528 bytes of stack memory per call. I only attach the patch to discuss the issue, but I now dislike the option: the result is bad, it's less portable and more dangerous.

----------
Added file: http://bugs.python.org/file45917/alloca.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28870>
_______________________________________

From report at bugs.python.org  Thu Dec 15 08:49:04 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Dec 2016 13:49:04 +0000
Subject: [issue28870] Reduce stack consumption of
 PyObject_CallFunctionObjArgs() and like
In-Reply-To: <1480891813.94.0.54795440575.issue28870@psf.upfronthosting.co.za>
Message-ID: <1481809744.89.0.309079655078.issue28870@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I also tried Serhiy's approach, split the function into subfunctions, but the result is not as good as expected: 496 bytes. See attached subfunc.patch.

----------
Added file: http://bugs.python.org/file45918/subfunc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28870>
_______________________________________

From report at bugs.python.org  Thu Dec 15 08:52:12 2016
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Thu, 15 Dec 2016 13:52:12 +0000
Subject: [issue28979] What's New entry on compact dict mentions "faster"
 implementation
Message-ID: <1481809932.35.0.280442382983.issue28979@psf.upfronthosting.co.za>


New submission from Jim Fasarakis-Hilliard:

Specifically, the entry reads:

"The dict type has been reimplemented to use a faster, more compact representation similar to the PyPy dict implementation."

Through, the text describing the new implementation doesn't mention anything on speed, it only mentions memory usage.

issue27350 and, specifically, msg275587 even report a slight regression ok key look-ups. Am I interpreting this differently? If not, is it a good idea to be stating it is faster?

----------
assignee: docs at python
components: Documentation
messages: 283304
nosy: Jim Fasarakis-Hilliard, docs at python
priority: normal
severity: normal
status: open
title: What's New entry on compact dict mentions "faster" implementation
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28979>
_______________________________________

From report at bugs.python.org  Thu Dec 15 08:58:20 2016
From: report at bugs.python.org (kumaar.nd)
Date: Thu, 15 Dec 2016 13:58:20 +0000
Subject: [issue28965] Multiprocessing spawn/forkserver fails to pass Queues
In-Reply-To: <1481676708.34.0.90034781132.issue28965@psf.upfronthosting.co.za>
Message-ID: <1481810300.81.0.0962272592791.issue28965@psf.upfronthosting.co.za>


kumaar.nd added the comment:

hi,

few comments on this: [when tested with 'spawn']

1. the document(3x, 17.2.1.2) clearly mentions that 'spawn' doesnt inherit the file-handles (hence FileNotFoundError).
2. the document's examples has spawn() followed by join() where parent waits for the Child to finish and exits gracefully. The error "OSError: [Errno 9] Bad file descriptor" is seen for Child process.
3. Isnt exception-handling for null file descriptors sufficient (with corresponding Document updates)

am not a core developer yet and still trying to learn and contribute.

Thanks

----------
nosy: +kumaar.nd

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28965>
_______________________________________

From report at bugs.python.org  Thu Dec 15 09:00:36 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Thu, 15 Dec 2016 14:00:36 +0000
Subject: [issue7291] urllib2 cannot handle https with proxy requiring auth
In-Reply-To: <1257741498.16.0.683281197284.issue7291@psf.upfronthosting.co.za>
Message-ID: <1481810436.1.0.481295475102.issue7291@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

Modify target versions to bugfix and feature branches

----------
versions: +Python 3.7 -Python 2.6, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7291>
_______________________________________

From report at bugs.python.org  Thu Dec 15 09:14:04 2016
From: report at bugs.python.org (R. David Murray)
Date: Thu, 15 Dec 2016 14:14:04 +0000
Subject: [issue28976] incorrect description that dose not conform to the
 actual behavior
In-Reply-To: <1481772295.45.0.836170310477.issue28976@psf.upfronthosting.co.za>
Message-ID: <1481811244.24.0.0870304353973.issue28976@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28976>
_______________________________________

From report at bugs.python.org  Thu Dec 15 09:23:41 2016
From: report at bugs.python.org (R. David Murray)
Date: Thu, 15 Dec 2016 14:23:41 +0000
Subject: [issue28968] xml rpc server fails with connection reset by peer error
 no 104
In-Reply-To: <1481709223.17.0.559234955094.issue28968@psf.upfronthosting.co.za>
Message-ID: <1481811821.34.0.298598493396.issue28968@psf.upfronthosting.co.za>


R. David Murray added the comment:

Connection reset by peer means the far end has terminated the connection.  You'll probably need to do some protocol analysis (wireshark or a similar tool) to find out why the connection is being dropped, or perhaps you can look at the far end logging.  As it is, there isn't enough information here to speculate as to a cause, or if there is any bug in the python library code.

(FYI Martin von Loewis hasn't had much time for CPython development lately, so I doubt he'll respond.)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28968>
_______________________________________

From report at bugs.python.org  Thu Dec 15 09:26:21 2016
From: report at bugs.python.org (woo yoo)
Date: Thu, 15 Dec 2016 14:26:21 +0000
Subject: [issue28976] incorrect description that dose not conform to the
 actual behavior
In-Reply-To: <1481772295.45.0.836170310477.issue28976@psf.upfronthosting.co.za>
Message-ID: <1481811981.39.0.0960338670563.issue28976@psf.upfronthosting.co.za>


woo yoo added the comment:

Why the issue was closed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28976>
_______________________________________

From report at bugs.python.org  Thu Dec 15 09:26:23 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Dec 2016 14:26:23 +0000
Subject: [issue28870] Reduce stack consumption of
 PyObject_CallFunctionObjArgs() and like
In-Reply-To: <1480891813.94.0.54795440575.issue28870@psf.upfronthosting.co.za>
Message-ID: <1481811983.24.0.91949651554.issue28870@psf.upfronthosting.co.za>


STINNER Victor added the comment:

For comparison, Python 3.5 (before fast calls) uses 448 bytes of C stack per call. Python 3.5 uses a tuple allocated in the heap memory.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28870>
_______________________________________

From report at bugs.python.org  Thu Dec 15 09:27:35 2016
From: report at bugs.python.org (Steve Dower)
Date: Thu, 15 Dec 2016 14:27:35 +0000
Subject: [issue28924] Inline PyEval_EvalFrameEx() in callers
In-Reply-To: <1481306450.73.0.124326033178.issue28924@psf.upfronthosting.co.za>
Message-ID: <1481812055.48.0.292780958718.issue28924@psf.upfronthosting.co.za>


Steve Dower added the comment:

At least define EvalFrameEx in a header as an inline func, rather than copying the body.

VS expected to walk the native stack and locate the f parameter in EvalFrameEx. Since the function gets inlined, it couldn't find the frame. I use the JIT hook to insert my own frame onto the stack which is easier to find, so yes, the debugger has been fixed, yes the function gets inlined, and yes this has an impact other than performance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28924>
_______________________________________

From report at bugs.python.org  Thu Dec 15 09:35:39 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Dec 2016 14:35:39 +0000
Subject: [issue28924] Inline PyEval_EvalFrameEx() in callers
In-Reply-To: <1481306450.73.0.124326033178.issue28924@psf.upfronthosting.co.za>
Message-ID: <1481812539.14.0.359105204638.issue28924@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> At least define EvalFrameEx in a header as an inline func, rather than copying the body.

Hum, it would break the stable ABI, no?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28924>
_______________________________________

From report at bugs.python.org  Thu Dec 15 09:37:06 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Dec 2016 14:37:06 +0000
Subject: [issue28924] Inline PyEval_EvalFrameEx() in callers
In-Reply-To: <1481306450.73.0.124326033178.issue28924@psf.upfronthosting.co.za>
Message-ID: <1481812626.46.0.703257827029.issue28924@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Well, since the impact on performance is likely non-existent, whereas drawbacks are real, I close the issue.

Thanks for your feedback ;-)

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28924>
_______________________________________

From report at bugs.python.org  Thu Dec 15 09:44:01 2016
From: report at bugs.python.org (R. David Murray)
Date: Thu, 15 Dec 2016 14:44:01 +0000
Subject: [issue28879] smtplib send_message should add Date header if it is
 missing, per RFC5322
In-Reply-To: <1480952895.22.0.418354723664.issue28879@psf.upfronthosting.co.za>
Message-ID: <1481813041.2.0.383903720244.issue28879@psf.upfronthosting.co.za>


R. David Murray added the comment:

The sendmail function will never modify the RFC822+ content.  send_message, however, already does several manipulations of the message headers to make sending email simpler.  Practicality (make it easy to send messages without knowing the details of the SMTP/RFC5322 rules) beats purity (an SMTP library should not modify the content of the DATA) in this case, especially since smtplib *does* provide the purity version if you prefer to work that way.

That is, 'sendmail' is pure SMTP, while send_message is a practical enhancement that provides additional services to the caller, and can (and does and probably should) do checks for RFC required headers.

If someone wants to do a purity refactor (to which I would not object, and would in fact encourage), the RFC5322-aware code could be factored out into one or more functions or Message object methods in the email library that smtplib would call from the send_message method.

My visualization is that the email library should allow you to construct a valid email in whatever order you want (adding the Date header late in the process, for example), but should support validating the email before it is sent.  One way to do this would be to have the SMTP policy do the unambiguous fixups such as date headers, and raising errors for the rest (probably only if the strict flag is on, at this point) when the message is serialized.

Note that we previously fixed send_message to add a Resent-Date header if there are Resent- headers and no Resent-Date, so the precedent is already set (that is, smptlib send_message is already "not pure" :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28879>
_______________________________________

From report at bugs.python.org  Thu Dec 15 09:46:26 2016
From: report at bugs.python.org (woo yoo)
Date: Thu, 15 Dec 2016 14:46:26 +0000
Subject: [issue28976] incorrect description that dose not conform to the
 actual behavior
In-Reply-To: <1481772295.45.0.836170310477.issue28976@psf.upfronthosting.co.za>
Message-ID: <1481813186.51.0.0927886628704.issue28976@psf.upfronthosting.co.za>


Changes by woo yoo <chaozhou1232 at gmail.com>:


----------
resolution: not a bug -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28976>
_______________________________________

From report at bugs.python.org  Thu Dec 15 09:51:50 2016
From: report at bugs.python.org (R. David Murray)
Date: Thu, 15 Dec 2016 14:51:50 +0000
Subject: [issue28978] a redundant right parentheses in the EBNF rules of
 parameter_list
In-Reply-To: <1481803174.61.0.122563860327.issue28978@psf.upfronthosting.co.za>
Message-ID: <1481813510.54.0.0846691417011.issue28978@psf.upfronthosting.co.za>


R. David Murray added the comment:

What do you mean by "a bare * followed by no parameters"?  That is, what is the thing that is considered invalid that you are saying the BNF rules allow?  I'm looking for a code snipped that produces a syntax error.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28978>
_______________________________________

From report at bugs.python.org  Thu Dec 15 09:57:05 2016
From: report at bugs.python.org (R. David Murray)
Date: Thu, 15 Dec 2016 14:57:05 +0000
Subject: [issue28976] incorrect description that dose not conform to the
 actual behavior
In-Reply-To: <1481772295.45.0.836170310477.issue28976@psf.upfronthosting.co.za>
Message-ID: <1481813825.82.0.213388035801.issue28976@psf.upfronthosting.co.za>


R. David Murray added the comment:

Because the documentation is correct.  There is no bug here.  As Brendan said, there is no need to repeat a fundamental (that statements can raise exceptions) in this context.  The point of the passage is that

  if x: a; b; c;

is equivalent to

  if x:
     a
     b
     c

not

  if x: a
  b
  c

And that is what it clearly says, in my opinion.  The language reference is a specification and not a tutorial, so more words here would not be a good idea.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28976>
_______________________________________

From report at bugs.python.org  Thu Dec 15 09:57:52 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 15 Dec 2016 14:57:52 +0000
Subject: [issue23246] distutils fails to locate vcvarsall with Visual C++
 Compiler for Python
In-Reply-To: <1421377193.75.0.720322416964.issue23246@psf.upfronthosting.co.za>
Message-ID: <1481813872.12.0.965715129071.issue23246@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23246>
_______________________________________

From report at bugs.python.org  Thu Dec 15 09:58:30 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 15 Dec 2016 14:58:30 +0000
Subject: [issue7291] urllib2 cannot handle https with proxy requiring auth
In-Reply-To: <1257741498.16.0.683281197284.issue7291@psf.upfronthosting.co.za>
Message-ID: <1481813910.53.0.227382632459.issue7291@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7291>
_______________________________________

From report at bugs.python.org  Thu Dec 15 09:59:32 2016
From: report at bugs.python.org (woo yoo)
Date: Thu, 15 Dec 2016 14:59:32 +0000
Subject: [issue28978] a redundant right parentheses in the EBNF rules of
 parameter_list
In-Reply-To: <1481803174.61.0.122563860327.issue28978@psf.upfronthosting.co.za>
Message-ID: <1481813972.78.0.414631410366.issue28978@psf.upfronthosting.co.za>


woo yoo added the comment:

Code:
>>>def f(a, *):
>>>    print(a)
....
....?SyntaxError occurs here?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28978>
_______________________________________

From report at bugs.python.org  Thu Dec 15 10:03:36 2016
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Thu, 15 Dec 2016 15:03:36 +0000
Subject: [issue28980] ResourceWarning when imorting antigravity in 3.6
Message-ID: <1481814216.83.0.890338512389.issue28980@psf.upfronthosting.co.za>


New submission from Ivan Levkivskyi:

In 3.6 importing antigravity prints a warning (although it does what it should do):

>>> import antigravity
/home/ivan/.../Lib/subprocess.py:761: ResourceWarning: subprocess 15501 is still running
  ResourceWarning, source=self)

This is probably related to http://bugs.python.org/issue27069

----------
components: Library (Lib)
messages: 283317
nosy: levkivskyi
priority: normal
severity: normal
status: open
title: ResourceWarning when imorting antigravity in 3.6
type: resource usage
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28980>
_______________________________________

From report at bugs.python.org  Thu Dec 15 10:03:47 2016
From: report at bugs.python.org (R. David Murray)
Date: Thu, 15 Dec 2016 15:03:47 +0000
Subject: [issue28978] a redundant right parentheses in the EBNF rules of
 parameter_list
In-Reply-To: <1481803174.61.0.122563860327.issue28978@psf.upfronthosting.co.za>
Message-ID: <1481814227.26.0.295291714923.issue28978@psf.upfronthosting.co.za>


R. David Murray added the comment:

Ah, I see.  (", " defparameter)* should instead be "+", or whatever the BNF equivalent is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28978>
_______________________________________

From report at bugs.python.org  Thu Dec 15 10:09:27 2016
From: report at bugs.python.org (Brendan Donegan)
Date: Thu, 15 Dec 2016 15:09:27 +0000
Subject: [issue28979] What's New entry on compact dict mentions "faster"
 implementation
In-Reply-To: <1481809932.35.0.280442382983.issue28979@psf.upfronthosting.co.za>
Message-ID: <1481814567.55.0.702359611417.issue28979@psf.upfronthosting.co.za>


Brendan Donegan added the comment:

Agree. Patch provided.

----------
keywords: +patch
nosy: +brendan-donegan
Added file: http://bugs.python.org/file45919/whatsnew36.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28979>
_______________________________________

From report at bugs.python.org  Thu Dec 15 10:10:28 2016
From: report at bugs.python.org (woo yoo)
Date: Thu, 15 Dec 2016 15:10:28 +0000
Subject: [issue28976] incorrect description that dose not conform to the
 actual behavior
In-Reply-To: <1481772295.45.0.836170310477.issue28976@psf.upfronthosting.co.za>
Message-ID: <1481814628.74.0.308811208976.issue28976@psf.upfronthosting.co.za>


woo yoo added the comment:

According to the original description, "either all or none...",what does 'none' represent?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28976>
_______________________________________

From report at bugs.python.org  Thu Dec 15 10:13:27 2016
From: report at bugs.python.org (Brendan Donegan)
Date: Thu, 15 Dec 2016 15:13:27 +0000
Subject: [issue28976] incorrect description that dose not conform to the
 actual behavior
In-Reply-To: <1481814628.74.0.308811208976.issue28976@psf.upfronthosting.co.za>
Message-ID: <CAESAk0g=iH-HOpo3mDA_vaQVTTiXKR1rRde4YS+SDk0yNNvSbQ@mail.gmail.com>


Brendan Donegan added the comment:

None represents the case where the if statement is false

On Thu, 15 Dec 2016 at 20:40 woo yoo <report at bugs.python.org> wrote:

>
> woo yoo added the comment:
>
> According to the original description, "either all or none...",what does
> 'none' represent?
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue28976>
> _______________________________________
>

----------
nosy: +brendand

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28976>
_______________________________________

From report at bugs.python.org  Thu Dec 15 10:20:46 2016
From: report at bugs.python.org (woo yoo)
Date: Thu, 15 Dec 2016 15:20:46 +0000
Subject: [issue28976] incorrect description that dose not conform to the
 actual behavior
In-Reply-To: <1481772295.45.0.836170310477.issue28976@psf.upfronthosting.co.za>
Message-ID: <1481815246.6.0.993886730873.issue28976@psf.upfronthosting.co.za>


woo yoo added the comment:

"either all or none of the print() calls are executed",I think the 'none' describes the number of the calls to be executed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28976>
_______________________________________

From report at bugs.python.org  Thu Dec 15 10:22:27 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 15 Dec 2016 15:22:27 +0000
Subject: [issue28979] What's New entry on compact dict mentions "faster"
 implementation
In-Reply-To: <1481809932.35.0.280442382983.issue28979@psf.upfronthosting.co.za>
Message-ID: <20161215152223.3621.12193.29210640@psf.io>


Roundup Robot added the comment:

New changeset 181453f9a0c4 by Victor Stinner in branch '3.6':
Issue #28979: Fix What's New in Python 3.6, dict
https://hg.python.org/cpython/rev/181453f9a0c4

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28979>
_______________________________________

From report at bugs.python.org  Thu Dec 15 10:23:17 2016
From: report at bugs.python.org (Brendan Donegan)
Date: Thu, 15 Dec 2016 15:23:17 +0000
Subject: [issue28976] incorrect description that dose not conform to the
 actual behavior
In-Reply-To: <1481815246.6.0.993886730873.issue28976@psf.upfronthosting.co.za>
Message-ID: <CAESAk0gh01gPpcWEsfzJWbZ3+tteS2hHj067E48vj6M+LBt3=Q@mail.gmail.com>


Brendan Donegan added the comment:

I think the consensus is that the wording is correct. If you can come up
with text that is clearer, and still correct, please do submit a patch.

On Thu, 15 Dec 2016 at 20:50 woo yoo <report at bugs.python.org> wrote:

>
> woo yoo added the comment:
>
> "either all or none of the print() calls are executed",I think the 'none'
> describes the number of the calls to be executed.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue28976>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28976>
_______________________________________

From report at bugs.python.org  Thu Dec 15 10:23:26 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Dec 2016 15:23:26 +0000
Subject: [issue28979] What's New entry on compact dict mentions "faster"
 implementation
In-Reply-To: <1481809932.35.0.280442382983.issue28979@psf.upfronthosting.co.za>
Message-ID: <1481815406.34.0.519837367998.issue28979@psf.upfronthosting.co.za>


STINNER Victor added the comment:

@Ned: Would you be ok to cherry-pick 181453f9a0c4 in Python 3.6.0?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28979>
_______________________________________

From report at bugs.python.org  Thu Dec 15 10:23:46 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Dec 2016 15:23:46 +0000
Subject: [issue28979] What's New entry on compact dict mentions "faster"
 implementation
In-Reply-To: <1481809932.35.0.280442382983.issue28979@psf.upfronthosting.co.za>
Message-ID: <1481815426.04.0.611592526843.issue28979@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +inada.naoki, ned.deily, serhiy.storchaka, yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28979>
_______________________________________

From report at bugs.python.org  Thu Dec 15 10:33:58 2016
From: report at bugs.python.org (Brendan Donegan)
Date: Thu, 15 Dec 2016 15:33:58 +0000
Subject: [issue27069] webbrowser creates zombi processes in the background mode
In-Reply-To: <1463746997.46.0.620771266968.issue27069@psf.upfronthosting.co.za>
Message-ID: <1481816038.16.0.996582753436.issue27069@psf.upfronthosting.co.za>


Brendan Donegan added the comment:

This appears to be Firefox specific? At least:

b = webbrowser.get("chromium-browser")
b.open("https://bugs.python.org/issue26741")

returns simply:

True

With no exception

----------
nosy: +brendan-donegan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27069>
_______________________________________

From report at bugs.python.org  Thu Dec 15 10:35:08 2016
From: report at bugs.python.org (Brendan Donegan)
Date: Thu, 15 Dec 2016 15:35:08 +0000
Subject: [issue28980] ResourceWarning when imorting antigravity in 3.6
In-Reply-To: <1481814216.83.0.890338512389.issue28980@psf.upfronthosting.co.za>
Message-ID: <1481816108.46.0.236613748775.issue28980@psf.upfronthosting.co.za>


Brendan Donegan added the comment:

I think this is essentially a duplicate of http://bugs.python.org/issue27069, or at least fixing that will fix this (as the exception is caused by the webbrowser.open() call)

----------
nosy: +brendan-donegan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28980>
_______________________________________

From report at bugs.python.org  Thu Dec 15 10:35:54 2016
From: report at bugs.python.org (woo yoo)
Date: Thu, 15 Dec 2016 15:35:54 +0000
Subject: [issue28976] incorrect description that dose not conform to the
 actual behavior
In-Reply-To: <1481772295.45.0.836170310477.issue28976@psf.upfronthosting.co.za>
Message-ID: <1481816154.87.0.99733921822.issue28976@psf.upfronthosting.co.za>


woo yoo added the comment:

In fact, I'm a newcomer to Python. When i have experimented with those description interactively using Python interpreter, i got confused.

I don't know how to submit a patch.If the description were changed by me,it would be?
>if x<y<z:print(x);print(y);print(z) 
>is equivalent to
>if x<y<z:
>    print(x)
>    print(y)
>    print(z)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28976>
_______________________________________

From report at bugs.python.org  Thu Dec 15 10:42:11 2016
From: report at bugs.python.org (R. David Murray)
Date: Thu, 15 Dec 2016 15:42:11 +0000
Subject: [issue28976] incorrect description that dose not conform to the
 actual behavior
In-Reply-To: <1481772295.45.0.836170310477.issue28976@psf.upfronthosting.co.za>
Message-ID: <1481816531.85.0.213599139633.issue28976@psf.upfronthosting.co.za>


R. David Murray added the comment:

As I said, the language reference is a specification, not a tutorual.  The text as written is clear technical English.  You are correct that 'none' refers to the number of statements executed, but 'none' are executed when the statement is false, and 'all' are executed when the statement is true.  The fact that execution of a suite may be interrupted by an exception is covered elsewhere in the language reference and it would not enhance the documentation to repeat it here.

If other core developers think putting in the example is appropriate I'm not going to object, but I don't think they will.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28976>
_______________________________________

From report at bugs.python.org  Thu Dec 15 10:47:46 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 15 Dec 2016 15:47:46 +0000
Subject: [issue22135] allow to break into pdb with Ctrl-C for all the commands
 that resume execution
In-Reply-To: <1407185061.52.0.89159247831.issue22135@psf.upfronthosting.co.za>
Message-ID: <1481816866.45.0.464220645595.issue22135@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Thanks for the patch. See my comments in Rietveld.
I think we can skip the 'step' command.
For the tests, can you use the existing run_pdb() method and trigger the signals from within the code being executed with 'os.kill(os.getpid(), signal.SIGINT |  signal.CTRL_C_EVENT)', this would avoid having to sleep on delays.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22135>
_______________________________________

From report at bugs.python.org  Thu Dec 15 10:52:18 2016
From: report at bugs.python.org (woo yoo)
Date: Thu, 15 Dec 2016 15:52:18 +0000
Subject: [issue28976] incorrect description that dose not conform to the
 actual behavior
In-Reply-To: <1481772295.45.0.836170310477.issue28976@psf.upfronthosting.co.za>
Message-ID: <1481817138.85.0.857163780569.issue28976@psf.upfronthosting.co.za>


woo yoo added the comment:

I think i understand you now.My english needs to improve.Thanks for your patience.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28976>
_______________________________________

From report at bugs.python.org  Thu Dec 15 10:53:05 2016
From: report at bugs.python.org (woo yoo)
Date: Thu, 15 Dec 2016 15:53:05 +0000
Subject: [issue28976] incorrect description that dose not conform to the
 actual behavior
In-Reply-To: <1481772295.45.0.836170310477.issue28976@psf.upfronthosting.co.za>
Message-ID: <1481817185.36.0.669717684372.issue28976@psf.upfronthosting.co.za>


Changes by woo yoo <chaozhou1232 at gmail.com>:


----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28976>
_______________________________________

From report at bugs.python.org  Thu Dec 15 10:54:42 2016
From: report at bugs.python.org (Ned Deily)
Date: Thu, 15 Dec 2016 15:54:42 +0000
Subject: [issue28979] What's New entry on compact dict mentions "faster"
 implementation
In-Reply-To: <1481809932.35.0.280442382983.issue28979@psf.upfronthosting.co.za>
Message-ID: <1481817282.65.0.921123587141.issue28979@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28979>
_______________________________________

From report at bugs.python.org  Thu Dec 15 11:02:28 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 15 Dec 2016 16:02:28 +0000
Subject: [issue27810] Add METH_FASTCALL: new calling convention for C functions
In-Reply-To: <1471653166.26.0.257085519078.issue27810@psf.upfronthosting.co.za>
Message-ID: <20161215160215.1497.36786.DBCF5ACA@psf.io>


Roundup Robot added the comment:

New changeset ecd218c41cd4 by Victor Stinner in branch 'default':
Use _PyDict_NewPresized() in _PyStack_AsDict()
https://hg.python.org/cpython/rev/ecd218c41cd4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27810>
_______________________________________

From report at bugs.python.org  Thu Dec 15 11:08:02 2016
From: report at bugs.python.org (Matt Bogosian)
Date: Thu, 15 Dec 2016 16:08:02 +0000
Subject: [issue23063] `python setup.py check --restructuredtext --strict
 --metadata` fails with: `warning: check: Could not finish the parsing.` if
 the RST document uses code or code-block directives.
In-Reply-To: <1418716685.25.0.847417973192.issue23063@psf.upfronthosting.co.za>
Message-ID: <1481818082.37.0.442700776201.issue23063@psf.upfronthosting.co.za>


Changes by Matt Bogosian <spam+python.org at eb3f73.yaymail.com>:


----------
nosy: +posita

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23063>
_______________________________________

From report at bugs.python.org  Thu Dec 15 11:11:31 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Dec 2016 16:11:31 +0000
Subject: [issue11322] encoding package's normalize_encoding() function is
 too	slow
In-Reply-To: <1298649332.11.0.637901441206.issue11322@psf.upfronthosting.co.za>
Message-ID: <1481818291.7.0.19003313627.issue11322@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oh, while reading Mercurial history, I found a note that I wrote:

"It's not exactly the same than encodings.normalize_encoding(): the C function also converts to lowercase."

IHMO it's fine to modify encodings.normalize_encoding() to also convert to lower-case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11322>
_______________________________________

From report at bugs.python.org  Thu Dec 15 11:23:51 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 15 Dec 2016 16:23:51 +0000
Subject: [issue28147] Unbounded memory growth resizing split-table dicts
In-Reply-To: <1473853453.13.0.556951743271.issue28147@psf.upfronthosting.co.za>
Message-ID: <20161215162346.1429.24053.2CC510DD@psf.io>


Roundup Robot added the comment:

New changeset 85be9dcc16a8 by Victor Stinner in branch '3.6':
Fix a memory leak in split-table dictionaries
https://hg.python.org/cpython/rev/85be9dcc16a8

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28147>
_______________________________________

From report at bugs.python.org  Thu Dec 15 11:25:16 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 15 Dec 2016 16:25:16 +0000
Subject: [issue28147] Unbounded memory growth resizing split-table dicts
In-Reply-To: <1473853453.13.0.556951743271.issue28147@psf.upfronthosting.co.za>
Message-ID: <1481819116.07.0.11405519806.issue28147@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I dislike pushing a change written by another core dev, I prefer that he/she directly push it, but we are out of time. Ned asked to first push to Python 3.6 to get a confirmation of buildbots, before being able to ask for a cherry-pick in 3.6.0 final.

Anyway, thanks for the fix Naoki!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28147>
_______________________________________

From report at bugs.python.org  Thu Dec 15 11:28:33 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Dec 2016 16:28:33 +0000
Subject: [issue28870] Reduce stack consumption of
 PyObject_CallFunctionObjArgs() and like
In-Reply-To: <1480891813.94.0.54795440575.issue28870@psf.upfronthosting.co.za>
Message-ID: <1481819313.92.0.0375266126998.issue28870@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I have tested all three patches with the stack_overflow.py script. The only affected are recursive Python implementations of __call__, __getitem__ and __iter__.

                        unpatched   less_stack  alloca      subfunc

test_python_call        9696        9876        9880        9876
test_python_getitem     9884        10264       9880        10688
test_python_iterator    7812        8052        8312        8872

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28870>
_______________________________________

From report at bugs.python.org  Thu Dec 15 13:04:51 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Dec 2016 18:04:51 +0000
Subject: [issue28147] Unbounded memory growth resizing split-table dicts
In-Reply-To: <1473853453.13.0.556951743271.issue28147@psf.upfronthosting.co.za>
Message-ID: <1481825091.11.0.441694604369.issue28147@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think this can be tested without _testcapi. See an example in issue28894.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28147>
_______________________________________

From report at bugs.python.org  Thu Dec 15 13:08:08 2016
From: report at bugs.python.org (Matt Bogosian)
Date: Thu, 15 Dec 2016 18:08:08 +0000
Subject: [issue28981] distutils/check.py overzealous catch block hides errors
Message-ID: <1481825288.28.0.614509725219.issue28981@psf.upfronthosting.co.za>


New submission from Matt Bogosian:

>From (e.g) https://github.com/python/cpython/blob/2.7/Lib/distutils/command/check.py#L145:

{{{
        try:
            parser.parse(data, document)
        except AttributeError as e:  # <- this could happen anywhere inside parser.parse
            reporter.messages.append(
(-1, 'Could not finish the parsing: %s.' % e, '', {}))
}}}

Without a stack trace, diagnosing problems like #23063 becomes unnecessarily difficult. See also:

* https://sourceforge.net/p/docutils/bugs/270/
* https://sourceforge.net/p/docutils/bugs/302/

I'd offer a patch, but I'm not sure what is meant to be signaled by the `AttributeError`. (Could `parser.parse` not exist? Is it something else?)

----------
components: Distutils
messages: 283338
nosy: dstufft, eric.araujo, posita
priority: normal
severity: normal
status: open
title: distutils/check.py overzealous catch block hides errors
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28981>
_______________________________________

From report at bugs.python.org  Thu Dec 15 13:21:28 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 15 Dec 2016 18:21:28 +0000
Subject: [issue28147] Unbounded memory growth resizing split-table dicts
In-Reply-To: <1473853453.13.0.556951743271.issue28147@psf.upfronthosting.co.za>
Message-ID: <1481826088.09.0.198350475355.issue28147@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I asked a question about the change in _PyObjectDict_SetItem. It is not clear to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28147>
_______________________________________

From report at bugs.python.org  Thu Dec 15 14:41:26 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 15 Dec 2016 19:41:26 +0000
Subject: [issue26919] on Android python fails to decode/encode command line
 arguments
In-Reply-To: <1462267115.39.0.594600458307.issue26919@psf.upfronthosting.co.za>
Message-ID: <1481830886.57.0.261332601113.issue26919@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

The patch fixes also the following errors in test_warnings:

======================================================================
FAIL: test_nonascii (test.test_warnings.CEnvironmentVariableTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sdcard/org.bitbucket.pyona/lib/python3.7/test/test_warnings/__init__.py", line 1072, in test_nonascii
    "['ignore:Deprecaci\xf3nWarning']".encode('utf-8'))
AssertionError: b"['ignore:Deprecaci\\udcc3\\udcb3nWarning']" != b"['ignore:Deprecaci\xc3\xb3nWarning']"

======================================================================
FAIL: test_nonascii (test.test_warnings.PyEnvironmentVariableTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sdcard/org.bitbucket.pyona/lib/python3.7/test/test_warnings/__init__.py", line 1072, in test_nonascii
    "['ignore:Deprecaci\xf3nWarning']".encode('utf-8'))
AssertionError: b"['ignore:Deprecaci\\udcc3\\udcb3nWarning']" != b"['ignore:Deprecaci\xc3\xb3nWarning']"

----------------------------------------------------------------------

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26919>
_______________________________________

From report at bugs.python.org  Thu Dec 15 15:02:34 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 15 Dec 2016 20:02:34 +0000
Subject: [issue26919] on Android python fails to decode/encode command line
 arguments
In-Reply-To: <1462267115.39.0.594600458307.issue26919@psf.upfronthosting.co.za>
Message-ID: <20161215200231.28492.4230.BC09419E@psf.io>


Roundup Robot added the comment:

New changeset e5360d413ce4 by Xavier de Gaye in branch '3.6':
Issue #26919: On Android, operating system data is now always encoded/decoded
https://hg.python.org/cpython/rev/e5360d413ce4

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26919>
_______________________________________

From report at bugs.python.org  Thu Dec 15 15:09:59 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 15 Dec 2016 20:09:59 +0000
Subject: [issue26919] on Android python fails to decode/encode command line
 arguments
In-Reply-To: <1462267115.39.0.594600458307.issue26919@psf.upfronthosting.co.za>
Message-ID: <1481832599.36.0.322604538603.issue26919@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Forgot the issue number in the commit message for the default branch, the corresponding changeset is 80a041d39c20.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26919>
_______________________________________

From report at bugs.python.org  Thu Dec 15 15:21:18 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Thu, 15 Dec 2016 20:21:18 +0000
Subject: [issue28794] inspect.isasyncgen and inspect.isasyncgenfunction aren't
 documented
In-Reply-To: <1480025404.72.0.713291262903.issue28794@psf.upfronthosting.co.za>
Message-ID: <1481833278.74.0.6639145436.issue28794@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

LGTM. Thanks for the patch!

----------
nosy: +ebarry
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28794>
_______________________________________

From report at bugs.python.org  Thu Dec 15 15:37:29 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 15 Dec 2016 20:37:29 +0000
Subject: [issue26919] on Android python fails to decode/encode command line
 arguments
In-Reply-To: <1462267115.39.0.594600458307.issue26919@psf.upfronthosting.co.za>
Message-ID: <1481834249.13.0.496607904967.issue26919@psf.upfronthosting.co.za>


Changes by Xavier de Gaye <xdegaye at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26919>
_______________________________________

From report at bugs.python.org  Thu Dec 15 15:44:25 2016
From: report at bugs.python.org (Ryan Brindley)
Date: Thu, 15 Dec 2016 20:44:25 +0000
Subject: [issue28982] multiprocessing.Queue.get(block=True,
 timeout=0) always raises queue.Empty
Message-ID: <1481834665.78.0.584713250682.issue28982@psf.upfronthosting.co.za>


New submission from Ryan Brindley:

Hey dev team,

According to the following test, `q.get(True, 0)` always raises queue.Empty.

from multiprocessing import Queue
q = Queue()
q.put('foo')
q.get(True, 0)  # raises Empty

This result throws me off as I was expecting a similar result to the underlying poll/select timeout where 0 actually just means non-blocking.

After reviewing Lib/multiprocessing/queues.py, I found the condition where the timeout, after the adjustment for the time required to acquire the lock, would not even call poll() if it was less than 0.

So, linked is a simple PR that I'm offering as a suggested fix/behavior-change of Queue.get's handling of timeout=0 to match the underlying poll/select handling (aka non-blocking).

Cheers,

Ryan Brindley

----------
components: Library (Lib)
messages: 283344
nosy: Ryan Brindley
priority: normal
pull_requests: 5
severity: normal
status: open
title: multiprocessing.Queue.get(block=True, timeout=0) always raises queue.Empty
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28982>
_______________________________________

From report at bugs.python.org  Thu Dec 15 15:48:11 2016
From: report at bugs.python.org (Ned Deily)
Date: Thu, 15 Dec 2016 20:48:11 +0000
Subject: [issue28982] multiprocessing.Queue.get(block=True,
 timeout=0) always raises queue.Empty
In-Reply-To: <1481834665.78.0.584713250682.issue28982@psf.upfronthosting.co.za>
Message-ID: <1481834891.72.0.556293592101.issue28982@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
nosy: +davin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28982>
_______________________________________

From report at bugs.python.org  Thu Dec 15 16:31:17 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Thu, 15 Dec 2016 21:31:17 +0000
Subject: [issue28518] execute("begin immediate") throwing OperationalError
In-Reply-To: <1477307118.31.0.70785963389.issue28518@psf.upfronthosting.co.za>
Message-ID: <1481837477.17.0.0960014835539.issue28518@psf.upfronthosting.co.za>


Aviv Palivoda added the comment:

I think that adding Serhiy patch in addition to the documentation improvement in issue #8145 would be the best way to proceed. This will insure no regression problems.
We can add a warning when someone try to use BEGIN, ROLLBACK, SAVEPOINT, and RELEASE without changing the isolation_level to None.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28518>
_______________________________________

From report at bugs.python.org  Thu Dec 15 17:25:42 2016
From: report at bugs.python.org (Rhesa Browning)
Date: Thu, 15 Dec 2016 22:25:42 +0000
Subject: [issue28983] Python 3.5.2 won't install on my computer
Message-ID: <1481840742.78.0.554470867064.issue28983@psf.upfronthosting.co.za>


New submission from Rhesa Browning:

When I install Python, I get an error message saying that the python35.dll file doesn't exist on my computer. That is at far as it goes.  I have attached a RAR folder with the logs from the times I tried to install.

----------
files: Python installation archive.rar
messages: 283346
nosy: Rhesa Browning
priority: normal
severity: normal
status: open
title: Python 3.5.2 won't install on my computer
type: performance
versions: Python 3.5
Added file: http://bugs.python.org/file45920/Python installation archive.rar

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28983>
_______________________________________

From report at bugs.python.org  Thu Dec 15 17:32:17 2016
From: report at bugs.python.org (Maciej Szulik)
Date: Thu, 15 Dec 2016 22:32:17 +0000
Subject: [issue28879] smtplib send_message should add Date header if it is
 missing, per RFC5322
In-Reply-To: <1480952895.22.0.418354723664.issue28879@psf.upfronthosting.co.za>
Message-ID: <1481841137.21.0.162064921505.issue28879@psf.upfronthosting.co.za>


Maciej Szulik added the comment:

I've chatted a bit with David about this feature. Here are some thoughts:
- check what SMTP standard says about some validation rules
- add validate method, probably into email package

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28879>
_______________________________________

From report at bugs.python.org  Thu Dec 15 17:34:36 2016
From: report at bugs.python.org (eryk sun)
Date: Thu, 15 Dec 2016 22:34:36 +0000
Subject: [issue28983] Python 3.5.2 won't install on my computer
In-Reply-To: <1481840742.78.0.554470867064.issue28983@psf.upfronthosting.co.za>
Message-ID: <1481841276.37.0.333607593765.issue28983@psf.upfronthosting.co.za>


Changes by eryk sun <eryksun at gmail.com>:


----------
components: +Installation, Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
type: performance -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28983>
_______________________________________

From report at bugs.python.org  Thu Dec 15 17:36:46 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 15 Dec 2016 22:36:46 +0000
Subject: [issue28091] Document PEP 525
In-Reply-To: <1480969186.28.0.879526881588.issue28091@psf.upfronthosting.co.za>
Message-ID: <20161215223643.125893.55624.081AC51C@psf.io>


Roundup Robot added the comment:

New changeset 78c8f450b84c by Yury Selivanov in branch '3.6':
Issue #28091: Document PEP 525 & PEP 530.
https://hg.python.org/cpython/rev/78c8f450b84c

New changeset 6bf84e661e69 by Yury Selivanov in branch 'default':
Merge 3.6 (issue #28091)
https://hg.python.org/cpython/rev/6bf84e661e69

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28091>
_______________________________________

From report at bugs.python.org  Thu Dec 15 17:38:25 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 15 Dec 2016 22:38:25 +0000
Subject: [issue28091] Document PEP 525
In-Reply-To: <1480969186.28.0.879526881588.issue28091@psf.upfronthosting.co.za>
Message-ID: <1481841505.3.0.521269390985.issue28091@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Pushed.  Thanks a lot, Eric, very good job!  (BTW, please enable trailing whitespace trimming in your editor)

Ned, maybe you want to cherry-pick this commit to 3.6.0, but I guess most people just use docs.python.org, so it's not that important.

----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28091>
_______________________________________

From report at bugs.python.org  Thu Dec 15 17:39:13 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 15 Dec 2016 22:39:13 +0000
Subject: [issue28090] Document PEP 530
In-Reply-To: <1480969286.88.0.896640535398.issue28090@psf.upfronthosting.co.za>
Message-ID: <1481841553.36.0.180002773985.issue28090@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Closing this one, the issue was resolved as part of #28091.

----------
priority: deferred blocker -> normal
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed
superseder:  -> Document PEP 525

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28090>
_______________________________________

From report at bugs.python.org  Thu Dec 15 17:56:33 2016
From: report at bugs.python.org (Steve Dower)
Date: Thu, 15 Dec 2016 22:56:33 +0000
Subject: [issue28983] Python 3.5.2 won't install on my computer
In-Reply-To: <1481840742.78.0.554470867064.issue28983@psf.upfronthosting.co.za>
Message-ID: <1481842593.34.0.723271703356.issue28983@psf.upfronthosting.co.za>


Steve Dower added the comment:

It looks like you have a partial install there, possibly from an earlier version.

Do you see a "Python" entry in Programs and Features? If so, running a Repair on that may help, or removing it.

If you don't see another entry there, installing Python without tcl/tk support (which seems to be breaking when it gets up to doing shortcuts) and without pip support may get you to the end of an install, at which point you can run a repair that should bring back the missing files.

As a last resort, running these commands from the command line might also help clean things up:

msiexec /x {EB0611B2-7F10-4D97-BCF2-DCAAB1199498}
msiexec /x {5DB2183B-62D3-407F-BBC1-EAD2F36283FA}

If you get as far as running these, I'd keep running them repeatedly until you start getting errors (this is to make sure you aren't decreasing a reference count from 3 to 2 - we want it to go all the way to 0).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28983>
_______________________________________

From report at bugs.python.org  Thu Dec 15 17:57:30 2016
From: report at bugs.python.org (Steve Dower)
Date: Thu, 15 Dec 2016 22:57:30 +0000
Subject: [issue28983] Python 3.5.2 won't install on my computer
In-Reply-To: <1481840742.78.0.554470867064.issue28983@psf.upfronthosting.co.za>
Message-ID: <1481842650.76.0.15803824489.issue28983@psf.upfronthosting.co.za>


Steve Dower added the comment:

(For anyone who comes here later, those last two commands are specially crafted for this situation based on the attached log files. You'll likely need different commands for whatever your situation is.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28983>
_______________________________________

From report at bugs.python.org  Thu Dec 15 17:58:02 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 15 Dec 2016 22:58:02 +0000
Subject: [issue28635] Update What's New for 3.6
In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za>
Message-ID: <20161215225759.33256.68055.648749C3@psf.io>


Roundup Robot added the comment:

New changeset 418ba3a0f090 by Yury Selivanov in branch '3.6':
Issue #28635: asyncio-related fixes and additions.
https://hg.python.org/cpython/rev/418ba3a0f090

New changeset 83eb8053a4e1 by Yury Selivanov in branch 'default':
Merge 3.6 (issue #28635)
https://hg.python.org/cpython/rev/83eb8053a4e1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28635>
_______________________________________

From report at bugs.python.org  Thu Dec 15 17:59:36 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 15 Dec 2016 22:59:36 +0000
Subject: [issue28091] Document PEP 525 & 530
In-Reply-To: <1480969186.28.0.879526881588.issue28091@psf.upfronthosting.co.za>
Message-ID: <1481842776.54.0.0292678650451.issue28091@psf.upfronthosting.co.za>


Changes by Yury Selivanov <yselivanov at gmail.com>:


----------
title: Document PEP 525 -> Document PEP 525 & 530

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28091>
_______________________________________

From report at bugs.python.org  Thu Dec 15 18:11:18 2016
From: report at bugs.python.org (Knut)
Date: Thu, 15 Dec 2016 23:11:18 +0000
Subject: [issue28984] json.dump + indent creates trailing extra spaces
Message-ID: <1481843478.24.0.510180134171.issue28984@psf.upfronthosting.co.za>


New submission from Knut:

module json
python 2.7.12

json.dump(..., indent=4, sort_keys=True) gives me:

{
    "size": {
        "total": 19106,X
        "code": 18614,X
        "data": 492
    },X
    "next_item": 10
}


The "X" mark extra trailing space characters which are needless.

----------
components: Library (Lib)
messages: 283354
nosy: voxspox
priority: normal
severity: normal
status: open
title: json.dump + indent creates trailing extra spaces
type: resource usage
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28984>
_______________________________________

From report at bugs.python.org  Thu Dec 15 19:43:13 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Fri, 16 Dec 2016 00:43:13 +0000
Subject: [issue28984] json.dump + indent creates trailing extra spaces
In-Reply-To: <1481843478.24.0.510180134171.issue28984@psf.upfronthosting.co.za>
Message-ID: <1481848993.02.0.345409199114.issue28984@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

This is documented behavior for Python 2 ( https://docs.python.org/2/library/json.html#basic-usage ):

>Note: Since the default item separator is ', ', the output might include trailing whitespace when indent is specified. You can use separators=(',', ': ') to avoid this.

and also:

If specified, separators should be an (item_separator, key_separator) tuple. By default, (', ', ': ') are used. To get the most compact JSON representation, you should specify (',', ':') to eliminate whitespace.

Python 3 gives a different guarantee (dynamically chosen default separators based on the value of indent), and it follows that contract.

Given it's clearly documented, easily worked around, and largely harmless, I see no strong argument for backporting the Python 3 behavior to the legacy codebase.

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28984>
_______________________________________

From report at bugs.python.org  Thu Dec 15 19:54:44 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Fri, 16 Dec 2016 00:54:44 +0000
Subject: [issue28969] lru_cache is not threadsafe
In-Reply-To: <1481712564.52.0.530922236321.issue28969@psf.upfronthosting.co.za>
Message-ID: <1481849684.05.0.698974904447.issue28969@psf.upfronthosting.co.za>


Changes by Josh Rosenberg <shadowranger+python at gmail.com>:


----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28969>
_______________________________________

From report at bugs.python.org  Thu Dec 15 20:01:03 2016
From: report at bugs.python.org (Ned Deily)
Date: Fri, 16 Dec 2016 01:01:03 +0000
Subject: [issue28984] json.dump + indent creates trailing extra spaces
In-Reply-To: <1481843478.24.0.510180134171.issue28984@psf.upfronthosting.co.za>
Message-ID: <1481850063.95.0.366041666281.issue28984@psf.upfronthosting.co.za>


Ned Deily added the comment:

I agree with Josh's assessment. Sorry!

----------
nosy: +ned.deily
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28984>
_______________________________________

From report at bugs.python.org  Thu Dec 15 20:09:01 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Fri, 16 Dec 2016 01:09:01 +0000
Subject: [issue28982] multiprocessing.Queue.get(block=True,
 timeout=0) always raises queue.Empty
In-Reply-To: <1481834665.78.0.584713250682.issue28982@psf.upfronthosting.co.za>
Message-ID: <1481850541.56.0.380483677308.issue28982@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

That argument combination appears to be undefined in the docs, the only cases covered are:

block truthy, timeout is None

block truthy, timeout is positive

block falsy, (timeout unspecified)

The case of block truthy, timeout <= 0 is not documented.

Saying "Block for a result, but not for any length of time" is a tad strange; I'd be inclined to make it an error, not a synonym for block == False.

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28982>
_______________________________________

From report at bugs.python.org  Thu Dec 15 20:20:55 2016
From: report at bugs.python.org (Rhesa Browning)
Date: Fri, 16 Dec 2016 01:20:55 +0000
Subject: [issue28983] Python 3.5.2 won't install on my computer
In-Reply-To: <1481840742.78.0.554470867064.issue28983@psf.upfronthosting.co.za>
Message-ID: <1481851255.65.0.464386489726.issue28983@psf.upfronthosting.co.za>


Rhesa Browning added the comment:

I went through your instructions without any improvement.  I first uninstalled the program.  Then I reinstalled without the items that you listed the tcl/tk and pip.  The error message still came up just like before.  Then I typed the two programs you gave me into the command prompt.  A message asked me for permission to uninstall the program, which I accepted.  Then I got an error message that said the program only works for products that are already installed.

If I try to open python now, I get the same error message "The program can't start because python35.dll is missing from your computer."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28983>
_______________________________________

From report at bugs.python.org  Thu Dec 15 20:22:14 2016
From: report at bugs.python.org (Eric Lafontaine)
Date: Fri, 16 Dec 2016 01:22:14 +0000
Subject: [issue28972] Document all "python -m" utilities
In-Reply-To: <1481720403.32.0.43245427479.issue28972@psf.upfronthosting.co.za>
Message-ID: <1481851334.59.0.316140574402.issue28972@psf.upfronthosting.co.za>


Eric Lafontaine added the comment:

Hi,

I believe it's already done.  The only thing that people tends to forget is that doing python -m "module.script(.py)" is only doing the equivalent of "python module/script.py". 

I believe it's clear though ;
https://docs.python.org/3/using/cmdline.html#cmdoption-m

Any module that anyone has done can do it, so it would be up to the module developer to put it in the README/Description of the module to describe how to use it.  That's what I think

BTW, I'm just giving my opinion out of contributing.  Please don't see it as a denial as it's not the case.  Python strive to be clearer but has 20 years of existence.  Enhancing it is hard.

Regards,
Eric Lafontaine

----------
nosy: +Eric Lafontaine

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28972>
_______________________________________

From report at bugs.python.org  Thu Dec 15 20:36:03 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 16 Dec 2016 01:36:03 +0000
Subject: [issue28794] inspect.isasyncgen and inspect.isasyncgenfunction aren't
 documented
In-Reply-To: <1480025404.72.0.713291262903.issue28794@psf.upfronthosting.co.za>
Message-ID: <1481852163.91.0.64118199906.issue28794@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, but these two functions have already been documented in 78c8f450b84c. Closing this as 'out of date'.

----------
nosy: +berker.peksag
resolution:  -> out of date
stage: commit review -> resolved
status: open -> closed
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28794>
_______________________________________

From report at bugs.python.org  Thu Dec 15 21:12:46 2016
From: report at bugs.python.org (Eric Lafontaine)
Date: Fri, 16 Dec 2016 02:12:46 +0000
Subject: [issue28879] smtplib send_message should add Date header if it is
 missing, per RFC5322
In-Reply-To: <1480952895.22.0.418354723664.issue28879@psf.upfronthosting.co.za>
Message-ID: <1481854366.24.0.0548341121635.issue28879@psf.upfronthosting.co.za>


Eric Lafontaine added the comment:

Hi all,

Thanks for the enlightment.  I never figured that there was a send_message function XD.  Never needed it and it's true that the example in the email library use sendmail and not send_message.
https://docs.python.org/2/library/smtplib.html#smtplib.SMTP.sendmail
https://docs.python.org/3.5/library/smtplib.html#smtplib.SMTP.send_message

This function is fairly recent (python 3.2) from what I see.

Reading the documentation of the python 3.5 send_message function :
"[...] If from_addr is None or to_addrs is None, send_message fills those arguments with addresses extracted from the headers of msg as specified in RFC 5322: from_addr is set to the Sender field if it is present, and otherwise to the From field. to_addrs combines the values (if any) of the To, Cc, and Bcc fields from msg. "

As we're already using this function for convenience of the RFC 5322, then I agree to add it.  We should also modify the doc & comment inside the code to make it clear that date is added if absent and following RFC 5322. (I've looked at the source and the send_message only mention RFC2822 in the comments, no RFC 5322).

Finally, why would we want to add a validate fonction to the email library?  What would it do ? validate that we respect a certain RFC?  Who other than SMTPlib would use it?  I would like to understand the reasonning behind it.  

Again, all this are opinions to let the discussion continue :).

For now, what I see we need to do (this bullet point list is intended to be expanded with what you think we need to do):
- implement a patch for the code to add a missing "Date" field if it doesn't exist
- Modify the documentation at the SMTPLib for the send_message to mention that it add missing date using the email.utils.formatdate
- Modify the comment of the send_message code to mention RFC 5322 in there (ideally with the section of the RFC).
- Fix it on all Python3 versions?  It should have been supported since 3.2 right?

As it's my first time trying to contribute... I still don't know how to do so...

Regards,
Eric Lafontaine
eric.lafontaine1 at gmail.com <= if you can help me outside of this discussion to contribute, it would be my pleasure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28879>
_______________________________________

From report at bugs.python.org  Thu Dec 15 21:31:01 2016
From: report at bugs.python.org (R. David Murray)
Date: Fri, 16 Dec 2016 02:31:01 +0000
Subject: [issue28879] smtplib send_message should add Date header if it is
 missing, per RFC5322
In-Reply-To: <1480952895.22.0.418354723664.issue28879@psf.upfronthosting.co.za>
Message-ID: <1481855461.42.0.929484366264.issue28879@psf.upfronthosting.co.za>


R. David Murray added the comment:

Sure the comments can be updated.  Some of them elsewhere have been already.

The reason for the email library to have a validation function is that it has an 'SMTP' policy that is designed to produce valid SMTP messages when the message is serialized.  (It also has an HTTP policy that is designed to produce valid HTTP header blocks...though I'm sure there are bugs there as well).  These policies are relatively new, even newer than the send_message method of smtplib.

If this gets done it time it could be fixed in 3.5...Larry is planning the final non-security-fix 3.5 release some time after 3.6.0 final goes out the door, as is our tradition.  After that it could only go into what will very shortly be the maintenance release (3.6) and the next feature release (3.7).

To contribute, create a diff against the tip of the default branch and post it here.  (We will be switching to github "soon", but posting a patch here will always work).  See docs.python.org/devguide for more details on contributing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28879>
_______________________________________

From report at bugs.python.org  Thu Dec 15 22:24:53 2016
From: report at bugs.python.org (Dingyuan Wang)
Date: Fri, 16 Dec 2016 03:24:53 +0000
Subject: [issue28985] sqlite3 authorizer codes constants not up to date
Message-ID: <1481858693.19.0.888054078986.issue28985@psf.upfronthosting.co.za>


New submission from Dingyuan Wang:

We have the sqlite3.set_authorizer function, where the first argument to its callback is one of the Authorizer Action Codes that the SQLite documentations defines[1]. However, the constants in the sqlite3 module is not up to date. The code in _sqlite/module.c haven't been updated since June, 2006.

According to the SQLite Changelog[2] and digging through the history,

* 2006-08-12 (3.3.7) added SQLITE_CREATE_VTABLE, SQLITE_DROP_VTABLE
* 2006-10-09 (3.3.8) added SQLITE_FUNCTION
* 2009-01-12 (3.6.8) added SQLITE_SAVEPOINT
* 2014-02-03 (3.8.3) added SQLITE_RECURSIVE

The constants above should be present in the module. The documentation[3] says, "All necessary constants are available in the sqlite3 module."

[1] https://sqlite.org/c3ref/c_alter_table.html
[2] https://sqlite.org/changes.html
[3] https://docs.python.org/3/library/sqlite3.html#sqlite3.Connection.set_authorizer

----------
components: Library (Lib)
files: sqlite3.patch
keywords: patch
messages: 283363
nosy: gumblex
priority: normal
severity: normal
status: open
title: sqlite3 authorizer codes constants not up to date
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45921/sqlite3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28985>
_______________________________________

From report at bugs.python.org  Thu Dec 15 23:01:28 2016
From: report at bugs.python.org (Ned Deily)
Date: Fri, 16 Dec 2016 04:01:28 +0000
Subject: [issue28689] OpenSSL 1.1.0c test failures
In-Reply-To: <1479132647.76.0.450425015981.issue28689@psf.upfronthosting.co.za>
Message-ID: <1481860888.37.0.898618204925.issue28689@psf.upfronthosting.co.za>


Ned Deily added the comment:

I added the following text to the "Notes on this release" section for the 3.6.0rc1 release page and will copy it to future 3.6.x release pages until sometime after a fixed 1.1.0 is released:

"If you are building Python from source, beware that the OpenSSL 1.1.0c release, the most recent as of this update, is known to cause Python 3.6 test suite failures and its use should be avoided without additional patches. It is expected that the next release of the OpenSSL 1.1.0 series will fix these problems. See http://bugs.python.org/issue28689 for more information."

https://www.python.org/downloads/release/python-360rc1/

I'm closing this issue for now; feel free to reopen if there is something else you plan to do with it.

----------
priority: release blocker -> 
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28689>
_______________________________________

From report at bugs.python.org  Fri Dec 16 01:12:12 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 16 Dec 2016 06:12:12 +0000
Subject: [issue28985] sqlite3 authorizer codes constants not up to date
In-Reply-To: <1481858693.19.0.888054078986.issue28985@psf.upfronthosting.co.za>
Message-ID: <1481868732.79.0.934952029344.issue28985@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Looks good to me. Thanks for the patch, Dingyuan.

Since this is an enhancement request, we can only commit your patch to the default branch so I updated the versions field accordingly.

----------
nosy: +berker.peksag
stage:  -> patch review
versions:  -Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28985>
_______________________________________

From report at bugs.python.org  Fri Dec 16 01:22:13 2016
From: report at bugs.python.org (Manish Singh)
Date: Fri, 16 Dec 2016 06:22:13 +0000
Subject: [issue28968] xml rpc server fails with connection reset by peer error
 no 104
In-Reply-To: <1481709223.17.0.559234955094.issue28968@psf.upfronthosting.co.za>
Message-ID: <1481869333.54.0.94237832901.issue28968@psf.upfronthosting.co.za>


Manish Singh added the comment:

Hi David Murray,
Thanks for replying.

I have mentioned that my client and server are running on same host. So communication is going through localhost address.

I have checked for possible reasons of connection reset by peer error, below are the possible causes,

1) The machine is connected to the network, and the network is not responsive. 
2) The other side of the connection is not running normally. 
3) There are not enough system resources available. Free up system resources if they are running low. 

Possibility for 1 and 2 are not applicable as it is loopback communication.

For Possibility 3, I have already checked system resource and there are enough resources. 

You can check below stack overflow link.
http://stackoverflow.com/questions/1434451/what-does-connection-reset-by-peer-mean?rq=1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28968>
_______________________________________

From report at bugs.python.org  Fri Dec 16 01:28:49 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Dec 2016 06:28:49 +0000
Subject: [issue28971] nntplib is broken when responses are longer than _MAXLINE
In-Reply-To: <1481716454.12.0.730668429479.issue28971@psf.upfronthosting.co.za>
Message-ID: <1481869729.55.0.148907004867.issue28971@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The limit to readline() was added to prevent consuming an excessive amount of memory. But this doesn't help in case of long multiline responses, since all lines are accumulated in a list in memory. A malicious server could cause a client consuming an excessive amount of memory by sending large number of short lines instead of one long line.

Christian, what are you think about this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28971>
_______________________________________

From report at bugs.python.org  Fri Dec 16 01:48:48 2016
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 16 Dec 2016 06:48:48 +0000
Subject: [issue28689] OpenSSL 1.1.0c test failures
In-Reply-To: <1479132647.76.0.450425015981.issue28689@psf.upfronthosting.co.za>
Message-ID: <1481870928.6.0.522000087098.issue28689@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Thanks, Ned!

To clarify, it's not jus the test suite. OpenSSL 1.1.0c broke the ssl module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28689>
_______________________________________

From report at bugs.python.org  Fri Dec 16 02:12:06 2016
From: report at bugs.python.org (Jiajun Huang)
Date: Fri, 16 Dec 2016 07:12:06 +0000
Subject: [issue28961] unittest.mock._Call ignores `name` parameter
In-Reply-To: <1481636868.17.0.0411235027553.issue28961@psf.upfronthosting.co.za>
Message-ID: <1481872326.1.0.511954311165.issue28961@psf.upfronthosting.co.za>


Jiajun Huang added the comment:

code and test case has been updated.

----------
Added file: http://bugs.python.org/file45922/mock.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28961>
_______________________________________

From report at bugs.python.org  Fri Dec 16 02:21:19 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Dec 2016 07:21:19 +0000
Subject: [issue28977] Document PyObject_CallFunction() special case more
 explicitly
In-Reply-To: <1481790961.1.0.0700086912401.issue28977@psf.upfronthosting.co.za>
Message-ID: <1481872879.84.0.0114129819879.issue28977@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

"O" is not the only special case. "S" and "N" unpack a tuple argument too. "O&" converter should return a tuple, otherwise it is an error. All other format codes are illegal for single argument.

I would just deprecate this feature (in PyObject_CallFunction, not in Py_BuildValue). The behavior of PyObject_CallFunction with a single argument can be made more consistent and useful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28977>
_______________________________________

From report at bugs.python.org  Fri Dec 16 02:44:42 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 16 Dec 2016 07:44:42 +0000
Subject: [issue28900] update 'docs for other versions'
In-Reply-To: <1481167683.31.0.460396131564.issue28900@psf.upfronthosting.co.za>
Message-ID: <20161216074439.1688.10709.8CCF2EF5@psf.io>


Roundup Robot added the comment:

New changeset 257a1c7f9507 by Ned Deily in branch '3.6':
Issue #28900: Update documentation sidebar for 3.6.0rc.
https://hg.python.org/cpython/rev/257a1c7f9507

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28900>
_______________________________________

From report at bugs.python.org  Fri Dec 16 02:44:42 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 16 Dec 2016 07:44:42 +0000
Subject: [issue28979] What's New entry on compact dict mentions "faster"
 implementation
In-Reply-To: <1481809932.35.0.280442382983.issue28979@psf.upfronthosting.co.za>
Message-ID: <20161216074439.1688.92423.827B54BE@psf.io>


Roundup Robot added the comment:

New changeset 911cc601089d by Victor Stinner in branch '3.6':
Issue #28979: Fix What's New in Python 3.6, dict
https://hg.python.org/cpython/rev/911cc601089d

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28979>
_______________________________________

From report at bugs.python.org  Fri Dec 16 02:44:44 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 16 Dec 2016 07:44:44 +0000
Subject: [issue28783] Embedded/nuget packages incorrectly reference
 bdist_wininst
In-Reply-To: <1479925784.02.0.834073933599.issue28783@psf.upfronthosting.co.za>
Message-ID: <20161216074439.1688.74036.45079B2C@psf.io>


Roundup Robot added the comment:

New changeset 1f69fb337288 by Steve Dower in branch '3.6':
Issue #28783: Replaces bdist_wininst in nuget packages with stub
https://hg.python.org/cpython/rev/1f69fb337288

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28783>
_______________________________________

From report at bugs.python.org  Fri Dec 16 02:44:44 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 16 Dec 2016 07:44:44 +0000
Subject: [issue28147] Unbounded memory growth resizing split-table dicts
In-Reply-To: <1473853453.13.0.556951743271.issue28147@psf.upfronthosting.co.za>
Message-ID: <20161216074439.1688.39306.C49556F7@psf.io>


Roundup Robot added the comment:

New changeset b70b2d3f3167 by Victor Stinner in branch '3.6':
Fix a memory leak in split-table dictionaries
https://hg.python.org/cpython/rev/b70b2d3f3167

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28147>
_______________________________________

From report at bugs.python.org  Fri Dec 16 02:44:45 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 16 Dec 2016 07:44:45 +0000
Subject: [issue28091] Document PEP 525 & 530
In-Reply-To: <1480969186.28.0.879526881588.issue28091@psf.upfronthosting.co.za>
Message-ID: <20161216074439.1688.83213.A375721B@psf.io>


Roundup Robot added the comment:

New changeset 5a11263bb612 by Yury Selivanov in branch '3.6':
Issue #28091: Document PEP 525 & PEP 530.
https://hg.python.org/cpython/rev/5a11263bb612

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28091>
_______________________________________

From report at bugs.python.org  Fri Dec 16 02:44:45 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 16 Dec 2016 07:44:45 +0000
Subject: [issue28896] Embeddable zip allows Windows registry to override
 module location
In-Reply-To: <1481128708.35.0.521458556277.issue28896@psf.upfronthosting.co.za>
Message-ID: <20161216074439.1688.80236.BA3198E5@psf.io>


Roundup Robot added the comment:

New changeset 6249350e654a by Steve Dower in branch '3.6':
Issue #28896: Deprecate WindowsRegistryFinder
https://hg.python.org/cpython/rev/6249350e654a

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28896>
_______________________________________

From report at bugs.python.org  Fri Dec 16 02:44:47 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 16 Dec 2016 07:44:47 +0000
Subject: [issue28089] asyncio: Document that TCP_NODELAY is now used by default
In-Reply-To: <1480969004.54.0.512137578278.issue28089@psf.upfronthosting.co.za>
Message-ID: <20161216074439.1688.40322.A244661C@psf.io>


Roundup Robot added the comment:

New changeset dfd1019f75f9 by Yury Selivanov in branch '3.6':
Issue #28089: Document TCP_NODELAY in asyncio
https://hg.python.org/cpython/rev/dfd1019f75f9

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28089>
_______________________________________

From report at bugs.python.org  Fri Dec 16 02:44:47 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 16 Dec 2016 07:44:47 +0000
Subject: [issue28898] Can't compile gdb with Python 3.6
In-Reply-To: <1481134479.52.0.174259382887.issue28898@psf.upfronthosting.co.za>
Message-ID: <20161216074439.1688.49106.C4EF790B@psf.io>


Roundup Robot added the comment:

New changeset d6c8803c55b4 by Benjamin Peterson in branch '3.6':
guard HAVE_LONG_LONG definition to prevent redefinition (#28898)
https://hg.python.org/cpython/rev/d6c8803c55b4

New changeset 9d0765c22bed by Ned Deily in branch '3.6':
Issue #28898: add Misc/NEWS entry
https://hg.python.org/cpython/rev/9d0765c22bed

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28898>
_______________________________________

From report at bugs.python.org  Fri Dec 16 02:44:48 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 16 Dec 2016 07:44:48 +0000
Subject: [issue28635] Update What's New for 3.6
In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za>
Message-ID: <20161216074439.1688.76082.664DBBA7@psf.io>


Roundup Robot added the comment:

New changeset cb4ad88fdc91 by Yury Selivanov in branch '3.6':
Issue #28635: Drop the note that whatsnew is incomplete
https://hg.python.org/cpython/rev/cb4ad88fdc91

New changeset c4d6ef15bb7c by Yury Selivanov in branch '3.6':
Issue #28635: asyncio-related fixes and additions.
https://hg.python.org/cpython/rev/c4d6ef15bb7c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28635>
_______________________________________

From report at bugs.python.org  Fri Dec 16 02:49:45 2016
From: report at bugs.python.org (Ned Deily)
Date: Fri, 16 Dec 2016 07:49:45 +0000
Subject: [issue28635] Update What's New for 3.6
In-Reply-To: <1478553156.63.0.138924593802.issue28635@psf.upfronthosting.co.za>
Message-ID: <1481874585.26.0.152437443016.issue28635@psf.upfronthosting.co.za>


Ned Deily added the comment:

[cherrypicked for 3.6.0r2]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28635>
_______________________________________

From report at bugs.python.org  Fri Dec 16 02:51:07 2016
From: report at bugs.python.org (Ned Deily)
Date: Fri, 16 Dec 2016 07:51:07 +0000
Subject: [issue28898] Can't compile gdb with Python 3.6
In-Reply-To: <1481134479.52.0.174259382887.issue28898@psf.upfronthosting.co.za>
Message-ID: <1481874667.77.0.121700703282.issue28898@psf.upfronthosting.co.za>


Ned Deily added the comment:

[cherrypicked for 3.6.0rc2]

----------
assignee: ned.deily -> 
priority: release blocker -> 
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28898>
_______________________________________

From report at bugs.python.org  Fri Dec 16 02:52:09 2016
From: report at bugs.python.org (Ned Deily)
Date: Fri, 16 Dec 2016 07:52:09 +0000
Subject: [issue28896] Embeddable zip allows Windows registry to override
 module location
In-Reply-To: <1481128708.35.0.521458556277.issue28896@psf.upfronthosting.co.za>
Message-ID: <1481874729.72.0.647775278928.issue28896@psf.upfronthosting.co.za>


Ned Deily added the comment:

[cherrypicked for 3.6.0rc2]

----------
priority: release blocker -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28896>
_______________________________________

From report at bugs.python.org  Fri Dec 16 02:53:05 2016
From: report at bugs.python.org (Ned Deily)
Date: Fri, 16 Dec 2016 07:53:05 +0000
Subject: [issue28783] Embedded/nuget packages incorrectly reference
 bdist_wininst
In-Reply-To: <1479925784.02.0.834073933599.issue28783@psf.upfronthosting.co.za>
Message-ID: <1481874785.53.0.107311084219.issue28783@psf.upfronthosting.co.za>


Ned Deily added the comment:

[cherrypicked for 3.6.0rc2]

----------
priority: release blocker -> 
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28783>
_______________________________________

From report at bugs.python.org  Fri Dec 16 02:54:15 2016
From: report at bugs.python.org (Ned Deily)
Date: Fri, 16 Dec 2016 07:54:15 +0000
Subject: [issue28089] asyncio: Document that TCP_NODELAY is now used by default
In-Reply-To: <1480969004.54.0.512137578278.issue28089@psf.upfronthosting.co.za>
Message-ID: <1481874855.35.0.0572317002013.issue28089@psf.upfronthosting.co.za>


Ned Deily added the comment:

[cherrypicked for 3.6.0rc2]

----------
priority: deferred blocker -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28089>
_______________________________________

From report at bugs.python.org  Fri Dec 16 02:55:29 2016
From: report at bugs.python.org (Ned Deily)
Date: Fri, 16 Dec 2016 07:55:29 +0000
Subject: [issue28979] What's New entry on compact dict mentions "faster"
 implementation
In-Reply-To: <1481809932.35.0.280442382983.issue28979@psf.upfronthosting.co.za>
Message-ID: <1481874929.68.0.859926562896.issue28979@psf.upfronthosting.co.za>


Ned Deily added the comment:

[cherrypicked for 3.6.0rc2]

----------
priority: release blocker -> 
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28979>
_______________________________________

From report at bugs.python.org  Fri Dec 16 02:57:17 2016
From: report at bugs.python.org (Ned Deily)
Date: Fri, 16 Dec 2016 07:57:17 +0000
Subject: [issue28147] Unbounded memory growth resizing split-table dicts
In-Reply-To: <1473853453.13.0.556951743271.issue28147@psf.upfronthosting.co.za>
Message-ID: <1481875037.3.0.616674174388.issue28147@psf.upfronthosting.co.za>


Ned Deily added the comment:

[cherrypicked for 3.6.0rc2]

----------
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28147>
_______________________________________

From report at bugs.python.org  Fri Dec 16 02:58:06 2016
From: report at bugs.python.org (Ned Deily)
Date: Fri, 16 Dec 2016 07:58:06 +0000
Subject: [issue28091] Document PEP 525 & 530
In-Reply-To: <1480969186.28.0.879526881588.issue28091@psf.upfronthosting.co.za>
Message-ID: <1481875086.89.0.409374028648.issue28091@psf.upfronthosting.co.za>


Ned Deily added the comment:

[cherrypicked for 3.6.0rc2]

----------
priority: deferred blocker -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28091>
_______________________________________

From report at bugs.python.org  Fri Dec 16 03:00:29 2016
From: report at bugs.python.org (Manish Singh)
Date: Fri, 16 Dec 2016 08:00:29 +0000
Subject: [issue28968] xml rpc server fails with connection reset by peer error
 no 104
In-Reply-To: <1481709223.17.0.559234955094.issue28968@psf.upfronthosting.co.za>
Message-ID: <1481875229.92.0.278520714831.issue28968@psf.upfronthosting.co.za>


Manish Singh added the comment:

Hi David Murray,

Please refer this link,

http://stackoverflow.com/questions/383738/104-connection-reset-by-peer-socket-error-or-when-does-closing-a-socket-resu

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28968>
_______________________________________

From report at bugs.python.org  Fri Dec 16 03:01:46 2016
From: report at bugs.python.org (Ned Deily)
Date: Fri, 16 Dec 2016 08:01:46 +0000
Subject: [issue28900] update 'docs for other versions'
In-Reply-To: <1481167683.31.0.460396131564.issue28900@psf.upfronthosting.co.za>
Message-ID: <1481875306.64.0.59772053673.issue28900@psf.upfronthosting.co.za>


Ned Deily added the comment:

[cherrypicked for 3.6.0rc2]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28900>
_______________________________________

From report at bugs.python.org  Fri Dec 16 03:02:38 2016
From: report at bugs.python.org (Ned Deily)
Date: Fri, 16 Dec 2016 08:02:38 +0000
Subject: [issue28900] update 'docs for other versions'
In-Reply-To: <1481167683.31.0.460396131564.issue28900@psf.upfronthosting.co.za>
Message-ID: <1481875358.24.0.201152668186.issue28900@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
priority: release blocker -> 
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28900>
_______________________________________

From report at bugs.python.org  Fri Dec 16 03:07:54 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Dec 2016 08:07:54 +0000
Subject: [issue28977] Document PyObject_CallFunction() special case more
 explicitly
In-Reply-To: <1481790961.1.0.0700086912401.issue28977@psf.upfronthosting.co.za>
Message-ID: <1481875674.43.0.0310547265459.issue28977@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Serhiy: "O" is not the only special case. "S" and "N" unpack a tuple argument too. "O&" converter should return a tuple, otherwise it is an error. All other format codes are illegal for single argument.

Oh, I didn't know. I should update my documentation.


Serhiy: I would just deprecate this feature (in PyObject_CallFunction, not in Py_BuildValue). The behavior of PyObject_CallFunction with a single argument can be made more consistent and useful.

PyObject_CallFunction(func, "O", arg) should call func(arg). I don't want the "O" format (and "S" and "N").

What do you mean exactly by deprecating the feature? Emit a warning if and only if te format string is "O" (or "S" or "N") and Py_BuildValue() returns a tuple?

I guess that PyObject_CallFunction(func, "(O)", arg) doesn't need to be modified, it already always call func(arg), even if arg is a tuple.

I am also tempted to fix PyObject_CallFunction() (and similar functions) rather than documenting the special case, but I dislike the idea of a deprecation.

Let's say that calling PyObject_CallFunction(func, "O", arg) where arg is a tuple would emit a DeprecationWarning and call func(*arg) in Python 3.7, but call func(arg) with no warning in Python 3.8. I dislike this path because developers would try to make the warning quiet in Python 3.7, for example use "(O)" format string, which is less obvious and looks like a hack to me.


More and more applications use Python bleeding edge (the development branch, default), and more and more developers quickly test their application on the new Python stable release. Maybe we can "simply" fix the behaviour of PyObject_CallFunction() with no transition period:

* Python 3.6: PyObject_CallFunction(func, "O", arg) calls func(arg), or func(*arg) if arg is a tuple
* Python 3.7: PyObject_CallFunction(func, "O", arg) always calls func(arg)

The special case was never documented. In my experience, almost no developer rely on this feature. Most developers don't expect the feature and so write code which doesn't work with tuple arguments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28977>
_______________________________________

From report at bugs.python.org  Fri Dec 16 03:14:52 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Dec 2016 08:14:52 +0000
Subject: [issue28977] Document PyObject_CallFunction() special case more
 explicitly
In-Reply-To: <1481790961.1.0.0700086912401.issue28977@psf.upfronthosting.co.za>
Message-ID: <1481876092.65.0.30455244179.issue28977@psf.upfronthosting.co.za>


STINNER Victor added the comment:

If the behaviour of PyObject_CallFunction(func, "O", arg) is changed, an application relying on the current behaviour would have to replace:

   res = PyObject_CallFunction(func, "O", arg);

with:

   /* code working on any Python version */
   if (PyTuple_Check(arg))
       res = PyObject_Call(func, arg, NULL);
   else
       res = PyObject_CallFunction(func, "O", arg);

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28977>
_______________________________________

From report at bugs.python.org  Fri Dec 16 03:27:49 2016
From: report at bugs.python.org (Ned Deily)
Date: Fri, 16 Dec 2016 08:27:49 +0000
Subject: [issue28770] Update python-gdb.py for fastcalls
In-Reply-To: <1479814975.16.0.381517171433.issue28770@psf.upfronthosting.co.za>
Message-ID: <1481876869.19.0.234970533001.issue28770@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
nosy: +ned.deily
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28770>
_______________________________________

From report at bugs.python.org  Fri Dec 16 03:28:44 2016
From: report at bugs.python.org (Ned Deily)
Date: Fri, 16 Dec 2016 08:28:44 +0000
Subject: [issue28770] Update python-gdb.py for fastcalls
In-Reply-To: <1479814975.16.0.381517171433.issue28770@psf.upfronthosting.co.za>
Message-ID: <1481876924.37.0.128371856357.issue28770@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28770>
_______________________________________

From report at bugs.python.org  Fri Dec 16 03:33:55 2016
From: report at bugs.python.org (INADA Naoki)
Date: Fri, 16 Dec 2016 08:33:55 +0000
Subject: [issue28147] Unbounded memory growth resizing split-table dicts
In-Reply-To: <1473853453.13.0.556951743271.issue28147@psf.upfronthosting.co.za>
Message-ID: <1481877235.57.0.977855940592.issue28147@psf.upfronthosting.co.za>


INADA Naoki added the comment:

Oh, I'm sorry.  It seems I had failed to push the commit yesterday.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28147>
_______________________________________

From report at bugs.python.org  Fri Dec 16 03:49:50 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Dec 2016 08:49:50 +0000
Subject: [issue28977] Document PyObject_CallFunction() special case more
 explicitly
In-Reply-To: <1481875674.43.0.0310547265459.issue28977@psf.upfronthosting.co.za>
Message-ID: <3340200.JrNllmOg0l@raxxla>


Serhiy Storchaka added the comment:

> All other format codes are illegal for single argument.

I was wrong. PyObject_CallFunction() handles correctly a single non-tuple 
argument. The problem is only with tuple result of Py_BuildValue().

> What do you mean exactly by deprecating the feature? Emit a warning if and
> only if te format string is "O" (or "S" or "N") and Py_BuildValue() returns
> a tuple?

Emit a FutureWarning if the format string contains the single format code and 
Py_BuildValue() returns a tuple. In 3.8 or 3.9 the behavior will be changed.

> I dislike this path
> because developers would try to make the warning quiet in Python 3.7, for
> example use "(O)" format string, which is less obvious and looks like a
> hack to me.

PyObject_CallFunctionObjArgs(func, arg, NULL) seems obvious and perhaps even 
more efficient in all versions.

> More and more applications use Python bleeding edge (the development branch,
> default), and more and more developers quickly test their application on
> the new Python stable release. Maybe we can "simply" fix the behaviour of
> PyObject_CallFunction() with no transition period:

Ask on Python-Dev. I afraid this is too dangerous. We should have at least one 
release with a FutureWarning.

> Most developers don't expect the feature and so write
> code which doesn't work with tuple arguments.

That is why we should add a FutureWarning. If the code doesn't fail by 
accident, but just works incorrectly, this can be unnoticed. FutureWarning 
could help to fix possible bugs in older Python versions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28977>
_______________________________________

From report at bugs.python.org  Fri Dec 16 04:13:52 2016
From: report at bugs.python.org (Nick Evans)
Date: Fri, 16 Dec 2016 09:13:52 +0000
Subject: [issue28986] Docs should say set.update takes iterable
Message-ID: <1481879632.81.0.577859496056.issue28986@psf.upfronthosting.co.za>


New submission from Nick Evans:

The docs say that set.update takes *args:

  update(*others)

But actually set.update takes an optional iterable:

  update([iterable])

----------
assignee: docs at python
components: Documentation
messages: 283394
nosy: docs at python, nre3976
priority: normal
severity: normal
status: open
title: Docs should say set.update takes iterable
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28986>
_______________________________________

From report at bugs.python.org  Fri Dec 16 04:24:59 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Dec 2016 09:24:59 +0000
Subject: [issue28147] Unbounded memory growth resizing split-table dicts
In-Reply-To: <1481877235.57.0.977855940592.issue28147@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwaeJKAMYXvWMwdwwV5rwFrSdVBaENyXQUGKkj74ZQNcOg@mail.gmail.com>


STINNER Victor added the comment:

> Oh, I'm sorry.  It seems I had failed to push the commit yesterday.

No problem. Thanks for your fix! I prefer to not see the bug in Python
3.6.0 final!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28147>
_______________________________________

From report at bugs.python.org  Fri Dec 16 05:17:12 2016
From: report at bugs.python.org (Knut)
Date: Fri, 16 Dec 2016 10:17:12 +0000
Subject: [issue28984] json.dump + indent creates trailing extra spaces
In-Reply-To: <1481843478.24.0.510180134171.issue28984@psf.upfronthosting.co.za>
Message-ID: <1481883432.97.0.945673218885.issue28984@psf.upfronthosting.co.za>


Knut added the comment:

sorry, I missed that point in the docs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28984>
_______________________________________

From report at bugs.python.org  Fri Dec 16 07:00:14 2016
From: report at bugs.python.org (David Andersen)
Date: Fri, 16 Dec 2016 12:00:14 +0000
Subject: [issue13051] Infinite recursion in curses.textpad.Textbox
In-Reply-To: <1317170831.29.0.145546521568.issue13051@psf.upfronthosting.co.za>
Message-ID: <1481889614.43.0.0213229997258.issue13051@psf.upfronthosting.co.za>


David Andersen added the comment:

Any progress on this? Its Dec 2016 and this bug is still around. There's a patch and a patch with tests. The problem is well-understood. I'm not sure what the holdup is, but it would be great to get fixed!

----------
nosy: +rxcomm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13051>
_______________________________________

From report at bugs.python.org  Fri Dec 16 07:22:43 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Dec 2016 12:22:43 +0000
Subject: [issue20191] resource.prlimit(int, int, str) crashs
In-Reply-To: <1389191622.9.0.0763750909735.issue20191@psf.upfronthosting.co.za>
Message-ID: <1481890963.74.0.791334466056.issue20191@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20191>
_______________________________________

From report at bugs.python.org  Fri Dec 16 07:55:10 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Dec 2016 12:55:10 +0000
Subject: [issue28518] execute("begin immediate") throwing OperationalError
In-Reply-To: <1477307118.31.0.70785963389.issue28518@psf.upfronthosting.co.za>
Message-ID: <1481892910.98.0.116879820192.issue28518@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a little simplified version. No need to handle a single "begin".

----------
Added file: http://bugs.python.org/file45923/sqlite-explicit-begin2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28518>
_______________________________________

From report at bugs.python.org  Fri Dec 16 08:26:53 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 16 Dec 2016 13:26:53 +0000
Subject: [issue25658] PyThread assumes pthread_key_t is an integer,
 which is against POSIX
In-Reply-To: <1447861816.88.0.632584646231.issue25658@psf.upfronthosting.co.za>
Message-ID: <1481894813.14.0.205228287456.issue25658@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25658>
_______________________________________

From report at bugs.python.org  Fri Dec 16 09:06:01 2016
From: report at bugs.python.org (R. David Murray)
Date: Fri, 16 Dec 2016 14:06:01 +0000
Subject: [issue28986] Docs should say set.update takes iterable
In-Reply-To: <1481879632.81.0.577859496056.issue28986@psf.upfronthosting.co.za>
Message-ID: <1481897161.3.0.1618513129.issue28986@psf.upfronthosting.co.za>


R. David Murray added the comment:

update([iterable]) is a specific case of update(*others).  udpate([1, 2], [3, 4]) is another specific case.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28986>
_______________________________________

From report at bugs.python.org  Fri Dec 16 09:19:17 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 16 Dec 2016 14:19:17 +0000
Subject: [issue28959] Add a macro for dict size
In-Reply-To: <1481634421.56.0.985862767516.issue28959@psf.upfronthosting.co.za>
Message-ID: <20161216141914.16255.18835.D787173B@psf.io>


Roundup Robot added the comment:

New changeset dbf72357cb4a by Serhiy Storchaka in branch 'default':
Issue #28959: Added private macro PyDict_GET_SIZE for retrieving the size of dict.
https://hg.python.org/cpython/rev/dbf72357cb4a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28959>
_______________________________________

From report at bugs.python.org  Fri Dec 16 09:49:37 2016
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Fri, 16 Dec 2016 14:49:37 +0000
Subject: [issue28987] Remove typo in whats new entry on Descriptor Protocol
 Enhancements
Message-ID: <1481899777.6.0.168027118987.issue28987@psf.upfronthosting.co.za>


New submission from Jim Fasarakis-Hilliard:

Attached patch removes small typo ('has') from text:

    extends the descriptor protocol has to include the new optional

----------
assignee: docs at python
components: Documentation
files: whatsnew_typo.patch
keywords: patch
messages: 283401
nosy: Jim Fasarakis-Hilliard, docs at python
priority: normal
severity: normal
status: open
title: Remove typo in whats new entry on Descriptor Protocol Enhancements
versions: Python 3.6
Added file: http://bugs.python.org/file45924/whatsnew_typo.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28987>
_______________________________________

From report at bugs.python.org  Fri Dec 16 09:58:48 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Dec 2016 14:58:48 +0000
Subject: [issue28770] Update python-gdb.py for fastcalls
In-Reply-To: <1479814975.16.0.381517171433.issue28770@psf.upfronthosting.co.za>
Message-ID: <1481900328.26.0.799477727662.issue28770@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The change was cherry-picked in Python 3.6.0RC2.

The issue is now fixed, so I close the issue.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28770>
_______________________________________

From report at bugs.python.org  Fri Dec 16 10:00:02 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Dec 2016 15:00:02 +0000
Subject: [issue28838] Using consistent naming for arguments of "call"
 functions (C API)
In-Reply-To: <1480504437.73.0.907175245586.issue28838@psf.upfronthosting.co.za>
Message-ID: <1481900402.62.0.477613420511.issue28838@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I consider that the cleanup itself is done, so I close the issue. For further enhancements, I will open new issues.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28838>
_______________________________________

From report at bugs.python.org  Fri Dec 16 10:01:07 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Dec 2016 15:01:07 +0000
Subject: [issue28988] Switch dict and set structures to PyVarObject
Message-ID: <1481900465.81.0.491407063999.issue28988@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

In issue28959 Raymond said that a dict structure can be switched to PyVarObject. Victor guessed that it makes sense to switch a set structure too. Proposed patch implements this. The layout of a dict structure is not changed. The number of used and filled entries in a set structure are swapped, therefore extensions that use PySet_GET_SIZE or access fields of PySetObject directly (both are not in a stable API) should be recompiled.

I don't see a benefit from this patch except some unification.

----------
assignee: rhettinger
components: Extension Modules
files: dict-set-var-object.patch
keywords: patch
messages: 283404
nosy: haypo, rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Switch dict and set structures to PyVarObject
type: enhancement
versions: Python 3.7
Added file: http://bugs.python.org/file45925/dict-set-var-object.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28988>
_______________________________________

From report at bugs.python.org  Fri Dec 16 10:07:22 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Dec 2016 15:07:22 +0000
Subject: [issue28988] Switch dict and set structures to PyVarObject
In-Reply-To: <1481900465.81.0.491407063999.issue28988@psf.upfronthosting.co.za>
Message-ID: <1481900842.86.0.802363763352.issue28988@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Copy/paste of my msg283176:

> dict doesn't end with array.

Right, but...

Recently I looked at dict internals. As a newcomer, I have to confess that it's currently really hard to understand the purpose of each dict field: they are many "sizes": size of the hash table, number of usable entries, number of used entries, number of items in the dictionary, etc.

I like the idea of using the standard ob_size field (PyVarObject) to make it more explicitl that this field is the expected result of len(obj).

Technically, I don't know any function inside Python core which rely on the fact that object data is at the end of the main memory block.

Other builtin Python types:

* tuple: PyVarObject
* list: PyVarObject
* bytes: PyVarObject
* bytearray: PyVarObject
* memoryview: PyVarObject
* set: "used" field
* str: "length" field

The str type is super optimized for memory footprint, there are technical reasons for not used PyVarObject here, like backward compatibility.

It may make sense to modify PySetObject to use PyVarObject as well, but that's a different topic :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28988>
_______________________________________

From report at bugs.python.org  Fri Dec 16 10:09:04 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Dec 2016 15:09:04 +0000
Subject: [issue28959] Add a macro for dict size
In-Reply-To: <1481634421.56.0.985862767516.issue28959@psf.upfronthosting.co.za>
Message-ID: <1481900944.03.0.10199351524.issue28959@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

After further analysis I conclude that instance dict can be only NULL or a dict. Therefore PyDict_Size() is correctly used in typeobject.c and _datetimemodule.c. It never fails, and additional PyDict_Check() is not needed.

Committed changes don't include switching a dict structure to PyVarObject. Separate issue28988 is opened for this.

Thanks Raymond, Inada and Victor for your reviews.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28959>
_______________________________________

From report at bugs.python.org  Fri Dec 16 10:11:38 2016
From: report at bugs.python.org (Ned Deily)
Date: Fri, 16 Dec 2016 15:11:38 +0000
Subject: [issue28770] Update python-gdb.py for fastcalls
In-Reply-To: <1479814975.16.0.381517171433.issue28770@psf.upfronthosting.co.za>
Message-ID: <1481901098.52.0.61177976425.issue28770@psf.upfronthosting.co.za>


Ned Deily added the comment:

Please leave this open until the cherry picking is completed.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28770>
_______________________________________

From report at bugs.python.org  Fri Dec 16 10:12:22 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Dec 2016 15:12:22 +0000
Subject: [issue28180] sys.getfilesystemencoding() should default to utf-8
In-Reply-To: <1474024622.65.0.838685461995.issue28180@psf.upfronthosting.co.za>
Message-ID: <1481901142.85.0.873618563618.issue28180@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Victor>> I proposed to add "-X utf8" command line option for UNIX to force utf8 encoding. Would it work for you?

Jan Niklas Hasse> Unfortunately no, as this would mean I'll have to change all my python invocations in my scripts and it wouldn't work for executable files with "#!/usr/bin/env python3" would it?

Usually, when a new option is added to Python, we add a command line option (-X utf8) but also an environment variable: I propose PYTHONUTF8=1.

Use your favorite method to define the env var "system wide" in your docker containers.

Note: Technically, I'm not sure that it's possible to support -E option with PYTHONUTF8, since -E comes from the command line, and we first need to decode command line arguments with an encoding to parse these options.... Chicken-and-egg issue ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28180>
_______________________________________

From report at bugs.python.org  Fri Dec 16 10:15:34 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 16 Dec 2016 15:15:34 +0000
Subject: [issue28180] sys.getfilesystemencoding() should default to utf-8
In-Reply-To: <1474024622.65.0.838685461995.issue28180@psf.upfronthosting.co.za>
Message-ID: <1481901334.84.0.637678025286.issue28180@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> I believe Victor put quite a bit of time into trying to get more selective approaches to work reliably and eventually gave up.

Yeah, it just doesn't work to use more than one encoding per process. You should use the same encoding for the whole lifetime of a process.

If you decode early data from an encoding A and later encode it back to encoding B, you get mojibake. The problem is simple.

Using more than one encoding per process means starting to make assumtpions on how data is used. For example, consider that environment variables use the encoding A, but filenames should use the encoding B. Or, but what if an environment variable contains a filename? Similar issues for command line arguments, subprocess pipes, standard streams (sys.std*), etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28180>
_______________________________________

From report at bugs.python.org  Fri Dec 16 10:27:43 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Fri, 16 Dec 2016 15:27:43 +0000
Subject: [issue28446] pyvenv generates malformed hashbangs for scripts
In-Reply-To: <1476492788.48.0.267846160291.issue28446@psf.upfronthosting.co.za>
Message-ID: <1481902063.65.0.453077686058.issue28446@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

Seems there are quite a few typos/copy-paste errors in the original steps-to-reproduce. Here are my steps on macOS:

$ ./python-build/python.exe -m venv 'aaa bbb'
$ source ./aaa\ bbb/bin/activate
$ pip
zsh: /Users/yen/tmp/aaa bbb/bin/pip: bad interpreter: "/Users/yen/tmp/aaa: no such file or directory

The result is similar on Linux.

Like Alex said, I don't think there's a portable solution, either, so here's a patch to warn users for possibly broken paths.

macOS kernel has another bug/limitation. In XNU, '#' symbol also breaks shebang:

$ ./python-build/python.exe -m venv 'aaa#bbb'
$ source ./aaa\#bbb/bin/activate
$ pip
zsh: /Users/yen/tmp/aaa#bbb/bin/pip: bad interpreter: /Users/yen/tmp/aaa#bbb/bin/python: no such file or directory

This is even confusing as the kernel thinks the interpreter is /Users/yen/tmp/aaa (everything after the first # is thrown away, see [1]) while zsh/bash thinks it's /Users/yen/tmp/aaa#bbb/bin/python. As a result, I add a warning for #, too

Some related discussions:
1. https://github.com/pypa/pip/issues/923 (pip does not support spaces in directories names)
2. https://github.com/pypa/virtualenv/issues/53 (Whitespace in root path of virtualenv breaks scripts)
3. https://github.com/pypa/virtualenv/issues/973 (bad interpreter error when creating virtualenv's in directories with '#' in name)

Adding venv maintainer and some macOS experts

[1] https://opensource.apple.com/source/xnu/xnu-3789.21.4/bsd/kern/kern_exec.c.auto.html, line 511

----------
components: +Library (Lib)
keywords: +patch
nosy: +Chi Hsuan Yen, ned.deily, ronaldoussoren, vinay.sajip
versions: +Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45926/venv-check-path.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28446>
_______________________________________

From report at bugs.python.org  Fri Dec 16 10:38:15 2016
From: report at bugs.python.org (Gabriel Lopez)
Date: Fri, 16 Dec 2016 15:38:15 +0000
Subject: [issue28989] .dll files missing
Message-ID: <1481902695.92.0.0511959734428.issue28989@psf.upfronthosting.co.za>


New submission from Gabriel Lopez:

Every time I try loading Python 3.5, it says "The program can't start because api-ms-win-crt-runtime-l1-1-0.dll is missing from your computer." How can I fix this?

----------
messages: 283411
nosy: Gabriel Lopez
priority: normal
severity: normal
status: open
title: .dll files missing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28989>
_______________________________________

From report at bugs.python.org  Fri Dec 16 11:00:08 2016
From: report at bugs.python.org (Henning von Bargen)
Date: Fri, 16 Dec 2016 16:00:08 +0000
Subject: [issue28879] smtplib send_message should add Date header if it is
 missing, per RFC5322
In-Reply-To: <1480952895.22.0.418354723664.issue28879@psf.upfronthosting.co.za>
Message-ID: <1481904008.38.0.224404099573.issue28879@psf.upfronthosting.co.za>


Henning von Bargen added the comment:

OK, I understand the arguments. 
If I understand correctly, this will be fixed in one way or another in Python 3.6 or 3.7.
For Python 2.7, this will not be fixed (so I have to work around this somehow, should be quite easy).
I think that at least the documentation and the examples for smtplib should be updated.

The doc should make it clear that the message is passed "as-is" and it's the caller's reponsibility to create a valid message string.

The examples at https://docs.python.org/2/library/email-examples.html should note which header fields are required by RFC 5322 and provide an example.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28879>
_______________________________________

From report at bugs.python.org  Fri Dec 16 11:06:20 2016
From: report at bugs.python.org (Ned Deily)
Date: Fri, 16 Dec 2016 16:06:20 +0000
Subject: [issue28989] .dll files missing
In-Reply-To: <1481902695.92.0.0511959734428.issue28989@psf.upfronthosting.co.za>
Message-ID: <1481904380.3.0.16057355031.issue28989@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28989>
_______________________________________

From report at bugs.python.org  Fri Dec 16 11:41:05 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 16 Dec 2016 16:41:05 +0000
Subject: [issue28990] asyncio SSL hangs if connection is closed before
 handshake completed
Message-ID: <1481906465.87.0.352329351706.issue28990@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

Resolved: https://github.com/python/asyncio/issues/472

----------
assignee: yselivanov
components: asyncio
messages: 283413
nosy: gvanrossum, larry, ned.deily, yselivanov
priority: release blocker
severity: normal
status: open
title: asyncio SSL hangs if connection is closed before handshake completed
versions: Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28990>
_______________________________________

From report at bugs.python.org  Fri Dec 16 11:42:17 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 16 Dec 2016 16:42:17 +0000
Subject: [issue28990] asyncio SSL hangs if connection is closed before
 handshake completed
Message-ID: <1481906537.83.0.66806407884.issue28990@psf.upfronthosting.co.za>


Changes by Yury Selivanov <yselivanov at gmail.com>:


----------
Removed message: http://bugs.python.org/msg283413

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28990>
_______________________________________

From report at bugs.python.org  Fri Dec 16 11:42:29 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 16 Dec 2016 16:42:29 +0000
Subject: [issue28990] asyncio SSL hangs if connection is closed before
 handshake completed
Message-ID: <1481906549.65.0.746486264017.issue28990@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

Upstream link: https://github.com/python/asyncio/pull/476

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28990>
_______________________________________

From report at bugs.python.org  Fri Dec 16 11:47:36 2016
From: report at bugs.python.org (Brendan Donegan)
Date: Fri, 16 Dec 2016 16:47:36 +0000
Subject: [issue28989] .dll files missing
In-Reply-To: <1481902695.92.0.0511959734428.issue28989@psf.upfronthosting.co.za>
Message-ID: <1481906856.92.0.141322581042.issue28989@psf.upfronthosting.co.za>


Brendan Donegan added the comment:

This more likely to be a system misconfiguration issue than a Python one. Following http://stackoverflow.com/questions/33265663/api-ms-win-crt-runtime-l1-1-0-dll-is-missing-when-opening-microsoft-office-file will probably fix the issue for you.

----------
nosy: +brendan-donegan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28989>
_______________________________________

From report at bugs.python.org  Fri Dec 16 11:53:17 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 16 Dec 2016 16:53:17 +0000
Subject: [issue28990] asyncio SSL hangs if connection is closed before
 handshake completed
In-Reply-To: <1481906549.65.0.746486264017.issue28990@psf.upfronthosting.co.za>
Message-ID: <20161216165314.1188.92715.1AB3F516@psf.io>


Roundup Robot added the comment:

New changeset fcba55d649ea by Yury Selivanov in branch '3.5':
Issue #28990: Fix SSL hanging if connection is closed before handshake completed.
https://hg.python.org/cpython/rev/fcba55d649ea

New changeset fcc642bf88c1 by Yury Selivanov in branch '3.6':
Merge 3.5 (issue #28990)
https://hg.python.org/cpython/rev/fcc642bf88c1

New changeset 59eea8122df6 by Yury Selivanov in branch 'default':
Merge 3.6 (issue #28990)
https://hg.python.org/cpython/rev/59eea8122df6

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28990>
_______________________________________

From report at bugs.python.org  Fri Dec 16 11:54:09 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 16 Dec 2016 16:54:09 +0000
Subject: [issue28990] asyncio SSL hangs if connection is closed before
 handshake completed
In-Reply-To: <1481906549.65.0.746486264017.issue28990@psf.upfronthosting.co.za>
Message-ID: <1481907249.1.0.648561885179.issue28990@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Ned, would you be able to cherry-pick this in 3.6.0?  Guido approved this.

----------
resolution:  -> fixed
stage:  -> resolved
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28990>
_______________________________________

From report at bugs.python.org  Fri Dec 16 12:07:16 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 16 Dec 2016 17:07:16 +0000
Subject: [issue14061] Misc fixes and cleanups in archiving code in shutil and
 test_shutil
In-Reply-To: <1329705067.15.0.02936958618.issue14061@psf.upfronthosting.co.za>
Message-ID: <20161216170712.78738.40551.4251B936@psf.io>


Roundup Robot added the comment:

New changeset 929c2d076a85 by Serhiy Storchaka in branch '3.5':
Issue #14061: Misc fixes and cleanups in archiving code in shutil.
https://hg.python.org/cpython/rev/929c2d076a85

New changeset 268d3763bb07 by Serhiy Storchaka in branch '3.6':
Issue #14061: Misc fixes and cleanups in archiving code in shutil.
https://hg.python.org/cpython/rev/268d3763bb07

New changeset 5fd772a20f25 by Serhiy Storchaka in branch 'default':
Issue #14061: Misc fixes and cleanups in archiving code in shutil.
https://hg.python.org/cpython/rev/5fd772a20f25

New changeset eb02db65e148 by Serhiy Storchaka in branch '2.7':
Issue #14061: Misc fixes and cleanups in archiving code in shutil.
https://hg.python.org/cpython/rev/eb02db65e148

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14061>
_______________________________________

From report at bugs.python.org  Fri Dec 16 12:09:50 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Dec 2016 17:09:50 +0000
Subject: [issue23262] webbrowser module broken with Firefox 36+
In-Reply-To: <1421554616.48.0.911036047072.issue23262@psf.upfronthosting.co.za>
Message-ID: <1481908190.75.0.395505338081.issue23262@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
assignee: serhiy.storchaka -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23262>
_______________________________________

From report at bugs.python.org  Fri Dec 16 12:13:58 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Fri, 16 Dec 2016 17:13:58 +0000
Subject: [issue28180] sys.getfilesystemencoding() should default to utf-8
In-Reply-To: <1474024622.65.0.838685461995.issue28180@psf.upfronthosting.co.za>
Message-ID: <1481908438.94.0.828002864909.issue28180@psf.upfronthosting.co.za>


Changes by Chi Hsuan Yen <yan12125 at gmail.com>:


----------
nosy: +Chi Hsuan Yen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28180>
_______________________________________

From report at bugs.python.org  Fri Dec 16 12:19:22 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 16 Dec 2016 17:19:22 +0000
Subject: [issue18896] Remove namedtuple 255 arguments restriction
In-Reply-To: <1377972310.66.0.567176219008.issue18896@psf.upfronthosting.co.za>
Message-ID: <20161216171918.40557.20893.71B032C0@psf.io>


Roundup Robot added the comment:

New changeset 7454ca88aacb by Serhiy Storchaka in branch 'default':
Issue #18896: Python function can now have more than 255 parameters.
https://hg.python.org/cpython/rev/7454ca88aacb

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18896>
_______________________________________

From report at bugs.python.org  Fri Dec 16 12:22:24 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Dec 2016 17:22:24 +0000
Subject: [issue18896] Remove namedtuple 255 arguments restriction
In-Reply-To: <1377972310.66.0.567176219008.issue18896@psf.upfronthosting.co.za>
Message-ID: <1481908944.55.0.378923999545.issue18896@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Raymond for your review.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18896>
_______________________________________

From report at bugs.python.org  Fri Dec 16 12:23:31 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Dec 2016 17:23:31 +0000
Subject: [issue14061] Misc fixes and cleanups in archiving code in shutil and
 test_shutil
In-Reply-To: <1329705067.15.0.02936958618.issue14061@psf.upfronthosting.co.za>
Message-ID: <1481909011.92.0.111967730253.issue14061@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Martin for your review.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14061>
_______________________________________

From report at bugs.python.org  Fri Dec 16 12:27:25 2016
From: report at bugs.python.org (Ryan Brindley)
Date: Fri, 16 Dec 2016 17:27:25 +0000
Subject: [issue28982] multiprocessing.Queue.get(block=True,
 timeout=0) always raises queue.Empty
In-Reply-To: <1481834665.78.0.584713250682.issue28982@psf.upfronthosting.co.za>
Message-ID: <1481909245.27.0.0644123123684.issue28982@psf.upfronthosting.co.za>


Ryan Brindley added the comment:

So, the code handles timeout = 0 on systems where time.time() returns an int. Look at the following snippet and consider 2 assumptions: (1) time.time() returns an int, and (2) self._rlock.acquire call takes less than a second

            if block:
                deadline = time.time() + timeout
            if not self._rlock.acquire(block, timeout):
                raise Empty
            try:
                if block:
                    timeout = deadline - time.time()
                    if timeout < 0 or not self._poll(timeout):
                        raise Empty


The problem for the timeout = 0 case happens on systems where time.time() returns a floating point number and the acquire lock takes enough time to cause a diff in time.time() result between the deadline instantiation line and the timeout update line.

Given that, especially the `if timeout < 0 ...` line, I thought it may have been in the original intent for the function to handle 0 timeout when block truthy.

That side, the whole concept of having a separate block bool arg in the first place is a tad strange for me. Isn't it a bit redundant?

Why not just follow the underlying poll/select timeout arg logic as follows:

timeout = None, block indefinitely
timeout <= 0, non-block
timeout > 0, block timeout length

We could simplify this interaction by just removing that block arg all together. Not that I'm asking to do that here though, but maybe in the future?

If we go down the suggested error-raising path though, I would ask that the error not be queue.Empty -- which is misleading.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28982>
_______________________________________

From report at bugs.python.org  Fri Dec 16 12:48:23 2016
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 16 Dec 2016 17:48:23 +0000
Subject: [issue28971] nntplib is broken when responses are longer than _MAXLINE
In-Reply-To: <1481716454.12.0.730668429479.issue28971@psf.upfronthosting.co.za>
Message-ID: <1481910503.61.0.423715508477.issue28971@psf.upfronthosting.co.za>


Zachary Ware added the comment:

This is causing all buildbots to fail again; I'd be in favor of temporarily skipping the affected tests with a message that points back to here until we have a permanent solution.

----------
keywords: +buildbot
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28971>
_______________________________________

From report at bugs.python.org  Fri Dec 16 13:02:22 2016
From: report at bugs.python.org (Francis Deslauriers)
Date: Fri, 16 Dec 2016 18:02:22 +0000
Subject: [issue28909] Adding LTTng-UST tracing support
In-Reply-To: <1481227474.94.0.337411886613.issue28909@psf.upfronthosting.co.za>
Message-ID: <1481911342.42.0.129171472185.issue28909@psf.upfronthosting.co.za>


Changes by Francis Deslauriers <fdeslaur at gmail.com>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28909>
_______________________________________

From report at bugs.python.org  Fri Dec 16 13:37:03 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 16 Dec 2016 18:37:03 +0000
Subject: [issue28971] nntplib is broken when responses are longer than _MAXLINE
In-Reply-To: <1481716454.12.0.730668429479.issue28971@psf.upfronthosting.co.za>
Message-ID: <1481913423.08.0.910353621655.issue28971@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Xavier's plan sounds good. We could increase the line length limitation to 64K and add another limitation of the maximum lines a multi-line block could contain. Any limitation is violated the connection is refused. This situation seems quite similar to http.client.parse_headers, which doesn't get a standard length limitation or number limitation either.

----------
nosy: +xiang.zhang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28971>
_______________________________________

From report at bugs.python.org  Fri Dec 16 13:50:00 2016
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 16 Dec 2016 18:50:00 +0000
Subject: [issue28971] nntplib is broken when responses are longer than _MAXLINE
In-Reply-To: <1481913423.08.0.910353621655.issue28971@psf.upfronthosting.co.za>
Message-ID: <E34B2003-DA88-4297-A6AD-CFDB6D16D0B1@cheimes.de>


Christian Heimes added the comment:

A larger limit is totally fine. The check protects against DoS with hundreds of MB.

I'm currently travelling and won't be available much until next week.

Am 16. Dezember 2016 19:37:03 MEZ, schrieb Xiang Zhang <report at bugs.python.org>:
>
>Xiang Zhang added the comment:
>
>Xavier's plan sounds good. We could increase the line length limitation
>to 64K and add another limitation of the maximum lines a multi-line
>block could contain. Any limitation is violated the connection is
>refused. This situation seems quite similar to
>http.client.parse_headers, which doesn't get a standard length
>limitation or number limitation either.
>
>----------
>nosy: +xiang.zhang
>
>_______________________________________
>Python tracker <report at bugs.python.org>
><http://bugs.python.org/issue28971>
>_______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28971>
_______________________________________

From report at bugs.python.org  Fri Dec 16 13:59:17 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 16 Dec 2016 18:59:17 +0000
Subject: [issue28991] Fix obscure lru_cache reentrancy bug
Message-ID: <1481914757.29.0.923999616367.issue28991@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Call __len__ directly inside the LRU cache code rather than using len().  This helps further encapsulate the cache internals making it less dependent on parts of the environment that are subject to change.

----------
assignee: serhiy.storchaka
components: Library (Lib)
files: fix_lru_len_reentrancy.diff
keywords: patch
messages: 283426
nosy: rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Fix obscure lru_cache reentrancy bug
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45927/fix_lru_len_reentrancy.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28991>
_______________________________________

From report at bugs.python.org  Fri Dec 16 14:10:44 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Dec 2016 19:10:44 +0000
Subject: [issue28991] Fix obscure lru_cache reentrancy bug
In-Reply-To: <1481914757.29.0.923999616367.issue28991@psf.upfronthosting.co.za>
Message-ID: <1481915444.41.0.231879474291.issue28991@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Wrapping len() in an lru_cache is bad idea, because this brakes len() of lists, dicts and other non-hashable collections.

Should we support this doubtful case?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28991>
_______________________________________

From report at bugs.python.org  Fri Dec 16 14:14:38 2016
From: report at bugs.python.org (Chun-Yu Tseng)
Date: Fri, 16 Dec 2016 19:14:38 +0000
Subject: [issue22135] allow to break into pdb with Ctrl-C for all the commands
 that resume execution
In-Reply-To: <1407185061.52.0.89159247831.issue22135@psf.upfronthosting.co.za>
Message-ID: <1481915678.45.0.238895211828.issue22135@psf.upfronthosting.co.za>


Chun-Yu Tseng added the comment:

Appreciate for your quick response. I have already left the reply in Rietveld.

I have uploaded a new patch with revised tests. In fact, the tests I wrote in the first patch are based on the style of `test_pdb2.py` in #7245 . But I am sure that now the new tests are better than the old because they run faster and source code looks simpler. (Note that these tests are still skipped to run on Windows)

Please tell me what can I do next :)

----------
Added file: http://bugs.python.org/file45928/fix-cc-and-add-tests-v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22135>
_______________________________________

From report at bugs.python.org  Fri Dec 16 14:40:14 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 16 Dec 2016 19:40:14 +0000
Subject: [issue28971] nntplib is broken when responses are longer than _MAXLINE
In-Reply-To: <1481716454.12.0.730668429479.issue28971@psf.upfronthosting.co.za>
Message-ID: <1481917214.57.0.49015352102.issue28971@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

> I'd be in favor of temporarily skipping the affected tests with a message that points back to here until we have a permanent solution.

I am working on it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28971>
_______________________________________

From report at bugs.python.org  Fri Dec 16 14:52:03 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 16 Dec 2016 19:52:03 +0000
Subject: [issue28971] nntplib is broken when responses are longer than _MAXLINE
In-Reply-To: <1481716454.12.0.730668429479.issue28971@psf.upfronthosting.co.za>
Message-ID: <20161216195200.33744.9763.AF454B95@psf.io>


Roundup Robot added the comment:

New changeset 1386795d266e by Xavier de Gaye in branch '3.5':
Issue #28971: Temporarily skip test_over until a permanent solution is found
https://hg.python.org/cpython/rev/1386795d266e

New changeset a33047e08711 by Xavier de Gaye in branch '3.6':
Issue #28971: Merge 3.5
https://hg.python.org/cpython/rev/a33047e08711

New changeset b51914417b41 by Xavier de Gaye in branch 'default':
Issue #28971: Merge 3.6
https://hg.python.org/cpython/rev/b51914417b41

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28971>
_______________________________________

From report at bugs.python.org  Fri Dec 16 15:05:53 2016
From: report at bugs.python.org (Eric Lafontaine)
Date: Fri, 16 Dec 2016 20:05:53 +0000
Subject: [issue28879] smtplib send_message should add Date header if it is
 missing, per RFC5322
In-Reply-To: <1480952895.22.0.418354723664.issue28879@psf.upfronthosting.co.za>
Message-ID: <1481918753.15.0.529319686228.issue28879@psf.upfronthosting.co.za>


Eric Lafontaine added the comment:

Hi all, I was looking at the code of the function and also noticed multiple "itching".

1- Why raise an error when 2 resent-date exist?  it may exist and completely legitimate as per RFC5322.  The code should always take the first one it sees as per the RFC.
2- Also, there was an "ehlo_or_helo_if_needed", but it's done in sendmail function so makes it always irrelevant.
3- The signature of the function is different from the one of sendmail function.  My understanding is that send_message is a replacement of sendmail with more feature (praticality) and should be simple to change by just swaping the 2 of them. 
4- This "send_message" shouldn't be dependant on the email.message.Message class.  It should allow a dictionary to be passed as well.  So I removed the "get_all" to be replaced with a "get" method (which align with what dictionaries do. 


I have addressed 1,2 and 4 in my patch (modified the test case as well) and my efforts to make this better and clearer, but number 3 seems to be something that may be a big change for clients... Should we handle it at all?

Please review and give me feedbacks please, I'm open to negative ones as well ;).  I need to know if I'm doing something wrong and I don't know all the principle (as you may have noticed).  

I've ran the "python -m test" & "./python -m smtplib" command, but is there something else I should've done?

List of things to do :
- Implement a patch for the code to add a missing "Date" field if it doesn't exist .   (in review)
- Modify the documentation at the SMTPLib for the send_message to mention that it add missing date using the email.utils.formatdate
- Modify the comment of the send_message code to mention RFC 5322 in there (ideally with the section of the RFC).  ( in review)
- Modify the example of Python 2 to present a RFC 5322 examples

Thanks Henning von Bargen, David, maciej.  I appreciate your support.  

Regards,
Eric Lafontaine

----------
keywords: +patch
Added file: http://bugs.python.org/file45929/issue_28879.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28879>
_______________________________________

From report at bugs.python.org  Fri Dec 16 15:21:19 2016
From: report at bugs.python.org (Ryan Brindley)
Date: Fri, 16 Dec 2016 20:21:19 +0000
Subject: [issue28982] multiprocessing.Queue.get(block=True,
 timeout=0) always raises queue.Empty
In-Reply-To: <1481834665.78.0.584713250682.issue28982@psf.upfronthosting.co.za>
Message-ID: <1481919679.46.0.422022229948.issue28982@psf.upfronthosting.co.za>


Ryan Brindley added the comment:

In addition, queue.Queue supports timeout value of 0 and its documentation says "non-negative number".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28982>
_______________________________________

From report at bugs.python.org  Fri Dec 16 15:28:42 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Dec 2016 20:28:42 +0000
Subject: [issue28992] Use bytes.fromhex()
Message-ID: <1481920122.63.0.616252652526.issue28992@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch makes the code and tests using bytes.fromhex(). The benefit of bytes.fromhex() over manual converting hexadecimals to bytes:

1. This is the one obvious way to do it.

2. This is the fastest way to do it.

----------
components: Library (Lib)
files: use_bytes_fromhex.patch
keywords: patch
messages: 283433
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Use bytes.fromhex()
type: enhancement
versions: Python 3.7
Added file: http://bugs.python.org/file45930/use_bytes_fromhex.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28992>
_______________________________________

From report at bugs.python.org  Fri Dec 16 15:29:42 2016
From: report at bugs.python.org (femi)
Date: Fri, 16 Dec 2016 20:29:42 +0000
Subject: [issue28993] math.ceil() python 2.7
Message-ID: <1481920182.19.0.244143078463.issue28993@psf.upfronthosting.co.za>


New submission from femi:

math.ceil(10/3) python 2.7.12 returns 3

----------
messages: 283434
nosy: akinfemi09
priority: normal
severity: normal
status: open
title: math.ceil() python 2.7
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28993>
_______________________________________

From report at bugs.python.org  Fri Dec 16 15:31:28 2016
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 16 Dec 2016 20:31:28 +0000
Subject: [issue28993] math.ceil() python 2.7
In-Reply-To: <1481920182.19.0.244143078463.issue28993@psf.upfronthosting.co.za>
Message-ID: <1481920288.3.0.810720102934.issue28993@psf.upfronthosting.co.za>


Zachary Ware added the comment:

The `/` operator in Python 2 does integer division.  `math.ceil(10/3)` in Python 2 is equivalent to `math.ceil(3)`.

----------
nosy: +zach.ware
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28993>
_______________________________________

From report at bugs.python.org  Fri Dec 16 15:40:29 2016
From: report at bugs.python.org (R. David Murray)
Date: Fri, 16 Dec 2016 20:40:29 +0000
Subject: [issue28879] smtplib send_message should add Date header if it is
 missing, per RFC5322
In-Reply-To: <1480952895.22.0.418354723664.issue28879@psf.upfronthosting.co.za>
Message-ID: <1481920829.75.0.861715357352.issue28879@psf.upfronthosting.co.za>


R. David Murray added the comment:

The signature of send_message cannot be changed for backward compatibility reasons.  It's signature was not intended to be an extension of the sendmail signature.

send_message cannot accept a dictionary, as then it would have to know how to format that dictionary into an RFC5322 compliant text string.  Nor can a dictionary represent a collection of email headers accurate.  Representing the headers and doing the serialization is the email package's job.

It is true that the ehlo_or_helo_if_needed is technically redundant, however, what it means is that once you've called any smtplib command you know that has been done, even if the subcommand raises an error.  This can make debuging easier (consistency of state), at a trivial cost.

The "more than one Resent block" error is explained in the comments.  If you want to write the heuristics to remove it, go ahead :)

Looking at that code, I see that I misremembered what it was doing.  I thought it was adding Resent-Date if it was missing, but it is instead determining what form of address headers it needs to add if Reset-Date is present.  That doesn't change the analysis in this issue, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28879>
_______________________________________

From report at bugs.python.org  Fri Dec 16 15:58:02 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Dec 2016 20:58:02 +0000
Subject: [issue28936] test_global_err_then_warn in test_syntax is no longer
 valid
In-Reply-To: <1481459590.71.0.768888502862.issue28936@psf.upfronthosting.co.za>
Message-ID: <1481921882.98.0.115387388153.issue28936@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I don't know what should we do with this. Is there a bug that needs to be fixed? Or maybe the test can be just removed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28936>
_______________________________________

From report at bugs.python.org  Fri Dec 16 16:12:18 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 16 Dec 2016 21:12:18 +0000
Subject: [issue28991] Fix obscure lru_cache reentrancy bug
In-Reply-To: <1481914757.29.0.923999616367.issue28991@psf.upfronthosting.co.za>
Message-ID: <1481922738.85.0.797482219477.issue28991@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

It is effortless to make this change and is consistent with all the other efforts taken to to protect against reentrancy, so yes, I think it should be done.  It isn't so much that I want this to be a use case, I would just like the implementation to be as sound as reasonably possible so that we don't find the LRU cache to be at heart of some future hard-to-find bug in a complex application.

How does the patch look to you?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28991>
_______________________________________

From report at bugs.python.org  Fri Dec 16 16:13:32 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 16 Dec 2016 21:13:32 +0000
Subject: [issue28986] Docs should say set.update takes iterable
In-Reply-To: <1481879632.81.0.577859496056.issue28986@psf.upfronthosting.co.za>
Message-ID: <1481922812.91.0.0827335270174.issue28986@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28986>
_______________________________________

From report at bugs.python.org  Fri Dec 16 16:16:08 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 16 Dec 2016 21:16:08 +0000
Subject: [issue28969] lru_cache is not threadsafe
In-Reply-To: <1481712564.52.0.530922236321.issue28969@psf.upfronthosting.co.za>
Message-ID: <1481922968.29.0.615383960637.issue28969@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Ned, can this be considered for inclusion in Python 3.6?   ISTM that this problematic in that it may already be causing hard-to-diagnose bugs in existing applications.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28969>
_______________________________________

From report at bugs.python.org  Fri Dec 16 16:30:39 2016
From: report at bugs.python.org (Ned Deily)
Date: Fri, 16 Dec 2016 21:30:39 +0000
Subject: [issue28969] lru_cache is not threadsafe
In-Reply-To: <1481712564.52.0.530922236321.issue28969@psf.upfronthosting.co.za>
Message-ID: <1481923839.81.0.34137428252.issue28969@psf.upfronthosting.co.za>


Ned Deily added the comment:

Before it could be considered for 3.6.0, it needs to be reviewed, pushed to the 3.6 branch for 3.6.1, and have some buildbot exposure.  3.6.0rc2 is in the process of manufacturing already.  Since this is a fairly extensive change, I think it would not be appropriate to throw it into a final release without prior release exposure.  Since it's also a bug in 3.5 and not a 3.6 release regression, I think it should wait for 3.6.1 unless we have a compelling reason to do a 3.6.0rc3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28969>
_______________________________________

From report at bugs.python.org  Fri Dec 16 16:30:51 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Dec 2016 21:30:51 +0000
Subject: [issue28765] _sre.compile(): be more strict on types of indexgroup
 and groupindex
In-Reply-To: <1479743857.98.0.418828964214.issue28765@psf.upfronthosting.co.za>
Message-ID: <1481923851.03.0.967859139723.issue28765@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Hum, sorry, I don't understand what is the issue with adding a few addition checks in the constructor? Is it a matter of speed?

It is a matter of readability and maintainability. Additional checks adds 21 lines of the code, and they hardcode error messages. I copied currently produced error messages, with hardcoded function name and argument numbers. Changes in PyArg* functions or Argument Clinic that could globally enhance error messages would not affect these ones. Changing the function name or the arguments order would need to change error messages.

> I don't understand your "unpythonic" argument.

Sorry, I used bad wording. I meant that this doesn't follow the practice of CPython code. Builtins and extensions often ignore subclassing and use concrete API for simplicity and speed. Especially in internal functions. The interface of _sre.compile() already is made less general, it no longer works with general sequences and mappings. Ignoring subclassing don't make it much worse.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28765>
_______________________________________

From report at bugs.python.org  Fri Dec 16 16:35:17 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 16 Dec 2016 21:35:17 +0000
Subject: [issue26342] Faster bit ops for single-digit positive longs
In-Reply-To: <1455219238.31.0.545521585495.issue26342@psf.upfronthosting.co.za>
Message-ID: <1481924117.44.0.676663678003.issue26342@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Closing this one, as we decided to not to micro-optimize int ops.

----------
resolution:  -> wont fix
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26342>
_______________________________________

From report at bugs.python.org  Fri Dec 16 16:37:12 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 16 Dec 2016 21:37:12 +0000
Subject: [issue24383] consider implementing __await__ on
 concurrent.futures.Future
In-Reply-To: <1433432578.55.0.498116142035.issue24383@psf.upfronthosting.co.za>
Message-ID: <1481924232.47.0.742550972703.issue24383@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

I think we should close this one.  Making concurrent.futures awaitable will likely only complicate things for end-users.

----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24383>
_______________________________________

From report at bugs.python.org  Fri Dec 16 16:38:19 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Dec 2016 21:38:19 +0000
Subject: [issue28991] Fix obscure lru_cache reentrancy bug
In-Reply-To: <1481914757.29.0.923999616367.issue28991@psf.upfronthosting.co.za>
Message-ID: <1481924299.33.0.74979907873.issue28991@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> How does the patch look to you?

It looks ugly, but technically correct. Push it if you like.

----------
assignee: serhiy.storchaka -> rhettinger
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28991>
_______________________________________

From report at bugs.python.org  Fri Dec 16 17:01:29 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 16 Dec 2016 22:01:29 +0000
Subject: [issue28991] Fix obscure lru_cache reentrancy bug
In-Reply-To: <1481914757.29.0.923999616367.issue28991@psf.upfronthosting.co.za>
Message-ID: <20161216220126.128588.19243.9675B660@psf.io>


Roundup Robot added the comment:

New changeset c23f8614151d by Raymond Hettinger in branch '3.5':
Issue #28991:  Fix obscure reentrancy bug in functools.lru_cache().
https://hg.python.org/cpython/rev/c23f8614151d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28991>
_______________________________________

From report at bugs.python.org  Fri Dec 16 17:16:09 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 16 Dec 2016 22:16:09 +0000
Subject: [issue28991] Fix obscure lru_cache reentrancy bug
In-Reply-To: <1481914757.29.0.923999616367.issue28991@psf.upfronthosting.co.za>
Message-ID: <1481926569.37.0.027042066669.issue28991@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28991>
_______________________________________

From report at bugs.python.org  Fri Dec 16 17:48:26 2016
From: report at bugs.python.org (Decorater)
Date: Fri, 16 Dec 2016 22:48:26 +0000
Subject: [issue28816] Document if zipimport can respect import hooks to load
 custom files from zip.
In-Reply-To: <1480326340.52.0.39566018579.issue28816@psf.upfronthosting.co.za>
Message-ID: <1481928506.12.0.586378437533.issue28816@psf.upfronthosting.co.za>


Decorater added the comment:

Well, Will there be any documentations for this before 3.6 final release or no because this would be nice to know for other people who would like to do something similar.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28816>
_______________________________________

From report at bugs.python.org  Fri Dec 16 18:01:05 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 16 Dec 2016 23:01:05 +0000
Subject: [issue28991] Fix obscure lru_cache reentrancy bug
In-Reply-To: <1481914757.29.0.923999616367.issue28991@psf.upfronthosting.co.za>
Message-ID: <20161216230101.96211.83186.96B3C0CA@psf.io>


Roundup Robot added the comment:

New changeset 5ec5bfcf0089 by Raymond Hettinger in branch 'default':
Issue #28991:  Address comment that the __len__ call looked unattractive
https://hg.python.org/cpython/rev/5ec5bfcf0089

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28991>
_______________________________________

From report at bugs.python.org  Fri Dec 16 18:11:42 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Dec 2016 23:11:42 +0000
Subject: [issue28969] lru_cache is not threadsafe
In-Reply-To: <1481712564.52.0.530922236321.issue28969@psf.upfronthosting.co.za>
Message-ID: <1481929902.16.0.629468578319.issue28969@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

An alternative patch changes semantic of _PyDict_Pop() with deflt == NULL, but makes the code simpler.

----------
Added file: http://bugs.python.org/file45931/lru_cache-dict-pop-simpler-3.5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28969>
_______________________________________

From report at bugs.python.org  Fri Dec 16 18:27:38 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 16 Dec 2016 23:27:38 +0000
Subject: [issue28927] bytes.fromhex should ignore all whitespace
In-Reply-To: <1481328446.9.0.450435696311.issue28927@psf.upfronthosting.co.za>
Message-ID: <1481930858.91.0.31710987169.issue28927@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I am a bit dubious about this.  There is a tradeoff here between convenience and bug detection.  The patch is not strictly necessary.

>>> bytes.fromhex('ab\ncd'.replace('\n', ''))
b'\xab\xcd'

Bytes (and bytearray) .fromhex already ignores spaces.  Not ignoring newlines, by default, may have been intentional.  Nick, you wrote the doc entry for 'fromhex'.  Do you know anything about the design intention?

----------
nosy: +ncoghlan, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28927>
_______________________________________

From report at bugs.python.org  Fri Dec 16 18:35:29 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 16 Dec 2016 23:35:29 +0000
Subject: [issue28929] Provide a link from documentation back to its source file
In-Reply-To: <1481331536.86.0.539237207001.issue28929@psf.upfronthosting.co.za>
Message-ID: <1481931329.9.0.689219481006.issue28929@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Nice idea.  I agree with an updated sidebar link, both aesthetically and as a practical matter for doc maintainers.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28929>
_______________________________________

From report at bugs.python.org  Fri Dec 16 18:38:17 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 16 Dec 2016 23:38:17 +0000
Subject: [issue28994] Misc fixes and cleanups in error handling C code
Message-ID: <1481931496.89.0.341758339319.issue28994@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch makes few minor changes related to handling errors in C.

* Fixed possible NULL dereference in PyErr_NormalizeException().

* Fixed error checking in atexit._run_exitfuncs().

* Fixed possible memory leaks in _Py_FatalError_PrintExc().

* PyErr_NormalizeException() no longer recursive.

* If an error is occurred during handling other error, the original exception is chained as the __contex__ attribute to the new exception instead of just be dropped.

* PyTraceBack_Print() no longer fails OverflowError if tracebacklimit is very large negative or positive value.

* ctype error message now include the name of the initial exception instead of the repr of its class.

* Py_XDECREFs is replaced with Py_DECREFs if this is safe.

* Added few asserts.

* Other minor cleanups.

----------
components: Interpreter Core
files: errors.diff
keywords: patch
messages: 283451
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Misc fixes and cleanups in error handling C code
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45932/errors.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28994>
_______________________________________

From report at bugs.python.org  Fri Dec 16 19:09:00 2016
From: report at bugs.python.org (Steve Dower)
Date: Sat, 17 Dec 2016 00:09:00 +0000
Subject: [issue28995] pathlib.WindowsPath.resolve() test expects short path
Message-ID: <1481933340.85.0.729517888649.issue28995@psf.upfronthosting.co.za>


New submission from Steve Dower:

With issue19717, WindowsPath.resolve() now properly resolves the filename using the Windows APIs.

However, this may cause parts of the path to be replaced with their full name when provided as the 8.3 short name. The test was not updated for this:

Traceback (most recent call last):
  File "C:\build\cpython36\lib\test\test_pathlib.py", line 1547, in test_resolve_common
    self._check_resolve_relative(p, P(d, 'foo'), False)
  File "C:\build\cpython36\lib\test\test_pathlib.py", line 1491, in _check_resolve
    self.assertEqual(q, expected)
AssertionError: WindowsPath('C:/Users/steve.dower/AppData/Local/Temp/2/tmptnm6y2cm-dirD/foo') != WindowsPath('C:/Users/STEVE~1.DOW/AppData/Local/Temp/2/tmptnm6y2cm-dirD/foo')

We should make sure the test is referring to the same file rather than doing a direct path comparison. Maybe write a UUID into a file and read it out?

----------
components: Tests, Windows
keywords: 3.6regression
messages: 283452
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: pathlib.WindowsPath.resolve() test expects short path
type: behavior
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28995>
_______________________________________

From report at bugs.python.org  Fri Dec 16 19:22:30 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 17 Dec 2016 00:22:30 +0000
Subject: [issue28956] return minimum of modes for a multimodal distribution
 instead of raising a StatisticsError
In-Reply-To: <1481602901.85.0.570887953824.issue28956@psf.upfronthosting.co.za>
Message-ID: <1481934150.27.0.0422978425118.issue28956@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Srikanth, when you reply by email, please remove the quotation of the previous message.  On the web page, it is just noise.  The only exception should be when you reply to a specific sentence and need to quote that sentence for context.

In my particular experience, mode() is unusally reserved for crudely describing unordered categorical data, where the concept of 'minimum' does not apply.

Mode is useful for determining the winner of a vote (or other decision process), but in general, it is not a substitute for a more comprehensive look at a dataset.

Problems with possibly returning a tuple of data items instead of a data item include:

1. The user then has to be prepared to handle a tuple instead of a data item.  It would be better then to always return a tuple, even for 1 item.

2. Data items can be tuples, making a tuple return ambiguous.  Example use case: planar points with int coordinates.

>>> mode(((0,0), (0,0), (0,1)))
(0, 0)

So, while StatisticsError is a nuisance, so are the apparent alternatives.  I think we should leave mode alone and close this.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28956>
_______________________________________

From report at bugs.python.org  Fri Dec 16 19:32:54 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 17 Dec 2016 00:32:54 +0000
Subject: [issue28957] undefined symbol: PyUnicodeUCS2_FromUnicode when
 executing any command with pip2.7
In-Reply-To: <1481609253.38.0.127310652457.issue28957@psf.upfronthosting.co.za>
Message-ID: <1481934774.23.0.218471596227.issue28957@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

This tracker is for fixing Python and CPython.  There are other forums (python-list, StackOverflow, for instance) for help with user errors.  I believe that there are people on python-list with experience building on Ubuntu and variants, so I suggest asking there.  Include details on exactly how you retrieved the source onto your machine.

----------
nosy: +terry.reedy
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28957>
_______________________________________

From report at bugs.python.org  Fri Dec 16 19:33:49 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 17 Dec 2016 00:33:49 +0000
Subject: [issue28957] undefined symbol: PyUnicodeUCS2_FromUnicode when
 executing any command with pip2.7
In-Reply-To: <1481609253.38.0.127310652457.issue28957@psf.upfronthosting.co.za>
Message-ID: <1481934829.52.0.574915958156.issue28957@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

PS, for future reference, 'crash' here means hanging or exiting *without* a traceback.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28957>
_______________________________________

From report at bugs.python.org  Fri Dec 16 19:38:25 2016
From: report at bugs.python.org (Robert Xiao)
Date: Sat, 17 Dec 2016 00:38:25 +0000
Subject: [issue28927] bytes.fromhex should ignore all whitespace
In-Reply-To: <1481328446.9.0.450435696311.issue28927@psf.upfronthosting.co.za>
Message-ID: <1481935105.88.0.500157393747.issue28927@psf.upfronthosting.co.za>


Robert Xiao added the comment:

Terry, can you elaborate what you mean by a tradeoff? I feel like such a patch makes .fromhex more consistent with other string methods like .split() and .strip() which implicitly consider all whitespace equivalent.

Martin, I've updated the patch to include documentation updates and more testcases.

----------
Added file: http://bugs.python.org/file45933/fromhex.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28927>
_______________________________________

From report at bugs.python.org  Fri Dec 16 19:39:17 2016
From: report at bugs.python.org (Robert Xiao)
Date: Sat, 17 Dec 2016 00:39:17 +0000
Subject: [issue28927] bytes.fromhex should ignore all whitespace
In-Reply-To: <1481328446.9.0.450435696311.issue28927@psf.upfronthosting.co.za>
Message-ID: <1481935157.25.0.535835874017.issue28927@psf.upfronthosting.co.za>


Robert Xiao added the comment:

Sorry, I should have clarified that these methods consider *ASCII whitespace* equivalent - just like my proposed patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28927>
_______________________________________

From report at bugs.python.org  Fri Dec 16 19:45:20 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 17 Dec 2016 00:45:20 +0000
Subject: [issue13051] Infinite recursion in curses.textpad.Textbox
In-Reply-To: <1317170831.29.0.145546521568.issue13051@psf.upfronthosting.co.za>
Message-ID: <1481935520.27.0.386130524201.issue13051@psf.upfronthosting.co.za>


Berker Peksag added the comment:

The patch doesn't apply cleanly anymore so the next step would be to provide an updated patch.

By the way, I can reproduce the first bug, but not the second one. If the second bug can't be reproducible anymore, we might need a simpler patch.

----------
nosy: +berker.peksag
type: crash -> behavior
versions: +Python 3.5, Python 3.6, Python 3.7 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13051>
_______________________________________

From report at bugs.python.org  Fri Dec 16 19:46:50 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 17 Dec 2016 00:46:50 +0000
Subject: [issue25782] CPython hangs on error __context__ set to the error
 itself
In-Reply-To: <1449076441.38.0.963505882098.issue25782@psf.upfronthosting.co.za>
Message-ID: <1481935610.13.0.821622161798.issue25782@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Issue #28962 appears to be an example of this issue.  It uses 'raise e from e' to create the loop.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25782>
_______________________________________

From report at bugs.python.org  Fri Dec 16 20:09:08 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 17 Dec 2016 01:09:08 +0000
Subject: [issue28987] Remove typo in whats new entry on Descriptor Protocol
 Enhancements
In-Reply-To: <1481899777.6.0.168027118987.issue28987@psf.upfronthosting.co.za>
Message-ID: <1481936948.89.0.482869587221.issue28987@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +Elvis.Pranskevichus, yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28987>
_______________________________________

From report at bugs.python.org  Fri Dec 16 20:54:41 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 17 Dec 2016 01:54:41 +0000
Subject: [issue28957] undefined symbol: PyUnicodeUCS2_FromUnicode when
 executing any command with pip2.7
In-Reply-To: <1481609253.38.0.127310652457.issue28957@psf.upfronthosting.co.za>
Message-ID: <1481939681.96.0.523314037588.issue28957@psf.upfronthosting.co.za>


Berker Peksag added the comment:

I think there are two different Python installations in your $PATH (the one you compiled with UCS4 and the other one is compiled with UCS2 - probably the system Python)

Anyway, like Terry said, this is out of scope for this tracker.

----------
nosy: +berker.peksag
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28957>
_______________________________________

From report at bugs.python.org  Fri Dec 16 21:05:53 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 17 Dec 2016 02:05:53 +0000
Subject: [issue28972] Document all "python -m" utilities
In-Reply-To: <1481720403.32.0.43245427479.issue28972@psf.upfronthosting.co.za>
Message-ID: <1481940353.22.0.811937999203.issue28972@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

+1 for Miki's idea.  It would be nice if there were a single page that collected together all the command-line tools (with examples).  It should include a 2to3 example as well.  Also, there should be some indication of which tools we guarantee to be available (2to3 json.tool) versus those that just happen to be exposed but are subject to change (possibly because they were just used for testing, or because they have a crummy API, or because Guido has said that we are in the library business, not the command-line tool business).

See also:  http://bugs.python.org/issue26488

----------
assignee: docs at python -> 
nosy: +gvanrossum, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28972>
_______________________________________

From report at bugs.python.org  Fri Dec 16 22:08:24 2016
From: report at bugs.python.org (kevin)
Date: Sat, 17 Dec 2016 03:08:24 +0000
Subject: [issue28951] re.flags not documented in Module Contents as promised.
In-Reply-To: <1481569402.68.0.145626334512.issue28951@psf.upfronthosting.co.za>
Message-ID: <CAGVXcSbxSLJ5Kd2dtr-AH44agx8ouE+jJSmbgDkC=T14cJB_QA@mail.gmail.com>


kevin added the comment:

Ordinarily when I see a cross-reference like that "the flags are described
in foo" I expect foo to have a heading "FLAGS" so I can tell I'm looking at
what was promised.  Not knowing much about flags, it was not clear to me
that those scattered lines re.A through re.X were the promised
descriptions.  I didn't even notice them until now, partly because it's
made more confusing by all the stuff that's out of alphabetic order.  Or I
think it is -- it's hard to tell because of things like re.S and re.DOTALL
being together.  My current guess is that the uppercase things come before
lowercase, but those odd pairings are definitely messing with my mind.

All of which is just to say it probably makes perfect sense to someone
who's used to it, but it's hard on someone new to these docs, and I'm not
even new to Python, just to the re module.

On Mon, Dec 12, 2016 at 11:03 AM, R. David Murray <report at bugs.python.org>
wrote:

>
> R. David Murray added the comment:
>
> When I follow the link to module contents, I find a list of the flags with
> their descriptions.  (re.A, re.I, etc, etc).  Perhaps you are confusing the
> letters used in the regular expression to represent the flags with the
> flags themselves?  I'm not sure how we could make that clearer.
>
> ----------
> nosy: +r.david.murray
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue28951>
> _______________________________________
>

-- 
Kevin O'Gorman
#define QUESTION ((bb) || (!bb))   /* Shakespeare */

Please consider the environment before printing this email.

----------
Added file: http://bugs.python.org/file45934/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28951>
_______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unnamed
Type: image/gif
Size: 441 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20161217/f7434179/attachment.gif>

From report at bugs.python.org  Fri Dec 16 22:45:24 2016
From: report at bugs.python.org (Evan)
Date: Sat, 17 Dec 2016 03:45:24 +0000
Subject: [issue14156] argparse.FileType for '-' doesn't work for a mode of 'rb'
In-Reply-To: <1330513271.31.0.437438851478.issue14156@psf.upfronthosting.co.za>
Message-ID: <1481946324.26.0.00615601042269.issue14156@psf.upfronthosting.co.za>


Evan added the comment:

This issue is relevant to Python 2 on Windows since you need to disable the EOL conversion if you're trying to receive binary data on stdin.

See: http://stackoverflow.com/questions/2850893/reading-binary-data-from-stdin

----------
nosy: +evan_

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14156>
_______________________________________

From report at bugs.python.org  Fri Dec 16 23:02:00 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 17 Dec 2016 04:02:00 +0000
Subject: [issue28990] asyncio SSL hangs if connection is closed before
 handshake completed
In-Reply-To: <1481906549.65.0.746486264017.issue28990@psf.upfronthosting.co.za>
Message-ID: <20161217040157.11043.97532.72D14DAA@psf.io>


Roundup Robot added the comment:

New changeset bfd4f13b478b by Yury Selivanov in branch '3.6':
Merge 3.5 (issue #28990)
https://hg.python.org/cpython/rev/bfd4f13b478b

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28990>
_______________________________________

From report at bugs.python.org  Fri Dec 16 23:02:00 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 17 Dec 2016 04:02:00 +0000
Subject: [issue28770] Update python-gdb.py for fastcalls
In-Reply-To: <1479814975.16.0.381517171433.issue28770@psf.upfronthosting.co.za>
Message-ID: <20161217040157.11043.60379.205C3262@psf.io>


Roundup Robot added the comment:

New changeset b0efa88c4cf4 by Victor Stinner in branch '3.6':
Issue #28770: Update python-gdb.py for fastcalls
https://hg.python.org/cpython/rev/b0efa88c4cf4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28770>
_______________________________________

From report at bugs.python.org  Sat Dec 17 00:09:15 2016
From: report at bugs.python.org (Ned Deily)
Date: Sat, 17 Dec 2016 05:09:15 +0000
Subject: [issue28990] asyncio SSL hangs if connection is closed before
 handshake completed
In-Reply-To: <1481906549.65.0.746486264017.issue28990@psf.upfronthosting.co.za>
Message-ID: <1481951355.32.0.761851327821.issue28990@psf.upfronthosting.co.za>


Ned Deily added the comment:

[cherrypicked for 3.6.0rc2]

----------
priority: release blocker -> 
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28990>
_______________________________________

From report at bugs.python.org  Sat Dec 17 00:09:56 2016
From: report at bugs.python.org (Ned Deily)
Date: Sat, 17 Dec 2016 05:09:56 +0000
Subject: [issue28770] Update python-gdb.py for fastcalls
In-Reply-To: <1479814975.16.0.381517171433.issue28770@psf.upfronthosting.co.za>
Message-ID: <1481951396.8.0.558959662901.issue28770@psf.upfronthosting.co.za>


Ned Deily added the comment:

[cherrypicked for 3.6.0rc2]

----------
priority: release blocker -> 
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28770>
_______________________________________

From report at bugs.python.org  Sat Dec 17 00:15:22 2016
From: report at bugs.python.org (Ned Deily)
Date: Sat, 17 Dec 2016 05:15:22 +0000
Subject: [issue28147] Unbounded memory growth resizing split-table dicts
In-Reply-To: <1473853453.13.0.556951743271.issue28147@psf.upfronthosting.co.za>
Message-ID: <1481951722.21.0.836443571501.issue28147@psf.upfronthosting.co.za>


Ned Deily added the comment:

So now that a fix has been released with 3.6.0rc2, what else needs to be done to close this issue?  Why is 3.5 selected in the applicable versions?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28147>
_______________________________________

From report at bugs.python.org  Sat Dec 17 01:41:52 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 17 Dec 2016 06:41:52 +0000
Subject: [issue13051] Infinite recursion in curses.textpad.Textbox
In-Reply-To: <1317170831.29.0.145546521568.issue13051@psf.upfronthosting.co.za>
Message-ID: <1481956912.5.0.373956370476.issue13051@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13051>
_______________________________________

From report at bugs.python.org  Sat Dec 17 02:46:52 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 17 Dec 2016 07:46:52 +0000
Subject: [issue28180] sys.getfilesystemencoding() should default to utf-8
In-Reply-To: <1474024622.65.0.838685461995.issue28180@psf.upfronthosting.co.za>
Message-ID: <1481960812.45.0.653542017329.issue28180@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

We've been discussing this further downstream in the Fedora Python SIG, and we have a draft approach that we're pretty sure will work for us (based in turn on the approach Armin Ronacher came up with for click), and we think it should work for other distros as well (as long as they already ship the C.UTF-8 locale, and if they don't, they should fix that limitation anyway).

So I'm assigning this to myself as I think the next step will be to write a PEP that both proposes the specific idea as the default behaviour in 3.7, and also encourages distros to opt-in to trialling it as a downstream patch for 3.6.

----------
assignee:  -> ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28180>
_______________________________________

From report at bugs.python.org  Sat Dec 17 02:52:12 2016
From: report at bugs.python.org (Miki Tebeka)
Date: Sat, 17 Dec 2016 07:52:12 +0000
Subject: [issue28972] Document all "python -m" utilities
In-Reply-To: <1481720403.32.0.43245427479.issue28972@psf.upfronthosting.co.za>
Message-ID: <1481961132.57.0.647089747379.issue28972@psf.upfronthosting.co.za>


Miki Tebeka added the comment:

Eric - sorry I wasn't clear. I'm not talking about the -m behavior in general but on the modules in the standard library that can be used with it. A lot of windows are happy to know about "python -m tarfile" to they can extract tar files without installing an extra tool and some Linux people are happy to know on "python -m zipfile" so they don't have to install the "zip" utility to extract/create zip archives. etc ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28972>
_______________________________________

From report at bugs.python.org  Sat Dec 17 02:56:20 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 17 Dec 2016 07:56:20 +0000
Subject: [issue28180] sys.getfilesystemencoding() should default to utf-8
In-Reply-To: <1474024622.65.0.838685461995.issue28180@psf.upfronthosting.co.za>
Message-ID: <1481961380.58.0.954586765946.issue28180@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Making an explicit note of this so I remember to mention it in the draft PEP: one of the biggest problems that arises in any attempt at a Python-only solution to overriding the locale is that we can end up disagreeing with C/C++ extensions, and this is *especially* a problem when sharing a process with GUI frameworks like Tcl/Tk, Qt, and GTK (since they tend to read the process-wide settings, rather than querying anything that CPython configures during normal operation).

So the approach I'm proposing is to implement a C->C.UTF-8 locale override in the *actual python CLI executable*, and then in the dynamically linked library we only emit a warning if we detect the C locale, we don't actually do anything to change it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28180>
_______________________________________

From report at bugs.python.org  Sat Dec 17 03:20:06 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 17 Dec 2016 08:20:06 +0000
Subject: [issue28596] on Android _bootlocale on startup relies on too many
 library modules
In-Reply-To: <1478166520.26.0.975749703987.issue28596@psf.upfronthosting.co.za>
Message-ID: <20161217082003.32090.9185.F7B1D530@psf.io>


Roundup Robot added the comment:

New changeset 1756beed417c by Xavier de Gaye in branch 'default':
Issue #28596: The preferred encoding is UTF-8 on Android.
https://hg.python.org/cpython/rev/1756beed417c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28596>
_______________________________________

From report at bugs.python.org  Sat Dec 17 03:24:54 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 17 Dec 2016 08:24:54 +0000
Subject: [issue26928] _bootlocale imports locale at startup on Android,
 causing test_site to fail
In-Reply-To: <1462284365.5.0.819379627022.issue26928@psf.upfronthosting.co.za>
Message-ID: <1481963094.14.0.312413363867.issue26928@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Closing as invalid, it is useful to have the test failing on platforms that do not have CODESET and detect that too many modules are imported on startup. For Android, this problem is fixed in issue 28596.

----------
resolution:  -> not a bug
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26928>
_______________________________________

From report at bugs.python.org  Sat Dec 17 03:35:18 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 17 Dec 2016 08:35:18 +0000
Subject: [issue28996] wcscoll is broken on Android and test_locale fails
Message-ID: <1481963718.08.0.920050367938.issue28996@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

These failures happen now that issue 28596 has been fixed and that locale.getpreferredencoding(False) returns 'UTF-8'.

======================================================================
FAIL: test_strcoll_with_diacritic (test.test_locale.TestEnUSCollation)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sdcard/org.bitbucket.pyona/lib/python3.7/test/test_locale.py", line 362, in test_strcoll_with_diacritic
    self.assertLess(locale.strcoll('?', 'b'), 0)
AssertionError: 1 not less than 0

======================================================================
FAIL: test_strxfrm_with_diacritic (test.test_locale.TestEnUSCollation)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sdcard/org.bitbucket.pyona/lib/python3.7/test/test_locale.py", line 365, in test_strxfrm_with_diacritic
    self.assertLess(locale.strxfrm('?'), locale.strxfrm('b'))
AssertionError: '?' not less than 'b'

----------------------------------------------------------------------

----------
assignee: xdegaye
components: Tests
messages: 283474
nosy: xdegaye
priority: normal
severity: normal
stage: needs patch
status: open
title: wcscoll is broken on Android and test_locale fails
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28996>
_______________________________________

From report at bugs.python.org  Sat Dec 17 03:39:00 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 17 Dec 2016 08:39:00 +0000
Subject: [issue28596] on Android _bootlocale on startup relies on too many
 library modules
In-Reply-To: <1478166520.26.0.975749703987.issue28596@psf.upfronthosting.co.za>
Message-ID: <1481963940.04.0.694301314113.issue28596@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Closing the issue. Thanks for the patch Chi Hsuan Yen.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28596>
_______________________________________

From report at bugs.python.org  Sat Dec 17 04:02:49 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 17 Dec 2016 09:02:49 +0000
Subject: [issue28997] test_readline.test_nonascii fails on Android
Message-ID: <1481965369.72.0.409169776064.issue28997@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

test_nonascii has been implemented in issue 16182.

The error message:
======================================================================
FAIL: test_nonascii (test.test_readline.TestReadline)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sdcard/org.bitbucket.pyona/lib/python3.7/test/test_readline.py", line 203, in test_nonascii
    self.assertIn(b"text 't\\xeb'\r\n", output)
AssertionError: b"text 't\\xeb'\r\n" not found in bytearray(b"^A^B^B^B^B^B^B^B\t\tx\t\r\n[\\303\\257nserted]|t\x07\x08\x08\x08\x08\x08\x08\x08\x07\x07xrted]|t\x08\x08\x08\x08\x08\x08\x08\x07\r\nresult \'[\\xefnsexrted]|t\'\r\nhistory \'[\\xefnsexrted]|t\'\r\n")

----------------------------------------------------------------------

----------
assignee: xdegaye
components: Tests
messages: 283476
nosy: xdegaye
priority: normal
severity: normal
stage: needs patch
status: open
title: test_readline.test_nonascii fails on Android
type: behavior
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28997>
_______________________________________

From report at bugs.python.org  Sat Dec 17 04:06:07 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 17 Dec 2016 09:06:07 +0000
Subject: [issue26865] Meta-issue: support of the android platform
In-Reply-To: <1461685011.99.0.617135447086.issue26865@psf.upfronthosting.co.za>
Message-ID: <1481965567.07.0.691889148533.issue26865@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

issue #28996: wcscoll is broken on Android and test_locale fails
issue #28997: test_readline.test_nonascii fails on Android

----------
dependencies: +test_readline.test_nonascii fails on Android, wcscoll is broken on Android and test_locale fails

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26865>
_______________________________________

From report at bugs.python.org  Sat Dec 17 04:26:43 2016
From: report at bugs.python.org (INADA Naoki)
Date: Sat, 17 Dec 2016 09:26:43 +0000
Subject: [issue28147] Unbounded memory growth resizing split-table dicts
In-Reply-To: <1473853453.13.0.556951743271.issue28147@psf.upfronthosting.co.za>
Message-ID: <1481966803.49.0.740953098274.issue28147@psf.upfronthosting.co.za>


INADA Naoki added the comment:

Before Python 3.6, instance.__dict__.pop(key) didn't trigger this.
But there are many way to trigger this. This bug is live from 3.3.
This script reproduce this issue on Python 3.5.

class C: pass
a = C()
a.a = 1
while True:
    a.__dict__.popitem()  # convert split table into combined table.
    a.a = 1   # convert combined table into split table again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28147>
_______________________________________

From report at bugs.python.org  Sat Dec 17 04:37:38 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 17 Dec 2016 09:37:38 +0000
Subject: [issue28998] Unifying Long Integers and Integers in 2.7
Message-ID: <1481967458.92.0.739722865425.issue28998@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Since implementing PEP 237 (Unifying Long Integers and Integers) in Python 2.4 int and long instances became interchangeable. Virtually any function that needs an integer, accepts both int and long. But there are few places where only int is accepted. Since it is easy unintentionally convert int to long (add and subtract large int, or add 0L), this can lead to subtle errors in rare circumstances.

Proposed patch makes few places that accepted only int accepting long too. This mainly is changing isinstance(x, int) to isinstance(x, (int, long)).

----------
components: Extension Modules, Library (Lib)
messages: 283479
nosy: benjamin.peterson, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Unifying Long Integers and Integers in 2.7
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28998>
_______________________________________

From report at bugs.python.org  Sat Dec 17 04:48:42 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 17 Dec 2016 09:48:42 +0000
Subject: [issue28998] Unifying Long Integers and Integers in 2.7
In-Reply-To: <1481967458.92.0.739722865425.issue28998@psf.upfronthosting.co.za>
Message-ID: <1481968122.85.0.300541477159.issue28998@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file45935/py2_int_long.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28998>
_______________________________________

From report at bugs.python.org  Sat Dec 17 05:09:47 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 17 Dec 2016 10:09:47 +0000
Subject: [issue28999] Use Py_RETURN_NONE and like
Message-ID: <1481969387.72.0.775552115596.issue28999@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

In the comment to issue28765 patch Victor suggested to replace "Py_INCREF(Py_None); return Py_None;" with "Py_RETURN_NONE;".

Here is a Coccinelle [1] semantic patch that replaces all returns of new references to None, True or False with macros Py_RETURN_NONE, Py_RETURN_TRUE or Py_RETURN_FALSE correspondingly.

[1] http://coccinelle.lip6.fr/

----------
components: Extension Modules, Interpreter Core
files: py_return.cocci
messages: 283480
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Use Py_RETURN_NONE and like
type: enhancement
versions: Python 3.7
Added file: http://bugs.python.org/file45936/py_return.cocci

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28999>
_______________________________________

From report at bugs.python.org  Sat Dec 17 05:11:07 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 17 Dec 2016 10:11:07 +0000
Subject: [issue28999] Use Py_RETURN_NONE and like
In-Reply-To: <1481969387.72.0.775552115596.issue28999@psf.upfronthosting.co.za>
Message-ID: <1481969467.69.0.372348605509.issue28999@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Resulting patch is huge. I don't think it can be pushed.

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file45937/py_return.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28999>
_______________________________________

From report at bugs.python.org  Sat Dec 17 05:15:25 2016
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 17 Dec 2016 10:15:25 +0000
Subject: [issue28180] sys.getfilesystemencoding() should default to utf-8
In-Reply-To: <1481961380.58.0.954586765946.issue28180@psf.upfronthosting.co.za>
Message-ID: <7bfd1a2b-a916-1b5f-c8f2-78c462fe84cf@egenix.com>


Marc-Andre Lemburg added the comment:

On 17.12.2016 08:56, Nick Coghlan wrote:
> 
> Making an explicit note of this so I remember to mention it in the draft PEP: one of the biggest problems that arises in any attempt at a Python-only solution to overriding the locale is that we can end up disagreeing with C/C++ extensions, and this is *especially* a problem when sharing a process with GUI frameworks like Tcl/Tk, Qt, and GTK (since they tend to read the process-wide settings, rather than querying anything that CPython configures during normal operation).

Another use case to consider is embedding the Python
interpreter in another application. In such situations,
the C locale will usually already be set by the main
application and it may conflict with the LANG or other
locale env var settings, since the user may have chosen
to use a different locale in the context of the application.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28180>
_______________________________________

From report at bugs.python.org  Sat Dec 17 05:34:52 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 17 Dec 2016 10:34:52 +0000
Subject: [issue28999] Use Py_RETURN_NONE and like
In-Reply-To: <1481969387.72.0.775552115596.issue28999@psf.upfronthosting.co.za>
Message-ID: <1481970892.66.0.407770182958.issue28999@psf.upfronthosting.co.za>


STINNER Victor added the comment:

py_return.patch LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28999>
_______________________________________

From report at bugs.python.org  Sat Dec 17 05:51:07 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 17 Dec 2016 10:51:07 +0000
Subject: [issue9770] curses.ascii.isblank() function is broken. It confuses
 backspace (BS 0x08) with tab (0x09)
In-Reply-To: <1283558509.74.0.494754089018.issue9770@psf.upfronthosting.co.za>
Message-ID: <1481971867.88.0.474580594642.issue9770@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Most issues was fixed in issue27079. Except handling negative integers. Following patch fixes the latter issue.

----------
nosy: +serhiy.storchaka
stage:  -> patch review
versions: +Python 3.6, Python 3.7 -Python 3.4
Added file: http://bugs.python.org/file45938/curses-ascii-negative.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9770>
_______________________________________

From report at bugs.python.org  Sat Dec 17 08:41:04 2016
From: report at bugs.python.org (woo yoo)
Date: Sat, 17 Dec 2016 13:41:04 +0000
Subject: [issue29000] Not matched behavior within printf style bytes formatting
Message-ID: <1481982064.72.0.399504561165.issue29000@psf.upfronthosting.co.za>


New submission from woo yoo:

Per the documentation,"The alternate form causes a leading octal specifier ('0o') to be inserted before the first digit", However the actual behavior didn't conform to the principle.

Code:
>>>b'%#07o' % 34

Output: b'0000o42'

----------
assignee: docs at python
components: Documentation
messages: 283485
nosy: docs at python, woo yoo
priority: normal
severity: normal
status: open
title: Not matched behavior within printf style bytes formatting
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29000>
_______________________________________

From report at bugs.python.org  Sat Dec 17 08:41:41 2016
From: report at bugs.python.org (woo yoo)
Date: Sat, 17 Dec 2016 13:41:41 +0000
Subject: [issue29000] Not matched behavior within printf style bytes formatting
In-Reply-To: <1481982064.72.0.399504561165.issue29000@psf.upfronthosting.co.za>
Message-ID: <1481982101.39.0.386426568393.issue29000@psf.upfronthosting.co.za>


woo yoo added the comment:

The link is https://docs.python.org/3.5/library/stdtypes.html#printf-style-bytes-formatting

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29000>
_______________________________________

From report at bugs.python.org  Sat Dec 17 09:13:28 2016
From: report at bugs.python.org (R. David Murray)
Date: Sat, 17 Dec 2016 14:13:28 +0000
Subject: [issue28951] re.flags not documented in Module Contents as promised.
In-Reply-To: <1481569048.46.0.00215126822864.issue28951@psf.upfronthosting.co.za>
Message-ID: <1481984008.62.0.0398042168525.issue28951@psf.upfronthosting.co.za>


R. David Murray added the comment:

Making a 'flags' subheading in module contents would be reasonable.  Alternatively we could just drop that parenthetical, since the descriptions for each flag are themselves cross-linked.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28951>
_______________________________________

From report at bugs.python.org  Sat Dec 17 09:29:46 2016
From: report at bugs.python.org (R. David Murray)
Date: Sat, 17 Dec 2016 14:29:46 +0000
Subject: [issue29000] Not matched behavior within printf style bytes formatting
In-Reply-To: <1481982064.72.0.399504561165.issue29000@psf.upfronthosting.co.za>
Message-ID: <1481984986.28.0.8449775426.issue29000@psf.upfronthosting.co.za>


R. David Murray added the comment:

The documentation matches the behavior.  In this context "the first digit" is the 4.  The leading zeros are the pad fill.  Now, whether this is *useful* behavior or not is a separate question :)  And yes, the docs could be clarified on this point either way.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29000>
_______________________________________

From report at bugs.python.org  Sat Dec 17 09:37:49 2016
From: report at bugs.python.org (woo yoo)
Date: Sat, 17 Dec 2016 14:37:49 +0000
Subject: [issue29000] Not matched behavior within printf style bytes formatting
In-Reply-To: <1481982064.72.0.399504561165.issue29000@psf.upfronthosting.co.za>
Message-ID: <1481985469.4.0.791325274007.issue29000@psf.upfronthosting.co.za>


woo yoo added the comment:

Make a slight change to my code, which becomes `b'%#07x' % 34`, the weird situation appears.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29000>
_______________________________________

From report at bugs.python.org  Sat Dec 17 10:15:32 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 17 Dec 2016 15:15:32 +0000
Subject: [issue28971] nntplib is broken when responses are longer than _MAXLINE
In-Reply-To: <1481716454.12.0.730668429479.issue28971@psf.upfronthosting.co.za>
Message-ID: <1481987732.53.0.0216092334746.issue28971@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

This patch defines a _MAXBYTES limit of 100 Mb. The limit is checked upon reading one line and also upon reading the multi-lines of the response to a user command.

----------
Added file: http://bugs.python.org/file45939/nntplib_maxbytes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28971>
_______________________________________

From report at bugs.python.org  Sat Dec 17 10:18:22 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 17 Dec 2016 15:18:22 +0000
Subject: [issue29000] Not matched behavior within printf style bytes formatting
In-Reply-To: <1481982064.72.0.399504561165.issue29000@psf.upfronthosting.co.za>
Message-ID: <1481987902.1.0.551264145122.issue29000@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is not documentation issue, but a bug in formatting octals in bytes.

>>> '%#07x' % 123
'0x0007b'
>>> b'%#07x' % 123
b'0x0007b'
>>> '%#07o' % 123
'0o00173'
>>> b'%#07o' % 123
b'000o173'
     ^

----------
components: +Interpreter Core -Documentation
nosy: +ethan.furman, serhiy.storchaka
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29000>
_______________________________________

From report at bugs.python.org  Sat Dec 17 10:19:53 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 17 Dec 2016 15:19:53 +0000
Subject: [issue28927] bytes.fromhex should ignore all whitespace
In-Reply-To: <1481328446.9.0.450435696311.issue28927@psf.upfronthosting.co.za>
Message-ID: <1481987993.03.0.205883345943.issue28927@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

My recollection is that fromhex() ignores spaces to account for particularly common ways of formatting hex numbers as space separated groups:

    "CAFE F00D"
    "CAFEF00D CAFEF00D CAFEF00D"
    "CA FE F0 0D"
    etc

Those show up even in structured hexadecimal data (like hex editor output and memory dumps in log files).

That recollection is supported by the example and specification of specifically "[0-9a-fA-F ]" in PEP 358 (https://www.python.org/dev/peps/pep-0358/) that guided Georg Brandl's initial implementation in http://bugs.python.org/issue1669379

Generally speaking, the type level string parsers *aren't* permissive when it comes to their whitespace handling - if they allow whitespace at all, it's usually only at the beginning or end, where it gets ignored (hence the PEP for 3.6 to allow underscores in both numeric literals and in the numeric constructors).

=====================
>>> float(" 1.0")
1.0
>>> float("1.0 ")
1.0
>>> float("1 0")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: could not convert string to float: '1 0'
>>> float("1. 0")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: could not convert string to float: '1. 0'
>>> float("1 .0")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: could not convert string to float: '1 .0'
=====================

The general technique to strip whitespace from *any* input data before handing it to a constructor relies on str.translate:

=====================
>>> import string
>>> _del_whitespace = str.maketrans('', '', string.whitespace)
>>> def clean_whitespace(text):
...     return text.translate(_del_whitespace)
... 
>>> clean_whitespace('CA FE\nF0\t0D')
'CAFEF00D'
=====================

(http://stackoverflow.com/questions/3739909/how-to-strip-all-whitespace-from-string also points out `"".join(text.split())` as a clever one liner for a similar outcome)

So I'm inclined to advise *against* making any changes here - the apparent benefit is more a symptom of the fact that there isn't an immediately obvious spelling of "strip all whitespace, including that between other characters, from this string" that can be readily applied as an initial filter on the incoming data.

(However, I do sometimes wonder if it would make sense to offer a "str.stripall()" that defaulted to removing all whitespace, rather than treating this purely as a particular use case for str.translate)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28927>
_______________________________________

From report at bugs.python.org  Sat Dec 17 10:25:56 2016
From: report at bugs.python.org (kevin)
Date: Sat, 17 Dec 2016 15:25:56 +0000
Subject: [issue28951] re.flags not documented in Module Contents as promised.
In-Reply-To: <1481984008.62.0.0398042168525.issue28951@psf.upfronthosting.co.za>
Message-ID: <CAGVXcSZ4SOPCtDrR7jWGDg-Q-A3njmZ862qoELYvtdq=xCNEZA@mail.gmail.com>


kevin added the comment:

Well, my original problem is that I wanted to find out what the flags did
and could not find any pointer in the table of contents.  I think they
deserve either really good cross-references, or a heading in the contents.
And a non-confusing alphabetized list, if they're going to be mixed in with
other module contents.

On Sat, Dec 17, 2016 at 6:13 AM, R. David Murray <report at bugs.python.org>
wrote:

>
> R. David Murray added the comment:
>
> Making a 'flags' subheading in module contents would be reasonable.
> Alternatively we could just drop that parenthetical, since the descriptions
> for each flag are themselves cross-linked.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue28951>
> _______________________________________
>

-- 
Kevin O'Gorman
#define QUESTION ((bb) || (!bb))   /* Shakespeare */

Please consider the environment before printing this email.

----------
Added file: http://bugs.python.org/file45940/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28951>
_______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unnamed
Type: image/gif
Size: 441 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20161217/64c0b987/attachment.gif>

From report at bugs.python.org  Sat Dec 17 10:29:15 2016
From: report at bugs.python.org (kevin)
Date: Sat, 17 Dec 2016 15:29:15 +0000
Subject: [issue28951] re.flags not documented in Module Contents as promised.
In-Reply-To: <1481984008.62.0.0398042168525.issue28951@psf.upfronthosting.co.za>
Message-ID: <CAGVXcSYrabTXbVTPNCupWXH6+Xi2VaOTJ7nwvu0aVC0McF5RoA@mail.gmail.com>


kevin added the comment:

Oh, and on the alphabetized list, I suggest NOT listing synonyms together,
but just mark some as "synonym for X" and listing them all alphabetically
(according to "en" collation, not "C" so upper- and lower-case sort
together, not separately).

On Sat, Dec 17, 2016 at 6:13 AM, R. David Murray <report at bugs.python.org>
wrote:

>
> R. David Murray added the comment:
>
> Making a 'flags' subheading in module contents would be reasonable.
> Alternatively we could just drop that parenthetical, since the descriptions
> for each flag are themselves cross-linked.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue28951>
> _______________________________________
>

-- 
Kevin O'Gorman
#define QUESTION ((bb) || (!bb))   /* Shakespeare */

Please consider the environment before printing this email.

----------
Added file: http://bugs.python.org/file45941/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28951>
_______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unnamed
Type: image/gif
Size: 441 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20161217/fd218635/attachment.gif>

From report at bugs.python.org  Sat Dec 17 10:33:17 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 17 Dec 2016 15:33:17 +0000
Subject: [issue28180] sys.getfilesystemencoding() should default to utf-8
In-Reply-To: <7bfd1a2b-a916-1b5f-c8f2-78c462fe84cf@egenix.com>
Message-ID: <CADiSq7dS7dMQpeAuVfLmwFym232RXbwEHDayA88=JP7m-1v4BA@mail.gmail.com>


Nick Coghlan added the comment:

On 17 December 2016 at 20:15, Marc-Andre Lemburg <report at bugs.python.org>
wrote:

> Another use case to consider is embedding the Python
> interpreter in another application. In such situations,
> the C locale will usually already be set by the main
> application and it may conflict with the LANG or other
> locale env var settings, since the user may have chosen
> to use a different locale in the context of the application.
>

Aye, that's the origin of the split proposal to only emit a warning in the
shared library (since CPython might only be a piece of a larger
application), but implement actual locale coercion (by overriding LANG and
LC_ALL in the process environment) in the command line app's main()
function (as in that case we know CPython *is* the application).

The hard part of writing the PEP isn't really going to be explaining the
proposal itself (I expect it to be around a 20 line patch to the C code) -
it's going to be explaining why all the other possibilities we've
considered over the years don't work, and why we (as in the Fedora Python
SIG) think this one actually stands a chance of working properly :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28180>
_______________________________________

From report at bugs.python.org  Sat Dec 17 10:53:31 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 17 Dec 2016 15:53:31 +0000
Subject: [issue28996] wcscoll is broken on Android and test_locale fails
In-Reply-To: <1481963718.08.0.920050367938.issue28996@psf.upfronthosting.co.za>
Message-ID: <1481990011.29.0.921091343055.issue28996@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Both strcoll() and strxfrm() are broken (character '?' unicode code point is 'e0'):

>>> import locale
>>> locale.setlocale(locale.LC_ALL, 'en_US.UTF-8')
'C.UTF-8'
>>> locale.strcoll('\u00e0', 'b')
1
>>> locale.strxfrm('\u00e0') < locale.strxfrm('b')
False

The correct results are -1 and True.

----------
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28996>
_______________________________________

From report at bugs.python.org  Sat Dec 17 11:02:25 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 17 Dec 2016 16:02:25 +0000
Subject: [issue28996] wcscoll is broken on Android and test_locale fails
In-Reply-To: <1481963718.08.0.920050367938.issue28996@psf.upfronthosting.co.za>
Message-ID: <1481990545.37.0.525913072862.issue28996@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Here is a patch that skips test_strcoll_with_diacritic and test_strxfrm_with_diacritic.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file45942/test_locale_strcoll.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28996>
_______________________________________

From report at bugs.python.org  Sat Dec 17 11:26:25 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 17 Dec 2016 16:26:25 +0000
Subject: [issue28972] Document all "python -m" utilities
In-Reply-To: <1481720403.32.0.43245427479.issue28972@psf.upfronthosting.co.za>
Message-ID: <1481991985.84.0.715419674588.issue28972@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I'm neutral on this idea.  I would much rather focus on making sure that the various modules (such as pdb or tarfile) which have useful command-line functionality document that clearly and uniformly, but as part of each module's library docs.

I don't think that a list of all modules that have such behavior really belongs in the stdlib docs, but if someone wants to add it and keep it up to date I won't object.  Just understand that whatever is documented must preserve some sort of backwards compatibility.  And don't repeat the same information in two places.

Maybe the blog post that started this is actually enough?  Or if something more official is needed, perhaps a how-to document?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28972>
_______________________________________

From report at bugs.python.org  Sat Dec 17 11:27:23 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 17 Dec 2016 16:27:23 +0000
Subject: [issue29000] Not matched behavior within printf style bytes formatting
In-Reply-To: <1481982064.72.0.399504561165.issue29000@psf.upfronthosting.co.za>
Message-ID: <1481992043.68.0.745969906681.issue29000@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Proposed patch fixes this inconsistency.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file45943/bytes-format-oct-alt-zero.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29000>
_______________________________________

From report at bugs.python.org  Sat Dec 17 12:09:30 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Sat, 17 Dec 2016 17:09:30 +0000
Subject: [issue28996] wcscoll is broken on Android and test_locale fails
In-Reply-To: <1481963718.08.0.920050367938.issue28996@psf.upfronthosting.co.za>
Message-ID: <1481994570.19.0.370206028268.issue28996@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

I'm afraid that the sentence "wcscoll/wcsxfrm have known bugs" is misleading for people who are not quite familiar with Android. The actual cause is that BioniC's setlocale() behaves differently than other platforms. Most implementations returns NULL if en_US.UTF-8 is not available, but BioniC returns C.UTF-8. I guess it's better to add some comments for the real cause on Android.

----------
nosy: +Chi Hsuan Yen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28996>
_______________________________________

From report at bugs.python.org  Sat Dec 17 12:52:20 2016
From: report at bugs.python.org (paul j3)
Date: Sat, 17 Dec 2016 17:52:20 +0000
Subject: [issue14364] Argparse incorrectly handles '--' as argument to option
In-Reply-To: <1332080953.55.0.495639573781.issue14364@psf.upfronthosting.co.za>
Message-ID: <1481997140.77.0.138681143526.issue14364@psf.upfronthosting.co.za>


paul j3 added the comment:

I've copied 'dbldash.patch' over from http://bugs.python.org/issue13922.  I mistakenly added it to a closed issue.

The patch is old, and should be revised.  It is also missing tests for this '--opt=--' case, even though it solves it.   

I also reference this patch in http://bugs.python.org/issue9571, which tries to refine dbldash handling for PARSER, REMAINDER nargs.

I'm raising the priority on this because the issue has a come up a couple of times on Stackoverflow:

http://stackoverflow.com/questions/40685320/python-argparse-with-as-the-value

----------
keywords: +needs review
priority: normal -> high
versions: +Python 3.6, Python 3.7 -Python 3.2, Python 3.3
Added file: http://bugs.python.org/file45944/dbldash.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14364>
_______________________________________

From report at bugs.python.org  Sat Dec 17 13:06:35 2016
From: report at bugs.python.org (R. David Murray)
Date: Sat, 17 Dec 2016 18:06:35 +0000
Subject: [issue29000] Not matched behavior within printf style bytes formatting
In-Reply-To: <1481982064.72.0.399504561165.issue29000@psf.upfronthosting.co.za>
Message-ID: <1481997995.75.0.300778227315.issue29000@psf.upfronthosting.co.za>


R. David Murray added the comment:

OK, that makes sense.  Patch looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29000>
_______________________________________

From report at bugs.python.org  Sat Dec 17 13:15:25 2016
From: report at bugs.python.org (R. David Murray)
Date: Sat, 17 Dec 2016 18:15:25 +0000
Subject: [issue28951] re.flags not documented in Module Contents as promised.
In-Reply-To: <1481569048.46.0.00215126822864.issue28951@psf.upfronthosting.co.za>
Message-ID: <1481998525.46.0.531625757926.issue28951@psf.upfronthosting.co.za>


R. David Murray added the comment:

(Please delete the message you are replying to when responding to bug tracker emails.)

I think a section heading would be good (three subheads under module contents: functions, flags, and exceptions).  I'm less in favor of alphabetical entries for synonyms.  We'll see what others think.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28951>
_______________________________________

From report at bugs.python.org  Sat Dec 17 13:24:09 2016
From: report at bugs.python.org (Robert Xiao)
Date: Sat, 17 Dec 2016 18:24:09 +0000
Subject: [issue28927] bytes.fromhex should ignore all whitespace
In-Reply-To: <1481328446.9.0.450435696311.issue28927@psf.upfronthosting.co.za>
Message-ID: <1481999049.76.0.0901294904638.issue28927@psf.upfronthosting.co.za>


Robert Xiao added the comment:

I see your point, Nick. Can I offer a counterpoint?

Most of the string parsers operate only on relatively short inputs, like numbers. Numbers in particular are rarely written with inner spaces, so it makes sense not to ignore internal whitespaces.

On the other hand, hexadecimal data can be very long, and is often formatted with spaces and newlines. For example, the default output of `xxd -p`, a format quite suitable for copy-paste, looks like this:

cffaedfe07000001030000800200000015000000d8080000858021000000
000019000000480000005f5f504147455a45524f00000000000000000000
000000000000000001000000000000000000000000000000000000000000
000000000000000000000000000019000000180300005f5f544558540000
0000000000000000000000000100000000909d0100000000000000000000

It would be desirable to write something like

blob = bytes.fromhex('''
cffaedfe07000001030000800200000015000000d8080000858021000000
000019000000480000005f5f504147455a45524f00000000000000000000
000000000000000001000000000000000000000000000000000000000000
000000000000000000000000000019000000180300005f5f544558540000
0000000000000000000000000100000000909d0100000000000000000000
''')

and not have to worry about sticking in some whitespace remover, like this:

blob = bytes.fromhex(''.join('''
cffaedfe07000001030000800200000015000000d8080000858021000000
000019000000480000005f5f504147455a45524f00000000000000000000
000000000000000001000000000000000000000000000000000000000000
000000000000000000000000000019000000180300005f5f544558540000
0000000000000000000000000100000000909d0100000000000000000000
'''.split()))

or removing the newlines in the source code, which impacts readability. 

Similar kinds of whitespaced output (sometimes with spaces between octets, words or dwords, sometimes with tabs between 8-16 byte groups, sometimes with newlines between groups, etc.) can be found in the wild and from the "hex" clipboard output from various applications.

We can already have newlines and other whitespace with base64, which is in principle quite similar:

blob = base64.b64decode('''
z/rt/gcAAAEDAACAAgAAABUAAADYCAAAhYAhAAAAAAAZAAAASAAAAF9fUEFHRVpFUk8AAAAAAAAAAAAA
AAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZAAAAGAMAAF9fVEVYVAAA
AAAAAAAAAAAAAAAAAQAAAACQnQEAAAAAAAAAAAAAAAAAkJ0BAAAAAAcAAAAFAAAACQAAAAAAAABfX3Rl
eHQAAAAAAAAAAAAAX19URVhUAAAAAAAAAAAAAAALAAABAAAARCF5AQAAAAAACwAACAAAAAAAAAAAAAAA
''')

so I think it makes sense to support other whitespaces in fromhex. I'm happy to reconsider if there's a strong argument against adding this convenience.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28927>
_______________________________________

From report at bugs.python.org  Sat Dec 17 14:13:03 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 17 Dec 2016 19:13:03 +0000
Subject: [issue28816] Document if zipimport can respect import hooks to load
 custom files from zip.
In-Reply-To: <1480326340.52.0.39566018579.issue28816@psf.upfronthosting.co.za>
Message-ID: <1482001983.78.0.118207427756.issue28816@psf.upfronthosting.co.za>


Brett Cannon added the comment:

The cutoff for 3.6.0 has passed, but documentation patches can still go in for 3.6.1 (and 3.5.3).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28816>
_______________________________________

From report at bugs.python.org  Sat Dec 17 14:20:21 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 17 Dec 2016 19:20:21 +0000
Subject: [issue13051] Infinite recursion in curses.textpad.Textbox
In-Reply-To: <1317170831.29.0.145546521568.issue13051@psf.upfronthosting.co.za>
Message-ID: <1482002421.37.0.737666077803.issue13051@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I can reproduce the second bug too.

Here is updated patch. The main difference is that it preserves maxx and maxy attributes and support them up to date.

----------
Added file: http://bugs.python.org/file45945/textpad-recursion-fix2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13051>
_______________________________________

From report at bugs.python.org  Sat Dec 17 14:21:37 2016
From: report at bugs.python.org (Jason R. Coombs)
Date: Sat, 17 Dec 2016 19:21:37 +0000
Subject: [issue28949] Stdlib modules disappear from file system
In-Reply-To: <1481553619.84.0.343525103437.issue28949@psf.upfronthosting.co.za>
Message-ID: <1482002497.66.0.138489675376.issue28949@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

Throughout the week, I've not experienced this issue again. Perhaps the reinstall of Dropbox corrected some transient condition. Or perhaps my system was in some environment where it was particularly sensitive on Monday but has since returned to the status quo. In any case, I'm going to close this issue until such a time that it occurs again.

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28949>
_______________________________________

From report at bugs.python.org  Sat Dec 17 14:30:35 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 17 Dec 2016 19:30:35 +0000
Subject: [issue28971] nntplib is broken when responses are longer than _MAXLINE
In-Reply-To: <1481716454.12.0.730668429479.issue28971@psf.upfronthosting.co.za>
Message-ID: <1482003035.93.0.530686009876.issue28971@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

If sender sends a lot of empty lines and file is not None, LF or CRLF is stripped from lines, and len(line) is 0. Every empty line increases the size of the lines list by 4 or 8 bytes. Since count is not changed, the loop is not bounded. Every LF byte sent by malicious sender increases memory consumption by 4 or 8 bytes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28971>
_______________________________________

From report at bugs.python.org  Sat Dec 17 14:35:16 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 17 Dec 2016 19:35:16 +0000
Subject: [issue28971] nntplib is broken when responses are longer than _MAXLINE
In-Reply-To: <1481716454.12.0.730668429479.issue28971@psf.upfronthosting.co.za>
Message-ID: <1482003316.38.0.128203586318.issue28971@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

I responded to your last review Serhiy, but the psf mail system reports a delivery failure, so you may have missed the notification as well as the other reviewers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28971>
_______________________________________

From report at bugs.python.org  Sat Dec 17 14:58:08 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 17 Dec 2016 19:58:08 +0000
Subject: [issue28971] nntplib is broken when responses are longer than _MAXLINE
In-Reply-To: <1481716454.12.0.730668429479.issue28971@psf.upfronthosting.co.za>
Message-ID: <1482004688.26.0.9666388092.issue28971@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

> If sender sends a lot of empty lines and file is not None, LF or CRLF is stripped from lines

Oh, I missed that. Maybe give a weight of 4 to 8 bytes or even more to a line, this value being added to the bytes count whether the line is empty or not.
Do you have another suggestion ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28971>
_______________________________________

From report at bugs.python.org  Sat Dec 17 15:00:59 2016
From: report at bugs.python.org (Bruce Edge)
Date: Sat, 17 Dec 2016 20:00:59 +0000
Subject: [issue29001] logging.handlers.RotatingFileHandler rotation broken
 under gunicorn
Message-ID: <1482004859.28.0.622019934032.issue29001@psf.upfronthosting.co.za>


New submission from Bruce Edge:

I've been seeing some funny behavior in log files form a logging.handlers.RotatingFileHandler.

Here's my handler config snippet, in a "log.cfg":

[handlers]
keys=log_file

[formatters]
keys=access

[formatter_access]
format=%(asctime)s - %(name)s(%(funcName)s:%(lineno)s)[%(process)d] - %(levelname)s: %(message)s
datefmt=%Y-%m-%d %H:%M:%S
class=logging.Formatter

[handler_log_file]
class=logging.handlers.RotatingFileHandler
formatter=access
args=('/var/log/ml-api/access.log', 'a', 10000000, 16, 'utf8')

Specified using:

 /usr/local/bin/gunicorn --worker-class=gevent --bind unix:ml-api.sock -m 007 --workers=8 --log-config=log.cfg --log-level=DEBUG app

I ran this script to show the progression of log file creation:

while true ; do ls -lrt && sleep 10; done

Initially there's one incrementing log file, fine:

-rw-r--r-- 1 ubuntu www-data 9765042 Dec 16 17:50 access.log
total 9572
-rw-r--r-- 1 ubuntu www-data 9796828 Dec 16 17:50 access.log
total 9656
-rw-r--r-- 1 ubuntu www-data 9881053 Dec 16 17:50 access.log
total 9708
-rw-r--r-- 1 ubuntu www-data 9936776 Dec 16 17:50 access.log
total 9756
-rw-r--r-- 1 ubuntu www-data 9984782 Dec 16 17:50 access.log
total 9816

But as soon as it gets rotated, I immediately get 8 log files:

-rw-r--r-- 1 ubuntu www-data 9999911 Dec 16 17:50 access.log.7
-rw-r--r-- 1 ubuntu www-data    2578 Dec 16 17:50 access.log.5
-rw-r--r-- 1 ubuntu www-data    2578 Dec 16 17:50 access.log.3
-rw-r--r-- 1 ubuntu www-data    6871 Dec 16 17:50 access.log.2
-rw-r--r-- 1 ubuntu www-data    5122 Dec 16 17:50 access.log.1
-rw-r--r-- 1 ubuntu www-data   11165 Dec 16 17:50 access.log.4
-rw-r--r-- 1 ubuntu www-data    1718 Dec 16 17:50 access.log
-rw-r--r-- 1 ubuntu www-data    2905 Dec 16 17:50 access.log.6
total 9864
-rw-r--r-- 1 ubuntu www-data 9999911 Dec 16 17:50 access.log.7
-rw-r--r-- 1 ubuntu www-data    8921 Dec 16 17:50 access.log.6
-rw-r--r-- 1 ubuntu www-data   15460 Dec 16 17:50 access.log
-rw-r--r-- 1 ubuntu www-data   10313 Dec 16 17:51 access.log.2
-rw-r--r-- 1 ubuntu www-data    7699 Dec 16 17:51 access.log.3
-rw-r--r-- 1 ubuntu www-data   21471 Dec 16 17:51 access.log.4
-rw-r--r-- 1 ubuntu www-data    6874 Dec 16 17:51 access.log.5
-rw-r--r-- 1 ubuntu www-data   11989 Dec 16 17:51 access.log.1
total 9892
-rw-r--r-- 1 ubuntu www-data 9999911 Dec 16 17:50 access.log.7
-rw-r--r-- 1 ubuntu www-data    7699 Dec 16 17:51 access.log.3
-rw-r--r-- 1 ubuntu www-data   12849 Dec 16 17:51 access.log.1
-rw-r--r-- 1 ubuntu www-data   14936 Dec 16 17:51 access.log.6
-rw-r--r-- 1 ubuntu www-data   30068 Dec 16 17:51 access.log.4
-rw-r--r-- 1 ubuntu www-data   19755 Dec 16 17:51 access.log
-rw-r--r-- 1 ubuntu www-data   11170 Dec 16 17:51 access.log.5
-rw-r--r-- 1 ubuntu www-data   15466 Dec 16 17:51 access.log.2
total 9932

Is this a consequence of the gunicorn --workers=8?

Does logging.handlers.RotatingFileHandler not work with gunicorn workers?

I tried --worker-class=gevent as well with the same result.

----------
components: Extension Modules
messages: 283511
nosy: Bruce Edge
priority: normal
severity: normal
status: open
title: logging.handlers.RotatingFileHandler rotation broken under gunicorn
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29001>
_______________________________________

From report at bugs.python.org  Sat Dec 17 15:12:18 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 17 Dec 2016 20:12:18 +0000
Subject: [issue28971] nntplib is broken when responses are longer than _MAXLINE
In-Reply-To: <1481716454.12.0.730668429479.issue28971@psf.upfronthosting.co.za>
Message-ID: <1482005538.46.0.96702765141.issue28971@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

On 32-bit platform the size of empty bytes object is 17 bytes not counting padding and GC links. Plus 4 bytes for a pointer in a list. On 64 bit platform numbers are about twice larger. Therefore add at least 20-40 bytes per line.

Is not 100 MiB too large for a list in memory? For files we could use larger limit, but the problem is that file can be io.BytesIO().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28971>
_______________________________________

From report at bugs.python.org  Sat Dec 17 15:14:05 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 17 Dec 2016 20:14:05 +0000
Subject: [issue9770] curses.ascii.isblank() function is broken. It confuses
 backspace (BS 0x08) with tab (0x09)
In-Reply-To: <1283558509.74.0.494754089018.issue9770@psf.upfronthosting.co.za>
Message-ID: <1482005645.76.0.150425916107.issue9770@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9770>
_______________________________________

From report at bugs.python.org  Sat Dec 17 15:16:48 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 17 Dec 2016 20:16:48 +0000
Subject: [issue29000] Not matched behavior within printf style bytes formatting
In-Reply-To: <1481982064.72.0.399504561165.issue29000@psf.upfronthosting.co.za>
Message-ID: <20161217201645.31922.71238.2EB1645D@psf.io>


Roundup Robot added the comment:

New changeset 96d728c14267 by Serhiy Storchaka in branch '3.5':
Issue #29000: Fixed bytes formatting of octals with zero padding in alternate
https://hg.python.org/cpython/rev/96d728c14267

New changeset 29c9c414c310 by Serhiy Storchaka in branch '3.6':
Issue #29000: Fixed bytes formatting of octals with zero padding in alternate
https://hg.python.org/cpython/rev/29c9c414c310

New changeset 4e55e011dd80 by Serhiy Storchaka in branch 'default':
Issue #29000: Fixed bytes formatting of octals with zero padding in alternate
https://hg.python.org/cpython/rev/4e55e011dd80

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29000>
_______________________________________

From report at bugs.python.org  Sat Dec 17 15:18:12 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 17 Dec 2016 20:18:12 +0000
Subject: [issue29000] Not matched behavior within printf style bytes formatting
In-Reply-To: <1481982064.72.0.399504561165.issue29000@psf.upfronthosting.co.za>
Message-ID: <1482005892.52.0.365645735998.issue29000@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thanks David.

----------
assignee: docs at python -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29000>
_______________________________________

From report at bugs.python.org  Sat Dec 17 15:19:37 2016
From: report at bugs.python.org (Jan Niklas Hasse)
Date: Sat, 17 Dec 2016 20:19:37 +0000
Subject: [issue28180] sys.getfilesystemencoding() should default to utf-8
In-Reply-To: <1474024622.65.0.838685461995.issue28180@psf.upfronthosting.co.za>
Message-ID: <1482005977.16.0.535554607716.issue28180@psf.upfronthosting.co.za>


Jan Niklas Hasse added the comment:

> Usually, when a new option is added to Python, we add a command line option (-X utf8) but also an environment variable: I propose PYTHONUTF8=1.
>
> Use your favorite method to define the env var "system wide" in your docker containers.

This doesn't help me, as I already set LANG to C.utf-8.

I'm rather thing about new people trying out Python in Docker who don't know about this.

Furthermore I think that UTF-8 is the future and the use of ASCII should be discouraged.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28180>
_______________________________________

From report at bugs.python.org  Sat Dec 17 15:40:32 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 17 Dec 2016 20:40:32 +0000
Subject: [issue27574] Faster parsing keyword arguments
In-Reply-To: <1468944235.85.0.107735525995.issue27574@psf.upfronthosting.co.za>
Message-ID: <1482007232.56.0.754776399083.issue27574@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Just for the history, there are two alternative patches. They unpack keyword arguments to linear array. I expected this approach can add more optimization, but actually the benefit is too small or negative.

----------
Added file: http://bugs.python.org/file45946/faster_keyword_args_parse_alt.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27574>
_______________________________________

From report at bugs.python.org  Sat Dec 17 15:41:04 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 17 Dec 2016 20:41:04 +0000
Subject: [issue27574] Faster parsing keyword arguments
In-Reply-To: <1468944235.85.0.107735525995.issue27574@psf.upfronthosting.co.za>
Message-ID: <1482007264.51.0.481894175976.issue27574@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
Added file: http://bugs.python.org/file45947/faster_keyword_args_parse_alt2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27574>
_______________________________________

From report at bugs.python.org  Sat Dec 17 15:51:14 2016
From: report at bugs.python.org (Steve Dower)
Date: Sat, 17 Dec 2016 20:51:14 +0000
Subject: [issue28747] Expose SSL_CTX_set_cert_verify_callback
In-Reply-To: <1479591372.9.0.198427018061.issue28747@psf.upfronthosting.co.za>
Message-ID: <1482007874.55.0.280041050367.issue28747@psf.upfronthosting.co.za>


Steve Dower added the comment:

The current _3.patch builds on default without warning and the tests pass (_2.patch is the one Ned tried).

Any objections to committing this into 3.7?

What about 3.6.1? As an additive and easy to detect API, I think it's suitable, and I will certainly use it (right now my library's setup.py depends on having each libeay.lib from each original CPython build handy to get some of the functions out of it - these files are about 50MB each, so it's a little painful).

If it helps, I'm happy to add a warning to the docs that setting the callback may cause a loss of security if the callback does not properly validate the certificate (or some wording to that effect). Personally I think that's fairly well implied though, as there isn't any other obvious use for the callback.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28747>
_______________________________________

From report at bugs.python.org  Sat Dec 17 16:32:27 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 17 Dec 2016 21:32:27 +0000
Subject: [issue25778] winreg.EnumValue does not truncate strings correctly
In-Reply-To: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za>
Message-ID: <20161217213222.23377.47062.693E17D7@psf.io>


Roundup Robot added the comment:

New changeset 8cee4862fb34 by Steve Dower in branch '3.6':
Issue #25778: winreg does not truncase string correctly (Patch by Eryk Sun)
https://hg.python.org/cpython/rev/8cee4862fb34

New changeset 3014854e68e4 by Steve Dower in branch 'default':
Issue #25778: winreg does not truncase string correctly (Patch by Eryk Sun)
https://hg.python.org/cpython/rev/3014854e68e4

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25778>
_______________________________________

From report at bugs.python.org  Sat Dec 17 16:33:16 2016
From: report at bugs.python.org (Ned Deily)
Date: Sat, 17 Dec 2016 21:33:16 +0000
Subject: [issue28747] Expose SSL_CTX_set_cert_verify_callback
In-Reply-To: <1479591372.9.0.198427018061.issue28747@psf.upfronthosting.co.za>
Message-ID: <1482010396.65.0.0448297583415.issue28747@psf.upfronthosting.co.za>


Ned Deily added the comment:

>From a release manager perspective, I'm OK in principle with adding it to 3.6.1 as long as the ssl experts are OK with it.

----------
nosy: +alex, dstufft, janssen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28747>
_______________________________________

From report at bugs.python.org  Sat Dec 17 16:39:03 2016
From: report at bugs.python.org (Steve Dower)
Date: Sat, 17 Dec 2016 21:39:03 +0000
Subject: [issue25778] winreg.EnumValue does not truncate strings correctly
In-Reply-To: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za>
Message-ID: <1482010743.78.0.10705488581.issue25778@psf.upfronthosting.co.za>


Steve Dower added the comment:

I've committed to 3.6.1 and 3.7, but I'm not convinced that the problem is worth the risk of changing the behaviour in 2.7.14 and 3.5.3.

Considering we kept forgetting to commit this for so long and largely got away with it, I assume there aren't hundreds of people being bitten by this on a daily basis. There are also other ways to work around the problems that have occurred (editing and resaving the values in Registry Editor should suffice, and the attached nullcheck scripts can help find the problematic values).

So while 2.7 and 3.5 will continue to not trim REG_SZ values at the first embedded null, I think that's best for preserving the ability of users to upgrade easily between microversions (particularly for 2.7).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25778>
_______________________________________

From report at bugs.python.org  Sat Dec 17 16:59:47 2016
From: report at bugs.python.org (Dillon Brock)
Date: Sat, 17 Dec 2016 21:59:47 +0000
Subject: [issue28407] Improve coverage of email.utils.make_msgid()
In-Reply-To: <1476119160.34.0.206786092221.issue28407@psf.upfronthosting.co.za>
Message-ID: <1482011987.86.0.3311830518.issue28407@psf.upfronthosting.co.za>


Dillon Brock added the comment:

Ping.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28407>
_______________________________________

From report at bugs.python.org  Sat Dec 17 17:01:01 2016
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sat, 17 Dec 2016 22:01:01 +0000
Subject: [issue28936] test_global_err_then_warn in test_syntax is no longer
 valid
In-Reply-To: <1481459590.71.0.768888502862.issue28936@psf.upfronthosting.co.za>
Message-ID: <1482012061.97.0.396933425815.issue28936@psf.upfronthosting.co.za>


Ivan Levkivskyi added the comment:

I don't think this is a bug, but detecting first a SyntaxError that appears textually first might be seen as an improvement. I would say such behaviour seems more intuitive. A possible downside could be a (probably very minor) slow-down of compilation.

I don't have any strong opinion here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28936>
_______________________________________

From report at bugs.python.org  Sat Dec 17 18:32:40 2016
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Sat, 17 Dec 2016 23:32:40 +0000
Subject: [issue28936] test_global_err_then_warn in test_syntax is no longer
 valid
In-Reply-To: <1481459590.71.0.768888502862.issue28936@psf.upfronthosting.co.za>
Message-ID: <1482017560.21.0.0413324641571.issue28936@psf.upfronthosting.co.za>


Ivan Levkivskyi added the comment:

Updated patch as proposed by Serhiy.

----------
Added file: http://bugs.python.org/file45948/syntax-error-order-v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28936>
_______________________________________

From report at bugs.python.org  Sat Dec 17 18:53:44 2016
From: report at bugs.python.org (Alex Jurkiewicz)
Date: Sat, 17 Dec 2016 23:53:44 +0000
Subject: [issue29002] typing.AnyStr doc is unclear about python2 unicode
 support
Message-ID: <1482018824.86.0.562219638154.issue29002@psf.upfronthosting.co.za>


New submission from Alex Jurkiewicz:

The typing.AnyStr documentation:

https://docs.python.org/3/library/typing.html#typing.AnyStr

It gives some examples using u-strings (u'foo') but doesn't make explicit some subtleties about behaviour with Python 2. Specifically, with Python 2 all the given examples work, and even this works:

concat("foo", u"bar")

Which seems contrary to the goal of AnyStr being "used for functions that may accept any kind of string without allowing different kinds of strings to mix".

I think the documentation should call out that for Python 2, AnyStr doesn't distinguish between str & unicode, and mention that in python 2, b'str' is equivalent to 'str' (I know this is mentioned elsewhere, but it seems useful to repeat it here).

----------
assignee: docs at python
components: Documentation
messages: 283524
nosy: aj, docs at python
priority: normal
severity: normal
status: open
title: typing.AnyStr doc is unclear about python2 unicode support
type: enhancement
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29002>
_______________________________________

From report at bugs.python.org  Sat Dec 17 20:06:28 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 18 Dec 2016 01:06:28 +0000
Subject: [issue27973] urllib.urlretrieve() fails on second ftp transfer
In-Reply-To: <1473174596.52.0.952829730129.issue27973@psf.upfronthosting.co.za>
Message-ID: <1482023188.51.0.734258593615.issue27973@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Just an update. We missed the last 2.7.13 release train. Sorry for that. 
It's worth to fix this bug still ASAP. It's intricately related to some other bugs like (issue25458, issue26960). I got to this and realized the dependency and other bugs. All those will be cleaned up and fixed together.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27973>
_______________________________________

From report at bugs.python.org  Sat Dec 17 20:11:02 2016
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Sun, 18 Dec 2016 01:11:02 +0000
Subject: [issue29002] typing.AnyStr doc is unclear about python2 unicode
 support
In-Reply-To: <1482018824.86.0.562219638154.issue29002@psf.upfronthosting.co.za>
Message-ID: <1482023462.98.0.329820773574.issue29002@psf.upfronthosting.co.za>


Jim Fasarakis-Hilliard added the comment:

The ``typing`` module doesn't exist in Python 2.7. 

All code samples provided in the docs *work* since no type-checking is performed by Python. That is, no enforcing of the types provided is made, that's for 3rd party packages to supply.

----------
nosy: +Jim Fasarakis-Hilliard

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29002>
_______________________________________

From report at bugs.python.org  Sat Dec 17 20:33:52 2016
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Sun, 18 Dec 2016 01:33:52 +0000
Subject: [issue29002] typing.AnyStr doc is unclear about python2 unicode
 support
In-Reply-To: <1482018824.86.0.562219638154.issue29002@psf.upfronthosting.co.za>
Message-ID: <1482024832.3.0.0920687006221.issue29002@psf.upfronthosting.co.za>


Jim Fasarakis-Hilliard added the comment:

Unless of course you mean pip installing typing for Py2 and then using ``# type``  comments to provide the types. 

Even in that case, I don't really think the documentation for Python 3.5 should be mentioning types in 2.7, that'd get confusing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29002>
_______________________________________

From report at bugs.python.org  Sat Dec 17 21:45:10 2016
From: report at bugs.python.org (Ma Lin)
Date: Sun, 18 Dec 2016 02:45:10 +0000
Subject: [issue10740] sqlite3 module breaks transactions and potentially
 corrupts data
In-Reply-To: <1292868135.81.0.257293444934.issue10740@psf.upfronthosting.co.za>
Message-ID: <1482029110.2.0.732508112091.issue10740@psf.upfronthosting.co.za>


Ma Lin added the comment:

I'm using Python 3.6.0 RC2, I don't know if it's a bug.

When I try to run VACUUM command, an exception raised:

conn.execute('begin')  # <- remove this line get the same result
conn.execute('VACUUM')

sqlite3.OperationalError: cannot VACUUM from within a transaction

~~~~~~~~~~~~~~~~~~~
On Python 3.5, everything is fine.
Attached file cant_vacuum.py is the full example code.

----------
nosy: +Ma Lin
Added file: http://bugs.python.org/file45949/cant_vacuum.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10740>
_______________________________________

From report at bugs.python.org  Sat Dec 17 22:00:14 2016
From: report at bugs.python.org (R. David Murray)
Date: Sun, 18 Dec 2016 03:00:14 +0000
Subject: [issue10740] sqlite3 module breaks transactions and potentially
 corrupts data
In-Reply-To: <1292868135.81.0.257293444934.issue10740@psf.upfronthosting.co.za>
Message-ID: <1482030014.53.0.337994717033.issue10740@psf.upfronthosting.co.za>


R. David Murray added the comment:

It is an unexpected change in behavior and is therefore probably a bug.  It will work if you set isolation_level=None.  Because of that I don't think it is a release critical bug, though one could wish we'd discovered it earlier.  Please open a new issue for this.

----------
assignee: ghaering -> 
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10740>
_______________________________________

From report at bugs.python.org  Sat Dec 17 22:05:52 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 18 Dec 2016 03:05:52 +0000
Subject: [issue28407] Improve coverage of email.utils.make_msgid()
In-Reply-To: <1476119160.34.0.206786092221.issue28407@psf.upfronthosting.co.za>
Message-ID: <20161218030549.23357.48444.428BF41E@psf.io>


Roundup Robot added the comment:

New changeset 8687b3554b1f by R David Murray in branch '3.5':
#28407 Improve test coverage of make_msgid.
https://hg.python.org/cpython/rev/8687b3554b1f

New changeset 87671b1f7ff4 by R David Murray in branch '3.6':
Merge #28407 Improve test coverage of make_msgid.
https://hg.python.org/cpython/rev/87671b1f7ff4

New changeset c016ab381894 by R David Murray in branch 'default':
Merge #28407 Improve test coverage of make_msgid.
https://hg.python.org/cpython/rev/c016ab381894

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28407>
_______________________________________

From report at bugs.python.org  Sat Dec 17 22:06:21 2016
From: report at bugs.python.org (R. David Murray)
Date: Sun, 18 Dec 2016 03:06:21 +0000
Subject: [issue28407] Improve coverage of email.utils.make_msgid()
In-Reply-To: <1476119160.34.0.206786092221.issue28407@psf.upfronthosting.co.za>
Message-ID: <1482030381.88.0.584095693257.issue28407@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks Dillon.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28407>
_______________________________________

From report at bugs.python.org  Sat Dec 17 22:19:32 2016
From: report at bugs.python.org (Ma Lin)
Date: Sun, 18 Dec 2016 03:19:32 +0000
Subject: [issue29003] sqlite3: can't run VACUUM on Python 3.6
Message-ID: <1482031172.61.0.238447305866.issue29003@psf.upfronthosting.co.za>


New submission from Ma Lin:

I'm using Python 3.6.0 RC2.
When I try to run VACUUM command, an exception raised:

conn.execute('begin')  # <- remove this line get the same result
conn.execute('VACUUM')

sqlite3.OperationalError: cannot VACUUM from within a transaction

On Python 3.5, everything is fine.
Attached file cant_vacuum.py is the full example code.

----------
related issue: #10740 sqlite3 module breaks transactions and potentially corrupts data

R. David Murray said in #10740 about this issue:
It is an unexpected change in behavior and is therefore probably a bug.  It will work if you set isolation_level=None.  Because of that I don't think it is a release critical bug, though one could wish we'd discovered it earlier.

----------
components: Library (Lib)
files: cannot_vacuum.py
messages: 283532
nosy: Ma Lin
priority: normal
severity: normal
status: open
title: sqlite3: can't run VACUUM on Python 3.6
type: behavior
versions: Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45950/cannot_vacuum.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29003>
_______________________________________

From report at bugs.python.org  Sat Dec 17 22:20:56 2016
From: report at bugs.python.org (Ma Lin)
Date: Sun, 18 Dec 2016 03:20:56 +0000
Subject: [issue10740] sqlite3 module breaks transactions and potentially
 corrupts data
In-Reply-To: <1292868135.81.0.257293444934.issue10740@psf.upfronthosting.co.za>
Message-ID: <1482031256.0.0.384347171158.issue10740@psf.upfronthosting.co.za>


Ma Lin added the comment:

#29003 created

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10740>
_______________________________________

From report at bugs.python.org  Sat Dec 17 22:31:32 2016
From: report at bugs.python.org (R. David Murray)
Date: Sun, 18 Dec 2016 03:31:32 +0000
Subject: [issue27584] New addition of vSockets to the python socket module
In-Reply-To: <1469115390.74.0.838831983223.issue27584@psf.upfronthosting.co.za>
Message-ID: <1482031892.32.0.992980138635.issue27584@psf.upfronthosting.co.za>


R. David Murray added the comment:

The second patch seems to be missing the configure changes.  Also, the tests have some over-long lines (we limit line lengths to 79 characters).  I realize there are other long lines in that file, but no need to add more :)

There is trailing whitespace on a number of lines in your patch.

Since this is new, we may not want to accept it until the support hits upstream.  Specifically, it will be difficult to get a review if the reviewer has to build a custom kernel to test the code :)  You do say that the VMCI is upstream, but I don't know what that means.  Which upstream?

Note: I'm not familiar with the socket C code, so I haven't reviewed the C code changes.  The tests look fine to me.

For the docs, the proposal doesn't seem to follow the format of the existing docs.  I would expect only the first paragraph located where you have it.  The remaining constants should be in the 'module contents'/'constants' section, I think.  Yes, that means each one gets a '.. versionadded' label.  Presumably also an 'availablility' label with whatever the minimum kernel version is...another reason we may need to wait.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27584>
_______________________________________

From report at bugs.python.org  Sat Dec 17 22:37:44 2016
From: report at bugs.python.org (R. David Murray)
Date: Sun, 18 Dec 2016 03:37:44 +0000
Subject: [issue27584] New addition of vSockets to the python socket module
In-Reply-To: <1469115390.74.0.838831983223.issue27584@psf.upfronthosting.co.za>
Message-ID: <1482032264.22.0.632708062.issue27584@psf.upfronthosting.co.za>


R. David Murray added the comment:

Oh, I see, the ac changes are there, I was looking at the patch delta instead of the complete patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27584>
_______________________________________

From report at bugs.python.org  Sat Dec 17 22:39:55 2016
From: report at bugs.python.org (Ned Deily)
Date: Sun, 18 Dec 2016 03:39:55 +0000
Subject: [issue29003] sqlite3: can't run VACUUM on Python 3.6
In-Reply-To: <1482031172.61.0.238447305866.issue29003@psf.upfronthosting.co.za>
Message-ID: <1482032395.88.0.745966807152.issue29003@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
keywords: +3.6regression
nosy: +berker.peksag, ghaering

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29003>
_______________________________________

From report at bugs.python.org  Sat Dec 17 22:50:02 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 18 Dec 2016 03:50:02 +0000
Subject: [issue28971] nntplib is broken when responses are longer than _MAXLINE
In-Reply-To: <1481716454.12.0.730668429479.issue28971@psf.upfronthosting.co.za>
Message-ID: <1482033002.95.0.0256987579553.issue28971@psf.upfronthosting.co.za>


Martin Panter added the comment:

The first offending message I found is number 183465:

>>> s.group("comp.lang.python")
('211 4329 179178 183507 comp.lang.python', 4329, 179178, 183507, 'comp.lang.python')
>>> s._putcmd("OVER 183465")
>>> s._getresp()
'224 Overview information for 183465 follows'
>>> line = s.file.readline()
>>> len(line)
2702
>>> [number, subject, from_header, date, message_id, references, bytes, lines, extra] = line.split(b"\t", 8)
>>> message_id
b'<mailman.122.1481898601.2322.python-list at python.org>'
>>> len(references)
2483
>>> len(references.split())
36

Assuming the References value is the only large field in an OVER response line, I would guess that a reasonable limit per line might be

200 bytes/message-id * 200 messages/thread = 40,000 bytes per OVER line

I agree with closing the session whenever the client?s protocol state is broken, but only for a different, tangential reason. See Issue 22350. Even if you raised an explicit exception when using a closed session, like in nntplib_maxbytes.patch, won?t that still cause the subsequent tests to fail? I think the best solution is to stop sharing one connection across multiple tests: Issue 19756.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28971>
_______________________________________

From report at bugs.python.org  Sun Dec 18 00:17:12 2016
From: report at bugs.python.org (Miki Tebeka)
Date: Sun, 18 Dec 2016 05:17:12 +0000
Subject: [issue28972] Document all "python -m" utilities
In-Reply-To: <1481720403.32.0.43245427479.issue28972@psf.upfronthosting.co.za>
Message-ID: <1482038232.81.0.348857817685.issue28972@psf.upfronthosting.co.za>


Miki Tebeka added the comment:

Thanks Guido, however I think my blog is not the right place - it's dog ugly and read by about 7 people on a good day :) 

I think that adding this to the official docs will add to the "batteries included" motto. I'll try to find a time and come up with a patch to the docs, however if this goes through we should place a note somewhere in the development docs about updating this section as well if someone adds a __main__.py or main function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28972>
_______________________________________

From report at bugs.python.org  Sun Dec 18 00:38:06 2016
From: report at bugs.python.org (Evan)
Date: Sun, 18 Dec 2016 05:38:06 +0000
Subject: [issue22343] Install bash activate script on Windows when using venv
In-Reply-To: <1409948648.7.0.892236136888.issue22343@psf.upfronthosting.co.za>
Message-ID: <1482039486.95.0.859151948226.issue22343@psf.upfronthosting.co.za>


Evan added the comment:

+1, I'm also using Windows with Git Bash and venv is unusable for me without Brandon's workaround.

----------
nosy: +evan_

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22343>
_______________________________________

From report at bugs.python.org  Sun Dec 18 00:43:55 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 18 Dec 2016 05:43:55 +0000
Subject: [issue28987] Remove typo in whats new entry on Descriptor Protocol
 Enhancements
In-Reply-To: <1481899777.6.0.168027118987.issue28987@psf.upfronthosting.co.za>
Message-ID: <20161218054352.11104.85476.A0BC4ECE@psf.io>


Roundup Robot added the comment:

New changeset a46a20a1f286 by Martin Panter in branch '3.6':
Issue #28987: Typos, grammar, spelling in documentation
https://hg.python.org/cpython/rev/a46a20a1f286

New changeset 28cf4ffcfbf3 by Martin Panter in branch 'default':
Issue #28987: Merge doc and comment fixes from 3.6
https://hg.python.org/cpython/rev/28cf4ffcfbf3

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28987>
_______________________________________

From report at bugs.python.org  Sun Dec 18 00:51:29 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 18 Dec 2016 05:51:29 +0000
Subject: [issue28987] Remove typo in whats new entry on Descriptor Protocol
 Enhancements
In-Reply-To: <1481899777.6.0.168027118987.issue28987@psf.upfronthosting.co.za>
Message-ID: <1482040289.45.0.762871041844.issue28987@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks Jim

----------
nosy: +martin.panter
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28987>
_______________________________________

From report at bugs.python.org  Sun Dec 18 01:30:48 2016
From: report at bugs.python.org (Ryan Brindley)
Date: Sun, 18 Dec 2016 06:30:48 +0000
Subject: [issue28982] multiprocessing.Queue.get(block=True,
 timeout=0) always raises queue.Empty
In-Reply-To: <1481834665.78.0.584713250682.issue28982@psf.upfronthosting.co.za>
Message-ID: <1482042648.7.0.995530408484.issue28982@psf.upfronthosting.co.za>


Ryan Brindley added the comment:

I've updated the PR to also include raising a ValueError for timeout values < 0.

This behavior mimics that of queue.Queue (noting here again that queue.Queue handles timeout = 0).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28982>
_______________________________________

From report at bugs.python.org  Sun Dec 18 01:48:13 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 18 Dec 2016 06:48:13 +0000
Subject: [issue28982] multiprocessing.Queue.get(block=True,
 timeout=0) always raises queue.Empty
In-Reply-To: <1481834665.78.0.584713250682.issue28982@psf.upfronthosting.co.za>
Message-ID: <1482043693.8.0.117693606436.issue28982@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28982>
_______________________________________

From report at bugs.python.org  Sun Dec 18 02:07:08 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 18 Dec 2016 07:07:08 +0000
Subject: [issue28927] bytes.fromhex should ignore all whitespace
In-Reply-To: <1481328446.9.0.450435696311.issue28927@psf.upfronthosting.co.za>
Message-ID: <1482044828.37.0.694685584022.issue28927@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Ah, the parallel with base64 decoding and embedding encoded data in multi-line string literals is indeed a compelling one - I'd missed that.

Given that rationale, +1 from me.

Perhaps it would make sense to call that out directly in the documentation? Something like a second example saying:

====
Ignoring all ASCII whitespace provides compatibility with common hexdump formats (like the output of ``xxd``), allowing such data to easily be read from a file or included directly in source code as a multiline string literal::

    >>> bytes.fromhex("""
    ... F0F1F2F3F4
    ... FAFBFCFDFE
    """)
    b'\xf0\xf1\xf2\xf4\xfa\xfb\xfc\xfd'

====

And then a versionchanged note for 3.7 to say that this was switched from filtering out specifically space to filtering out any ASCII whitespace.

My other question would be whether or not a separate issue should be filed to update the bytes-to-bytes "hex" codec to be consistent with this change - at the moment, it doesn't allow whitespace *at all* (not even ASCII spaces), while the base64 decoder is consistent with base64.b64decode and allows it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28927>
_______________________________________

From report at bugs.python.org  Sun Dec 18 02:10:59 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 18 Dec 2016 07:10:59 +0000
Subject: [issue28180] sys.getfilesystemencoding() should default to utf-8
In-Reply-To: <1474024622.65.0.838685461995.issue28180@psf.upfronthosting.co.za>
Message-ID: <1482045059.85.0.0686922052505.issue28180@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


Added file: http://bugs.python.org/file45951/fedora-cpython-PYTHONALLOWCLOCALE.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28180>
_______________________________________

From report at bugs.python.org  Sun Dec 18 02:20:38 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 18 Dec 2016 07:20:38 +0000
Subject: [issue28180] sys.getfilesystemencoding() should default to utf-8
In-Reply-To: <1474024622.65.0.838685461995.issue28180@psf.upfronthosting.co.za>
Message-ID: <1482045638.07.0.579730579987.issue28180@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

For folks not following the Fedora BZ issue directly, I've also attached the latest draft downstream patch here, which gives the following behaviour:

==========================

$ ./python -c "import sys; print(sys.getfilesystemencoding())"
utf-8

$ LANG=C.UTF-8 ./python -c "import sys; print(sys.getfilesystemencoding())"
utf-8

$ LANG=C ./python -c "import sys; print(sys.getfilesystemencoding())"
Python detected LC_CTYPE=C, forcing LC_ALL & LANG to C.UTF-8 (set PYTHONALLOWCLOCALE to disable this behaviour).
utf-8

$ PYTHONALLOWCLOCALE=1 LANG=C ./python -c "import sys; print(sys.getfilesystemencoding())"
Python detected LC_CTYPE=C, but PYTHONALLOWCLOCALE is set. Some libraries, applications, and operating system interfaces may not work correctly.
Py_Initialize detected LC_CTYPE=C, which limits Unicode compatibility. Some libraries and operating system interfaces may not work correctly. Use `PYTHONALLOWCLOCALE=1 LC_CTYPE=C python3` to configure a similar environment when running Python directly.
ascii
==========================

(The double warning in the last example is likely to go away by skipping the CLI level warning in that case)

The Python tests checking for the expected behaviour are signficantly longer than the C level changes needed to implement it :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28180>
_______________________________________

From report at bugs.python.org  Sun Dec 18 02:24:25 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 18 Dec 2016 07:24:25 +0000
Subject: [issue28997] test_readline.test_nonascii fails on Android
In-Reply-To: <1481965369.72.0.409169776064.issue28997@psf.upfronthosting.co.za>
Message-ID: <1482045865.53.0.584513397623.issue28997@psf.upfronthosting.co.za>


Martin Panter added the comment:

This is a breakdown of running the test script on my Linux setup (UTF-8 locale):

^A^B^B^B^B^B^B^B\t\tx\t\r\n
    Input echoed back (before Readline disables echo)
[\xc3\xafnserted]
    Inserted by pre_input_hook()
|t\xc3\xab[after]
    Inserted by the Ctrl+A macro
\x08\x08\x08\x08\x08\x08\x08
    Response to moving the cursor left of [after]
text \'t\\xeb\'\r\n
    Encoded completer(text=...) parameter for testing
line \'[\\xefnserted]|t\\xeb[after]\'\r\n
    get_line_buffer() result for testing
indexes 11 13\r\n
    get_begidx(), get_endidx()
\x07
    Rings terminal bell due to multiple possible completions
text . . . line . . . indexes . . .\r\n
    From second round of completer() calls due to second Tab input
substitution \'t\\xeb\'\r\n
matches [\'t\\xebnt\', \'t\\xebxt\']\r\n
    display() parameters
x[after]\x08\x08\x08\x08\x08\x08\x08
    Response to inserting ?x?
t[after]\x08\x08\x08\x08\x08\x08\x08
    Completion of "t\xEBxt"
\r\n
    Response to inputting Return
result \'[\\xefnserted]|t\\xebxt[after]\'\r\n
    input() function call return value
history \'[\\xefnserted]|t\\xebxt[after]\'\r\n
    Line as retrieved from history

The problem is that the Ctrl+A macro seems to have only inserted the two ASCII characters "|t" and has stopped at the non-ASCII character "\xEB". Everthing else relies on the macro working properly to get the right cursor positioning and completion text.

Xavier: If you run the following code in an interactive Python session, what does pressing $ print out?

import readline
readline.parse_and_bind('Control-a: "|t\xEB[after]"')
readline.parse_and_bind('"$": dump-macros')

For me, it prints this: (includes ?te? with an umlaut)

\C-a outputs |t?[after]

What locale encoding does Python use for you? The parse_and_bind() call should be encoding "\xEB" with PyUnicode_EncodeLocale(), and passing the resulting string to Readline. Then Readline is supposed to insert the string when we invoke the macro. Somewhere the string is getting truncated.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28997>
_______________________________________

From report at bugs.python.org  Sun Dec 18 03:44:32 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 18 Dec 2016 08:44:32 +0000
Subject: [issue28927] bytes.fromhex should ignore all whitespace
In-Reply-To: <1481328446.9.0.450435696311.issue28927@psf.upfronthosting.co.za>
Message-ID: <1482050672.77.0.361734708219.issue28927@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Is it worth to ignore also non-ASCII whitespaces for compatibility with string-to-number convertions and base64 decoder?

>>> float('\xa01.0')
1.0
>>> base64.decodebytes(b'\xa0YWJj')
b'abc'

Note that not all spaces are ignored. They shouldn't break hexadecimal pairs.

>>> bytes.fromhex('a b')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: non-hexadecimal number found in fromhex() arg at position 1

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28927>
_______________________________________

From report at bugs.python.org  Sun Dec 18 03:47:34 2016
From: report at bugs.python.org (Remi Pointel)
Date: Sun, 18 Dec 2016 08:47:34 +0000
Subject: [issue28932] Fail compile Python 3.6.0rc1 on OpenBSD 6.0
In-Reply-To: <1481388547.33.0.916805591486.issue28932@psf.upfronthosting.co.za>
Message-ID: <1482050854.65.0.923730359475.issue28932@psf.upfronthosting.co.za>


Remi Pointel added the comment:

Hello,

I have exactly the same problem with Python 2.7.13 on OpenBSD.

Works fine with the same patch.

Remi.

----------
nosy: +rpointel
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28932>
_______________________________________

From report at bugs.python.org  Sun Dec 18 04:17:53 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 18 Dec 2016 09:17:53 +0000
Subject: [issue28932] Fail compile Python 3.6.0rc1 on OpenBSD 6.0
In-Reply-To: <1481388547.33.0.916805591486.issue28932@psf.upfronthosting.co.za>
Message-ID: <1482052673.36.0.331016289363.issue28932@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +benjamin.peterson, ned.deily
priority: normal -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28932>
_______________________________________

From report at bugs.python.org  Sun Dec 18 04:25:28 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 18 Dec 2016 09:25:28 +0000
Subject: [issue28769] Make PyUnicode_AsUTF8 returning "const char *" rather of
 "char *"
In-Reply-To: <1479801324.65.0.962202188144.issue28769@psf.upfronthosting.co.za>
Message-ID: <1482053128.4.0.992403972486.issue28769@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Opened a topic on Python-Dev: https://mail.python.org/pipermail/python-dev/2016-December/147029.html.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28769>
_______________________________________

From report at bugs.python.org  Sun Dec 18 05:52:31 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 18 Dec 2016 10:52:31 +0000
Subject: [issue29004] binascii.crc_hqx() implements CRC-CCITT
Message-ID: <1482058351.49.0.0302572495626.issue29004@psf.upfronthosting.co.za>


New submission from Martin Panter:

If I had known this it would have saved me getting a separate implementation working.

>>> hex(binascii.crc_hqx(b"\x01", 0))
'0x1021'
https://files.stairways.com/other/binhex-40-specs-info.txt

Documenting this might helped many other people. Top Google hits seem oblivious to crc_hqx(), using other CRC implementations, and even other helper functions from the binascii module:

https://pypi.python.org/pypi/crc16
http://stackoverflow.com/questions/26204060/calculate-crc-ccitt-0xffff-for-hex-string

----------
assignee: docs at python
components: Documentation
files: crc-ccitt.patch
keywords: patch
messages: 283548
nosy: docs at python, martin.panter
priority: normal
severity: normal
stage: patch review
status: open
title: binascii.crc_hqx() implements CRC-CCITT
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45952/crc-ccitt.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29004>
_______________________________________

From report at bugs.python.org  Sun Dec 18 06:03:02 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 18 Dec 2016 11:03:02 +0000
Subject: [issue28927] bytes.fromhex should ignore all whitespace
In-Reply-To: <1481328446.9.0.450435696311.issue28927@psf.upfronthosting.co.za>
Message-ID: <1482058982.74.0.53958747727.issue28927@psf.upfronthosting.co.za>


Martin Panter added the comment:

As far as I know, non-ASCII newlines and whitespace are not supported in Python source code, so there is not a big need to support it in bytes.fromhex() either. But since bytes.fromhex() accepts Unicode strings, I think non-ASCII whitespace would be okay if it was easy to implement.

Serhiy: Whitespace is not treated specially by the base-64 decoders, it is just treated like any non-alphabet character. See <https://docs.python.org/3/library/base64.html#base64.b64decode> and b64decode(validate=True).

Regarding hex-codec, I doubt many people use it in Python 3. To decode a whole string, binascii.unhexlify() or bytes.fromhex() is probably more obvious, and I think the incremental decoder never worked properly (Issue 20132).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28927>
_______________________________________

From report at bugs.python.org  Sun Dec 18 06:13:12 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 18 Dec 2016 11:13:12 +0000
Subject: [issue29004] binascii.crc_hqx() implements CRC-CCITT
In-Reply-To: <1482058351.49.0.0302572495626.issue29004@psf.upfronthosting.co.za>
Message-ID: <1482059592.43.0.445617832898.issue29004@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

If document the polynomial for crc_hqx, maybe document it for crc32 and adler32?

Wouldn't be better to write the formula as *x*\ :sup:`16` + *x*\ :sup:`12 + *x*\ :sup:`5` + 1 ?

----------
nosy: +eric.smith, lemburg, mark.dickinson, serhiy.storchaka, stutzbach

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29004>
_______________________________________

From report at bugs.python.org  Sun Dec 18 06:42:06 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 18 Dec 2016 11:42:06 +0000
Subject: [issue28927] bytes.fromhex should ignore all whitespace
In-Reply-To: <1481328446.9.0.450435696311.issue28927@psf.upfronthosting.co.za>
Message-ID: <1482061326.8.0.804113314672.issue28927@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

No, it is not easy to implement. Currently bytes.fromhex() works only with ASCII strings and can just iterate over char*.

If add support of non-ASCII whitespaces, we should add a support of non-ASCII digits, as in float(). This looks excessive.

In case if there is a case for this, we rather would expose _PyUnicode_TransformDecimalAndSpaceToASCII() in Python level.

In general fromhex.patch LGTM, but please add versionchanged directives and document the change in What's New.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28927>
_______________________________________

From report at bugs.python.org  Sun Dec 18 06:47:52 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 18 Dec 2016 11:47:52 +0000
Subject: [issue29004] binascii.crc_hqx() implements CRC-CCITT
In-Reply-To: <1482058351.49.0.0302572495626.issue29004@psf.upfronthosting.co.za>
Message-ID: <1482061672.93.0.199568145867.issue29004@psf.upfronthosting.co.za>


Martin Panter added the comment:

It seems I can write it without the escaped spaces. Is there a problem with this:

*x*:sup:`16` + *x*:sup:`12` + *x*:sup:`5` + 1

I?m happy to add the CRC-32 polynomial if you think it would be useful, although it is a lot longer (fifteen terms instead of four). And this CRC is already easily identified by the CRC-32 name. As well as the polynomial, there are other details that identify a CRC. The bits in CRC-32 are reversed and inverted compared to CRC-CCITT.

>>> hex(crc32(b"\x80", 0xFFFFFFFF) ^ 0xFFFFFFFF)
'0xedb88320'
# 0xEDB88320 is the reversed polynomial representation; the x^0 term corresponds to bit 31

Adler32 is not a CRC, and I don?t think there are multiple versions of the algorithm, so I don?t think it would need any special explanation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29004>
_______________________________________

From report at bugs.python.org  Sun Dec 18 06:53:11 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 18 Dec 2016 11:53:11 +0000
Subject: [issue29004] binascii.crc_hqx() implements CRC-CCITT
In-Reply-To: <1482058351.49.0.0302572495626.issue29004@psf.upfronthosting.co.za>
Message-ID: <1482061991.98.0.655491883555.issue29004@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Okay, then the patch LGTM. Use the form of the polynomial that you prefer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29004>
_______________________________________

From report at bugs.python.org  Sun Dec 18 08:02:51 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 18 Dec 2016 13:02:51 +0000
Subject: [issue23507] Tuple creation is too slow
In-Reply-To: <1424765312.55.0.269687406134.issue23507@psf.upfronthosting.co.za>
Message-ID: <1482066171.24.0.811292324856.issue23507@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is rebased patch (just for history). Caching argtuple is not faster (or even slower) than using fast call.

Regression in stack consumption is fixed in issue28858.

Thanks Victor!

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
Added file: http://bugs.python.org/file45953/reuse_argtuples_4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23507>
_______________________________________

From report at bugs.python.org  Sun Dec 18 10:27:49 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 18 Dec 2016 15:27:49 +0000
Subject: [issue28997] test_readline.test_nonascii fails on Android
In-Reply-To: <1481965369.72.0.409169776064.issue28997@psf.upfronthosting.co.za>
Message-ID: <1482074869.82.0.8567288979.issue28997@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

> For me, it prints this: (includes ?te? with an umlaut)
I got this same result when testing on Android with the interactive interpreter.

See the content of the 'completer' list below, when run with tracing_the_completer.patch:
On linux:
test_nonascii (test.test_readline.TestReadline) ... bytearray(b"^A^B^B^B^B^B^B^B\t\tx\t\r\n[\xc3\xafnserted]|t\xc3\xab[after]\x08\x08\x08\x08\x08\x08\x08text \'t\\xeb\'\r\nline \'[\\xefnserted]|t\\xeb[after]\'\r\nindexes 11 13\r\ntext \'t\\xeb\'\r\nline \'[\\xefnserted]|t\\xeb[after]\'\r\nindexes 1113\r\nsubstitution \'t\\xeb\'\r\nmatches [\'t\\xebnt\', \'t\\xebxt\']\r\nx[after]\x08\x08\x08\x08\x08\x08\x08t[after]\x08\x08\x08\x08\x08\x08\x08\r\nresult \'[\\xefnserted]|t\\xebxt[after]\'\r\nhistory \'[\\xefnserted]|t\\xebxt[after]\'\r\ncompleter [\'t\xc3\xab-0\', \'GOT 1\', \'t\xc3\xab-1\', \'GOT 2\', \'t\xc3\xab-2\', \'t\xc3\xab-0\', \'GOT 1\', \'t\xc3\xab-1\', \'GOT 2\', \'t\xc3\xab-2\', \'t\xc3\xabx-0\', \'GOT 3\', \'t\xc3\xabx-1\']\r\n")

On Android:
AssertionError: b"text 't\\xeb'\r\n" not found in bytearray(b"^A^B^B^B^B^B^B^B\t\tx\t\r\n[\\303\\257nserted]|t\x07\x08\x08\x08\x08\x08\x08\x08\x07\x07xrted]|t\x08\x08\x08\x08\x08\x08\x08\x07\r\nresult \'[\\xefnsexrted]|t\'\r\nhistory \'[\\xefnsexrted]|t\'\r\ncompleter [\'\xc3\xafnse-0\', \'\xc3\xafnse-0\', \'\xc3\xafnsex-0\']\r\n")

b'\xc3\xab' is the UTF-8 code for '\xEB'
b'\xc3\xaf' is the UTF-8 code for '\xEF'
It seems that the completer is triggered by the wrong key.

----------
keywords: +patch
Added file: http://bugs.python.org/file45954/tracing_the_completer.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28997>
_______________________________________

From report at bugs.python.org  Sun Dec 18 10:50:13 2016
From: report at bugs.python.org (woo yoo)
Date: Sun, 18 Dec 2016 15:50:13 +0000
Subject: [issue29005] Possibly incorrect description about method objects
Message-ID: <1482076212.99.0.372888946767.issue29005@psf.upfronthosting.co.za>


New submission from woo yoo:

"In general, calling a method with a list of n arguments is equivalent to calling the corresponding function with an argument list that is created by inserting the method?s object before the first argument."

Is  above description right?
The link is https://docs.python.org/3.5/tutorial/classes.html#method-objects

----------
assignee: docs at python
components: Documentation
messages: 283556
nosy: docs at python, woo yoo
priority: normal
severity: normal
status: open
title: Possibly incorrect description about method objects
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29005>
_______________________________________

From report at bugs.python.org  Sun Dec 18 11:10:56 2016
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Sun, 18 Dec 2016 16:10:56 +0000
Subject: [issue29005] Possibly incorrect description about method objects
In-Reply-To: <1482076212.99.0.372888946767.issue29005@psf.upfronthosting.co.za>
Message-ID: <1482077456.79.0.331744070263.issue29005@psf.upfronthosting.co.za>


Jim Fasarakis-Hilliard added the comment:

Seems right to me, this is also stated clearly in the reference manual:

> When an instance method object is called, the underlying function (__func__) is called, inserting the class instance (__self__) in front of the argument list. For instance, when C is a class which contains a definition for a function f(), and x is an instance of C, calling x.f(1) is equivalent to calling C.f(x, 1).

What doesn't look right to you?

----------
nosy: +Jim Fasarakis-Hilliard

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29005>
_______________________________________

From report at bugs.python.org  Sun Dec 18 11:15:28 2016
From: report at bugs.python.org (woo yoo)
Date: Sun, 18 Dec 2016 16:15:28 +0000
Subject: [issue29005] Possibly incorrect description about method objects
In-Reply-To: <1482076212.99.0.372888946767.issue29005@psf.upfronthosting.co.za>
Message-ID: <1482077728.58.0.301063103024.issue29005@psf.upfronthosting.co.za>


woo yoo added the comment:

Maybe the last "method's" should be changed into "class instance"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29005>
_______________________________________

From report at bugs.python.org  Sun Dec 18 11:22:52 2016
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Sun, 18 Dec 2016 16:22:52 +0000
Subject: [issue29005] Possibly incorrect description about method objects
In-Reply-To: <1482076212.99.0.372888946767.issue29005@psf.upfronthosting.co.za>
Message-ID: <1482078172.44.0.703310412691.issue29005@psf.upfronthosting.co.za>


Jim Fasarakis-Hilliard added the comment:

I see. I'd agree that `instance object` is probably better here. Let's see what others think.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29005>
_______________________________________

From report at bugs.python.org  Sun Dec 18 11:25:55 2016
From: report at bugs.python.org (R. David Murray)
Date: Sun, 18 Dec 2016 16:25:55 +0000
Subject: [issue29005] Possibly incorrect description about method objects
In-Reply-To: <1482076212.99.0.372888946767.issue29005@psf.upfronthosting.co.za>
Message-ID: <1482078355.67.0.120394147896.issue29005@psf.upfronthosting.co.za>


R. David Murray added the comment:

Given the (clearer) explanation in the final paragraph of that section, I think the bare 'object' in the first couple paragraphs should be replaced by 'instance object'.  There are multiple objects involved, and that will disambiguate which one is being referred to for insertion as the first argument, and make the language of the section self-consistent.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29005>
_______________________________________

From report at bugs.python.org  Sun Dec 18 11:37:47 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 18 Dec 2016 16:37:47 +0000
Subject: [issue28885] Python 3.5.2 strange-behavior issues (from PyPy)
In-Reply-To: <1481025768.53.0.205646799997.issue28885@psf.upfronthosting.co.za>
Message-ID: <1482079067.78.0.445441678786.issue28885@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

(S3) is a side effect of implementing __eq__ in dict_keys and dict_items. Since __eq__ is not implemented in dict_values, __hash__ is inherited from object.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28885>
_______________________________________

From report at bugs.python.org  Sun Dec 18 12:10:12 2016
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Sun, 18 Dec 2016 17:10:12 +0000
Subject: [issue29005] Possibly incorrect description about method objects
In-Reply-To: <1482076212.99.0.372888946767.issue29005@psf.upfronthosting.co.za>
Message-ID: <1482081012.12.0.736980523559.issue29005@psf.upfronthosting.co.za>


Jim Fasarakis-Hilliard added the comment:

I've added a little patch that takes care of this. I didn't add "method's instance object" in the second substitution because it seems evident by the previous sentences.

----------
keywords: +patch
Added file: http://bugs.python.org/file45955/method_obj35.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29005>
_______________________________________

From report at bugs.python.org  Sun Dec 18 12:38:29 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 18 Dec 2016 17:38:29 +0000
Subject: [issue28997] test_readline.test_nonascii fails on Android
In-Reply-To: <1481965369.72.0.409169776064.issue28997@psf.upfronthosting.co.za>
Message-ID: <1482082709.26.0.32443046384.issue28997@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

FWIW on Android we have:

>>> readline.__doc__ and "libedit" in readline.__doc__
False
>>> getattr(readline, "set_pre_input_hook", None)
<built-in function set_pre_input_hook>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28997>
_______________________________________

From report at bugs.python.org  Sun Dec 18 12:54:43 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 18 Dec 2016 17:54:43 +0000
Subject: [issue28997] test_readline.test_nonascii fails on Android
In-Reply-To: <1481965369.72.0.409169776064.issue28997@psf.upfronthosting.co.za>
Message-ID: <1482083683.83.0.952255215821.issue28997@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Checking that the the problem is indeed an encoding problem on Android with readline.set_pre_input_hook(): with tracing_the_completer_2.patch that replaces '\xEB' with 'A', the test now succeeds and prints:

test_nonascii (test.test_readline.TestReadline) ... bytearray(b"^A^B^B^B^B^B^B^B\t\tx\t\r\n[\\303\\257nserted]|tA[after]\x08\x08\x08\x08\x08\x08\x08text \'tA\'\r\nline \'[\\xefnserted]|tA[after]\'\r\nindexes 11 13\r\n\x07text \'tA\'\r\nline \'[\\xefnserted]|tA[after]\'\r\nindexes 11 13\r\nsubstitution \'tA\'\r\nmatches [\'tAnt\', \'tAxt\']\r\nx[after]\x08\x08\x08\x08\x08\x08\x08t[after]\x08\x08\x08\x08\x08\x08\x08\r\nresult \'[\\xefnserted]|tAxt[after]\'\r\nhistory \'[\\xefnserted]|tAxt[after]\'\r\ncompleter [\'tA-0\', \'GOT 1\', \'tA-1\', \'GOT 2\', \'tA-2\', \'tA-0\', \'GOT 1\', \'tA-1\', \'GOT 2\', \'tA-2\', \'tAx-0\', \'GOT 3\', \'tAx-1\']\r\n")
ok

----------
Added file: http://bugs.python.org/file45956/tracing_the_completer_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28997>
_______________________________________

From report at bugs.python.org  Sun Dec 18 14:31:32 2016
From: report at bugs.python.org (R. David Murray)
Date: Sun, 18 Dec 2016 19:31:32 +0000
Subject: [issue29005] Possibly incorrect description about method objects
In-Reply-To: <1482076212.99.0.372888946767.issue29005@psf.upfronthosting.co.za>
Message-ID: <1482089492.86.0.176610438261.issue29005@psf.upfronthosting.co.za>


R. David Murray added the comment:

I think it is better to say "the method's instance object", because in the final paragraph we discuss the fact that each method object has an associated instance object.  The instance object isn't magically acquired from elsewhere and added, it is added because it has been bound into the method object.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29005>
_______________________________________

From report at bugs.python.org  Sun Dec 18 14:49:26 2016
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Sun, 18 Dec 2016 19:49:26 +0000
Subject: [issue29005] Possibly incorrect description about method objects
In-Reply-To: <1482076212.99.0.372888946767.issue29005@psf.upfronthosting.co.za>
Message-ID: <1482090566.21.0.966092961613.issue29005@psf.upfronthosting.co.za>


Jim Fasarakis-Hilliard added the comment:

Agreed, attached amended patch

----------
Added file: http://bugs.python.org/file45957/method_obj35_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29005>
_______________________________________

From report at bugs.python.org  Sun Dec 18 15:03:05 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 18 Dec 2016 20:03:05 +0000
Subject: [issue29005] Possibly incorrect description about method objects
In-Reply-To: <1482076212.99.0.372888946767.issue29005@psf.upfronthosting.co.za>
Message-ID: <20161218200259.11104.13217.ECA131F0@psf.io>


Roundup Robot added the comment:

New changeset 6f89f5eb4422 by R David Murray in branch '3.5':
#29005: clarify terminology in tutorial 'method' discussion.
https://hg.python.org/cpython/rev/6f89f5eb4422

New changeset 7314e08dc907 by R David Murray in branch '3.6':
Merge: #29005: clarify terminology in tutorial 'method' discussion.
https://hg.python.org/cpython/rev/7314e08dc907

New changeset 3cc193be79ab by R David Murray in branch 'default':
Merge: #29005: clarify terminology in tutorial 'method' discussion.
https://hg.python.org/cpython/rev/3cc193be79ab

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29005>
_______________________________________

From report at bugs.python.org  Sun Dec 18 15:04:09 2016
From: report at bugs.python.org (R. David Murray)
Date: Sun, 18 Dec 2016 20:04:09 +0000
Subject: [issue29005] Possibly incorrect description about method objects
In-Reply-To: <1482076212.99.0.372888946767.issue29005@psf.upfronthosting.co.za>
Message-ID: <1482091449.41.0.933683720254.issue29005@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks, woo and Jim.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29005>
_______________________________________

From report at bugs.python.org  Sun Dec 18 15:22:59 2016
From: report at bugs.python.org (Hans-Peter Jansen)
Date: Sun, 18 Dec 2016 20:22:59 +0000
Subject: [issue9253] argparse: optional subparsers
In-Reply-To: <1279056589.03.0.566167994161.issue9253@psf.upfronthosting.co.za>
Message-ID: <1482092579.78.0.23439494349.issue9253@psf.upfronthosting.co.za>


Changes by Hans-Peter Jansen <hpj at urpla.net>:


----------
nosy: +frispete

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9253>
_______________________________________

From report at bugs.python.org  Sun Dec 18 16:18:59 2016
From: report at bugs.python.org (Armin Rigo)
Date: Sun, 18 Dec 2016 21:18:59 +0000
Subject: [issue29006] 2.7.13 _sqlite more prone to "database table is locked"
Message-ID: <1482095939.25.0.891516594682.issue29006@psf.upfronthosting.co.za>


New submission from Armin Rigo:

2.7.13 did a small change to the sqlite commit() method, http://bugs.python.org/issue10513, which I think is causing troubles.  I noticed the problem in PyPy, which (with the same change) fails another test in Lib/sqlite3/test/regression.py, CheckTypeMapUsage(), containing this code:

        ...
        con.execute(SELECT)
        con.execute("drop table foo")
        ...

The first execute() method creates a cursor; assuming it is not promptly deleted, its mere existence causes the second execute() method to fail inside Sqlite with "OperationalError: database table is locked".  As a second step, I could reproduce the problem in CPython by changing the test like this:

        ...
        keepalive = con.execute(SELECT)    # the cursor stays alive
        con.execute("drop table foo")
        ...

The reason is that in the commit() done by the second execute(), we no longer reset all this connection's cursors before proceeding.  But depending on the operation, Sqlite may then complain that the "table is locked" by these old cursors.  In other words, this new situation introduced in 2.7.13 potentially makes a few complicated cases crash by "table is locked" on CPython, where they would work fine previously---which is bad IMHO.  About PyPy, many more cases would crash, to the point that we may have no choice but not implement this 2.7.13 change at all.

----------
messages: 283569
nosy: arigo
priority: normal
severity: normal
status: open
title: 2.7.13 _sqlite more prone to "database table is locked"
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29006>
_______________________________________

From report at bugs.python.org  Sun Dec 18 16:20:40 2016
From: report at bugs.python.org (Ned Deily)
Date: Sun, 18 Dec 2016 21:20:40 +0000
Subject: [issue29006] 2.7.13 _sqlite more prone to "database table is locked"
In-Reply-To: <1482095939.25.0.891516594682.issue29006@psf.upfronthosting.co.za>
Message-ID: <1482096040.39.0.635261502553.issue29006@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
nosy: +benjamin.peterson, berker.peksag, ghaering

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29006>
_______________________________________

From report at bugs.python.org  Sun Dec 18 17:10:22 2016
From: report at bugs.python.org (Armin Rigo)
Date: Sun, 18 Dec 2016 22:10:22 +0000
Subject: [issue29006] 2.7.13 _sqlite more prone to "database table is locked"
In-Reply-To: <1482095939.25.0.891516594682.issue29006@psf.upfronthosting.co.za>
Message-ID: <1482099022.92.0.963482232158.issue29006@psf.upfronthosting.co.za>


Armin Rigo added the comment:

Or maybe it would be enough to change commit() so that if Sqlite fails with "table is locked", pysqlite would reset all cursors and then try again?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29006>
_______________________________________

From report at bugs.python.org  Sun Dec 18 19:31:57 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 19 Dec 2016 00:31:57 +0000
Subject: [issue28927] bytes.fromhex should ignore all whitespace
In-Reply-To: <1481328446.9.0.450435696311.issue28927@psf.upfronthosting.co.za>
Message-ID: <1482107517.02.0.51359142573.issue28927@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

+1 to the above Unicode whitespace discussion - the "ASCII space -> ASCII whitespace" change is relatively straightforward to implement, and clearly beneficial given Robert's point regarding the popularity of multi-line terminal-oriented hexdump formats.

Neither of those points apply to Unicode whitespace (it would be much harder to implement, and we don't have a demonstrated use case for it), so it makes sense to avoid going that far.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28927>
_______________________________________

From report at bugs.python.org  Sun Dec 18 21:40:53 2016
From: report at bugs.python.org (Eric Lafontaine)
Date: Mon, 19 Dec 2016 02:40:53 +0000
Subject: [issue28879] smtplib send_message should add Date header if it is
 missing, per RFC5322
In-Reply-To: <1480952895.22.0.418354723664.issue28879@psf.upfronthosting.co.za>
Message-ID: <1482115253.69.0.178658406445.issue28879@psf.upfronthosting.co.za>


Eric Lafontaine added the comment:

Hi all,

this is not a short answer, like I hoped it would be ;).  But skip to the last section if you don't want to read it all.
________________________________
the heuristic problem :

For the heuristic of the resent headers, it's clearly say in the RFC5322 that all resent block should be PREPENDED to messages.  So only the first ones you see should be handled.  email.message keeps the order of the headers while reading and "get" always takes the first one if it exist :).    

from the RFC: 
   Each new set of resent fields is prepended to the
   message; that is, the most recent set of resent fields appears
   earlier in the message.  No other fields in the message are changed
   when resent fields are added.

For the behavior of the send_message, we used Resent-Date as it should always be present for EACH set of resent : 
   When resent fields are used, the "Resent-From:" and "Resent-Date:"
   fields MUST be sent.  The "Resent-Message-ID:" field SHOULD be sent.
   "Resent-Sender:" SHOULD NOT be used if "Resent-Sender:" would be
   identical to "Resent-From:".
   
It's fantastic that things work well like this for coders :).

The issues is with the msg object being passed...  It does retain the order, but doesn't prepend new-headers... it only append new headers (putting them at the bottom of the e-mail).

If someone wants to prepend headers (i.e. the "Resend-"), they will have to take the msg obj and do the addition manually; 
    msg._headers.insert(0,msg.policy.header_store_parse(name, val)).
    
They already have to do it though as the as_string function will print them at the bottom anyway.  Changing the "__setitem__" of message change the behavior too much...  even though it would be the right thing to do... email.message read e-mail from top to bottom and "set" each line.  In other words, for order dependant headers like the Resent, we're screwed.

i.e. from the test case about the multiple resent, here is what is sent down the "data" smtp command :
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: foo at bar.com
To: John
CC: Sally, Fred
Bcc: John Root <root at localhost>, "Dinsdale" <warped at silly.walks.com>
Resent-Date: Thu, 1 Jan 1970 17:42:00 +0000
Resent-From: holy at grail.net
Resent-To: Martha <my_mom at great.cooker.com>, Jeff
Resent-Bcc: doe at losthope.net
Resent-Date: Thu, 2 Jan 1970 17:42:00 +0000
Resent-To: holy at grail.net
Resent-From: Martha <my_mom at great.cooker.com>, Jeff
Date: Sun, 18 Dec 2016 20:32:11 -0000

A test message


___________________________________

Finally, for the "ehlo_or_helo_if_needed", I thought about it and here's what I think and what I believe we should be doing (I'm not attached to the idea though);
    The send_message is a higher level of thinking and should be able to be modified if someone wants to act differently by sub-classing the smtplib.SMTP class.  in other words, if that someone wants to modify the SMTP behavior, he could modify the sendmail function, which would also impact the send_message function.
    
    This leads the developpers to have to use ehlo and prepare the connection for send_message, but doesn't enforce it :).  Which would also already be the case of doing it with sendmail and that instead of having to over-ride 2 methods, only one is over-written.  
    
    If this is not desired, than I suggest "protecting our reference" by using thunder sendmail instead.
    
I prefer to remove the ehlo from the send_message and allow "flexibility" on the send_message itself.  
___________________________________

The issue I have right now, is what David Mentionned about the heuristic... I should raise an error when 2 Resent-Date are found, but that will prevent me from using it for production ( as I have more than one resent field present sometime...).  This would also prevent people from using it and I find it sad.  For now, i'm guessing that adding a keyword parameter "guess" would be the right things to do, but will let that be in an other ticket.  David, I find that somehow the RFC5322 isn't clear enough on the "Resent-" header order, so I've written to the IETF to have some explanation on the rules in edge cases.  The heuristic is implemented (takes the first one it finds), but just not activated yet for multiple Resent-Date.

I'll re-iterate my need for someone to review the code though :).

Eric Lafontaine

----------
Added file: http://bugs.python.org/file45958/issue_28879_V2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28879>
_______________________________________

From report at bugs.python.org  Sun Dec 18 21:50:41 2016
From: report at bugs.python.org (Brian Davis)
Date: Mon, 19 Dec 2016 02:50:41 +0000
Subject: [issue29007] Virus detected when attempting to download
 numpy-1.11.3-cp35-none-win32.whl
Message-ID: <1482115841.03.0.80807750574.issue29007@psf.upfronthosting.co.za>


New submission from Brian Davis:

When attempting to download the latest numpy windows binary, it is quarantined due to the presence of Trojan:Win32/Spursint.A!cl.  This should be removed, and root caused as to how this could have made it into the package.

----------
messages: 283573
nosy: Brian Davis
priority: normal
severity: normal
status: open
title: Virus detected when attempting to download  numpy-1.11.3-cp35-none-win32.whl
type: security

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29007>
_______________________________________

From report at bugs.python.org  Sun Dec 18 21:53:16 2016
From: report at bugs.python.org (Eric Lafontaine)
Date: Mon, 19 Dec 2016 02:53:16 +0000
Subject: [issue28879] smtplib send_message should add Date header if it is
 missing, per RFC5322
In-Reply-To: <1480952895.22.0.418354723664.issue28879@psf.upfronthosting.co.za>
Message-ID: <1482115996.51.0.700254702314.issue28879@psf.upfronthosting.co.za>


Eric Lafontaine added the comment:

forgot to re-post the to-do, and to correct the documentation :
List of things to do :
- Implement a patch for the code to add a missing "Date" field if it doesn't exist .   (in review)
- Modify the documentation at the SMTPLib for the send_message to mention that it add missing date using the email.utils.formatdate 
- Modify the comment of the send_message code to mention RFC 5322 in there (ideally with the section of the RFC).  ( in review)
- Modify the example of Python 2 to present a RFC 5322 examples 

Feedback welcome as always!

----------
Added file: http://bugs.python.org/file45959/issue_28879_V3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28879>
_______________________________________

From report at bugs.python.org  Sun Dec 18 22:17:19 2016
From: report at bugs.python.org (Dan Snider)
Date: Mon, 19 Dec 2016 03:17:19 +0000
Subject: [issue29008] Can't do dict comp from previously defined dict in the
 outermost scope of class defintion
Message-ID: <1482117439.83.0.807887809751.issue29008@psf.upfronthosting.co.za>


New submission from Dan Snider:

class MyClass:
    a_dict = {'key':'value'}
    r_dict = {a_dict[k]:k for k in a_dict}
    
throws the error: 

Traceback (most recent call last):
  File "C:/Users/D/AppData/Local/Programs/Python/Python35-32/deleteme.py", line 1, in <module>
    class MyClass:
  File "C:/Users/D/AppData/Local/Programs/Python/Python35-32/deleteme.py", line 3, in MyClass
    r_dict = {a_dict[k]:k for k in a_dict}
  File "C:/Users/D/AppData/Local/Programs/Python/Python35-32/deleteme.py", line 3, in <dictcomp>
    r_dict = {a_dict[k]:k for k in a_dict}
NameError: name 'a_dict' is not defined

----------
assignee: terry.reedy
components: IDLE, Interpreter Core, Windows
messages: 283575
nosy: Assume_Away, paul.moore, steve.dower, terry.reedy, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Can't do dict comp from previously defined dict in the outermost scope of class defintion
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29008>
_______________________________________

From report at bugs.python.org  Sun Dec 18 22:39:53 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 19 Dec 2016 03:39:53 +0000
Subject: [issue29008] Can't do dict comp from previously defined dict in the
 outermost scope of class defintion
In-Reply-To: <1482117439.83.0.807887809751.issue29008@psf.upfronthosting.co.za>
Message-ID: <1482118793.83.0.722629092027.issue29008@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

This is by design in 3.x. You can refer #11796 for explanation.

----------
nosy: +xiang.zhang
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
superseder:  -> Comprehensions in a class definition mostly cannot access class variable

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29008>
_______________________________________

From report at bugs.python.org  Sun Dec 18 23:10:12 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 19 Dec 2016 04:10:12 +0000
Subject: [issue29008] Can't do dict comp from previously defined dict in the
 outermost scope of class defintion
In-Reply-To: <1482117439.83.0.807887809751.issue29008@psf.upfronthosting.co.za>
Message-ID: <1482120612.91.0.0613047704981.issue29008@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Also http://stackoverflow.com/a/4199355/2189957.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29008>
_______________________________________

From report at bugs.python.org  Sun Dec 18 23:30:27 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 19 Dec 2016 04:30:27 +0000
Subject: [issue29008] Can't do dict comp from previously defined dict in the
 outermost scope of class defintion
In-Reply-To: <1482117439.83.0.807887809751.issue29008@psf.upfronthosting.co.za>
Message-ID: <1482121827.48.0.242867949394.issue29008@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
assignee: terry.reedy -> 
nosy:  -terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29008>
_______________________________________

From report at bugs.python.org  Sun Dec 18 23:30:59 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 19 Dec 2016 04:30:59 +0000
Subject: [issue29009] Outdated part in the doc of PyUnicode_RichCompare
Message-ID: <1482121859.8.0.633122991353.issue29009@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

The sentence:

"Note that Py_EQ and Py_NE comparisons can cause a UnicodeWarning in case the conversion of the arguments to Unicode fails with a UnicodeDecodeError."

in the doc of PyUnicode_RichCompare is not true in 3.x. Proposed patch simply deletes it.

----------
assignee: docs at python
components: Documentation
files: doc-of-PyUnicode_RichCompare.patch
keywords: patch
messages: 283578
nosy: docs at python, haypo, xiang.zhang
priority: normal
severity: normal
stage: patch review
status: open
title: Outdated part in the doc of PyUnicode_RichCompare
versions: Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45960/doc-of-PyUnicode_RichCompare.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29009>
_______________________________________

From report at bugs.python.org  Sun Dec 18 23:45:08 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 19 Dec 2016 04:45:08 +0000
Subject: [issue20185] Derby #17: Convert 49 sites to Argument Clinic across 13
 files
In-Reply-To: <1389140539.55.0.106381625615.issue20185@psf.upfronthosting.co.za>
Message-ID: <1482122708.46.0.254873468565.issue20185@psf.upfronthosting.co.za>


Martin Panter added the comment:

I finished reviewing the most recent patches and left some comments. Perhaps it is worth splitting the conglomerate patch up. I don?t see any point holding back some modules while things are tweaked in unrelated files.

My biggest concern is casting function pointers, especially when the number of parameters is different than expected. It would be good to fix or discuss that more before going ahead with floatobject.c.

----------
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20185>
_______________________________________

From report at bugs.python.org  Sun Dec 18 23:45:33 2016
From: report at bugs.python.org (woo yoo)
Date: Mon, 19 Dec 2016 04:45:33 +0000
Subject: [issue29010] Incorrect description about scope related with
 inheritance
Message-ID: <1482122733.15.0.137275171819.issue29010@psf.upfronthosting.co.za>


New submission from woo yoo:

The current description is "The name BaseClassName must be defined in a scope containing the derived class definition", which did not conform to the actual situation ,e.g. the base class object is not in the same scope as the derived class.

----------
messages: 283580
nosy: woo yoo
priority: normal
severity: normal
status: open
title: Incorrect description about scope related with inheritance

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29010>
_______________________________________

From report at bugs.python.org  Sun Dec 18 23:46:18 2016
From: report at bugs.python.org (woo yoo)
Date: Mon, 19 Dec 2016 04:46:18 +0000
Subject: [issue29010] Incorrect description about scope related with
 inheritance
In-Reply-To: <1482122733.15.0.137275171819.issue29010@psf.upfronthosting.co.za>
Message-ID: <1482122778.61.0.0824941212553.issue29010@psf.upfronthosting.co.za>


woo yoo added the comment:

The associated link is https://docs.python.org/3.6/tutorial/classes.html#inheritance

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
versions: +Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29010>
_______________________________________

From report at bugs.python.org  Sun Dec 18 23:54:34 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Mon, 19 Dec 2016 04:54:34 +0000
Subject: [issue29007] Virus detected when attempting to download
 numpy-1.11.3-cp35-none-win32.whl
In-Reply-To: <1482115841.03.0.80807750574.issue29007@psf.upfronthosting.co.za>
Message-ID: <1482123274.03.0.175807511823.issue29007@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

numpy is not part of Python. Please report this to http://www.numpy.org/

----------
assignee:  -> christian.heimes
components: +SSL
nosy: +Chi Hsuan Yen, christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29007>
_______________________________________

From report at bugs.python.org  Sun Dec 18 23:55:26 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Mon, 19 Dec 2016 04:55:26 +0000
Subject: [issue29007] Virus detected when attempting to download
 numpy-1.11.3-cp35-none-win32.whl
In-Reply-To: <1482115841.03.0.80807750574.issue29007@psf.upfronthosting.co.za>
Message-ID: <1482123326.62.0.501031778682.issue29007@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

Sorry Crys, I misclicked on SSL and I don't have the permission to revert it :/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29007>
_______________________________________

From report at bugs.python.org  Mon Dec 19 00:35:24 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 19 Dec 2016 05:35:24 +0000
Subject: [issue29007] Virus detected when attempting to download
 numpy-1.11.3-cp35-none-win32.whl
In-Reply-To: <1482115841.03.0.80807750574.issue29007@psf.upfronthosting.co.za>
Message-ID: <1482125724.24.0.0202730485663.issue29007@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
assignee: christian.heimes -> 
resolution:  -> third party
stage:  -> resolved
status: open -> closed
type: security -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29007>
_______________________________________

From report at bugs.python.org  Mon Dec 19 00:39:53 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 19 Dec 2016 05:39:53 +0000
Subject: [issue20191] resource.prlimit(int, int, str) crashs
In-Reply-To: <1389191622.9.0.0763750909735.issue20191@psf.upfronthosting.co.za>
Message-ID: <1482125993.03.0.852578177605.issue20191@psf.upfronthosting.co.za>


Martin Panter added the comment:

Patch looks good to me. Although maybe you don?t need the IndexError check in the test. Won?t limit[key] already handle that for you (as long as key isn?t -1 etc).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20191>
_______________________________________

From report at bugs.python.org  Mon Dec 19 00:43:13 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 19 Dec 2016 05:43:13 +0000
Subject: [issue29009] Outdated part in the doc of PyUnicode_RichCompare
In-Reply-To: <1482121859.8.0.633122991353.issue29009@psf.upfronthosting.co.za>
Message-ID: <1482126193.54.0.953651227033.issue29009@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This sentence also is in the header.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29009>
_______________________________________

From report at bugs.python.org  Mon Dec 19 01:07:53 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 19 Dec 2016 06:07:53 +0000
Subject: [issue20191] resource.prlimit(int, int, str) crashs
In-Reply-To: <1389191622.9.0.0763750909735.issue20191@psf.upfronthosting.co.za>
Message-ID: <20161219060749.21869.83357.6BAA3F54@psf.io>


Roundup Robot added the comment:

New changeset dac72bc14c00 by Serhiy Storchaka in branch '3.5':
Issue #20191: Fixed a crash in resource.prlimit() when pass a sequence that
https://hg.python.org/cpython/rev/dac72bc14c00

New changeset 7bc2923a41b6 by Serhiy Storchaka in branch '3.6':
Issue #20191: Fixed a crash in resource.prlimit() when pass a sequence that
https://hg.python.org/cpython/rev/7bc2923a41b6

New changeset b4d2bff1c5f8 by Serhiy Storchaka in branch 'default':
Issue #20191: Fixed a crash in resource.prlimit() when pass a sequence that
https://hg.python.org/cpython/rev/b4d2bff1c5f8

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20191>
_______________________________________

From report at bugs.python.org  Mon Dec 19 01:08:56 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 19 Dec 2016 06:08:56 +0000
Subject: [issue29009] Outdated part in the doc of PyUnicode_RichCompare
In-Reply-To: <1482121859.8.0.633122991353.issue29009@psf.upfronthosting.co.za>
Message-ID: <1482127735.99.0.909701841181.issue29009@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

> This sentence also is in the header.

Ohh, yes. Thanks Serhiy!

----------
Added file: http://bugs.python.org/file45961/doc-of-PyUnicode_RichCompare_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29009>
_______________________________________

From report at bugs.python.org  Mon Dec 19 01:09:45 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 19 Dec 2016 06:09:45 +0000
Subject: [issue20191] resource.prlimit(int, int, str) crashs
In-Reply-To: <1389191622.9.0.0763750909735.issue20191@psf.upfronthosting.co.za>
Message-ID: <1482127785.43.0.0550805015872.issue20191@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Although maybe you don?t need the IndexError check in the test.

Good point. Thank you for your review Martin!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20191>
_______________________________________

From report at bugs.python.org  Mon Dec 19 01:10:37 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 19 Dec 2016 06:10:37 +0000
Subject: [issue29009] Outdated part in the doc of PyUnicode_RichCompare
In-Reply-To: <1482121859.8.0.633122991353.issue29009@psf.upfronthosting.co.za>
Message-ID: <1482127837.79.0.900977792673.issue29009@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM.

----------
assignee: docs at python -> xiang.zhang
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29009>
_______________________________________

From report at bugs.python.org  Mon Dec 19 01:19:33 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 19 Dec 2016 06:19:33 +0000
Subject: [issue29011] No entry for deques in typing
Message-ID: <1482128373.3.0.983889719325.issue29011@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

We have:

    # Concrete collection types.
    'Dict',
    'DefaultDict',
    'List',
    'Set',
    'FrozenSet',
    'NamedTuple',  # Not really a type.
    'Generator',

But no mention of Deque.

What this an intended omission?

I would like to be able to write something like this:

   user_posts = defaultdict(deque)  # type: DefaultDict[User, Deque[Post]]

----------
messages: 283590
nosy: gvanrossum, rhettinger
priority: normal
severity: normal
status: open
title: No entry for deques in typing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29011>
_______________________________________

From report at bugs.python.org  Mon Dec 19 01:36:08 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 19 Dec 2016 06:36:08 +0000
Subject: [issue29011] No entry for deques in typing
In-Reply-To: <1482128373.3.0.983889719325.issue29011@psf.upfronthosting.co.za>
Message-ID: <1482129368.09.0.277363448355.issue29011@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

FWIW, I tried "d = deque() # type: typing.MutableSequence" but this gave:

    error: MutableSequence[Post] has no attribute "appendleft"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29011>
_______________________________________

From report at bugs.python.org  Mon Dec 19 01:47:07 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 19 Dec 2016 06:47:07 +0000
Subject: [issue25677] Syntax error caret confused by indentation
In-Reply-To: <1447998656.06.0.471632717786.issue25677@psf.upfronthosting.co.za>
Message-ID: <20161219064703.34331.21178.147D760F@psf.io>


Roundup Robot added the comment:

New changeset 35b50c26f780 by Martin Panter in branch '3.5':
Issue #25677: Correct syntax error caret for indented blocks.
https://hg.python.org/cpython/rev/35b50c26f780

New changeset d4effdd699de by Martin Panter in branch '3.6':
Issue #25677: Merge SyntaxError caret positioning from 3.5
https://hg.python.org/cpython/rev/d4effdd699de

New changeset 2342726ea0c0 by Martin Panter in branch 'default':
Issue #25677: Merge SyntaxError caret positioning from 3.6
https://hg.python.org/cpython/rev/2342726ea0c0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25677>
_______________________________________

From report at bugs.python.org  Mon Dec 19 02:32:54 2016
From: report at bugs.python.org (Henning von Bargen)
Date: Mon, 19 Dec 2016 07:32:54 +0000
Subject: [issue28879] smtplib send_message should add Date header if it is
 missing, per RFC5322
In-Reply-To: <1480952895.22.0.418354723664.issue28879@psf.upfronthosting.co.za>
Message-ID: <1482132774.36.0.0438140215177.issue28879@psf.upfronthosting.co.za>


Henning von Bargen added the comment:

I think Eric's To-Do list sums it up pretty well.

I just wanted to say how much I appreciate the Python community. It seems that every little detail is very well-thought-out.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28879>
_______________________________________

From report at bugs.python.org  Mon Dec 19 02:50:25 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 19 Dec 2016 07:50:25 +0000
Subject: [issue29011] No entry Deque in typing.py
In-Reply-To: <1482128373.3.0.983889719325.issue29011@psf.upfronthosting.co.za>
Message-ID: <1482133825.15.0.31069766624.issue29011@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
title: No entry for deques in typing -> No entry Deque in typing.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29011>
_______________________________________

From report at bugs.python.org  Mon Dec 19 02:59:09 2016
From: report at bugs.python.org (Henning von Bargen)
Date: Mon, 19 Dec 2016 07:59:09 +0000
Subject: [issue22139] python windows 2.7.8 64-bit did not install
In-Reply-To: <1407238374.16.0.107772681213.issue22139@psf.upfronthosting.co.za>
Message-ID: <1482134349.52.0.843093621011.issue22139@psf.upfronthosting.co.za>


Henning von Bargen added the comment:

A belated update... What I'm trying is similar to virtualenv:

My application should not depend on any pre-installed Python and not have any influence on it (and it should not modify the registry or the system environment variables).

It should be noted that my application is using a different executable instead of python.exe.

On Linux, I can do "make altinstall", but on Windows, setting up everything for compiling Python is out of scope.

Some of my other programs are using Python 3.5. With its "embeddable zip" it is very easy to achieve this goal.

Unfortunately, the most important program is using Python 2 on Windows and re-writing it for Python 3 would be quite an effort.

I think I finally found a way now with Python 2.7:

1. Define a directory where Python 2.x should be installed.
   SET PYTHONHOME=....
2. Create that directory
   MKDIR %PYTHONHOME%
3. Run the installer like this:
   msiexec /a python-2.7.12.amd64 /qb TARGETDIR=%PYTHONHOME%
4. Useful: pushd %PYTHONHOME%; python -m ensurepip; popd
5. Copy python 27.dll next to your executable (see http://blog.pyspoken.com/2016/04/27/embedding-python-how-to-confuse-python-and-yourself) - this is the important step.
   copy /b %PYTHONHOME%\python27.dll %MY_APPLICATION_HOME%\bin\
6. When running your executable, use a script which sets %PYTHONHOME%
   copy /b %PYTHONHOME%\

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22139>
_______________________________________

From report at bugs.python.org  Mon Dec 19 03:00:07 2016
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Mon, 19 Dec 2016 08:00:07 +0000
Subject: [issue29012] __bases__ is a tuple (possibly empty or a singleton)
Message-ID: <1482134407.67.0.814127407079.issue29012@psf.upfronthosting.co.za>


New submission from Jim Fasarakis-Hilliard:

The following statement is in the Language Reference for Custom classes:

>  __bases__ is a tuple (possibly empty or a singleton) containing the base classes

AFAIK, ``object.__bases__`` is the only object for which ``__bases__`` is empty and it isn't a *custom* class. Attempts to create a class and assign __bases__ to an empty tuple is checked to enforce inheritance from ``object``. This *seems* to be something that slipped through when the docs were created for Python 3.0?

I'm curious to see if this can actually be empty, if not, attached patch removes ''empty'' from the sentence.

----------
assignee: docs at python
components: Documentation
files: fixbasesdoc.patch
keywords: patch
messages: 283595
nosy: Jim Fasarakis-Hilliard, docs at python
priority: normal
severity: normal
status: open
title: __bases__ is a tuple (possibly empty or a singleton)
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45962/fixbasesdoc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29012>
_______________________________________

From report at bugs.python.org  Mon Dec 19 03:38:27 2016
From: report at bugs.python.org (Brendan Donegan)
Date: Mon, 19 Dec 2016 08:38:27 +0000
Subject: [issue29010] Incorrect description about scope related with
 inheritance
In-Reply-To: <1482122733.15.0.137275171819.issue29010@psf.upfronthosting.co.za>
Message-ID: <1482136707.41.0.627798222674.issue29010@psf.upfronthosting.co.za>


Brendan Donegan added the comment:

Hi. Can you please provide a small code snippet illustrating where this diverges from the actual behaviour?

----------
nosy: +brendan-donegan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29010>
_______________________________________

From report at bugs.python.org  Mon Dec 19 04:04:33 2016
From: report at bugs.python.org (Monte Davidoff)
Date: Mon, 19 Dec 2016 09:04:33 +0000
Subject: [issue29013] zipfile: inconsistent doc for ZIP64 file size
Message-ID: <1482138273.34.0.375914911911.issue29013@psf.upfronthosting.co.za>


New submission from Monte Davidoff:

The documentation for the zipfile module, https://docs.python.org/3.5/library/zipfile.html, contains inconsistent descriptions of the maximum size of a ZIP file when allowZip64 is False.

The second paragraph in the zipfile module documentation states:

"It can handle ZIP files that use the ZIP64 extensions (that is ZIP files that are more than 4 GiB in size)."

Later on, in the description of the zipfile.ZipFile class, it says:

"If allowZip64 is True (the default) zipfile will create ZIP files that use the ZIP64 extensions when the zipfile is larger than 2 GiB."

The two sizes (4 GiB and 2 GiB) should be the same. According to https://en.wikipedia.org/wiki/Zip_(file_format)#ZIP64, 4 GiB is the correct value.

There is a similar problem in the 2.7.13 documentation, https://docs.python.org/2.7/library/zipfile.html.

----------
assignee: docs at python
components: Documentation
messages: 283597
nosy: docs at python, mndavidoff
priority: normal
severity: normal
status: open
title: zipfile: inconsistent doc for ZIP64 file size
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29013>
_______________________________________

From report at bugs.python.org  Mon Dec 19 04:47:35 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 19 Dec 2016 09:47:35 +0000
Subject: [issue28996] wcscoll is broken on Android and test_locale fails
In-Reply-To: <1481963718.08.0.920050367938.issue28996@psf.upfronthosting.co.za>
Message-ID: <20161219094731.34566.22025.5031BCF3@psf.io>


Roundup Robot added the comment:

New changeset 781c56168484 by Xavier de Gaye in branch '3.6':
Issue #28996: Skip two tests that fail on Android with the locale strcoll() and
https://hg.python.org/cpython/rev/781c56168484

New changeset 5c5cf7687dc1 by Xavier de Gaye in branch 'default':
Issue #28996: Merge 3.6.
https://hg.python.org/cpython/rev/5c5cf7687dc1

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28996>
_______________________________________

From report at bugs.python.org  Mon Dec 19 05:01:25 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 19 Dec 2016 10:01:25 +0000
Subject: [issue19542] WeakValueDictionary bug in setdefault()&pop()
In-Reply-To: <1384073464.47.0.0676946313386.issue19542@psf.upfronthosting.co.za>
Message-ID: <20161219100121.128270.24661.DBF2657E@psf.io>


Roundup Robot added the comment:

New changeset 5a542a2bca08 by Antoine Pitrou in branch '3.5':
Issue #19542: Fix bugs in WeakValueDictionary.setdefault() and WeakValueDictionary.pop()
https://hg.python.org/cpython/rev/5a542a2bca08

New changeset f3706a9430da by Antoine Pitrou in branch '3.6':
Issue #19542: Fix bugs in WeakValueDictionary.setdefault() and WeakValueDictionary.pop()
https://hg.python.org/cpython/rev/f3706a9430da

New changeset ac2715d04119 by Antoine Pitrou in branch 'default':
Issue #19542: Fix bugs in WeakValueDictionary.setdefault() and WeakValueDictionary.pop()
https://hg.python.org/cpython/rev/ac2715d04119

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19542>
_______________________________________

From report at bugs.python.org  Mon Dec 19 05:08:12 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Dec 2016 10:08:12 +0000
Subject: [issue29009] Outdated part in the doc of PyUnicode_RichCompare
In-Reply-To: <1482121859.8.0.633122991353.issue29009@psf.upfronthosting.co.za>
Message-ID: <1482142092.75.0.880056226693.issue29009@psf.upfronthosting.co.za>


STINNER Victor added the comment:

doc-of-PyUnicode_RichCompare_v2.patch LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29009>
_______________________________________

From report at bugs.python.org  Mon Dec 19 05:14:00 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 19 Dec 2016 10:14:00 +0000
Subject: [issue19542] WeakValueDictionary bug in setdefault()&pop()
In-Reply-To: <1384073464.47.0.0676946313386.issue19542@psf.upfronthosting.co.za>
Message-ID: <20161219101357.127783.96863.1829415F@psf.io>


Roundup Robot added the comment:

New changeset bcb1f0698401 by Antoine Pitrou in branch '2.7':
Issue #19542: Fix bugs in WeakValueDictionary.setdefault() and WeakValueDictionary.pop()
https://hg.python.org/cpython/rev/bcb1f0698401

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19542>
_______________________________________

From report at bugs.python.org  Mon Dec 19 05:14:27 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Dec 2016 10:14:27 +0000
Subject: [issue19542] WeakValueDictionary bug in setdefault()&pop()
In-Reply-To: <1384073464.47.0.0676946313386.issue19542@psf.upfronthosting.co.za>
Message-ID: <1482142467.63.0.52886858105.issue19542@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

This is finally fixed!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19542>
_______________________________________

From report at bugs.python.org  Mon Dec 19 05:16:19 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 19 Dec 2016 10:16:19 +0000
Subject: [issue28996] wcscoll is broken on Android and test_locale fails
In-Reply-To: <1481963718.08.0.920050367938.issue28996@psf.upfronthosting.co.za>
Message-ID: <1482142579.76.0.796446100598.issue28996@psf.upfronthosting.co.za>


Changes by Xavier de Gaye <xdegaye at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28996>
_______________________________________

From report at bugs.python.org  Mon Dec 19 05:22:51 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Dec 2016 10:22:51 +0000
Subject: [issue28950] regrtest: -j0 fails the check -j is not allowed together
 with -T/-l
In-Reply-To: <1481566513.26.0.47817718709.issue28950@psf.upfronthosting.co.za>
Message-ID: <1482142971.61.0.200912161781.issue28950@psf.upfronthosting.co.za>


STINNER Victor added the comment:

test-command-line-j0-with-test.patch LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28950>
_______________________________________

From report at bugs.python.org  Mon Dec 19 05:43:14 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 19 Dec 2016 10:43:14 +0000
Subject: [issue28879] smtplib send_message should add Date header if it is
 missing, per RFC5322
In-Reply-To: <1480952895.22.0.418354723664.issue28879@psf.upfronthosting.co.za>
Message-ID: <1482144194.77.0.959612061396.issue28879@psf.upfronthosting.co.za>


R. David Murray added the comment:

There is at least one open ticket (maybe two, I forget) about providing a way to insert headers at arbitrary locations in the header list.  Our trouble has been deciding on an API.  There is a mailing list (email-sig) where such things can be discussed (it has been idle for a while now...).

I think you are right about the 'heuristic'.  Thinking about it now I believe the problem was partly the lack of an API for inserting headers at the top: if there is only one resent block we are OK appending the address headers, but if there is more than one block then that would be wrong.  The other aspect, to which the comment is referring, is that if we are "augmenting" headers, how do we decide if we are augmenting an existing block, or creating a new one?  Looking at it now with fresh eyes I think we could just decide on the rules and document them.  And we probably want an option that says "this is a resend, add all the Resent headers as a new block".  Or maybe that is enough by itself.  No heuristics, refuse to guess :)  Either the user adds all the headers themselves, or none of them, and we construct them in send_message.  (I haven't reviewed the RFC lately, so I'm not sure that covers all the use cases.)

I don't have a strong opinion on the ehlo_helo issue, but I'm not clear on why its presence causes any difficulty for subclassing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28879>
_______________________________________

From report at bugs.python.org  Mon Dec 19 05:43:42 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 19 Dec 2016 10:43:42 +0000
Subject: [issue29009] Outdated part in the doc of PyUnicode_RichCompare
In-Reply-To: <1482121859.8.0.633122991353.issue29009@psf.upfronthosting.co.za>
Message-ID: <20161219104338.21591.24827.34D52F3B@psf.io>


Roundup Robot added the comment:

New changeset 8f5ed2a38f64 by Xiang Zhang in branch '3.5':
Issue #29009: Remove outdated doc of PyUnicode_RichCompare.
https://hg.python.org/cpython/rev/8f5ed2a38f64

New changeset da958d01755a by Xiang Zhang in branch '3.6':
Issue #29009: Merge 3.5.
https://hg.python.org/cpython/rev/da958d01755a

New changeset 9568343fde42 by Xiang Zhang in branch 'default':
Issue #29009: Merge 3.6.
https://hg.python.org/cpython/rev/9568343fde42

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29009>
_______________________________________

From report at bugs.python.org  Mon Dec 19 05:44:42 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 19 Dec 2016 10:44:42 +0000
Subject: [issue29009] Outdated part in the doc of PyUnicode_RichCompare
In-Reply-To: <1482121859.8.0.633122991353.issue29009@psf.upfronthosting.co.za>
Message-ID: <1482144282.57.0.645297060447.issue29009@psf.upfronthosting.co.za>


Changes by Xiang Zhang <angwerzx at 126.com>:


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29009>
_______________________________________

From report at bugs.python.org  Mon Dec 19 06:31:38 2016
From: report at bugs.python.org (David Karimi)
Date: Mon, 19 Dec 2016 11:31:38 +0000
Subject: [issue29014] Python 3.5.2 installer doesn't register IDLE .py
 extensions on Windows 10
Message-ID: <1482147098.02.0.695368643489.issue29014@psf.upfronthosting.co.za>


New submission from David Karimi:

"Edit with IDLE" option is also not present in my installation when I right-click on a .py file. And when I try to choose the IDLE application, it just defaults to the command line version every time. I don't know why this happens. I was able to run it fine on my Windows 7 and it recognized all my .py student files as IDLE-based which is exactly what I want: to see them in a script editing environment. 

Any help would be appreciated. All the proposed solutions online haven't helped.

----------
assignee: terry.reedy
components: IDLE
messages: 283606
nosy: frostyelsa, terry.reedy
priority: normal
severity: normal
status: open
title: Python 3.5.2 installer doesn't register IDLE .py extensions on Windows 10
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29014>
_______________________________________

From report at bugs.python.org  Mon Dec 19 06:55:36 2016
From: report at bugs.python.org (Cathy Avery)
Date: Mon, 19 Dec 2016 11:55:36 +0000
Subject: [issue27584] New addition of vSockets to the python socket module
In-Reply-To: <1469115390.74.0.838831983223.issue27584@psf.upfronthosting.co.za>
Message-ID: <1482148536.52.0.110519578147.issue27584@psf.upfronthosting.co.za>


Cathy Avery added the comment:

Is there a format checker I could use on the patch?

VMCI and the vmw_vsock_vmci_transport kernel modules are located in the upstream linux tree at 

git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

They have been there for about years. These drivers are part of various downstream kernels such as RHEL. You will need a Vmware virtual machine in order to test it. 

Only the virtio-vsock driver is a new vsock application that needs to be custom built.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27584>
_______________________________________

From report at bugs.python.org  Mon Dec 19 06:56:50 2016
From: report at bugs.python.org (Cathy Avery)
Date: Mon, 19 Dec 2016 11:56:50 +0000
Subject: [issue27584] New addition of vSockets to the python socket module
In-Reply-To: <1469115390.74.0.838831983223.issue27584@psf.upfronthosting.co.za>
Message-ID: <1482148610.69.0.7450114216.issue27584@psf.upfronthosting.co.za>


Cathy Avery added the comment:

Sorry about the typo the drivers have been there for about 4 years.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27584>
_______________________________________

From report at bugs.python.org  Mon Dec 19 06:57:09 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 19 Dec 2016 11:57:09 +0000
Subject: [issue29007] Virus detected when attempting to download
 numpy-1.11.3-cp35-none-win32.whl
In-Reply-To: <1482115841.03.0.80807750574.issue29007@psf.upfronthosting.co.za>
Message-ID: <1482148629.59.0.833160721556.issue29007@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
components:  -SSL

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29007>
_______________________________________

From report at bugs.python.org  Mon Dec 19 06:59:15 2016
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 19 Dec 2016 11:59:15 +0000
Subject: [issue26110] Speedup method calls 1.2x
In-Reply-To: <1452791347.05.0.923215900831.issue26110@psf.upfronthosting.co.za>
Message-ID: <1482148755.97.0.0910530574382.issue26110@psf.upfronthosting.co.za>


Changes by INADA Naoki <songofacandy at gmail.com>:


Added file: http://bugs.python.org/file45963/call-method-doc4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26110>
_______________________________________

From report at bugs.python.org  Mon Dec 19 07:04:07 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 19 Dec 2016 12:04:07 +0000
Subject: [issue29012] __bases__ is a tuple (possibly empty or a singleton)
In-Reply-To: <1482134407.67.0.814127407079.issue29012@psf.upfronthosting.co.za>
Message-ID: <1482149047.59.0.546380079739.issue29012@psf.upfronthosting.co.za>


R. David Murray added the comment:

Most likely it just slipped through.  In 2.7 the section is just called 'classes', not 'custom classes', and covered both classic classes and the new style classes that are all that python3 has.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29012>
_______________________________________

From report at bugs.python.org  Mon Dec 19 07:05:45 2016
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 19 Dec 2016 12:05:45 +0000
Subject: [issue28383] __hash__ documentation recommends naive XOR to combine
 but this is suboptimal
In-Reply-To: <1475815043.27.0.00299962010674.issue28383@psf.upfronthosting.co.za>
Message-ID: <1482149145.44.0.158163680897.issue28383@psf.upfronthosting.co.za>


INADA Naoki added the comment:

LGTM

----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28383>
_______________________________________

From report at bugs.python.org  Mon Dec 19 07:10:39 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 19 Dec 2016 12:10:39 +0000
Subject: [issue28383] __hash__ documentation recommends naive XOR to combine
 but this is suboptimal
In-Reply-To: <1475815043.27.0.00299962010674.issue28383@psf.upfronthosting.co.za>
Message-ID: <20161219121036.23338.44186.49A0F422@psf.io>


Roundup Robot added the comment:

New changeset cb802a78ceea by Victor Stinner in branch '3.5':
doc: Suggest to hash(tuple of attr) rather than XOR
https://hg.python.org/cpython/rev/cb802a78ceea

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28383>
_______________________________________

From report at bugs.python.org  Mon Dec 19 07:12:01 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 19 Dec 2016 12:12:01 +0000
Subject: [issue27584] New addition of vSockets to the python socket module
In-Reply-To: <1469115390.74.0.838831983223.issue27584@psf.upfronthosting.co.za>
Message-ID: <1482149521.73.0.342093954496.issue27584@psf.upfronthosting.co.za>


R. David Murray added the comment:

'make patchcheck' will do whitespace checking because that's hard to eyeball (although many editors/IDEs do support making it visible nowadays).  We don't use any other checking tools other than eyeballs, since not all of the existing code conforms to PEP7/8 and for various reasons we aren't going to update most of the old code to conform.

So, if I'm running an ubuntu virtual machine under VMWare Fusion (which I already have set up) I should be able to get the tests to run?  Or does it need to be RedHat (or presumably CentOS)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27584>
_______________________________________

From report at bugs.python.org  Mon Dec 19 07:12:47 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 19 Dec 2016 12:12:47 +0000
Subject: [issue28838] Using consistent naming for arguments of "call"
 functions (C API)
In-Reply-To: <1480504437.73.0.907175245586.issue28838@psf.upfronthosting.co.za>
Message-ID: <20161219121237.34931.28010.BE4C5D24@psf.io>


Roundup Robot added the comment:

New changeset 3ab0a6692e25 by Victor Stinner in branch 'default':
abstract.h: remove long outdated comment
https://hg.python.org/cpython/rev/3ab0a6692e25

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28838>
_______________________________________

From report at bugs.python.org  Mon Dec 19 07:16:21 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 19 Dec 2016 12:16:21 +0000
Subject: [issue28383] __hash__ documentation recommends naive XOR to combine
 but this is suboptimal
In-Reply-To: <1475815043.27.0.00299962010674.issue28383@psf.upfronthosting.co.za>
Message-ID: <20161219121618.95816.22239.DC0F1292@psf.io>


Roundup Robot added the comment:

New changeset fac2362f248c by Victor Stinner in branch '2.7':
doc: Suggest to hash(tuple of attr) rather than XOR
https://hg.python.org/cpython/rev/fac2362f248c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28383>
_______________________________________

From report at bugs.python.org  Mon Dec 19 07:17:11 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Dec 2016 12:17:11 +0000
Subject: [issue28383] __hash__ documentation recommends naive XOR to combine
 but this is suboptimal
In-Reply-To: <1475815043.27.0.00299962010674.issue28383@psf.upfronthosting.co.za>
Message-ID: <1482149831.5.0.963449538471.issue28383@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I updated the doc of Python 2.7, 3.5, 3.6 and default (3.7).

Thanks for the suggestion Kevin, thanks for the review Naoki.

----------
resolution:  -> fixed
status: open -> closed
versions:  -Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28383>
_______________________________________

From report at bugs.python.org  Mon Dec 19 07:24:09 2016
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 19 Dec 2016 12:24:09 +0000
Subject: [issue28158] Implement LOAD_GLOBAL opcode cache
In-Reply-To: <1473886080.87.0.000411119678127.issue28158@psf.upfronthosting.co.za>
Message-ID: <1482150249.32.0.940481172563.issue28158@psf.upfronthosting.co.za>


INADA Naoki added the comment:

I'll update this patch and #10401 and then run benchmark suite when I have time.

As far as I look quickly, #10401 uses namei as cache key
and this patch uses opcode index as cache key, am I right?

----------
nosy: +inada.naoki
priority: critical -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28158>
_______________________________________

From report at bugs.python.org  Mon Dec 19 07:51:09 2016
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 19 Dec 2016 12:51:09 +0000
Subject: [issue25617] Installing local installation of Python
In-Reply-To: <1447426322.89.0.546978633067.issue25617@psf.upfronthosting.co.za>
Message-ID: <1482151869.05.0.944757024517.issue25617@psf.upfronthosting.co.za>


INADA Naoki added the comment:

I can't understand what's your problem.

> The inherent behaviour of python installations (local or global) is such that it expects to source system wide modules from the global python installation.

What local installation means?
What global installation means?
What "expects to source system wide module ..." means?

Could you give us concrete example?

----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25617>
_______________________________________

From report at bugs.python.org  Mon Dec 19 08:01:40 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 19 Dec 2016 13:01:40 +0000
Subject: [issue25617] Installing local installation of Python
In-Reply-To: <1447426322.89.0.546978633067.issue25617@psf.upfronthosting.co.za>
Message-ID: <1482152500.46.0.212568187751.issue25617@psf.upfronthosting.co.za>


R. David Murray added the comment:

If you build and install a "local python", you will be installing the library locally as well, and python will not look to the lib dir of the system installed python.  So yes, please explain your problem with more specifics.

In any case the problem of python trying to run with the wrong version of a .pyc file is solved in python3, since each version of python writes separately-named pyc files.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25617>
_______________________________________

From report at bugs.python.org  Mon Dec 19 08:02:39 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 19 Dec 2016 13:02:39 +0000
Subject: [issue28971] nntplib is broken when responses are longer than _MAXLINE
In-Reply-To: <1481716454.12.0.730668429479.issue28971@psf.upfronthosting.co.za>
Message-ID: <1482152559.17.0.364542204831.issue28971@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Martin in response to your last review, I still hold to my opinion stated in msg283294 but this should not prevent this high priority issue to progress. Can you propose another patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28971>
_______________________________________

From report at bugs.python.org  Mon Dec 19 08:09:07 2016
From: report at bugs.python.org (Cathy Avery)
Date: Mon, 19 Dec 2016 13:09:07 +0000
Subject: [issue27584] New addition of vSockets to the python socket module
In-Reply-To: <1469115390.74.0.838831983223.issue27584@psf.upfronthosting.co.za>
Message-ID: <1482152947.09.0.570054979692.issue27584@psf.upfronthosting.co.za>


Cathy Avery added the comment:

First make sure the driver is in your kernel. It will be with RHEL. Look in /lib/modeles/"your kernel name"/kernel/net/vmw_vsock/vmw_vsock_vmci_transport. I have never tried it on vmware fusion. I have tested it on ESX. See if there is a VMCI option to enable on your VM's settings. Start the vm and do an lsmod to see if vmw_vsock_vmci_transport is loaded.

I've attached a little C program thats netcat for vsock. Its a quick confirmation that your transport is loaded correctly. It will show you your CID.

run ./nc-vsock

CID = 973033371
CID = 0x39ff4f9b
usage: ./nc-vsock [-l <port> [-t <dst> <dstport>] | <cid> <port>]

----------
Added file: http://bugs.python.org/file45964/nc-vsock

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27584>
_______________________________________

From report at bugs.python.org  Mon Dec 19 08:11:30 2016
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 19 Dec 2016 13:11:30 +0000
Subject: [issue24165] Free list for single-digits ints
In-Reply-To: <1431352769.3.0.375640200007.issue24165@psf.upfronthosting.co.za>
Message-ID: <1482153090.38.0.22463297585.issue24165@psf.upfronthosting.co.za>


Changes by INADA Naoki <songofacandy at gmail.com>:


----------
nosy: +inada.naoki
versions: +Python 3.7 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24165>
_______________________________________

From report at bugs.python.org  Mon Dec 19 08:15:33 2016
From: report at bugs.python.org (woo yoo)
Date: Mon, 19 Dec 2016 13:15:33 +0000
Subject: [issue29010] Incorrect description about scope related with
 inheritance
In-Reply-To: <1482122733.15.0.137275171819.issue29010@psf.upfronthosting.co.za>
Message-ID: <1482153333.97.0.842302051411.issue29010@psf.upfronthosting.co.za>


woo yoo added the comment:

Code:
>class A(object):
    pass

'object' is not in the same scope as 'A'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29010>
_______________________________________

From report at bugs.python.org  Mon Dec 19 08:20:45 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 19 Dec 2016 13:20:45 +0000
Subject: [issue29010] Incorrect description about scope related with
 inheritance
In-Reply-To: <1482122733.15.0.137275171819.issue29010@psf.upfronthosting.co.za>
Message-ID: <1482153645.33.0.631505871518.issue29010@psf.upfronthosting.co.za>


R. David Murray added the comment:

It is part of the global scope, which contains all other scopes.  (I'm not 100% sure I'm comfortable with that language, but it doesn't seem obviously wrong.)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29010>
_______________________________________

From report at bugs.python.org  Mon Dec 19 09:00:50 2016
From: report at bugs.python.org (woo yoo)
Date: Mon, 19 Dec 2016 14:00:50 +0000
Subject: [issue29010] Incorrect description about scope related with
 inheritance
In-Reply-To: <1482122733.15.0.137275171819.issue29010@psf.upfronthosting.co.za>
Message-ID: <1482156050.93.0.192500713985.issue29010@psf.upfronthosting.co.za>


woo yoo added the comment:

The previous description about scope classify  it into 3 types explicitly, which means the scope containing the current module's global names is not same as the scope containing built-in names.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29010>
_______________________________________

From report at bugs.python.org  Mon Dec 19 09:15:08 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 19 Dec 2016 14:15:08 +0000
Subject: [issue28950] regrtest: -j0 fails the check -j is not allowed together
 with -T/-l
In-Reply-To: <1481566513.26.0.47817718709.issue28950@psf.upfronthosting.co.za>
Message-ID: <20161219141504.6750.78011.CBCB34FA@psf.io>


Roundup Robot added the comment:

New changeset cf564121f9f0 by Xiang Zhang in branch '3.5':
Issue #28950: Disallow -j0 combined with -T/-l/-M in regrtest.
https://hg.python.org/cpython/rev/cf564121f9f0

New changeset 692834062e80 by Xiang Zhang in branch '3.6':
Issue #28950: Disallow -j0 combined with -T/-l in regrtest.
https://hg.python.org/cpython/rev/692834062e80

New changeset 3b4d00e20694 by Xiang Zhang in branch 'default':
Issue #28950: Merge 3.6.
https://hg.python.org/cpython/rev/3b4d00e20694

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28950>
_______________________________________

From report at bugs.python.org  Mon Dec 19 09:23:12 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 19 Dec 2016 14:23:12 +0000
Subject: [issue28427] WeakValueDictionary next bug (with multithreading)
In-Reply-To: <1476354989.22.0.575160455599.issue28427@psf.upfronthosting.co.za>
Message-ID: <1482157392.46.0.662032568984.issue28427@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

The dict implementation in 3.6 has become very complicated, so I'd like someone to review the attached 3.6 patch. Serhiy, Inada?

----------
nosy: +inada.naoki
Added file: http://bugs.python.org/file45965/issue28427-3.6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28427>
_______________________________________

From report at bugs.python.org  Mon Dec 19 10:38:56 2016
From: report at bugs.python.org (=?utf-8?b?0KHQtdGA0LPQtdC5INCh0L3QtdCz0LjRgNGR0LI=?=)
Date: Mon, 19 Dec 2016 15:38:56 +0000
Subject: [issue29015] re slashes
Message-ID: <1482161936.1.0.52333974721.issue29015@psf.upfronthosting.co.za>


New submission from ?????? ????????:

>>> path
'd:/\\temp\\\\'
>>> pat = '[{}]+'.format(re.escape('\\/'))
>>> re.sub(pat, '\\', path)
Traceback (most recent call last):
  File "<pyshell#78>", line 1, in <module>
    re.sub(pat, '\\', path)
  File "C:\Users\??????\AppData\Local\Programs\Python\Python35\lib\re.py", line 182, in sub
    return _compile(pattern, flags).sub(repl, string, count)
  File "C:\Users\??????\AppData\Local\Programs\Python\Python35\lib\re.py", line 325, in _subx
    template = _compile_repl(template, pattern)
  File "C:\Users\??????\AppData\Local\Programs\Python\Python35\lib\re.py", line 312, in _compile_repl
    p = sre_parse.parse_template(repl, pattern)
  File "C:\Users\??????\AppData\Local\Programs\Python\Python35\lib\sre_parse.py", line 849, in parse_template
    s = Tokenizer(source)
  File "C:\Users\??????\AppData\Local\Programs\Python\Python35\lib\sre_parse.py", line 225, in __init__
    self.__next()
  File "C:\Users\??????\AppData\Local\Programs\Python\Python35\lib\sre_parse.py", line 239, in __next
    self.string, len(self.string) - 1) from None
sre_constants.error: bad escape (end of pattern) at position 0
>>> pat
'[\\\\\\/]+'
>>> 

In JS it works:

> 'd:/\\temp\\\\'.replace(new RegExp('[\\\\\\/]+', 'g'), '\\')
"d:\temp\"

----------
components: Regular Expressions
messages: 283626
nosy: ezio.melotti, mrabarnett, ?????? ????????
priority: normal
severity: normal
status: open
title: re slashes
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29015>
_______________________________________

From report at bugs.python.org  Mon Dec 19 10:57:23 2016
From: report at bugs.python.org (Robert Xiao)
Date: Mon, 19 Dec 2016 15:57:23 +0000
Subject: [issue28927] bytes.fromhex should ignore all whitespace
In-Reply-To: <1481328446.9.0.450435696311.issue28927@psf.upfronthosting.co.za>
Message-ID: <1482163043.07.0.881682680272.issue28927@psf.upfronthosting.co.za>


Robert Xiao added the comment:

OK, I've attached a new version of the patch with the requested documentation changes (versionchanged and whatsnew).

----------
Added file: http://bugs.python.org/file45966/fromhex.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28927>
_______________________________________

From report at bugs.python.org  Mon Dec 19 11:02:01 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 19 Dec 2016 16:02:01 +0000
Subject: [issue29015] re slashes
In-Reply-To: <1482161936.1.0.52333974721.issue29015@psf.upfronthosting.co.za>
Message-ID: <1482163321.69.0.0905111341732.issue29015@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There is a problem with your replacement template. Python string literal '\\' is Python string containing a single backslash character. But backslash has special meaning in a replacement template, it starts escapes and backreferences. For using a literal backslash, it should be escaped: r'\\' or '\\\\'.

>>> re.sub(pat, r'\\', path)
'd:\\temp\\'

----------
nosy: +serhiy.storchaka
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29015>
_______________________________________

From report at bugs.python.org  Mon Dec 19 11:14:50 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 19 Dec 2016 16:14:50 +0000
Subject: [issue28158] Implement LOAD_GLOBAL opcode cache
In-Reply-To: <1473886080.87.0.000411119678127.issue28158@psf.upfronthosting.co.za>
Message-ID: <1482164090.22.0.147359306241.issue28158@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> As far as I look quickly, #10401 uses namei as cache key
and this patch uses opcode index as cache key, am I right?

Correct.  Actually, if you don't mind, I'd like to update the patch myself. I have a few ideas how to restructure it and add support for LOAD_ATTR.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28158>
_______________________________________

From report at bugs.python.org  Mon Dec 19 11:21:11 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 19 Dec 2016 16:21:11 +0000
Subject: [issue28950] regrtest: -j0 fails the check -j is not allowed together
 with -T/-l
In-Reply-To: <1481566513.26.0.47817718709.issue28950@psf.upfronthosting.co.za>
Message-ID: <1482164471.83.0.0538315597278.issue28950@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Thanks Victor. 2.7 is not affected since in 2.7 -j0 does not spawn processes.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28950>
_______________________________________

From report at bugs.python.org  Mon Dec 19 11:33:26 2016
From: report at bugs.python.org (Robert Xiao)
Date: Mon, 19 Dec 2016 16:33:26 +0000
Subject: [issue28927] bytes.fromhex should ignore all whitespace
In-Reply-To: <1481328446.9.0.450435696311.issue28927@psf.upfronthosting.co.za>
Message-ID: <1482165206.42.0.978222755736.issue28927@psf.upfronthosting.co.za>


Robert Xiao added the comment:

New patch with proper line lengths in documentation.

----------
Added file: http://bugs.python.org/file45967/fromhex.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28927>
_______________________________________

From report at bugs.python.org  Mon Dec 19 11:37:46 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 19 Dec 2016 16:37:46 +0000
Subject: [issue28927] bytes.fromhex should ignore all whitespace
In-Reply-To: <1481328446.9.0.450435696311.issue28927@psf.upfronthosting.co.za>
Message-ID: <1482165466.59.0.301255873019.issue28927@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM.

----------
assignee:  -> serhiy.storchaka
components: +Interpreter Core
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28927>
_______________________________________

From report at bugs.python.org  Mon Dec 19 11:52:12 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 19 Dec 2016 16:52:12 +0000
Subject: [issue28927] bytes.fromhex should ignore all whitespace
In-Reply-To: <1481328446.9.0.450435696311.issue28927@psf.upfronthosting.co.za>
Message-ID: <20161219165209.34378.77717.B09385F7@psf.io>


Roundup Robot added the comment:

New changeset fcc09d9ee7d4 by Serhiy Storchaka in branch 'default':
Issue #28927: bytes.fromhex() and bytearray.fromhex() now ignore all ASCII
https://hg.python.org/cpython/rev/fcc09d9ee7d4

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28927>
_______________________________________

From report at bugs.python.org  Mon Dec 19 11:53:57 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 19 Dec 2016 16:53:57 +0000
Subject: [issue28927] bytes.fromhex should ignore all whitespace
In-Reply-To: <1481328446.9.0.450435696311.issue28927@psf.upfronthosting.co.za>
Message-ID: <1482166437.75.0.61280436334.issue28927@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your contribution Robert.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28927>
_______________________________________

From report at bugs.python.org  Mon Dec 19 12:31:43 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 19 Dec 2016 17:31:43 +0000
Subject: [issue29014] Python 3.5.2 installer doesn't register IDLE .py
 extensions on Windows 10
In-Reply-To: <1482147098.02.0.695368643489.issue29014@psf.upfronthosting.co.za>
Message-ID: <1482168703.29.0.317272837399.issue29014@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

.py files are not 'IDLE based', even if edited with IDLE.  They are Python files and should normally be registered to run with Python directly, and not via IDLE.

The right click context menu *should* include "Edit with IDLE".  I have re-marked this issue for that problem, though I believe there is another issue about this.  I have Win 10 also and I have "Edit with IDLE >" which open submenu containing "Edit with IDLE 3.5 (64 bit)" and "Edit with IDLE 3.6 (64 bit)".  This is a Windows installer issue, not an IDLE issue per se.

I don't understand "And when I try to choose the IDLE application, it just defaults to the command line version every time".  If you mean that clicking the IDLE entry in the start menu brings up console Python, then something went wrong in your installation process.  Have you tried re-installing?  Are there any error messages while installing?

----------
assignee: terry.reedy -> 
components: +Installation, Windows -IDLE
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29014>
_______________________________________

From report at bugs.python.org  Mon Dec 19 12:35:02 2016
From: report at bugs.python.org (Robin W Gambill)
Date: Mon, 19 Dec 2016 17:35:02 +0000
Subject: [issue29016] negative numbers raised to power zero should be 1, not -1
Message-ID: <1482168902.44.0.695125384594.issue29016@psf.upfronthosting.co.za>


Changes by Robin W Gambill <r_w_gambill at yahoo.com>:


----------
components: Interpreter Core
nosy: rwgambill
priority: normal
severity: normal
status: open
title: negative numbers raised to power zero should be 1, not -1
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29016>
_______________________________________

From report at bugs.python.org  Mon Dec 19 12:51:56 2016
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 19 Dec 2016 17:51:56 +0000
Subject: [issue28147] Unbounded memory growth resizing split-table dicts
In-Reply-To: <1473853453.13.0.556951743271.issue28147@psf.upfronthosting.co.za>
Message-ID: <1482169916.38.0.661882705898.issue28147@psf.upfronthosting.co.za>


Changes by INADA Naoki <songofacandy at gmail.com>:


Added file: http://bugs.python.org/file45968/fix-28147-py35-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28147>
_______________________________________

From report at bugs.python.org  Mon Dec 19 12:51:57 2016
From: report at bugs.python.org (Tim Peters)
Date: Mon, 19 Dec 2016 17:51:57 +0000
Subject: [issue29016] negative numbers raised to power zero should be 1, not -1
Message-ID: <1482169917.77.0.870171182512.issue29016@psf.upfronthosting.co.za>


New submission from Tim Peters:

They already are.

>>> (-2)**0
1

You're probably doing this instead:

>>> -2**0
-1

Exponentiation has higher precedence than unary minus, so that last example groups as -(2**0), and -1 is correct.

----------
nosy: +tim.peters
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29016>
_______________________________________

From report at bugs.python.org  Mon Dec 19 12:59:59 2016
From: report at bugs.python.org (Robin W Gambill)
Date: Mon, 19 Dec 2016 17:59:59 +0000
Subject: [issue29016] negative numbers raised to power zero should be 1, not -1
In-Reply-To: <1482169917.77.0.870171182512.issue29016@psf.upfronthosting.co.za>
Message-ID: <926659831.1732571.1482170185282@mail.yahoo.com>


Robin W Gambill added the comment:

I see my error now. I'm sorry for my ignorance. I will google how to delete the bugs item, but I guess is permanent, se la vie.
Thank you.
Robin
--------------------------------------------
On Mon, 12/19/16, Tim Peters <report at bugs.python.org> wrote:

 Subject: [issue29016] negative numbers raised to power zero should be 1, not -1
 To: r_w_gambill at yahoo.com
 Date: Monday, December 19, 2016, 12:51 PM

 New submission from Tim Peters:

 They already are.

 >>> (-2)**0
 1

 You're probably doing this instead:

 >>> -2**0
 -1

 Exponentiation has higher precedence than unary minus, so
 that last example groups as -(2**0), and -1 is correct.

 ----------
 nosy: +tim.peters
 resolution:? -> not a bug
 stage:? -> resolved
 status: open -> closed

 _______________________________________
 Python tracker <report at bugs.python.org>
 <http://bugs.python.org/issue29016>
 _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29016>
_______________________________________

From report at bugs.python.org  Mon Dec 19 13:01:09 2016
From: report at bugs.python.org (12345 67890)
Date: Mon, 19 Dec 2016 18:01:09 +0000
Subject: [issue20486] msilib: can't close opened database
In-Reply-To: <1391355449.68.0.999858284587.issue20486@psf.upfronthosting.co.za>
Message-ID: <1482170469.71.0.845098969522.issue20486@psf.upfronthosting.co.za>


12345 67890 added the comment:

This is still present in Python 3.5. There is no way to unlock the MSI file without killing the Python process first.

----------
nosy: +12345 67890
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20486>
_______________________________________

From report at bugs.python.org  Mon Dec 19 13:13:34 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 19 Dec 2016 18:13:34 +0000
Subject: [issue28927] bytes.fromhex should ignore all whitespace
In-Reply-To: <1481328446.9.0.450435696311.issue28927@psf.upfronthosting.co.za>
Message-ID: <1482171214.01.0.565493463965.issue28927@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I think non-ASCII whitespace and digits are YAGNI until we are convinced otherwise by evidence from the field that people are routinely mixing other decimal digits with 'abcdef' as hex numerals.  Anyone who does try such a thing can write a wrapper that first translates to ascii digits.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28927>
_______________________________________

From report at bugs.python.org  Mon Dec 19 13:15:15 2016
From: report at bugs.python.org (Steve Dower)
Date: Mon, 19 Dec 2016 18:15:15 +0000
Subject: [issue29014] Python 3.5.2 installer doesn't register IDLE .py
 extensions on Windows 10
In-Reply-To: <1482147098.02.0.695368643489.issue29014@psf.upfronthosting.co.za>
Message-ID: <1482171315.79.0.904936345578.issue29014@psf.upfronthosting.co.za>


Steve Dower added the comment:

I'm not familiar with any of the other proposed solutions - could you link to a few?

One important factor is that you need to install the Python Launcher to get the context menus (this is the default in 3.5 and later). Associating directly to the Python installation just causes conflicts when you install another version, so we set them up via the launcher instead. In effect, the launcher is the integration point between Windows Explorer and Python, and without it you only get the shortcuts.

Installing Python 2.7 and leaving the "Register Extensions" option selected will overwrite the context menu from Python 3.5 or later. So if you've installed 2.7 after 3.5 then I would strongly recommend running a Repair of 3.5.

Otherwise, answers to Terry's questions would also be helpful. It isn't entirely clear how you are "choos[ing] the IDLE application", or if the installations were successful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29014>
_______________________________________

From report at bugs.python.org  Mon Dec 19 13:20:55 2016
From: report at bugs.python.org (Steve Dower)
Date: Mon, 19 Dec 2016 18:20:55 +0000
Subject: [issue20486] msilib: can't close opened database
In-Reply-To: <1391355449.68.0.999858284587.issue20486@psf.upfronthosting.co.za>
Message-ID: <1482171655.26.0.346936664461.issue20486@psf.upfronthosting.co.za>


Steve Dower added the comment:

Guessing the msiobj_close function in PC/_msi.c ought to be exposed. 

Patches welcome.

----------
keywords: +easy
priority: normal -> low
stage:  -> needs patch
versions: +Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20486>
_______________________________________

From report at bugs.python.org  Mon Dec 19 13:25:24 2016
From: report at bugs.python.org (Ned Deily)
Date: Mon, 19 Dec 2016 18:25:24 +0000
Subject: [issue25617] Installing local installation of Python
In-Reply-To: <1447426322.89.0.546978633067.issue25617@psf.upfronthosting.co.za>
Message-ID: <1482171924.43.0.441101069151.issue25617@psf.upfronthosting.co.za>


Ned Deily added the comment:

Perhaps the issue here is that you are installing a local version of Python with the same configured prefix as a system installed Python of the same major version.  This is a primary use of the --prefix option to the ./configure script of Python.  You should ensure that each Python x.y instance is built and installed with unique values for --prefix; that should ensure that there is no conflict among those instances with regard to their "global" file paths.  That said, there can still be conflicts with --user locations where the same user-specific paths are used by all instances of a particular Python major version.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25617>
_______________________________________

From report at bugs.python.org  Mon Dec 19 13:32:45 2016
From: report at bugs.python.org (eryk sun)
Date: Mon, 19 Dec 2016 18:32:45 +0000
Subject: [issue29014] Python 3.5.2 installer doesn't register IDLE .py
 extensions on Windows 10
In-Reply-To: <1482147098.02.0.695368643489.issue29014@psf.upfronthosting.co.za>
Message-ID: <1482172365.4.0.370819350011.issue29014@psf.upfronthosting.co.za>


eryk sun added the comment:

It looks like you've accidentally created and selected an auto-generated association between .py and python.exe. You should be able to restore the original file association to get the "Edit with IDLE" menu back. In Windows 10 the "open with" menu has an option to "choose another app". In the dialog select "always use this app to open .py files". Or go to the control panel's "default programs" app, and choose "associate a file type" and double click on ".py" in the list. Either way, select the "Python" entry with a rocket on the icon. Hopefully this selects the "Python.File" ProgId that was configured by Python's installer.

What we're trying to do here is modify the contents of the registry key "HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.py\UserChoice". Python's installer doesn't have anything to do with this key. It's based on what the user selects in Explorer, and it's intentionally difficult for code to directly modify this key. It's protected by an access control entry that denies the user (i.e. programs running as the user) the right to modify the key directly, plus a hash of the user's selection. But one thing you can still do is to delete the key, which will restore the default user and system file association.

----------
nosy: +eryk sun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29014>
_______________________________________

From report at bugs.python.org  Mon Dec 19 13:45:51 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 19 Dec 2016 18:45:51 +0000
Subject: [issue28147] Unbounded memory growth resizing split-table dicts
In-Reply-To: <1482169916.44.0.286516869527.issue28147@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZa7Ly=qt8GX5VcAu125VQqie4k68kc+ypEusqwE=T3SQ@mail.gmail.com>


STINNER Victor added the comment:

The 3.5 patch LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28147>
_______________________________________

From report at bugs.python.org  Mon Dec 19 14:02:44 2016
From: report at bugs.python.org (Eric Lafontaine)
Date: Mon, 19 Dec 2016 19:02:44 +0000
Subject: [issue28879] smtplib send_message should add Date header if it is
 missing, per RFC5322
In-Reply-To: <1480952895.22.0.418354723664.issue28879@psf.upfronthosting.co.za>
Message-ID: <1482174164.12.0.662568463154.issue28879@psf.upfronthosting.co.za>


Eric Lafontaine added the comment:

Hi all,

@David, the "Resent-" block should be added by the user and he needs to know what he's doing.  Hell, I work with emails all the time and never knew about this.  The Worse part of it is that I have to communicate with the IETF just to know how we can do the rules... that doesn't mean another programmer didn't interpret it wrong...

@Henning, this is my first contribution :P  I've just been brain-washed by Raymond Hettinger and his beautifuls speechs.  I suggest (no shame plug) you look at the first 5-6 videos of the following link if you got free time.  https://www.youtube.com/playlist?list=PLRVdut2KPAguz3xcd22i_o_onnmDKj3MA

I've received his "call to arms" ; https://www.youtube.com/watch?v=-TdrFjDJn5E&list=PLRVdut2KPAguz3xcd22i_o_onnmDKj3MA&index=16 

David, I said the API was awkward because of what is mention in this latest link.  I really believe we ought to change it ASAP if it's possible at all and make it more like sendmail... that's only an opinion though.  https://youtu.be/-TdrFjDJn5E?list=PLRVdut2KPAguz3xcd22i_o_onnmDKj3MA&t=4231

Finally, Could I know how to modify the Doc of the Python2 ? 
Regards,
Eric Lafontaine


- Implement a patch for the code to add a missing "Date" field if it doesn't exist .   (in review)
- Modify the documentation at the SMTPLib for the send_message to mention that it add missing date using the email.utils.formatdate (in review)
- Modify the comment of the send_message code to mention RFC 5322 in there (ideally with the section of the RFC).  (in review)
- Modify the example of Python 2 to present a RFC 5322 examples

----------
Added file: http://bugs.python.org/file45969/issue_28879_V4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28879>
_______________________________________

From report at bugs.python.org  Mon Dec 19 14:03:48 2016
From: report at bugs.python.org (Ettore Atalan)
Date: Mon, 19 Dec 2016 19:03:48 +0000
Subject: [issue29017] Docs: PySide is provided by 'The Qt Company' and not by
 'Nokia'
Message-ID: <1482174228.93.0.510062905066.issue29017@psf.upfronthosting.co.za>


New submission from Ettore Atalan:

Regarding
URL: http://docs.python.org/3/library/othergui.html
Section: PySide

PySide is provided by 'The Qt Company' and no longer by 'Nokia' like mentioned in the documentation.

----------
assignee: docs at python
components: Documentation
messages: 283646
nosy: Ettore Atalan, docs at python
priority: normal
severity: normal
status: open
title: Docs: PySide is provided by 'The Qt Company' and not by 'Nokia'
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29017>
_______________________________________

From report at bugs.python.org  Mon Dec 19 14:46:49 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 19 Dec 2016 19:46:49 +0000
Subject: [issue28879] smtplib send_message should add Date header if it is
 missing, per RFC5322
In-Reply-To: <1480952895.22.0.418354723664.issue28879@psf.upfronthosting.co.za>
Message-ID: <1482176809.14.0.449330157037.issue28879@psf.upfronthosting.co.za>


R. David Murray added the comment:

The documentation is all in the Doc subdirectory of the checkout.

So, this should teach me to rely on vague memory instead of reading the code.  I've probably still missed something because I don't have enough time to read it properly.

Yes, you are correct, the Resent headers need to be added by the user.  So adding a Resent-Date header is the only question, and we can assume that it should go before the first Resent-X header we find.

Here is my reconstruction of why I made that restriction and comment:  There is no specified order to the Resent- block headers.  So how do we know where the first block ends and the next begins?  It will almost always be at the Resent-Date header...but we can't assume that that will *always* be true.

For sendmail/send_message, I'm not going to look at a youtube video, so you'll have to make your argument in text :)  But you may not want to bother, it is indeed too late: we can't change the signature for backward compatibility reasons.  In any case IMO the signature is optimal as it is: the only required argument is msg, and that, therefore, has to come first.  Otherwise the arguments are already in the same order as they are for sendmail.

I spent a lot of time reading RFCs while working on these libraries, but it has been a while since my head was buried in that space :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28879>
_______________________________________

From report at bugs.python.org  Mon Dec 19 14:53:09 2016
From: report at bugs.python.org (12345 67890)
Date: Mon, 19 Dec 2016 19:53:09 +0000
Subject: [issue20486] msilib: can't close opened database
In-Reply-To: <1391355449.68.0.999858284587.issue20486@psf.upfronthosting.co.za>
Message-ID: <1482177189.6.0.918844059769.issue20486@psf.upfronthosting.co.za>


12345 67890 added the comment:

I will prefix this by saying that I have not contributed to the Python source before and this patch is probably wrong, but here is my attempt at a fix.

----------
Added file: http://bugs.python.org/file45970/_msi.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20486>
_______________________________________

From report at bugs.python.org  Mon Dec 19 15:29:55 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 19 Dec 2016 20:29:55 +0000
Subject: [issue25677] Syntax error caret confused by indentation
In-Reply-To: <1447998656.06.0.471632717786.issue25677@psf.upfronthosting.co.za>
Message-ID: <1482179395.01.0.528445874714.issue25677@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25677>
_______________________________________

From report at bugs.python.org  Mon Dec 19 16:19:44 2016
From: report at bugs.python.org (issuefinder)
Date: Mon, 19 Dec 2016 21:19:44 +0000
Subject: [issue29018] Misinformation when showing how slices work in The
 Tutorial
Message-ID: <1482182384.19.0.82503979706.issue29018@psf.upfronthosting.co.za>


New submission from issuefinder:

In this page:
https://docs.python.org/3/tutorial/introduction.html#strings

When showing how slices work:
+---+---+---+---+---+---+
 | P | y | t | h | o | n |
 +---+---+---+---+---+---+
 0   1   2   3   4   5   6
-6  -5  -4  -3  -2  -1

The accurate matrix is:

+---+---+---+---+---+---+
 | P | y | t | h | o | n |
 +---+---+---+---+---+---+
 0   1   2   3   4   5   6
 0  -6  -5  -4  -3  -2  -1

----------
assignee: docs at python
components: Documentation
messages: 283649
nosy: docs at python, issuefinder
priority: normal
severity: normal
status: open
title: Misinformation when showing how slices work in The Tutorial
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29018>
_______________________________________

From report at bugs.python.org  Mon Dec 19 16:23:09 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 19 Dec 2016 21:23:09 +0000
Subject: [issue29014] Python 3.5.2 installer doesn't register IDLE .py
 extensions on Windows 10
In-Reply-To: <1482147098.02.0.695368643489.issue29014@psf.upfronthosting.co.za>
Message-ID: <1482182589.67.0.109156655677.issue29014@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Here is another possible reason (and cure) for intentionally installed  python to not work.  Just posted to Python list.

"Turns out that another instance of Python *was* installed, not as part of OEM software, but by a digital camera (Califone) that is being used in some of our classrooms.  The suggestion to look for environmental variables was the key  -  on the PCs where we were having the problem, there was a variable starting with PYTHON ... which pointed to the camera software.  Once the camera was uninstalled, Python 3.5.2 worked just fine."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29014>
_______________________________________

From report at bugs.python.org  Mon Dec 19 16:38:33 2016
From: report at bugs.python.org (Eric Lafontaine)
Date: Mon, 19 Dec 2016 21:38:33 +0000
Subject: [issue28945] get_boundary invokes unquote twice
In-Reply-To: <1481547297.88.0.91240101349.issue28945@psf.upfronthosting.co.za>
Message-ID: <1482183513.75.0.899214043444.issue28945@psf.upfronthosting.co.za>


Eric Lafontaine added the comment:

Hi all,

I believe this is the right behavior and what ever generated the boundary "<<>>" is the problem ; 


RFC  2046 page 22:
_____________________
The only mandatory global parameter for the "multipart" media type is the boundary parameter, which consists of 1 to 70 characters from a set of characters known to be very robust through mail gateways, and NOT ending with white space. (If a boundary delimiter line appears to end with white space, the white space must be presumed to have been added by a gateway, and must be deleted.)  It is formally specified by the following BNF:

     boundary := 0*69<bchars> bcharsnospace

     bchars := bcharsnospace / " "

     bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" /
                      "+" / "_" / "," / "-" / "." /
                      "/" / ":" / "=" / "?"
_____________________
In other words, the only valid boundaries characters are :
01234567890 abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ'()+_,-./:=?

Any other character should be removed to get the boundary right.  I believe the issue is that it wasn't removed in the first place.  It is a bug in my opinion, but the other way around :).

Funny thing is that the unquote function only remove the first&last character it sees... either '<' and the '"'...

def unquote(str):
    """Remove quotes from a string."""
    if len(str) > 1:
        if str.startswith('"') and str.endswith('"'):
            return str[1:-1].replace('\\\\', '\\').replace('\\"', '"')
        if str.startswith('<') and str.endswith('>'):
            return str[1:-1]
    return str

Now, if I modify unquote to only keep the list of character above, would I break something? Probably. 
I haven't found any other defining RFC about boundaries that tells me what was the format supported.  Can someone help me on that?

This is what the function should look like :

import string
def get_boundary(str):
    """ return the valid boundary parameter as per RFC 2046 page 22. """
    if len(str) > 1:
        import re
        return re.sub('[^'+
                      string.ascii_letters +
                      string.digits +
                      r""" '()+_,-./:=?]|="""
                      ,'',str
                      ).rstrip(' ')
    return str

import unittest

class boundary_tester(unittest.TestCase):
    def test_get_boundary(self):
        boundary1 = """ abc def gh< 123 >!@ %!%' """
        ref_boundary1 = """ abc def gh 123  '""" # this is the valid Boundary
        ret_value = get_boundary(boundary1)
        self.assertEqual(ret_value,ref_boundary1)

    def test_get_boundary2(self):
        boundary1 = ''.join((' ',string.printable))
        ref_boundary1 = ' 0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ\'()+,-./:?_' # this is the valid Boundary
        ret_value = get_boundary(boundary1)
        self.assertEqual(ret_value,ref_boundary1)


I believe this should be added to the email.message.Message get_boundary function.  

Regards,
Eric Lafontaine

----------
nosy: +Eric Lafontaine

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28945>
_______________________________________

From report at bugs.python.org  Mon Dec 19 16:55:01 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 19 Dec 2016 21:55:01 +0000
Subject: [issue29018] Misinformation when showing how slices work in The
 Tutorial
In-Reply-To: <1482182384.19.0.82503979706.issue29018@psf.upfronthosting.co.za>
Message-ID: <1482184501.38.0.180652957352.issue29018@psf.upfronthosting.co.za>


R. David Murray added the comment:

If your version was correct, 'python'[-2:] would produce 'n', which is not what it produces.  Perhaps you being confused by the fact that the diagram is pointing the indexes *between* the characters?  That's the point of the mnemonic and I find it very useful to think of it that way, myself.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29018>
_______________________________________

From report at bugs.python.org  Mon Dec 19 17:10:56 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Mon, 19 Dec 2016 22:10:56 +0000
Subject: [issue20486] msilib: can't close opened database
In-Reply-To: <1391355449.68.0.999858284587.issue20486@psf.upfronthosting.co.za>
Message-ID: <1482185456.8.0.695190578116.issue20486@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20486>
_______________________________________

From report at bugs.python.org  Mon Dec 19 17:26:21 2016
From: report at bugs.python.org (12345 67890)
Date: Mon, 19 Dec 2016 22:26:21 +0000
Subject: [issue20486] msilib: can't close opened database
In-Reply-To: <1391355449.68.0.999858284587.issue20486@psf.upfronthosting.co.za>
Message-ID: <1482186381.92.0.211058782066.issue20486@psf.upfronthosting.co.za>


Changes by 12345 67890 <xoviat at gmail.com>:


Removed file: http://bugs.python.org/file45970/_msi.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20486>
_______________________________________

From report at bugs.python.org  Mon Dec 19 17:26:46 2016
From: report at bugs.python.org (12345 67890)
Date: Mon, 19 Dec 2016 22:26:46 +0000
Subject: [issue20486] msilib: can't close opened database
In-Reply-To: <1391355449.68.0.999858284587.issue20486@psf.upfronthosting.co.za>
Message-ID: <1482186406.57.0.802167498884.issue20486@psf.upfronthosting.co.za>


Changes by 12345 67890 <xoviat at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file45971/Add_ability_to_close_MSI_database_.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20486>
_______________________________________

From report at bugs.python.org  Mon Dec 19 18:24:11 2016
From: report at bugs.python.org (Gaurav Tatke)
Date: Mon, 19 Dec 2016 23:24:11 +0000
Subject: [issue21150] Add quick links table to argparse docs
In-Reply-To: <1396558035.28.0.485991636726.issue21150@psf.upfronthosting.co.za>
Message-ID: <1482189851.75.0.675054426771.issue21150@psf.upfronthosting.co.za>


Gaurav Tatke added the comment:

Hello All,

I would like to help with this issue. I am a beginner. I am attaching a 'SampleOfSummaryTable.PNG' file which I think is one way of organizing summary table.

I think if we put quick links of function parameters in summary table then it will make existing parameter quick links above detailed summary of each parameter as redundant.

Please let me know if this is okay.

----------
nosy: +Gaurav Tatke
Added file: http://bugs.python.org/file45972/SampleOfSummaryTable.PNG

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21150>
_______________________________________

From report at bugs.python.org  Mon Dec 19 18:29:42 2016
From: report at bugs.python.org (Rasmus Villemoes)
Date: Mon, 19 Dec 2016 23:29:42 +0000
Subject: [issue29019] dict.fromkeys overallocates when given a sparse dict
Message-ID: <1482190182.71.0.221629635951.issue29019@psf.upfronthosting.co.za>


New submission from Rasmus Villemoes:

Somewhat related to #23971, but with the opposite sign: Using Py_SIZE on a PyDictObject gives the ma_fill member in 2.7 (and until 3.2 AFAICT), not the ma_used member. So calling dict.fromkeys(d) overallocates significantly if a lot of elements have been deleted from d.

The fix is trivial, though one could of course avoid the function call and do a cast. Not sure this qualifies for 2.7, though.

----------
components: Interpreter Core
files: fromkeys.patch
keywords: patch
messages: 283654
nosy: villemoes
priority: normal
severity: normal
status: open
title: dict.fromkeys overallocates when given a sparse dict
type: resource usage
versions: Python 2.7
Added file: http://bugs.python.org/file45973/fromkeys.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29019>
_______________________________________

From report at bugs.python.org  Mon Dec 19 18:37:31 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 19 Dec 2016 23:37:31 +0000
Subject: [issue29018] Misinformation when showing how slices work in The
 Tutorial
In-Reply-To: <1482182384.19.0.82503979706.issue29018@psf.upfronthosting.co.za>
Message-ID: <1482190651.28.0.837724845307.issue29018@psf.upfronthosting.co.za>


Steven D'Aprano added the comment:

You haven't given any reason to explain why you think the existing docs are wrong, nor any reason why you think your version is better. Just stating that the docs give "misinformation" is not good enough.

By your matrix, 'Python'[0:-1] should take a slice starting from the left of 'P' and ending at the *right* of 'n', returning 'Python' unchanged. According to the original, documented matrix, 'Python'[0:-1] takes a slice starting at the left of 'P' and ending at the *left* of 'n', returning 'Pytho'. without the n, which is what actually does happen.

You should also consider the slice 'Python'[-6:-5] according to the documented matrix (returns 'P') and your matrix (returns 'y').

----------
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29018>
_______________________________________

From report at bugs.python.org  Mon Dec 19 19:20:28 2016
From: report at bugs.python.org (bpoaugust)
Date: Tue, 20 Dec 2016 00:20:28 +0000
Subject: [issue28945] get_boundary invokes unquote twice
In-Reply-To: <1481547297.88.0.91240101349.issue28945@psf.upfronthosting.co.za>
Message-ID: <1482193228.76.0.0568395314197.issue28945@psf.upfronthosting.co.za>


bpoaugust added the comment:

I agree that strictly speaking the boundary is invalid.
However:
'Be strict in what you generate, be liberal in what you accept'
The mail package should never create such boundaries.
However it should process them if possible.

If the boundary definition is mangled by stripping out all the invalid characters, then it won't match the markers. So it won't solve the issue.

Whereas ensuring that only a single level of quotes is removed does fix the issue.

This is what works for me:

def get_boundary(self, failobj=None):
    missing = object()
    # get_param removes the outer quotes
    boundary = self.get_param('boundary', missing)
    if boundary is missing:
        return failobj
    # Don't unquote again in collapse_rfc2231_value
    if not isinstance(boundary, tuple) or len(boundary) != 3:
        return boundary
    # RFC 2046 says that boundaries may begin but not end in w/s
    return utils.collapse_rfc2231_value(boundary).rstrip()

I think the bug is actually in collapse_rfc2231_value - that should not do any unquoting, as the value will be passed to it already unquoted (at least in this case). However there might perhaps be some cases where collapse_rfc2231_value is called with a quoted value, so to fix the immediate problem it's safer to fix get_boundary. (I could have re-quoted the value instead, and let collapse_rfc2231_value do its thing.)

unquote is correct as it stands - it should only remove the outer quotes. There may be a need to quote strings that just happen to be enclosed in quote chars.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28945>
_______________________________________

From report at bugs.python.org  Mon Dec 19 19:22:47 2016
From: report at bugs.python.org (Javier Domingo)
Date: Tue, 20 Dec 2016 00:22:47 +0000
Subject: [issue26467] Add async magic method support to unittest.mock.Mock
In-Reply-To: <1456872706.59.0.97059255221.issue26467@psf.upfronthosting.co.za>
Message-ID: <1482193367.79.0.872961853516.issue26467@psf.upfronthosting.co.za>


Javier Domingo added the comment:

I found this while trying to test an async context manager. This is a critical feature to enable migrations to async code, as the impossibility to test something properly is not acceptable in many environments.

Implementing it in a way that __call__ returns an object capable of being coroutine or normal function would avoid having to implement Async specific Mocks, wouldn't it? I am not too confident, but would it be doable to have an implementation that depends on whether _is_coroutine is accessed or not?

I don't like it, but I really don't like the fact that we need to patch different all the methods depending on whether they are coroutine or not.

Obviously, having the __acall__ method would really help solving this issue.

----------
nosy: +txomon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26467>
_______________________________________

From report at bugs.python.org  Mon Dec 19 19:30:12 2016
From: report at bugs.python.org (bpoaugust)
Date: Tue, 20 Dec 2016 00:30:12 +0000
Subject: [issue29020] collapse_rfc2231_value has inconsistent unquoting
Message-ID: <1482193812.46.0.729778317823.issue29020@psf.upfronthosting.co.za>


New submission from bpoaugust:

collapse_rfc2231_value unquotes the value before returning it except here:

rawbytes = bytes(text, 'raw-unicode-escape')
return str(rawbytes, charset, errors)

Why is the text not unquoted in this case?

Actually I wonder whether the function should do any unquoting at all.
There is at least one case where it is called with an already unquoted value (get_boundary, see issue28945).

But if it is intended to do unquoting, it should be consistent.

----------
components: email
messages: 283658
nosy: barry, bpoaugust, r.david.murray
priority: normal
severity: normal
status: open
title: collapse_rfc2231_value has inconsistent unquoting
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29020>
_______________________________________

From report at bugs.python.org  Mon Dec 19 19:30:31 2016
From: report at bugs.python.org (bpoaugust)
Date: Tue, 20 Dec 2016 00:30:31 +0000
Subject: [issue29020] collapse_rfc2231_value has inconsistent unquoting
In-Reply-To: <1482193812.46.0.729778317823.issue29020@psf.upfronthosting.co.za>
Message-ID: <1482193831.69.0.672151396375.issue29020@psf.upfronthosting.co.za>


Changes by bpoaugust <sebbaz+bpo at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29020>
_______________________________________

From report at bugs.python.org  Mon Dec 19 19:54:38 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 20 Dec 2016 00:54:38 +0000
Subject: [issue28147] Unbounded memory growth resizing split-table dicts
In-Reply-To: <1473853453.13.0.556951743271.issue28147@psf.upfronthosting.co.za>
Message-ID: <20161220005434.20642.15362.3DD1A7FB@psf.io>


Roundup Robot added the comment:

New changeset cc40470c10f8 by INADA Naoki in branch '3.5':
Issue #28147: Fix a memory leak in split-table dictionaries
https://hg.python.org/cpython/rev/cc40470c10f8

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28147>
_______________________________________

From report at bugs.python.org  Mon Dec 19 19:55:55 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 20 Dec 2016 00:55:55 +0000
Subject: [issue29011] No entry Deque in typing.py
In-Reply-To: <1482128373.3.0.983889719325.issue29011@psf.upfronthosting.co.za>
Message-ID: <1482195355.35.0.708664302225.issue29011@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I don't recall exactly what happened here, but I think it was left out during formulation of PEP 484 because it's not an ABC.  IIRC originally we only wanted to include builtins and ABCs.  But we changed that subsequently to include e.g. DefaultDict.

I suppose we should change this now, but the cat is out of the bag for 3.6.0 and I would prefer not to change typing.py in any way between 3.6.0 and 3.5.3, so the best we could do would be to add it to 3.6.1 and 3.5.4 (whenever that will be).

In the meantime collections.deque is generic, but that's only helpful in type comments, not in annotations.

In a sense I wish we hadn't put typing.py in the stdlib, it would have been much simpler to fix this kind of issue.  OTOH there are also advantages to having it in the stdlib, and anyways, it's too late to change, so we'll just have to suck it up (I certainly am).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29011>
_______________________________________

From report at bugs.python.org  Mon Dec 19 20:05:08 2016
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 20 Dec 2016 01:05:08 +0000
Subject: [issue28147] Unbounded memory growth resizing split-table dicts
In-Reply-To: <1473853453.13.0.556951743271.issue28147@psf.upfronthosting.co.za>
Message-ID: <1482195908.32.0.839376694468.issue28147@psf.upfronthosting.co.za>


Changes by INADA Naoki <songofacandy at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28147>
_______________________________________

From report at bugs.python.org  Mon Dec 19 22:07:09 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 20 Dec 2016 03:07:09 +0000
Subject: [issue29019] dict.fromkeys overallocates when given a sparse dict
In-Reply-To: <1482190182.71.0.221629635951.issue29019@psf.upfronthosting.co.za>
Message-ID: <1482203229.17.0.451376692995.issue29019@psf.upfronthosting.co.za>


Changes by Xiang Zhang <angwerzx at 126.com>:


----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29019>
_______________________________________

From report at bugs.python.org  Mon Dec 19 22:23:49 2016
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 20 Dec 2016 03:23:49 +0000
Subject: [issue29019] dict.fromkeys overallocates when given a sparse dict
In-Reply-To: <1482190182.71.0.221629635951.issue29019@psf.upfronthosting.co.za>
Message-ID: <1482204229.45.0.312822384477.issue29019@psf.upfronthosting.co.za>


INADA Naoki added the comment:

Since `seq` is checked by PyDict_CheckExact(seq) already,
((PyDictObject*)seq)->ma_used may be better.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29019>
_______________________________________

From report at bugs.python.org  Mon Dec 19 22:34:54 2016
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 20 Dec 2016 03:34:54 +0000
Subject: [issue28158] Implement LOAD_GLOBAL opcode cache
In-Reply-To: <1473886080.87.0.000411119678127.issue28158@psf.upfronthosting.co.za>
Message-ID: <1482204894.28.0.725023343263.issue28158@psf.upfronthosting.co.za>


INADA Naoki added the comment:

>  Actually, if you don't mind, I'd like to update the patch myself. I have a few ideas how to restructure it and add support for LOAD_ATTR.

Sounds interesting.
I'll wait to touch this patch.  There are enough time by Python 3.7
and enough other issues I can work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28158>
_______________________________________

From report at bugs.python.org  Mon Dec 19 22:48:15 2016
From: report at bugs.python.org (woo yoo)
Date: Tue, 20 Dec 2016 03:48:15 +0000
Subject: [issue29010] Incorrect description about scope related with
 inheritance
In-Reply-To: <1482122733.15.0.137275171819.issue29010@psf.upfronthosting.co.za>
Message-ID: <1482205695.46.0.515084664573.issue29010@psf.upfronthosting.co.za>


woo yoo added the comment:

If i was wrong about this issue, please tell me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29010>
_______________________________________

From report at bugs.python.org  Mon Dec 19 23:02:45 2016
From: report at bugs.python.org (David)
Date: Tue, 20 Dec 2016 04:02:45 +0000
Subject: [issue29014] Python 3.5.2 installer doesn't register IDLE .py
 extensions on Windows 10
In-Reply-To: <1482147098.02.0.695368643489.issue29014@psf.upfronthosting.co.za>
Message-ID: <1482206565.93.0.513304565834.issue29014@psf.upfronthosting.co.za>


David added the comment:

I'm going to tackle the questions one-by-one: 

I would like these ".py" files to be IDLE files in the sense that they have the IDLE icon and they open up directly into an idle file with a shell in the background. For context: on my other Windows 10 machine, I've been able to amass a semester's worth of ".py" that are all opened by, and have the icon of, IDLE. 

I have tried to manually associate the ".py" in the "default programs" app with the IDLE application shortcut but to no avail. Instead of opening in IDLE it opens in the command line format (that black python icon). So basically it opens up for a fraction of a second and then closes. No bueno. 

I have tried repairing, installing and reinstalling Python on my machine all with the appropriate settings (and launcher included in all of those tries). No dice. Still no right-click context menu. Still no ability to have ".py" files open up with IDLE. 

Note: I _have_ been able to associate the ".py" extension with "idle.bat" -- this works. But that's not an acceptable workaround. There is something deeper wrong here that I cannot pinpoint. Is it in my installer? I have no idea. I've tried most everything...

Including deleting the UserChoice key/folder/whatever it is and still nothing producing. I even tried "idle.exe" but Windows 10 gives me the error: "This app can't run on your PC -- to find a version for your PC, contact the software publisher." Just great. 

There are no error messages on any install/reinstall/repair that I've managed to try. Everything goes smoothly from start to finish. But the product is broken. 

In addition: I've never programmed in 2.7 and have never installed it on my computer. All of my Python knowledge is based in 3.5.2: it was for a semester-long course. So even the repair that I did run (which didn't work) wouldn't be accounting for any potential conflicts with 2.7. 

Furthermore, I was not able to find a python rocket icon in my files even with hidden items in view so I was not able to complete the ".py" and ".pythonrocketapp" association. However, I did notice in my program/applications folder that Python Launcher was indeed installed on my computer at the very least. 

This is absolutely perplexing and I appreciate all of your help in troubleshooting this. Thank you, and Merry Christmas.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29014>
_______________________________________

From report at bugs.python.org  Mon Dec 19 23:36:23 2016
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 20 Dec 2016 04:36:23 +0000
Subject: [issue29019] dict.fromkeys overallocates when given a sparse dict
In-Reply-To: <1482190182.71.0.221629635951.issue29019@psf.upfronthosting.co.za>
Message-ID: <1482208583.18.0.574283889147.issue29019@psf.upfronthosting.co.za>


INADA Naoki added the comment:

While the patch is trivial, I need LGTM from another comitter.

----------
stage:  -> patch review
Added file: http://bugs.python.org/file45974/fromkeys2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29019>
_______________________________________

From report at bugs.python.org  Mon Dec 19 23:38:29 2016
From: report at bugs.python.org (Brendan Donegan)
Date: Tue, 20 Dec 2016 04:38:29 +0000
Subject: [issue29010] Incorrect description about scope related with
 inheritance
In-Reply-To: <1482205695.46.0.515084664573.issue29010@psf.upfronthosting.co.za>
Message-ID: <CAESAk0gCXmofCNYcSuwOLq_nk1A4QOc2c+02L5h_n_UO41BZ5g@mail.gmail.com>


Brendan Donegan added the comment:

IMO there's no actual bug in Python. Perhaps documentation can be clarified
in a short simple way. I would reiterate the point that restating facts of
the language all over the documentation is not a great idea, but maybe here
the benefits outweigh the drawbacks.

Anyway I think the bug is clear now (it's a docs issue if anything) so I'd
leave it open until someone offers a patch or a strong argument why it
shouldn't be clarified.

On Tue, 20 Dec 2016 at 09:18 woo yoo <report at bugs.python.org> wrote:

>
> woo yoo added the comment:
>
> If i was wrong about this issue, please tell me.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue29010>
> _______________________________________
>

----------
nosy: +brendand

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29010>
_______________________________________

From report at bugs.python.org  Tue Dec 20 00:18:29 2016
From: report at bugs.python.org (woo yoo)
Date: Tue, 20 Dec 2016 05:18:29 +0000
Subject: [issue29010] Incorrect description about scope related with
 inheritance
In-Reply-To: <1482122733.15.0.137275171819.issue29010@psf.upfronthosting.co.za>
Message-ID: <1482211109.51.0.120707397408.issue29010@psf.upfronthosting.co.za>


woo yoo added the comment:

I agree with you

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29010>
_______________________________________

From report at bugs.python.org  Tue Dec 20 00:24:39 2016
From: report at bugs.python.org (Steve Dower)
Date: Tue, 20 Dec 2016 05:24:39 +0000
Subject: [issue29014] Python 3.5.2 installer doesn't register IDLE .py
 extensions on Windows 10
In-Reply-To: <1482147098.02.0.695368643489.issue29014@psf.upfronthosting.co.za>
Message-ID: <1482211479.29.0.0640570098472.issue29014@psf.upfronthosting.co.za>


Steve Dower added the comment:

The Python launcher is the right app to select. Double-clicking .py files has always run them with the interpreter, but you will also get the right-click menu once they are associated with the launcher (this is what I meant by it being the single integration point).

There has never been a time when double-clicking a .py file has opened in IDLE by default after installing any release from python.org. Associating with idle.bat is the best way to achieve this as we do not include any other launcher (and we don't support using idle.bat either, though it should work and we'll try and help you if it doesn't, but it's not a core scenario for the main distribution).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29014>
_______________________________________

From report at bugs.python.org  Tue Dec 20 00:28:12 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 20 Dec 2016 05:28:12 +0000
Subject: [issue29019] dict.fromkeys overallocates when given a sparse dict
In-Reply-To: <1482190182.71.0.221629635951.issue29019@psf.upfronthosting.co.za>
Message-ID: <1482211692.69.0.012918634708.issue29019@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29019>
_______________________________________

From report at bugs.python.org  Tue Dec 20 00:46:17 2016
From: report at bugs.python.org (elemental)
Date: Tue, 20 Dec 2016 05:46:17 +0000
Subject: [issue15729] PyStructSequence_NewType enhancement
In-Reply-To: <1345407378.13.0.964225258094.issue15729@psf.upfronthosting.co.za>
Message-ID: <1482212777.26.0.373801469633.issue15729@psf.upfronthosting.co.za>


Changes by elemental <mar.kazmierczak at gmail.com>:


----------
nosy: +elemental

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15729>
_______________________________________

From report at bugs.python.org  Tue Dec 20 00:48:18 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 20 Dec 2016 05:48:18 +0000
Subject: [issue15729] PyStructSequence_NewType enhancement
In-Reply-To: <1345407378.13.0.964225258094.issue15729@psf.upfronthosting.co.za>
Message-ID: <1482212898.88.0.248351258995.issue15729@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15729>
_______________________________________

From report at bugs.python.org  Tue Dec 20 01:40:33 2016
From: report at bugs.python.org (Manish Singh)
Date: Tue, 20 Dec 2016 06:40:33 +0000
Subject: [issue28968] xml rpc server fails with connection reset by peer error
 no 104
In-Reply-To: <1481709223.17.0.559234955094.issue28968@psf.upfronthosting.co.za>
Message-ID: <1482216033.2.0.147316682047.issue28968@psf.upfronthosting.co.za>


Manish Singh added the comment:

Hi Davud Murray,

Can you reply to above comments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28968>
_______________________________________

From report at bugs.python.org  Tue Dec 20 01:47:05 2016
From: report at bugs.python.org (David)
Date: Tue, 20 Dec 2016 06:47:05 +0000
Subject: [issue29014] Python 3.5.2 installer doesn't register IDLE .py
 extensions on Windows 10
In-Reply-To: <1482147098.02.0.695368643489.issue29014@psf.upfronthosting.co.za>
Message-ID: <1482216425.91.0.438229406194.issue29014@psf.upfronthosting.co.za>


David added the comment:

Thanks for the help Steve, however I cannot find the Python Launcher app anywhere on my computer. Even after repairing/reinstalling. Where might I find this file? What is it called exactly? Much appreciated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29014>
_______________________________________

From report at bugs.python.org  Tue Dec 20 02:07:40 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 20 Dec 2016 07:07:40 +0000
Subject: [issue29019] dict.fromkeys overallocates when given a sparse dict
In-Reply-To: <1482190182.71.0.221629635951.issue29019@psf.upfronthosting.co.za>
Message-ID: <20161220070736.18275.12955.6FF4819C@psf.io>


Roundup Robot added the comment:

New changeset 46e329ef13ae by INADA Naoki in branch '2.7':
Issue #29019: Fix dict.fromkeys(x) overallocates when x is sparce dict.
https://hg.python.org/cpython/rev/46e329ef13ae

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29019>
_______________________________________

From report at bugs.python.org  Tue Dec 20 02:08:22 2016
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 20 Dec 2016 07:08:22 +0000
Subject: [issue29019] dict.fromkeys overallocates when given a sparse dict
In-Reply-To: <1482190182.71.0.221629635951.issue29019@psf.upfronthosting.co.za>
Message-ID: <1482217702.74.0.74568829455.issue29019@psf.upfronthosting.co.za>


Changes by INADA Naoki <songofacandy at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29019>
_______________________________________

From report at bugs.python.org  Tue Dec 20 02:57:37 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 20 Dec 2016 07:57:37 +0000
Subject: [issue28932] Fail compile Python 3.6.0rc1 on OpenBSD 6.0
In-Reply-To: <1481388547.33.0.916805591486.issue28932@psf.upfronthosting.co.za>
Message-ID: <20161220075733.20315.43985.AC822FEB@psf.io>


Roundup Robot added the comment:

New changeset 2f004cc84153 by Benjamin Peterson in branch '3.5':
add a specific configure check for sys/random.h (closes #28932)
https://hg.python.org/cpython/rev/2f004cc84153

New changeset bfd4140d9c5d by Benjamin Peterson in branch '3.6':
merge 3.5 (#28932)
https://hg.python.org/cpython/rev/bfd4140d9c5d

New changeset 31df7d9863f3 by Benjamin Peterson in branch 'default':
merge 3.6 (#28932)
https://hg.python.org/cpython/rev/31df7d9863f3

New changeset 32cc37a89b58 by Benjamin Peterson in branch '2.7':
add a specific configure check for sys/random.h (closes #28932)
https://hg.python.org/cpython/rev/32cc37a89b58

----------
nosy: +python-dev
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28932>
_______________________________________

From report at bugs.python.org  Tue Dec 20 04:24:51 2016
From: report at bugs.python.org (Ingo Ruhnke)
Date: Tue, 20 Dec 2016 09:24:51 +0000
Subject: [issue29021] Custom functions in sqlite receive None on invalid UTF-8
Message-ID: <1482225891.27.0.11020777474.issue29021@psf.upfronthosting.co.za>


New submission from Ingo Ruhnke:

When a sqlite database contains invalid UTF-8 code in a TEXT column, Python can query that data normally when .text_factory is set appropriately. However when a custom function is created with .create_function() and applied to that column the custom function will receive 'None' as argument instead of the value of the column.

The following example demonstrate the issue:

Example:
--------

import sqlite3
import sys
import os

con = sqlite3.connect(":memory:")
con.text_factory = os.fsdecode

con.create_function("py_identity", 1, lambda x: x)

cur = con.cursor()
cur.execute("CREATE TABLE foo(bar TEXT)")

# insert some invalid UTF-8 into the database
cur.execute("INSERT INTO foo(bar) VALUES(cast(? AS TEXT))", [b"\xff"])

# try to call a custom function on the invalid UTF-8
cur.execute("SELECT "
            "  typeof(bar), "
            "  bar, " # this works
            "  py_identity(bar), " # this returns None instead of the content of 'bar'
            "  cast(py_identity(cast(bar as BLOB)) AS TEXT) " # this works around the issue
            "FROM foo")

for row in cur:
    print(row)

Output:
-------

('text', '\udcff', None, '\udcff')


Expected:
---------

('text', '\udcff', '\udcff', '\udcff')

----------
components: Library (Lib)
messages: 283674
nosy: Ingo Ruhnke
priority: normal
severity: normal
status: open
title: Custom functions in sqlite receive None on invalid UTF-8
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29021>
_______________________________________

From report at bugs.python.org  Tue Dec 20 04:26:54 2016
From: report at bugs.python.org (Armin Rigo)
Date: Tue, 20 Dec 2016 09:26:54 +0000
Subject: [issue29006] 2.7.13 _sqlite more prone to "database table is locked"
In-Reply-To: <1482095939.25.0.891516594682.issue29006@psf.upfronthosting.co.za>
Message-ID: <1482226014.4.0.129099360189.issue29006@psf.upfronthosting.co.za>


Armin Rigo added the comment:

Tried that, but reverted because on Windows CheckTypeMapUsage() would fail with SQLITE_MISUSE ("ProgrammingError: database table is locked").  For now PyPy will not implement this 2.7.13 change.  I really suspect you can get the same problems on CPython in some cases, as described.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29006>
_______________________________________

From report at bugs.python.org  Tue Dec 20 05:17:28 2016
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 20 Dec 2016 10:17:28 +0000
Subject: [issue28999] Use Py_RETURN_NONE and like
In-Reply-To: <1481969387.72.0.775552115596.issue28999@psf.upfronthosting.co.za>
Message-ID: <1482229048.86.0.721387618767.issue28999@psf.upfronthosting.co.za>


INADA Naoki added the comment:

LGTM

----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28999>
_______________________________________

From report at bugs.python.org  Tue Dec 20 05:29:45 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Dec 2016 10:29:45 +0000
Subject: [issue28932] Fail compile Python 3.6.0rc1 on OpenBSD 6.0
In-Reply-To: <20161220075733.20315.43985.AC822FEB@psf.io>
Message-ID: <CAMpsgwa1KR3G79MLbF1p+piRRYmSCRkvDY5MSiPqRJwYGyF_Cw@mail.gmail.com>


STINNER Victor added the comment:

Thanks Benjamin!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28932>
_______________________________________

From report at bugs.python.org  Tue Dec 20 05:38:51 2016
From: report at bugs.python.org (bpoaugust)
Date: Tue, 20 Dec 2016 10:38:51 +0000
Subject: [issue28945] get_boundary invokes unquote twice
In-Reply-To: <1481547297.88.0.91240101349.issue28945@psf.upfronthosting.co.za>
Message-ID: <1482230331.59.0.583316950548.issue28945@psf.upfronthosting.co.za>


bpoaugust added the comment:

It looks like a simpler alternative is to just change

boundary = self.get_param('boundary', missing)
to
boundary = self.get_param('boundary', missing, unquote=False)

and let collapse_rfc2231_value do the unquoting

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28945>
_______________________________________

From report at bugs.python.org  Tue Dec 20 06:04:20 2016
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 20 Dec 2016 11:04:20 +0000
Subject: [issue28988] Switch dict and set structures to PyVarObject
In-Reply-To: <1481900465.81.0.491407063999.issue28988@psf.upfronthosting.co.za>
Message-ID: <1482231860.96.0.306294479049.issue28988@psf.upfronthosting.co.za>


INADA Naoki added the comment:

LGTM

----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28988>
_______________________________________

From report at bugs.python.org  Tue Dec 20 06:07:43 2016
From: report at bugs.python.org (bpoaugust)
Date: Tue, 20 Dec 2016 11:07:43 +0000
Subject: [issue28945] get_boundary invokes unquote twice
In-Reply-To: <1481547297.88.0.91240101349.issue28945@psf.upfronthosting.co.za>
Message-ID: <1482232063.98.0.152897991496.issue28945@psf.upfronthosting.co.za>


bpoaugust added the comment:

According to RFC822, a quoted-string should only be wrapped in double-quotes. 

So I'm not sure why unquote treats <> as quotes. If it did not, then again this issue would not arise.

However maybe utils.unquote is needed by other code that uses <>, so it cannot just be updated without further analysis.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28945>
_______________________________________

From report at bugs.python.org  Tue Dec 20 06:20:53 2016
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 20 Dec 2016 11:20:53 +0000
Subject: [issue28158] Implement LOAD_GLOBAL opcode cache
In-Reply-To: <1473886080.87.0.000411119678127.issue28158@psf.upfronthosting.co.za>
Message-ID: <1482232853.98.0.349069968321.issue28158@psf.upfronthosting.co.za>


INADA Naoki added the comment:

memo: http://bugs.python.org/issue26219 may be relating to this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28158>
_______________________________________

From report at bugs.python.org  Tue Dec 20 06:25:47 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Dec 2016 11:25:47 +0000
Subject: [issue28822] Fix indices handling in PyUnicode_FindChar
In-Reply-To: <1480350558.9.0.582516213925.issue28822@psf.upfronthosting.co.za>
Message-ID: <1482233147.55.0.0359621987434.issue28822@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Ignore my request about special direction values. It's not worth it to writ tests for that.

PyUnicode_FindChar-v2.patch LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28822>
_______________________________________

From report at bugs.python.org  Tue Dec 20 06:54:32 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 20 Dec 2016 11:54:32 +0000
Subject: [issue28971] nntplib is broken when responses are longer than _MAXLINE
In-Reply-To: <1481716454.12.0.730668429479.issue28971@psf.upfronthosting.co.za>
Message-ID: <1482234872.44.0.368411738698.issue28971@psf.upfronthosting.co.za>


Martin Panter added the comment:

I will try to come up with something in a few days

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28971>
_______________________________________

From report at bugs.python.org  Tue Dec 20 07:00:51 2016
From: report at bugs.python.org (Jacopo)
Date: Tue, 20 Dec 2016 12:00:51 +0000
Subject: [issue29022] Aritmetic error
Message-ID: <1482235251.59.0.167697278337.issue29022@psf.upfronthosting.co.za>


New submission from Jacopo:

$ python
Python 2.7.3 (default, Jun 21 2016, 18:38:19) 
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 69.90 + 2.90
72.80000000000001

----------
components: Interpreter Core
messages: 283684
nosy: r00ta
priority: normal
severity: normal
status: open
title: Aritmetic error
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29022>
_______________________________________

From report at bugs.python.org  Tue Dec 20 07:04:28 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 20 Dec 2016 12:04:28 +0000
Subject: [issue29022] Aritmetic error
In-Reply-To: <1482235251.59.0.167697278337.issue29022@psf.upfronthosting.co.za>
Message-ID: <1482235468.02.0.0276181871216.issue29022@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the report, but it works as expected. Please see https://docs.python.org/2/tutorial/floatingpoint.html for more information.

----------
nosy: +berker.peksag
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29022>
_______________________________________

From report at bugs.python.org  Tue Dec 20 07:46:14 2016
From: report at bugs.python.org (Jakub Mateusz Kowalski)
Date: Tue, 20 Dec 2016 12:46:14 +0000
Subject: [issue29023] Results of random.seed() call with integer argument
 should be claimed deterministic.
Message-ID: <1482237974.75.0.612413216492.issue29023@psf.upfronthosting.co.za>


New submission from Jakub Mateusz Kowalski:

In https://docs.python.org/2/library/random.html#random.seed I can find that "If a hashable object is given, deterministic results are only assured when PYTHONHASHSEED is disabled."

Both int and long are hashable. However, tests on the random module as well as C source code of random_seed (as indicated in http://stackoverflow.com/a/41228062/4879688) suggest that behaviour of the module is deterministic when seeded with an integer.

----------
assignee: docs at python
components: Documentation
messages: 283686
nosy: Jakub.Mateusz.Kowalski, docs at python
priority: normal
severity: normal
status: open
title: Results of random.seed() call with integer argument should be claimed deterministic.
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29023>
_______________________________________

From report at bugs.python.org  Tue Dec 20 07:46:36 2016
From: report at bugs.python.org (Alexander Taylor)
Date: Tue, 20 Dec 2016 12:46:36 +0000
Subject: [issue29024] Add Kivy entry to Graphic User Interface FAQ
Message-ID: <1482237996.76.0.238481497642.issue29024@psf.upfronthosting.co.za>


Changes by Alexander Taylor <alexanderjohntaylor at gmail.com>:


----------
assignee: docs at python
components: Documentation
files: gui_faq_kivy.patch
keywords: patch
nosy: docs at python, inclement
priority: normal
severity: normal
status: open
title: Add Kivy entry to Graphic User Interface FAQ
type: enhancement
versions: Python 3.7
Added file: http://bugs.python.org/file45975/gui_faq_kivy.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29024>
_______________________________________

From report at bugs.python.org  Tue Dec 20 07:55:58 2016
From: report at bugs.python.org (Alexander Taylor)
Date: Tue, 20 Dec 2016 12:55:58 +0000
Subject: [issue29024] Add Kivy entry to Graphic User Interface FAQ
Message-ID: <1482238558.15.0.504318202846.issue29024@psf.upfronthosting.co.za>


Changes by Alexander Taylor <alexanderjohntaylor at gmail.com>:


----------
type: enhancement -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29024>
_______________________________________

From report at bugs.python.org  Tue Dec 20 08:03:36 2016
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 20 Dec 2016 13:03:36 +0000
Subject: [issue24165] Free list for single-digits ints
In-Reply-To: <1431352769.3.0.375640200007.issue24165@psf.upfronthosting.co.za>
Message-ID: <1482239016.04.0.614536022298.issue24165@psf.upfronthosting.co.za>


INADA Naoki added the comment:

Performance version: 0.5.0
Python version: 3.7.0a0 (64-bit) revision 31df7d9863f3+
Report on Linux-4.8.0-30-generic-x86_64-with-debian-stretch-sid

Slower (13):
- nbody: 232 ms +- 3 ms -> 241 ms +- 6 ms: 1.04x slower
- unpack_sequence: 118 ns +- 3 ns -> 121 ns +- 0 ns: 1.03x slower
- call_method_slots: 14.7 ms +- 0.1 ms -> 15.1 ms +- 0.4 ms: 1.02x slower
- logging_silent: 724 ns +- 15 ns -> 740 ns +- 8 ns: 1.02x slower
- telco: 22.5 ms +- 0.5 ms -> 22.9 ms +- 0.5 ms: 1.02x slower
- sqlite_synth: 9.69 us +- 0.27 us -> 9.85 us +- 0.20 us: 1.02x slower
- pickle_list: 8.45 us +- 0.11 us -> 8.57 us +- 0.16 us: 1.01x slower
- pickle_dict: 61.5 us +- 0.5 us -> 62.1 us +- 4.1 us: 1.01x slower
- call_method: 15.2 ms +- 0.1 ms -> 15.3 ms +- 0.1 ms: 1.01x slower
- python_startup_no_site: 9.45 ms +- 0.02 ms -> 9.50 ms +- 0.02 ms: 1.00x slower
- call_method_unknown: 17.2 ms +- 0.2 ms -> 17.2 ms +- 0.2 ms: 1.00x slower
- meteor_contest: 197 ms +- 2 ms -> 198 ms +- 2 ms: 1.00x slower
- python_startup: 15.7 ms +- 0.0 ms -> 15.7 ms +- 0.0 ms: 1.00x slower

Faster (35):
- spectral_norm: 284 ms +- 7 ms -> 262 ms +- 10 ms: 1.08x faster
- scimark_sparse_mat_mult: 8.62 ms +- 0.30 ms -> 7.99 ms +- 0.22 ms: 1.08x faster
- mako: 45.5 ms +- 0.3 ms -> 43.4 ms +- 0.6 ms: 1.05x faster
- scimark_fft: 691 ms +- 13 ms -> 660 ms +- 13 ms: 1.05x faster
- chameleon: 30.5 ms +- 0.3 ms -> 29.4 ms +- 0.5 ms: 1.04x faster
- scimark_sor: 491 ms +- 9 ms -> 474 ms +- 8 ms: 1.04x faster
- fannkuch: 1.07 sec +- 0.03 sec -> 1.04 sec +- 0.01 sec: 1.04x faster
- crypto_pyaes: 229 ms +- 2 ms -> 222 ms +- 4 ms: 1.03x faster
- hexiom: 23.5 ms +- 0.1 ms -> 22.8 ms +- 0.2 ms: 1.03x faster
- regex_compile: 440 ms +- 5 ms -> 430 ms +- 3 ms: 1.03x faster
- pickle: 24.3 us +- 0.5 us -> 23.7 us +- 0.5 us: 1.02x faster
- unpickle: 31.6 us +- 0.3 us -> 30.9 us +- 0.3 us: 1.02x faster
- xml_etree_generate: 291 ms +- 5 ms -> 284 ms +- 7 ms: 1.02x faster
- xml_etree_process: 249 ms +- 3 ms -> 243 ms +- 4 ms: 1.02x faster
- json_loads: 62.6 us +- 0.8 us -> 61.2 us +- 1.1 us: 1.02x faster
- xml_etree_iterparse: 223 ms +- 6 ms -> 218 ms +- 5 ms: 1.02x faster
- scimark_monte_carlo: 263 ms +- 8 ms -> 257 ms +- 9 ms: 1.02x faster
- raytrace: 1.31 sec +- 0.01 sec -> 1.28 sec +- 0.01 sec: 1.02x faster
- pickle_pure_python: 1.31 ms +- 0.01 ms -> 1.29 ms +- 0.02 ms: 1.02x faster
- unpickle_pure_python: 923 us +- 15 us -> 906 us +- 32 us: 1.02x faster
- chaos: 298 ms +- 2 ms -> 294 ms +- 2 ms: 1.01x faster
- sympy_sum: 207 ms +- 6 ms -> 204 ms +- 6 ms: 1.01x faster
- call_simple: 14.0 ms +- 0.3 ms -> 13.9 ms +- 0.3 ms: 1.01x faster
- regex_v8: 46.0 ms +- 2.1 ms -> 45.5 ms +- 0.7 ms: 1.01x faster
- genshi_text: 88.5 ms +- 0.9 ms -> 87.4 ms +- 1.3 ms: 1.01x faster
- sympy_expand: 1.03 sec +- 0.01 sec -> 1.02 sec +- 0.01 sec: 1.01x faster
- 2to3: 737 ms +- 3 ms -> 730 ms +- 3 ms: 1.01x faster
- sympy_str: 462 ms +- 4 ms -> 458 ms +- 6 ms: 1.01x faster
- unpickle_list: 7.67 us +- 0.32 us -> 7.60 us +- 0.11 us: 1.01x faster
- go: 593 ms +- 3 ms -> 589 ms +- 5 ms: 1.01x faster
- dulwich_log: 153 ms +- 1 ms -> 152 ms +- 1 ms: 1.01x faster
- sqlalchemy_declarative: 311 ms +- 3 ms -> 309 ms +- 3 ms: 1.01x faster
- pathlib: 50.3 ms +- 1.4 ms -> 50.0 ms +- 0.6 ms: 1.01x faster
- django_template: 398 ms +- 3 ms -> 396 ms +- 5 ms: 1.01x faster
- pidigits: 310 ms +- 0 ms -> 308 ms +- 0 ms: 1.00x faster

Benchmark hidden because not significant (16): deltablue, float, genshi_xml, html5lib, json_dumps, logging_format, logging_simple, nqueens, regex_dna, regex_effbot, richards, scimark_lu, sqlalchemy_imperative, sympy_integrate, tornado_http, xml_etree_parse

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24165>
_______________________________________

From report at bugs.python.org  Tue Dec 20 08:07:17 2016
From: report at bugs.python.org (Jakub Mateusz Kowalski)
Date: Tue, 20 Dec 2016 13:07:17 +0000
Subject: [issue29025] random.seed() relation to hash() function and its
 determinism is vague
Message-ID: <1482239237.17.0.976890507022.issue29025@psf.upfronthosting.co.za>


New submission from Jakub Mateusz Kowalski:

2.7 (https://docs.python.org/2/library/random.html#random.seed)
- warning about PYTHONHASHSEED (environmental variable) voiding determinism
- no warning on -R interpreter switch 
- relation to hash() function omitted

2.6 (https://docs.python.org/2.6/library/random.html#random.seed)
3.0 (https://docs.python.org/3.0/library/random.html#random.seed)
3.1 (https://docs.python.org/3.1/library/random.html#random.seed)
3.2 (https://docs.python.org/3.2/library/random.html#random.seed)
3.3 (https://docs.python.org/3.3/library/random.html#random.seed)
3.4 (https://docs.python.org/3.4/library/random.html#random.seed)
- no warning about PYTHONHASHSEED nor -R switch
- relation to hash() function acknowledged

3.5 (https://docs.python.org/3.5/library/random.html#random.seed)
3.6 (https://docs.python.org/3.6/library/random.html#random.seed)
3.7 (https://docs.python.org/3.7/library/random.html#random.seed)
- no warning about PYTHONHASHSEED nor -R switch
- relation to hash() function omitted

----------
assignee: docs at python
components: Documentation
messages: 283688
nosy: Jakub.Mateusz.Kowalski, docs at python
priority: normal
severity: normal
status: open
title: random.seed() relation to hash() function and its determinism is vague
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29025>
_______________________________________

From report at bugs.python.org  Tue Dec 20 09:14:52 2016
From: report at bugs.python.org (Steve Dower)
Date: Tue, 20 Dec 2016 14:14:52 +0000
Subject: [issue29014] Python 3.5.2 installer doesn't register IDLE .py
 extensions on Windows 10
In-Reply-To: <1482147098.02.0.695368643489.issue29014@psf.upfronthosting.co.za>
Message-ID: <1482243292.23.0.537302293305.issue29014@psf.upfronthosting.co.za>


Steve Dower added the comment:

C:\Windows\py.exe (probably. If you changed from the default options it may be elsewhere, but if you Open With on a .py file it should be there)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29014>
_______________________________________

From report at bugs.python.org  Tue Dec 20 09:24:49 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Dec 2016 14:24:49 +0000
Subject: [issue29026] time.time() documentation should mention UTC timezone
Message-ID: <1482243889.09.0.538886851254.issue29026@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The documentation of the time.time() mentions "epoch" which it doesn't define epoch. If I recall correctly, it's January 1st, 1970 on most OS and most implementations of Python, except of IronPython which uses a different epoch.

https://docs.python.org/dev/library/time.html#time.time

Moreover, the timezone is not defined. In practice, it's UTC, so it would be nice to document it.

I opened this issue because I wasn't sure if time.time() is impacted by DST or not. The answer is no. Maybe the behaviour of time.time() on DST should also be documentation. Hint: it is not impacted by DST since it uses UTC timezone.

Related question on StackOverflow:
http://stackoverflow.com/questions/32469318/python-time-time-and-daylight-saving-time

----------
assignee: docs at python
components: Documentation
messages: 283690
nosy: belopolsky, docs at python, haypo
priority: normal
severity: normal
status: open
title: time.time() documentation should mention UTC timezone
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29026>
_______________________________________

From report at bugs.python.org  Tue Dec 20 09:35:15 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 20 Dec 2016 14:35:15 +0000
Subject: [issue29010] Incorrect description about scope related with
 inheritance
In-Reply-To: <1482122733.15.0.137275171819.issue29010@psf.upfronthosting.co.za>
Message-ID: <1482244515.38.0.932240012738.issue29010@psf.upfronthosting.co.za>


R. David Murray added the comment:

Would it make it clearer if we said "BaseClassName must be defined in a namespace accessible from the scope containing the dervied class definition" ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29010>
_______________________________________

From report at bugs.python.org  Tue Dec 20 09:40:14 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 20 Dec 2016 14:40:14 +0000
Subject: [issue28968] xml rpc server fails with connection reset by peer error
 no 104
In-Reply-To: <1481709223.17.0.559234955094.issue28968@psf.upfronthosting.co.za>
Message-ID: <1482244814.66.0.484285061478.issue28968@psf.upfronthosting.co.za>


R. David Murray added the comment:

I'm sorry, I don't have time to dig in to this right now.  Hopefully someone else can pick it up.  You might try posting on the python-list mailing list, there are several core devs who hang out there and might be interested in the problem.

----------
nosy:  -loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28968>
_______________________________________

From report at bugs.python.org  Tue Dec 20 09:47:39 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 20 Dec 2016 14:47:39 +0000
Subject: [issue28945] get_boundary invokes unquote twice
In-Reply-To: <1481547297.88.0.91240101349.issue28945@psf.upfronthosting.co.za>
Message-ID: <1482245259.43.0.364232619887.issue28945@psf.upfronthosting.co.za>


R. David Murray added the comment:

I'm pretty sure you are correct in your guess that the utility is used by other code that depends on the <> unquoting.

The new email policies (that is, the new header parsing code) probably do a better job of this, but get_param and friends haven't been wired up to use them when available yet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28945>
_______________________________________

From report at bugs.python.org  Tue Dec 20 09:49:45 2016
From: report at bugs.python.org (Brendan Donegan)
Date: Tue, 20 Dec 2016 14:49:45 +0000
Subject: [issue29010] Incorrect description about scope related with
 inheritance
In-Reply-To: <1482122733.15.0.137275171819.issue29010@psf.upfronthosting.co.za>
Message-ID: <1482245385.3.0.37584893708.issue29010@psf.upfronthosting.co.za>


Brendan Donegan added the comment:

Worth putting them side by side I think:

"The name BaseClassName must be defined in a scope containing the derived class definition"

vs.

"BaseClassName must be defined in a namespace accessible from the scope containing the derived class definition"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29010>
_______________________________________

From report at bugs.python.org  Tue Dec 20 09:55:53 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 20 Dec 2016 14:55:53 +0000
Subject: [issue28822] Fix indices handling in PyUnicode_FindChar
In-Reply-To: <1480350558.9.0.582516213925.issue28822@psf.upfronthosting.co.za>
Message-ID: <20161220145550.107288.5991.7CCD060A@psf.io>


Roundup Robot added the comment:

New changeset ce6a6cc3765d by Xiang Zhang in branch 'default':
Issue #28822: Adjust indices handling of PyUnicode_FindChar().
https://hg.python.org/cpython/rev/ce6a6cc3765d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28822>
_______________________________________

From report at bugs.python.org  Tue Dec 20 09:57:49 2016
From: report at bugs.python.org (woo yoo)
Date: Tue, 20 Dec 2016 14:57:49 +0000
Subject: [issue29010] Incorrect description about scope related with
 inheritance
In-Reply-To: <1482122733.15.0.137275171819.issue29010@psf.upfronthosting.co.za>
Message-ID: <1482245869.85.0.426476506906.issue29010@psf.upfronthosting.co.za>


woo yoo added the comment:

As for me, i prefer the new description, which is clear and easy to understand.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29010>
_______________________________________

From report at bugs.python.org  Tue Dec 20 09:59:11 2016
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 20 Dec 2016 14:59:11 +0000
Subject: [issue29026] time.time() documentation should mention UTC timezone
In-Reply-To: <1482243889.09.0.538886851254.issue29026@psf.upfronthosting.co.za>
Message-ID: <1482245951.77.0.511380281359.issue29026@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

time.time() is not quite UTC on Unix: it usually (*) doesn't include leap seconds, which UTC does.

The Wikipedia page has a good definition and explanation:

https://en.wikipedia.org/wiki/Unix_time

(*) "usually" because POSIX defines time() to not include leap seconds, but on some older or not quite POSIX compliant Unix systems, leap seconds are included.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29026>
_______________________________________

From report at bugs.python.org  Tue Dec 20 10:07:03 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 20 Dec 2016 15:07:03 +0000
Subject: [issue29026] time.time() documentation should mention UTC timezone
In-Reply-To: <1482243889.09.0.538886851254.issue29026@psf.upfronthosting.co.za>
Message-ID: <1482246423.72.0.28698303419.issue29026@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> time.time() is not quite UTC on Unix

Handling time is a complex task, so we should enhance the doc to help users.

If there are multiple cases, we can list them: "time.time() uses UTC timezone with or without leap seconds". Maybe with a link to https://en.wikipedia.org/wiki/Unix_time ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29026>
_______________________________________

From report at bugs.python.org  Tue Dec 20 10:15:44 2016
From: report at bugs.python.org (kevin)
Date: Tue, 20 Dec 2016 15:15:44 +0000
Subject: [issue29027] 3.5.2 compile error from ssl related.
Message-ID: <1482246944.19.0.555352966537.issue29027@psf.upfronthosting.co.za>


New submission from kevin:

Download the python version 3.5.2 source code from official web site.
Compile the python code by the following steps:
sudo ./configure
sudo make
sudo make install

but from make, I get the following errors:


/home/boot/tools/Python-3.5.2/Modules/_ssl.c:2582:46: error: dereferencing pointer to incomplete type ?X509_STORE {aka struct x509_store_st}?
     flags = X509_VERIFY_PARAM_get_flags(store->param);
                                              ^
/home/boot/tools/Python-3.5.2/Modules/_ssl.c: In function ?_ssl__SSLContext_load_cert_chain_impl?:
/home/boot/tools/Python-3.5.2/Modules/_ssl.c:2782:48: error: dereferencing pointer to incomplete type ?SSL_CTX {aka struct ssl_ctx_st}?
     pem_password_cb *orig_passwd_cb = self->ctx->default_passwd_callback;
                                                ^
/home/boot/tools/Python-3.5.2/Modules/_ssl.c: In function ?_ssl__SSLContext_cert_store_stats_impl?:
/home/boot/tools/Python-3.5.2/Modules/_ssl.c:3443:20: error: dereferencing pointer to incomplete type ?X509_OBJECT {aka struct x509_object_st}?
         switch (obj->type) {
                    ^
/home/boot/tools/Python-3.5.2/Modules/_ssl.c:3453:18: error: ?X509_LU_PKEY? undeclared (first use in this function)
             case X509_LU_PKEY:

then I install the openssl by compiling download code,and the ssl can work, and compile python code,the error still exists.
please help me check where I take a mistake.
Thanks a lot.

----------
assignee: christian.heimes
components: SSL
messages: 283699
nosy: christian.heimes, kevin.zhai80
priority: normal
severity: normal
status: open
title: 3.5.2 compile error from ssl related.
type: compile error
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29027>
_______________________________________

From report at bugs.python.org  Tue Dec 20 10:25:31 2016
From: report at bugs.python.org (dyjakan)
Date: Tue, 20 Dec 2016 15:25:31 +0000
Subject: [issue29028] Use-After-Free in PyString_FromStringAndSize() of
 stringobject.c
Message-ID: <1482247531.75.0.221402980867.issue29028@psf.upfronthosting.co.za>


New submission from dyjakan:

Recently I started doing some research related to language interpreters
and I've stumbled upon a bug in current Python 2.7. I already contacted PSRT and we concluded that this doesn't have security implications.

Repro file looks like this:

```
class Index(object):
    def __index__(self):
        for c in "foobar"*n:
            a.append(c)
        return n * 4

for n in range(1, 100000, 100):
    a = bytearray("test"*n)
    buf = buffer(a)
    s = buf[:Index():1]
```

If you have ASAN build then you'll see this:

```
==29054== ERROR: AddressSanitizer: heap-use-after-free on address 0x60040000a233 at pc 0x4fab7f bp 0x7ffdbfec0b50 sp 0x7ffdbfec0b48
READ of size 1 at 0x60040000a233 thread T0
    #0 0x4fab7e (/home/ad/builds/python-2.7-asan/bin/python2.7+0x4fab7e)
    #1 0x6bbed4 (/home/ad/builds/python-2.7-asan/bin/python2.7+0x6bbed4)
    #2 0x59d998 (/home/ad/builds/python-2.7-asan/bin/python2.7+0x59d998)
    #3 0x5b53fe (/home/ad/builds/python-2.7-asan/bin/python2.7+0x5b53fe)
    #4 0x5b5a65 (/home/ad/builds/python-2.7-asan/bin/python2.7+0x5b5a65)
    #5 0x637eac (/home/ad/builds/python-2.7-asan/bin/python2.7+0x637eac)
    #6 0x63b3af (/home/ad/builds/python-2.7-asan/bin/python2.7+0x63b3af)
    #7 0x4192d0 (/home/ad/builds/python-2.7-asan/bin/python2.7+0x4192d0)
    #8 0x7f6da3cf0f44 (/lib/x86_64-linux-gnu/libc-2.19.so+0x21f44)
    #9 0x417c11 (/home/ad/builds/python-2.7-asan/bin/python2.7+0x417c11)
0x60040000a233 is located 3 bytes inside of 5-byte region [0x60040000a230,0x60040000a235)
freed by thread T0 here:
    #0 0x7f6da49d455f (/usr/lib/x86_64-linux-gnu/libasan.so.0.0.0+0x1555f)
    #1 0x6c5388 (/home/ad/builds/python-2.7-asan/bin/python2.7+0x6c5388)
    #2 0x5b15fb (/home/ad/builds/python-2.7-asan/bin/python2.7+0x5b15fb)
    #3 0x5b53fe (/home/ad/builds/python-2.7-asan/bin/python2.7+0x5b53fe)
    #4 0x6f59c2 (/home/ad/builds/python-2.7-asan/bin/python2.7+0x6f59c2)
    #5 0x440bc8 (/home/ad/builds/python-2.7-asan/bin/python2.7+0x440bc8)
    #6 0x44a712 (/home/ad/builds/python-2.7-asan/bin/python2.7+0x44a712)
    #7 0x440bc8 (/home/ad/builds/python-2.7-asan/bin/python2.7+0x440bc8)
    #8 0x52afeb (/home/ad/builds/python-2.7-asan/bin/python2.7+0x52afeb)
    #9 0x4391ab (/home/ad/builds/python-2.7-asan/bin/python2.7+0x4391ab)
    #10 0x5b5d35 (/home/ad/builds/python-2.7-asan/bin/python2.7+0x5b5d35)
    #11 0x4ea936 (/home/ad/builds/python-2.7-asan/bin/python2.7+0x4ea936)
    #12 0x6bbd20 (/home/ad/builds/python-2.7-asan/bin/python2.7+0x6bbd20)
    #13 0x59d998 (/home/ad/builds/python-2.7-asan/bin/python2.7+0x59d998)
    #14 0x5b53fe (/home/ad/builds/python-2.7-asan/bin/python2.7+0x5b53fe)
    #15 0x5b5a65 (/home/ad/builds/python-2.7-asan/bin/python2.7+0x5b5a65)
    #16 0x637eac (/home/ad/builds/python-2.7-asan/bin/python2.7+0x637eac)
    #17 0x63b3af (/home/ad/builds/python-2.7-asan/bin/python2.7+0x63b3af)
    #18 0x4192d0 (/home/ad/builds/python-2.7-asan/bin/python2.7+0x4192d0)
    #19 0x7f6da3cf0f44 (/lib/x86_64-linux-gnu/libc-2.19.so+0x21f44)
previously allocated by thread T0 here:
    #0 0x7f6da49d455f (/usr/lib/x86_64-linux-gnu/libasan.so.0.0.0+0x1555f)
    #1 0x6c7b3d (/home/ad/builds/python-2.7-asan/bin/python2.7+0x6c7b3d)
    #2 0x6ca853 (/home/ad/builds/python-2.7-asan/bin/python2.7+0x6ca853)
    #3 0x522ddd (/home/ad/builds/python-2.7-asan/bin/python2.7+0x522ddd)
    #4 0x440bc8 (/home/ad/builds/python-2.7-asan/bin/python2.7+0x440bc8)
    #5 0x59f1ca (/home/ad/builds/python-2.7-asan/bin/python2.7+0x59f1ca)
    #6 0x5b53fe (/home/ad/builds/python-2.7-asan/bin/python2.7+0x5b53fe)
    #7 0x5b5a65 (/home/ad/builds/python-2.7-asan/bin/python2.7+0x5b5a65)
    #8 0x637eac (/home/ad/builds/python-2.7-asan/bin/python2.7+0x637eac)
    #9 0x63b3af (/home/ad/builds/python-2.7-asan/bin/python2.7+0x63b3af)
    #10 0x4192d0 (/home/ad/builds/python-2.7-asan/bin/python2.7+0x4192d0)
    #11 0x7f6da3cf0f44 (/lib/x86_64-linux-gnu/libc-2.19.so+0x21f44)
Shadow bytes around the buggy address:
  0x0c00ffff93f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c00ffff9400: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c00ffff9410: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c00ffff9420: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c00ffff9430: fa fa fa fa fa fa fa fa fa fa fa fa fa fa 00 04
=>0x0c00ffff9440: fa fa fd fa fa fa[fd]fa fa fa fd fa fa fa fd fa
  0x0c00ffff9450: fa fa fd fd fa fa fd fa fa fa fd fa fa fa 00 fa
  0x0c00ffff9460: fa fa 06 fa fa fa fd fa fa fa fd fa fa fa fd fd
  0x0c00ffff9470: fa fa fd fa fa fa fd fa fa fa fd fd fa fa fd fa
  0x0c00ffff9480: fa fa fd fd fa fa fd fa fa fa 00 fa fa fa fd fa
  0x0c00ffff9490: fa fa fd fa fa fa fd fd fa fa fd fa fa fa fd fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07
  Heap left redzone:     fa
  Heap righ redzone:     fb
  Freed Heap region:     fd
  Stack left redzone:    f1
  Stack mid redzone:     f2
  Stack right redzone:   f3
  Stack partial redzone: f4
  Stack after return:    f5
  Stack use after scope: f8
  Global redzone:        f9
  Global init order:     f6
  Poisoned by user:      f7
  ASan internal:         fe
==29054== ABORTING
```

----------
components: Interpreter Core
messages: 283700
nosy: dyjakan
priority: normal
severity: normal
status: open
title: Use-After-Free in PyString_FromStringAndSize() of stringobject.c
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29028>
_______________________________________

From report at bugs.python.org  Tue Dec 20 10:30:38 2016
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 20 Dec 2016 15:30:38 +0000
Subject: [issue29027] 3.5.2 compile error from ssl related.
In-Reply-To: <1482246944.19.0.555352966537.issue29027@psf.upfronthosting.co.za>
Message-ID: <DF067A75-A982-4326-869A-812A90ABAFAA@cheimes.de>


Christian Heimes added the comment:

What is your platform, compiler and OpenSSL version?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29027>
_______________________________________

From report at bugs.python.org  Tue Dec 20 11:21:22 2016
From: report at bugs.python.org (Eric Lafontaine)
Date: Tue, 20 Dec 2016 16:21:22 +0000
Subject: [issue28945] get_boundary invokes unquote twice
In-Reply-To: <1481547297.88.0.91240101349.issue28945@psf.upfronthosting.co.za>
Message-ID: <1482250882.6.0.258486817509.issue28945@psf.upfronthosting.co.za>


Eric Lafontaine added the comment:

Hi all,

I hate this proposition.  I feel it's a "victory" for the people who don't want to follow RFC standard and allow "triple"-quoting on things that aren't supposed to...

Now that my opinion is said, I made 2 test case that should be added to the test_email file of the test library to support the change :

_________________________________________________________
    def test_rfc2231_multiple_quote_boundary(self):
        m = '''\
Content-Type: multipart/alternative;
\tboundary*0*="<<This%20is%20even%20more%20";
\tboundary*1*="%2A%2A%2Afun%2A%2A%2A%20";
\tboundary*2="is it not.pdf>>"

'''
        msg = email.message_from_string(m)
        self.assertEqual(msg.get_boundary(),
                         '<<This is even more ***fun*** is it not.pdf>>')
    def test_rfc2231_multiple_quote_boundary2(self):
        m = '''\
Content-Type: multipart/alternative;
\tboundary="<<This is even more >>";

'''
        msg = email.message_from_string(m)
        self.assertEqual(msg.get_boundary(),
                         '<<This is even more >>')
_______________________________________________________

The problem however does lie within collapse function as you've mentionned (because you've taken the code from there haven't you? :P) :
def collapse_rfc2231_value(value, errors='replace',
                           fallback_charset='us-ascii'):
    if not isinstance(value, tuple) or len(value) != 3:
        return value                                     <=======removed unquote on value
        
 This doesn't seem to have broken any of the 1580 tests case of test_email (Python3.7), but I can't help but to feel weird about it.  Could someone explain why we were unquoting there? and why use those weird condition (not isintance(value,tuple) or len(value) !=3)....?
 
 Regards,
 Eric Lafontaine

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28945>
_______________________________________

From report at bugs.python.org  Tue Dec 20 11:28:44 2016
From: report at bugs.python.org (Eric Lafontaine)
Date: Tue, 20 Dec 2016 16:28:44 +0000
Subject: [issue28945] get_boundary invokes unquote twice
In-Reply-To: <1481547297.88.0.91240101349.issue28945@psf.upfronthosting.co.za>
Message-ID: <1482251324.81.0.0695561575275.issue28945@psf.upfronthosting.co.za>


Eric Lafontaine added the comment:

N.B., I've tried to do the keyword parameter on the get_param inside the get_boundary as well as I though it was a good Idea as well, but it was breaking some test cases (multiple ones).  So I didn't pursue.

N.B.  I'm guessing (guessing) unquote must've been used for email adresses as well i.e. "Eric Lafontaine <eric.lafontaine1 at gmail.com>"

I also didn't had the time to read all answer since yesterday, sorry for not adding it to my earlier answer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28945>
_______________________________________

From report at bugs.python.org  Tue Dec 20 11:32:57 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 20 Dec 2016 16:32:57 +0000
Subject: [issue28945] get_boundary invokes unquote twice
In-Reply-To: <1481547297.88.0.91240101349.issue28945@psf.upfronthosting.co.za>
Message-ID: <1482251577.42.0.868155127935.issue28945@psf.upfronthosting.co.za>


R. David Murray added the comment:

The RFC compliance battle in email was lost long ago.  We have to do our best to process what we get, and to produce only RFC correct output (unless retransmitting without change).  That is Postel's law, and you can't successfully process Internet email without following the first part.

I haven't looked at the proposed solution yet.  Not sure when I'll get time, since I should try to think and research the questions (why was it done the way it is currently done?), which will take quite a bit of time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28945>
_______________________________________

From report at bugs.python.org  Tue Dec 20 11:41:01 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 20 Dec 2016 16:41:01 +0000
Subject: [issue28822] Fix indices handling in PyUnicode_FindChar
In-Reply-To: <1480350558.9.0.582516213925.issue28822@psf.upfronthosting.co.za>
Message-ID: <1482252061.68.0.0295759695024.issue28822@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Thanks Victor and Serhiy!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28822>
_______________________________________

From report at bugs.python.org  Tue Dec 20 13:00:43 2016
From: report at bugs.python.org (eryk sun)
Date: Tue, 20 Dec 2016 18:00:43 +0000
Subject: [issue29014] Python 3.5.2 installer doesn't register IDLE .py
 extensions on Windows 10
In-Reply-To: <1482147098.02.0.695368643489.issue29014@psf.upfronthosting.co.za>
Message-ID: <1482256843.64.0.414139905295.issue29014@psf.upfronthosting.co.za>


eryk sun added the comment:

When you change the association for executing scripts (either via Default Programs or the Open with => Choose another app menu), do not "look for another app on this PC". Manually associating files with an executable such as py.exe creates a ProgId that's only meant for opening data files, i.e. there's no "%*" in the template to pass command-line arguments. (Microsoft should provide an option here to support passing command-line arguments.)

You have to select "Python" in the listed applications. Explorer lists them only by name and icon. There may be multiple entries named "Python". The one you're looking for should have a rocket on the icon because it opens using the py.exe launcher. Hopefully this should be for the "Python.File" ProgId that's configured by Python's installer. 

If switching to it doesn't add the IDLE menu, first confirm that the "ProgId" value is "Python.File" in the user choice registry key at the following path: "HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.py\UserChoice". If not, pick a different "Python" app from the list until the user choice is "Python.File". (Microsoft should provide an advanced way to select a ProgId explicitly. They took away the ability to edit the UserChoice key, which is fine, but they failed to provide an advanced alternative to the dumbed-down app list, which is hostile to both power users and developers.) If no entry sets the user choice to "Python.File" or if it's set to "Python.File" and there's no IDLE menu, then maybe the ProgId itself has been modified or deleted. Try repairing your Python installation to fix this.

Steve, you could move the "Edit with IDLE" menu out of the Python.File ProgId to an entry defined in SystemFileAssociations. This should normally be available regardless of the application the user associates with .py files. Here's an example .reg file to add this for a system install of 64-bit 3.5:

    Windows Registry Editor Version 5.00

    [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\SystemFileAssociations\.py]

    [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\SystemFileAssociations\.py\shell]

    [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\SystemFileAssociations\.py\shell\editwithidle]
    "MUIVerb"="&Edit with IDLE"
    "Subcommands"=""

    [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\SystemFileAssociations\.py\shell\editwithidle\shell]

    [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\SystemFileAssociations\.py\shell\editwithidle\shell\edit35]
    "MUIVerb"="Edit with IDLE 3.5 (64-bit)"

    [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\SystemFileAssociations\.py\shell\editwithidle\shell\edit35\command]
    @="\"C:\\Program Files\\Python35\\pythonw.exe\" -m idlelib \"%1\" %*"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29014>
_______________________________________

From report at bugs.python.org  Tue Dec 20 14:14:03 2016
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 20 Dec 2016 19:14:03 +0000
Subject: [issue24672] shutil.rmtree fails on non ascii filenames
In-Reply-To: <1437381607.37.0.102405626215.issue24672@psf.upfronthosting.co.za>
Message-ID: <1482261243.7.0.840196291208.issue24672@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

I'm afraid I need to re-open this issue.

Although passing unicode names to rmtree fixes the issue on Windows systems, it causes problems on Linux systems where LC_ALL=C. Consider this script:

#################################
# encoding: utf-8

from __future__ import unicode_literals

import os
import shutil

os.mkdir('temp')

with open('temp/????? ???????.html'.encode('utf-8'), 'w'):
    pass

print(os.listdir(b'temp')[0])

shutil.rmtree('temp')
#################################

Invoked thus, a UnicodeDecodeError occurs:

vagrant at trusty:/vagrant$ LC_ALL=C python2.7 issue24672.py 
????? ????????.html
Traceback (most recent call last):
  File "issue24672.py", line 15, in <module>
    shutil.rmtree('temp')
  File "/usr/lib/python2.7/shutil.py", line 241, in rmtree
    fullname = os.path.join(path, name)
  File "/usr/lib/python2.7/posixpath.py", line 80, in join
    path += '/' + b
UnicodeDecodeError: 'ascii' codec can't decode byte 0xd0 in position 1: ordinal not in range(128)


This is the same error seen trying to rmtree an extraction of Sphinx (a package containing an offending non-ascii character)::

vagrant at trusty:/vagrant$ wget 'https://files.pythonhosted.org/packages/b2/d5/bb4bf7fbc2e6b85d1e3832716546ecd434632d9d434a01efe87053fe5f25/Sphinx-1.5.1.tar.gz' -O - | tar xz 
--2016-12-20 19:07:21--  https://files.pythonhosted.org/packages/b2/d5/bb4bf7fbc2e6b85d1e3832716546ecd434632d9d434a01efe87053fe5f25/Sphinx-1.5.1.tar.gz
Resolving files.pythonhosted.org (files.pythonhosted.org)... 151.101.33.63
Connecting to files.pythonhosted.org (files.pythonhosted.org)|151.101.33.63|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 4397246 (4.2M) [binary/octet-stream]
Saving to: ?STDOUT?

100%[========================================================>] 4,397,246   2.06MB/s   in 2.0s   

2016-12-20 19:07:23 (2.06 MB/s) - written to stdout [4397246/4397246]

vagrant at trusty:/vagrant$ LC_ALL=C python2.7 -c "import shutil; shutil.rmtree(u'Sphinx-1.5.1')"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python2.7/shutil.py", line 247, in rmtree
    rmtree(fullname, ignore_errors, onerror)
  File "/usr/lib/python2.7/shutil.py", line 247, in rmtree
    rmtree(fullname, ignore_errors, onerror)
  File "/usr/lib/python2.7/shutil.py", line 247, in rmtree
    rmtree(fullname, ignore_errors, onerror)
  File "/usr/lib/python2.7/shutil.py", line 241, in rmtree
    fullname = os.path.join(path, name)
  File "/usr/lib/python2.7/posixpath.py", line 80, in join
    path += '/' + b
UnicodeDecodeError: 'ascii' codec can't decode byte 0xcc in position 8: ordinal not in range(128)


Is the solution to call rmtree with unicode on Windows, but with bytes when on Python 2 and Linux? What else can be done?

----------
resolution: wont fix -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24672>
_______________________________________

From report at bugs.python.org  Tue Dec 20 14:36:42 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 20 Dec 2016 19:36:42 +0000
Subject: [issue28997] test_readline.test_nonascii fails on Android
In-Reply-To: <1481965369.72.0.409169776064.issue28997@psf.upfronthosting.co.za>
Message-ID: <1482262602.11.0.195197989708.issue28997@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

The test is ok on Android when LANG=en_US.UTF-8.
When LANG is not set, the check made by the first statement in test_nonascii() should skip the test but fails to skip it on Android as Py_EncodeLocale() always encode to utf8 whatever the locale (same as with darwin).
This patch adds a second check to verify that readline does handle multi bytes characters and does skip the test if not. So on Android the test is skipped now when LANG is not set.  Another solution would have been to set LANG=en_US.UTF-8 in the environment of the process forked by run_pty(), but it does not sound robust as there may be other setups where readline does not handle multi bytes characters.

----------
Added file: http://bugs.python.org/file45976/readline_multibyte.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28997>
_______________________________________

From report at bugs.python.org  Tue Dec 20 14:37:03 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 20 Dec 2016 19:37:03 +0000
Subject: [issue28997] test_readline.test_nonascii fails on Android
In-Reply-To: <1481965369.72.0.409169776064.issue28997@psf.upfronthosting.co.za>
Message-ID: <1482262623.0.0.136980513305.issue28997@psf.upfronthosting.co.za>


Changes by Xavier de Gaye <xdegaye at gmail.com>:


----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28997>
_______________________________________

From report at bugs.python.org  Tue Dec 20 15:33:34 2016
From: report at bugs.python.org (Steve Dower)
Date: Tue, 20 Dec 2016 20:33:34 +0000
Subject: [issue29014] Python 3.5.2 installer doesn't register IDLE .py
 extensions on Windows 10
In-Reply-To: <1482147098.02.0.695368643489.issue29014@psf.upfronthosting.co.za>
Message-ID: <1482266013.99.0.949995926775.issue29014@psf.upfronthosting.co.za>


Steve Dower added the comment:

> Steve, you could move the "Edit with IDLE" menu out of the Python.File ProgId to an entry defined in SystemFileAssociations.

I could, but I don't want to. I'd rather figure out adding an "Open With" entry for IDLE.

There's no reason to for IDLE to be a system-level association if the user has not chosen the association, just as I'd expect any text editor to be opt-in.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29014>
_______________________________________

From report at bugs.python.org  Tue Dec 20 15:39:54 2016
From: report at bugs.python.org (Steve Dower)
Date: Tue, 20 Dec 2016 20:39:54 +0000
Subject: [issue24672] shutil.rmtree fails on non ascii filenames
In-Reply-To: <1437381607.37.0.102405626215.issue24672@psf.upfronthosting.co.za>
Message-ID: <1482266394.95.0.409715400077.issue24672@psf.upfronthosting.co.za>


Steve Dower added the comment:

Lib/posixpath.py needs a huge amount of work to behave correctly for either bytes or Unicode paths. I don't know why Lib/ntpath.py is okay here, but the code is different so I suspect it just happens to not need the same conversion.

Switching for each platform is probably the only way, unless you find someone willing to go through and make Unicode paths viable on Python 2.7 (this came up earlier today on one of the lists).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24672>
_______________________________________

From report at bugs.python.org  Tue Dec 20 16:30:18 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 20 Dec 2016 21:30:18 +0000
Subject: [issue29029] Faster positional arguments parsing in
 PyArg_ParseTupleAndKeywords
Message-ID: <1482269418.38.0.550958237488.issue29029@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch speeds up parsing positional arguments in PyArg_ParseTupleAndKeywords().

$ ./python -m perf timeit "1 .to_bytes(1, 'little', signed=False)"
Unpatched:  Median +- std dev: 2.01 us +- 0.09 us
Patched:    Median +- std dev: 1.23 us +- 0.03 us

Currently names of all passed positional argument are looked up in the kwargs dictionary for checking if the argument is passed as positional and keyword argument. With the patch this is checked only if there are unhandled keyword arguments after parsing keyword arguments that don't passed as positional arguments.

The same optimization also is applied to _PyArg_ParseTupleAndKeywordsFast() and like, but the effect is much smaller.

The patch also includes tiny refactoring.

----------
components: Interpreter Core
files: PyArg_ParseTupleAndKeywords-faster-positional-args-parse.patch
keywords: patch
messages: 283711
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Faster positional arguments parsing in PyArg_ParseTupleAndKeywords
type: performance
versions: Python 3.7
Added file: http://bugs.python.org/file45977/PyArg_ParseTupleAndKeywords-faster-positional-args-parse.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29029>
_______________________________________

From report at bugs.python.org  Tue Dec 20 17:06:46 2016
From: report at bugs.python.org (Ned Deily)
Date: Tue, 20 Dec 2016 22:06:46 +0000
Subject: [issue29021] Custom functions in sqlite receive None on invalid UTF-8
In-Reply-To: <1482225891.27.0.11020777474.issue29021@psf.upfronthosting.co.za>
Message-ID: <1482271606.04.0.372280541512.issue29021@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
nosy: +ghaering

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29021>
_______________________________________

From report at bugs.python.org  Tue Dec 20 17:09:26 2016
From: report at bugs.python.org (Ned Deily)
Date: Tue, 20 Dec 2016 22:09:26 +0000
Subject: [issue28932] Fail compile Python 3.6.0rc1 on OpenBSD 6.0
In-Reply-To: <1481388547.33.0.916805591486.issue28932@psf.upfronthosting.co.za>
Message-ID: <1482271766.57.0.376967061146.issue28932@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
priority: release blocker -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28932>
_______________________________________

From report at bugs.python.org  Tue Dec 20 18:36:55 2016
From: report at bugs.python.org (eryk sun)
Date: Tue, 20 Dec 2016 23:36:55 +0000
Subject: [issue29014] Python 3.5.2 installer doesn't register IDLE .py
 extensions on Windows 10
In-Reply-To: <1482147098.02.0.695368643489.issue29014@psf.upfronthosting.co.za>
Message-ID: <1482277015.94.0.397438632958.issue29014@psf.upfronthosting.co.za>


eryk sun added the comment:

> There's no reason to for IDLE to be a system-level association if 
> the user has not chosen the association

Ok, to clarify, SystemFileAssociations can be defined in either the system or user hive. It's fine if the IDLE menu is added this way when it's done just for the current user (perhaps with an addition option in the installer). The problem is setting it in the system hive for a per-machine install because an individual user won't be able to disable the menu.

> I'd rather figure out adding an "Open With" entry for IDLE

As you've suggested before, that requires bundling an idle.exe launcher.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29014>
_______________________________________

From report at bugs.python.org  Tue Dec 20 19:52:26 2016
From: report at bugs.python.org (Cyker Way)
Date: Wed, 21 Dec 2016 00:52:26 +0000
Subject: [issue29030] argparse: choices override metavar
Message-ID: <1482281546.0.0.613026945443.issue29030@psf.upfronthosting.co.za>


New submission from Cyker Way:

Using `choices` option in `argparse` module caused unwanted behavior.

# Without `choices`

    parser = argparse.ArgumentParser()
    parser.add_argument('length')
    parser.print_help()

## Output

    usage: demo.py [-h] length

    positional arguments:
      length

    optional arguments:
      -h, --help  show this help message and exit

# With choices

    parser = argparse.ArgumentParser()
    parser.add_argument('length', choices=[1,2,3])
    parser.print_help()

## Output

    usage: demo.py [-h] {1,2,3}

    positional arguments:
      {1,2,3}

    optional arguments:
      -h, --help  show this help message and exit

I think the doc says ArgumentParser objects use the `dest` value as the ?name? of each object. And the doc doesn't mention anything about `dest` be changed by `choices`. The help text looks ugly when there is a long list of choices.

Currently the problem can be remedied by adding a `metavar` option. But I hope it will be fixed in the library itself.

----------
components: Library (Lib)
messages: 283713
nosy: cyker
priority: normal
severity: normal
status: open
title: argparse: choices override metavar
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29030>
_______________________________________

From report at bugs.python.org  Tue Dec 20 20:37:08 2016
From: report at bugs.python.org (R. David Murray)
Date: Wed, 21 Dec 2016 01:37:08 +0000
Subject: [issue29030] argparse: choices override metavar
In-Reply-To: <1482281546.0.0.613026945443.issue29030@psf.upfronthosting.co.za>
Message-ID: <1482284228.27.0.741052548233.issue29030@psf.upfronthosting.co.za>


R. David Murray added the comment:

metavar is, I believe, the intended way to change the default behavior.  Whether or not this needs better documentation is a separate question :)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29030>
_______________________________________

From report at bugs.python.org  Tue Dec 20 20:42:00 2016
From: report at bugs.python.org (Steve Dower)
Date: Wed, 21 Dec 2016 01:42:00 +0000
Subject: [issue23903] Generate PC/python3.def by scraping headers
In-Reply-To: <1428637761.13.0.348463350169.issue23903@psf.upfronthosting.co.za>
Message-ID: <1482284520.58.0.241370361647.issue23903@psf.upfronthosting.co.za>


Steve Dower added the comment:

I just ran into this because PyModule_AddFunctions() was added to the stable ABI in 3.5, but was not added to python3.dll.

This is blatantly a compilation error. We _need_ python3.def and the stable ABI to be in sync.

I've rerun the script against Python 3.6 and attached it. I'm also going to post to python-dev to attract some attention.

I think at this stage we ought to update python3.dll to include everything that could be used from the headers. Unfortunately, that means extensions could potentially break if built on 3.6.1 and run against 3.6.0, but it's inevitable that there will be some breakage and this way it's only temporary.

----------
versions: +Python 3.5, Python 3.7
Added file: http://bugs.python.org/file45978/python3def.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23903>
_______________________________________

From report at bugs.python.org  Tue Dec 20 21:15:22 2016
From: report at bugs.python.org (David)
Date: Wed, 21 Dec 2016 02:15:22 +0000
Subject: [issue29014] Python 3.5.2 installer doesn't register IDLE .py
 extensions on Windows 10
In-Reply-To: <1482147098.02.0.695368643489.issue29014@psf.upfronthosting.co.za>
Message-ID: <1482286522.52.0.143687587999.issue29014@psf.upfronthosting.co.za>


David added the comment:

So I tried changing it to py.exe, and it doesn't load the IDLE: instead, it opens up the run command for the program in command prompt. That's not what I want it to do. Also, there still is no Edit With IDLE option. And I tried doing the ProgID stuff, but none of it worked even after repairing/uninstalling, etc. 

I'm kind of hopeless at this point. Thank you everyone for helping.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29014>
_______________________________________

From report at bugs.python.org  Tue Dec 20 23:42:44 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 21 Dec 2016 04:42:44 +0000
Subject: [issue19846] Python 3 raises Unicode errors with the C locale
In-Reply-To: <1385847645.21.0.327287028528.issue19846@psf.upfronthosting.co.za>
Message-ID: <1482295364.64.0.527614613268.issue19846@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Also see http://bugs.python.org/issue28180 for a more recent proposal to tackle this by coercing the C locale to the C.UTF-8 locale

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19846>
_______________________________________

From report at bugs.python.org  Tue Dec 20 23:44:05 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 21 Dec 2016 04:44:05 +0000
Subject: [issue13643] 'ascii' is a bad filesystem default encoding
In-Reply-To: <1324407741.91.0.375379899581.issue13643@psf.upfronthosting.co.za>
Message-ID: <1482295445.63.0.830027988064.issue13643@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Also see http://bugs.python.org/issue28180 for a more recent proposal to tackle this by coercing the C locale to the C.UTF-8 locale

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13643>
_______________________________________

From report at bugs.python.org  Wed Dec 21 00:38:51 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 21 Dec 2016 05:38:51 +0000
Subject: [issue28988] Switch dict and set structures to PyVarObject
In-Reply-To: <1481900465.81.0.491407063999.issue28988@psf.upfronthosting.co.za>
Message-ID: <1482298731.46.0.629711701586.issue28988@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Please leave the set object patch for me.  I would like to do it a bit differently.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28988>
_______________________________________

From report at bugs.python.org  Wed Dec 21 01:36:24 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 21 Dec 2016 06:36:24 +0000
Subject: [issue29011] No entry Deque in typing.py
In-Reply-To: <1482128373.3.0.983889719325.issue29011@psf.upfronthosting.co.za>
Message-ID: <1482302184.87.0.693494139002.issue29011@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
components: +Library (Lib)
keywords: +patch
nosy: +ned.deily
stage:  -> patch review
type:  -> enhancement
versions: +Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45979/Deque.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29011>
_______________________________________

From report at bugs.python.org  Wed Dec 21 01:41:35 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 21 Dec 2016 06:41:35 +0000
Subject: [issue29025] random.seed() relation to hash() function and its
 determinism is vague
In-Reply-To: <1482239237.17.0.976890507022.issue29025@psf.upfronthosting.co.za>
Message-ID: <1482302495.07.0.545718786563.issue29025@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

In Python 3.5 and Python 3.6, this is already fixed (decoupled from PYTHONHASHSEED).  In Python 2.7, I could backport the fix, add a note to the docs, or just let it be (since seeding is turned off by default).  The other versions of Python are already inactive.

----------
assignee: docs at python -> rhettinger
nosy: +rhettinger
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29025>
_______________________________________

From report at bugs.python.org  Wed Dec 21 02:22:04 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 21 Dec 2016 07:22:04 +0000
Subject: [issue28975] os.walk generator giving inconsistent results
In-Reply-To: <1481753319.18.0.913748060881.issue28975@psf.upfronthosting.co.za>
Message-ID: <1482304924.6.0.0636772982354.issue28975@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
stage:  -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28975>
_______________________________________

From report at bugs.python.org  Wed Dec 21 03:13:10 2016
From: report at bugs.python.org (Thomas Heller)
Date: Wed, 21 Dec 2016 08:13:10 +0000
Subject: [issue29031] 'from module import *' and __all__
Message-ID: <1482307990.24.0.476248226278.issue29031@psf.upfronthosting.co.za>


New submission from Thomas Heller:

The documentation states that 'from module import *' imports all symbols that are listed in the module's __all__ list.
In Python 3, unlike Python 2, only symbols that do NOT start with an underscore are actually imported.

The following code works in Python 2.7, but raises a NameError
in Python 3.5:
python -c "from ctypes.wintypes import *; print(_ULARGE_INTEGER)"

----------
components: Interpreter Core
messages: 283721
nosy: theller
priority: normal
severity: normal
status: open
title: 'from module import *' and __all__
type: behavior
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29031>
_______________________________________

From report at bugs.python.org  Wed Dec 21 03:29:46 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 21 Dec 2016 08:29:46 +0000
Subject: [issue28838] Using consistent naming for arguments of "call"
 functions (C API)
In-Reply-To: <1480504437.73.0.907175245586.issue28838@psf.upfronthosting.co.za>
Message-ID: <1482308986.23.0.509019997918.issue28838@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Since no one on Python-Dev has objections, I'm fine with this too. I was opposed not so much to the changes themselves, as to making large changes to one of basic files that could affect everybody without wider discussion. Excuse me if I looked unfriendly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28838>
_______________________________________

From report at bugs.python.org  Wed Dec 21 04:06:20 2016
From: report at bugs.python.org (David)
Date: Wed, 21 Dec 2016 09:06:20 +0000
Subject: [issue29014] Python 3.5.2 installer doesn't register IDLE .py
 extensions on Windows 10
In-Reply-To: <1482147098.02.0.695368643489.issue29014@psf.upfronthosting.co.za>
Message-ID: <1482311179.99.0.962542731852.issue29014@psf.upfronthosting.co.za>


David added the comment:

Also, I created a reg file with the commands in a txt file and when I merged it, it was able to show the "Edit with IDLE" but it would do nothing. IDLE isn't there. Very perplexing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29014>
_______________________________________

From report at bugs.python.org  Wed Dec 21 04:08:52 2016
From: report at bugs.python.org (woo yoo)
Date: Wed, 21 Dec 2016 09:08:52 +0000
Subject: [issue29032] How does the __self__ attribute of method become a class
 rather a instance?
Message-ID: <1482311332.86.0.69129698975.issue29032@psf.upfronthosting.co.za>


New submission from woo yoo:

The documentation of instance methods confused me, it classifies methods into two types:the one is retrieved by an instance of a class, the other is created by retrieving a method from a class or instance.

According to the description,

>When an instance method object is created by retrieving a class method >object from a class or instance, its __self__ attribute is the class >itself, and its __func__ attribute is the function object underlying the >class method.

the  __self__ attribute of the more complex methods is a class. How does this happen? Is this description incorrect?

----------
assignee: docs at python
components: Documentation
messages: 283724
nosy: docs at python, woo yoo
priority: normal
severity: normal
status: open
title: How does the __self__ attribute of method become a class rather a instance?
type: behavior
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29032>
_______________________________________

From report at bugs.python.org  Wed Dec 21 04:12:09 2016
From: report at bugs.python.org (woo yoo)
Date: Wed, 21 Dec 2016 09:12:09 +0000
Subject: [issue29032] How does the __self__ attribute of method become a class
 rather a instance?
In-Reply-To: <1482311332.86.0.69129698975.issue29032@psf.upfronthosting.co.za>
Message-ID: <1482311529.74.0.67803459911.issue29032@psf.upfronthosting.co.za>


woo yoo added the comment:

The quotation section :

When an instance method object is created by retrieving a class method object from a class or instance, its __self__ attribute is the class itself, and its __func__ attribute is the function object underlying the class method.

The associated link is https://docs.python.org/3.6/reference/datamodel.html#the-standard-type-hierarchy ,which lies in the 'instance mthods' section.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29032>
_______________________________________

From report at bugs.python.org  Wed Dec 21 04:16:25 2016
From: report at bugs.python.org (Mr B Jones)
Date: Wed, 21 Dec 2016 09:16:25 +0000
Subject: [issue29033] Windows Python installer rolls back when run under
 SYSTEM account (SCCM)
Message-ID: <1482311785.5.0.564825395885.issue29033@psf.upfronthosting.co.za>


New submission from Mr B Jones:

Hi,
When I try to use the Python 3.5 and later installer for windows to make an automated unattended install via SCCM, it seems to work, but some time later it rolls back leaving only a few files installed (seems to be pip.exe and friends).

I have attached all the Python installer logs from a test machine from the temp folder used by the SYSTEM account (%SystemRoot%\Temp).

Manually installing from an account which is a member of the Administrators group works fine (not for 800+ machines though).
Thanks,
Bryn

----------
components: Installation, Windows
files: python352logs.zip
messages: 283726
nosy: Mr B Jones, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows Python installer rolls back when run under SYSTEM account (SCCM)
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file45980/python352logs.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29033>
_______________________________________

From report at bugs.python.org  Wed Dec 21 04:17:36 2016
From: report at bugs.python.org (woo yoo)
Date: Wed, 21 Dec 2016 09:17:36 +0000
Subject: [issue29032] How does the __self__ attribute of method become a class
 rather a instance?
In-Reply-To: <1482311332.86.0.69129698975.issue29032@psf.upfronthosting.co.za>
Message-ID: <1482311856.47.0.463442690867.issue29032@psf.upfronthosting.co.za>


woo yoo added the comment:

Not a bug,sorry to bother

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29032>
_______________________________________

From report at bugs.python.org  Wed Dec 21 04:23:16 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 21 Dec 2016 09:23:16 +0000
Subject: [issue29032] How does the __self__ attribute of method become a class
 rather a instance?
In-Reply-To: <1482311332.86.0.69129698975.issue29032@psf.upfronthosting.co.za>
Message-ID: <1482312196.31.0.955108757496.issue29032@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The description looks correct to me. Note that it says about class methods.

>>> class A:
...     @classmethod
...     def f(cls): pass
... 
>>> a = A()
>>> A.f
<bound method A.f of <class '__main__.A'>>
>>> A.f.__self__
<class '__main__.A'>
>>> a.f
<bound method A.f of <class '__main__.A'>>
>>> a.f.__self__
<class '__main__.A'>

----------
nosy: +serhiy.storchaka
resolution:  -> not a bug
stage:  -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29032>
_______________________________________

From report at bugs.python.org  Wed Dec 21 04:36:01 2016
From: report at bugs.python.org (woo yoo)
Date: Wed, 21 Dec 2016 09:36:01 +0000
Subject: [issue29032] How does the __self__ attribute of method become a class
 rather a instance?
In-Reply-To: <1482311332.86.0.69129698975.issue29032@psf.upfronthosting.co.za>
Message-ID: <1482312961.3.0.0843487413475.issue29032@psf.upfronthosting.co.za>


woo yoo added the comment:

Thanks for your reply.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29032>
_______________________________________

From report at bugs.python.org  Wed Dec 21 04:46:44 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 21 Dec 2016 09:46:44 +0000
Subject: [issue28769] Make PyUnicode_AsUTF8 returning "const char *" rather of
 "char *"
In-Reply-To: <1479801324.65.0.962202188144.issue28769@psf.upfronthosting.co.za>
Message-ID: <1482313604.11.0.766535098875.issue28769@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Addressed comments, added the versionchanged directives, the code in _decimal.c is now more obvious.

----------
Added file: http://bugs.python.org/file45981/PyUnicode_AsUTF8-const-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28769>
_______________________________________

From report at bugs.python.org  Wed Dec 21 04:47:07 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Dec 2016 09:47:07 +0000
Subject: [issue28838] Using consistent naming for arguments of "call"
 functions (C API)
In-Reply-To: <1482308986.23.0.509019997918.issue28838@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwY_Mstihui3Z32Vaa1d_ECmx_7xYuQemxBeduyOjch2bQ@mail.gmail.com>


STINNER Victor added the comment:

Serhiy Storchaka added the comment:
> Since no one on Python-Dev has objections, I'm fine with this too. I was opposed not so much to the changes themselves, as to making large changes to one of basic files that could affect everybody without wider discussion. Excuse me if I looked unfriendly.

No problem. Well, it's just reformating. It doesn't change the API for
example. It should only impact people maintaining large external
patches on Python 3.6. I'm not aware of any pending patch modifying
abstract.h. And as I wrote, if there is such patch, contact me, I will
help to rebase your change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28838>
_______________________________________

From report at bugs.python.org  Wed Dec 21 04:54:58 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Dec 2016 09:54:58 +0000
Subject: [issue28180] sys.getfilesystemencoding() should default to utf-8
In-Reply-To: <1474024622.65.0.838685461995.issue28180@psf.upfronthosting.co.za>
Message-ID: <1482314098.21.0.564262206842.issue28180@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Previous related work:

changeset:   89836:bc06f67234d0
user:        Victor Stinner <victor.stinner at gmail.com>
date:        Tue Mar 18 01:18:21 2014 +0100
files:       Doc/whatsnew/3.5.rst Lib/test/test_sys.py Misc/NEWS Python/pythonru
description:
Issue #19977: When the ``LC_TYPE`` locale is the POSIX locale (``C`` locale),
:py:data:`sys.stdin` and :py:data:`sys.stdout` are now using the
``surrogateescape`` error handler, instead of the ``strict`` error handler.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28180>
_______________________________________

From report at bugs.python.org  Wed Dec 21 04:57:41 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Dec 2016 09:57:41 +0000
Subject: [issue28988] Switch dict and set structures to PyVarObject
In-Reply-To: <1482298731.46.0.629711701586.issue28988@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbmW19Pq0XCFw0VHDKuyKS_K=kCa0Hgy786E1CVnCJVrw@mail.gmail.com>


STINNER Victor added the comment:

Raymond Hettinger:
> Please leave the set object patch for me.  I would like to do it a bit differently.

Differently? How?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28988>
_______________________________________

From report at bugs.python.org  Wed Dec 21 05:02:57 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 21 Dec 2016 10:02:57 +0000
Subject: [issue29031] 'from module import *' and __all__
In-Reply-To: <1482307990.24.0.476248226278.issue29031@psf.upfronthosting.co.za>
Message-ID: <1482314577.85.0.418855027301.issue29031@psf.upfronthosting.co.za>


Martin Panter added the comment:

Python 3 doesn?t have an __all__ list; it was removed in r85073 (Issue 3612).

I don?t understand why it was removed. Maybe Hirokazu didn?t understand what it does. Since this is a regression, perhaps it should be added back.

----------
components: +Library (Lib) -Interpreter Core
nosy: +martin.panter
versions:  -Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29031>
_______________________________________

From report at bugs.python.org  Wed Dec 21 05:07:30 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 21 Dec 2016 10:07:30 +0000
Subject: [issue28988] Switch dict and set structures to PyVarObject
In-Reply-To: <1481900465.81.0.491407063999.issue28988@psf.upfronthosting.co.za>
Message-ID: <1482314850.5.0.350361679856.issue28988@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Since I don't see a benefit from this change I leave both patches to you Raymond.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28988>
_______________________________________

From report at bugs.python.org  Wed Dec 21 05:12:21 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 21 Dec 2016 10:12:21 +0000
Subject: [issue28512] PyErr_SyntaxLocationEx() and
 PyErr_SyntaxLocationObject() always set the offset attribute to None
In-Reply-To: <1477173007.35.0.842183977255.issue28512@psf.upfronthosting.co.za>
Message-ID: <1482315141.73.0.384320265207.issue28512@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28512>
_______________________________________

From report at bugs.python.org  Wed Dec 21 05:34:58 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 21 Dec 2016 10:34:58 +0000
Subject: [issue29034] refleak in path_converter on error case
Message-ID: <1482316498.7.0.932585385435.issue29034@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

It looks like the bytes variable should be Py_DECREFed on error cases as the patch shows.

----------
components: Library (Lib)
files: path_converter.patch
keywords: patch
messages: 283736
nosy: haypo, steve.dower, xiang.zhang
priority: normal
severity: normal
stage: patch review
status: open
title: refleak in path_converter on error case
versions: Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45982/path_converter.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29034>
_______________________________________

From report at bugs.python.org  Wed Dec 21 05:44:13 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Dec 2016 10:44:13 +0000
Subject: [issue29034] refleak in path_converter on error case
In-Reply-To: <1482316498.7.0.932585385435.issue29034@psf.upfronthosting.co.za>
Message-ID: <1482317053.55.0.568316618146.issue29034@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oh crap, memory leaks on Windows are rarely checked. I recall that I found a huge memory leak on Windows just before Python 3.6 beta 1 release:

changeset:   103956:6232e610e310
branch:      3.6
parent:      103954:c1d9052996f1
user:        Victor Stinner <victor.stinner at gmail.com>
date:        Mon Sep 19 11:55:44 2016 +0200
files:       Misc/NEWS Modules/posixmodule.c
description:
Fix memory leak in path_converter()

Issue #28200: Replace PyUnicode_AsWideCharString() with
PyUnicode_AsUnicodeAndSize().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29034>
_______________________________________

From report at bugs.python.org  Wed Dec 21 05:53:45 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 21 Dec 2016 10:53:45 +0000
Subject: [issue29034] refleak in path_converter on error case
In-Reply-To: <1482316498.7.0.932585385435.issue29034@psf.upfronthosting.co.za>
Message-ID: <1482317624.99.0.595012785442.issue29034@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Ohh, I haven't read all related code so I didn't realize that's a leak. But if that is, there is still a wide = PyUnicode_AsWideCharString around the codes I altered.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29034>
_______________________________________

From report at bugs.python.org  Wed Dec 21 05:56:44 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 21 Dec 2016 10:56:44 +0000
Subject: [issue28871] Destructor of ElementTree.Element is recursive
In-Reply-To: <1480892604.34.0.360751620771.issue28871@psf.upfronthosting.co.za>
Message-ID: <20161221105641.107445.69291.C2EE446C@psf.io>


Roundup Robot added the comment:

New changeset 957091874ea0 by Serhiy Storchaka in branch '3.5':
Issue #28871: Fixed a crash when deallocate deep ElementTree.
https://hg.python.org/cpython/rev/957091874ea0

New changeset 78bf34b6a713 by Serhiy Storchaka in branch '2.7':
Issue #28871: Fixed a crash when deallocate deep ElementTree.
https://hg.python.org/cpython/rev/78bf34b6a713

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28871>
_______________________________________

From report at bugs.python.org  Wed Dec 21 05:57:11 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 21 Dec 2016 10:57:11 +0000
Subject: [issue28871] Destructor of ElementTree.Element is recursive
In-Reply-To: <1480892604.34.0.360751620771.issue28871@psf.upfronthosting.co.za>
Message-ID: <1482317831.21.0.896377047736.issue28871@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28871>
_______________________________________

From report at bugs.python.org  Wed Dec 21 05:59:47 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 21 Dec 2016 10:59:47 +0000
Subject: [issue28992] Use bytes.fromhex()
In-Reply-To: <1481920122.63.0.616252652526.issue28992@psf.upfronthosting.co.za>
Message-ID: <20161221105944.18108.81232.CF9ABDC5@psf.io>


Roundup Robot added the comment:

New changeset 44c62456de75 by Serhiy Storchaka in branch 'default':
Issue #28992: Use bytes.fromhex().
https://hg.python.org/cpython/rev/44c62456de75

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28992>
_______________________________________

From report at bugs.python.org  Wed Dec 21 06:00:02 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 21 Dec 2016 11:00:02 +0000
Subject: [issue28992] Use bytes.fromhex()
In-Reply-To: <1481920122.63.0.616252652526.issue28992@psf.upfronthosting.co.za>
Message-ID: <1482318002.63.0.651155299622.issue28992@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28992>
_______________________________________

From report at bugs.python.org  Wed Dec 21 06:08:09 2016
From: report at bugs.python.org (Manish Singh)
Date: Wed, 21 Dec 2016 11:08:09 +0000
Subject: [issue28968] xml rpc server fails with connection reset by peer error
 no 104
In-Reply-To: <1481709223.17.0.559234955094.issue28968@psf.upfronthosting.co.za>
Message-ID: <1482318489.76.0.157356441182.issue28968@psf.upfronthosting.co.za>


Manish Singh added the comment:

Hi David,

How can i port it to main python-dev list.

Need to mail on it or some other group is there so that we can send the message to it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28968>
_______________________________________

From report at bugs.python.org  Wed Dec 21 06:20:03 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 21 Dec 2016 11:20:03 +0000
Subject: [issue29034] Fix memory leak in path_converter
In-Reply-To: <1482316498.7.0.932585385435.issue29034@psf.upfronthosting.co.za>
Message-ID: <1482319203.22.0.255456966529.issue29034@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

v2 applies the comments. And another separate change is to change PyUnicode_AsWideCharString to PyUnicode_AsUnicodeAndSize.

----------
title: refleak in path_converter on error case -> Fix memory leak in path_converter
Added file: http://bugs.python.org/file45983/path_converter-v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29034>
_______________________________________

From report at bugs.python.org  Wed Dec 21 06:46:44 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 21 Dec 2016 11:46:44 +0000
Subject: [issue29034] Fix memory leak in path_converter
In-Reply-To: <1482316498.7.0.932585385435.issue29034@psf.upfronthosting.co.za>
Message-ID: <1482320804.87.0.79532774824.issue29034@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

You could just reuse to_cleanup instead of to_cleanup2.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29034>
_______________________________________

From report at bugs.python.org  Wed Dec 21 06:48:02 2016
From: report at bugs.python.org (Jakub Mateusz Kowalski)
Date: Wed, 21 Dec 2016 11:48:02 +0000
Subject: [issue29025] random.seed() relation to hash() function and its
 determinism is vague
In-Reply-To: <1482239237.17.0.976890507022.issue29025@psf.upfronthosting.co.za>
Message-ID: <1482320882.14.0.620513370827.issue29025@psf.upfronthosting.co.za>


Jakub Mateusz Kowalski added the comment:

Python 2.7
I think note to the docs is enough.

Python 3.5+
I have a doubt. Isn't .seed(a, version=1) still coupled with PYTHONHASHSEED? The manual says version 1 is "reproducing random sequences from older versions of Python", and for 3.1 (and earlier) hash() is used, which (according to the manual) depends on PYTHONHASHSEED. Also, in Python 3.2-3.4 it is stated explicitly, that hash() is used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29025>
_______________________________________

From report at bugs.python.org  Wed Dec 21 06:49:00 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 21 Dec 2016 11:49:00 +0000
Subject: [issue28538] _socket module cross-compilation error on android-24
In-Reply-To: <1477474733.85.0.0781476042155.issue28538@psf.upfronthosting.co.za>
Message-ID: <20161221114857.17174.51648.9A5E0046@psf.io>


Roundup Robot added the comment:

New changeset e248bfb0f520 by Xavier de Gaye in branch '3.6':
Issue #28538: Fix the compilation error that occurs because if_nameindex() is
https://hg.python.org/cpython/rev/e248bfb0f520

New changeset 55bf0b79ec55 by Xavier de Gaye in branch 'default':
Issue #28538: Merge 3.6.
https://hg.python.org/cpython/rev/55bf0b79ec55

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28538>
_______________________________________

From report at bugs.python.org  Wed Dec 21 06:50:16 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Dec 2016 11:50:16 +0000
Subject: [issue29034] Fix memory leak in path_converter
In-Reply-To: <1482316498.7.0.932585385435.issue29034@psf.upfronthosting.co.za>
Message-ID: <1482321016.29.0.930310151775.issue29034@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> You could just reuse to_cleanup instead of to_cleanup2.

Ah, it would be better to avoid a new variable, but this code is too complex for my head. I don't understand what is to_cleanup in this code path :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29034>
_______________________________________

From report at bugs.python.org  Wed Dec 21 06:52:52 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Dec 2016 11:52:52 +0000
Subject: [issue28992] Use bytes.fromhex()
In-Reply-To: <1481920122.63.0.616252652526.issue28992@psf.upfronthosting.co.za>
Message-ID: <1482321172.35.0.366250378886.issue28992@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Unhappy buildbot:

buildbot.python.org/all/builders/AMD64 Debian root 3.x/builds/103/steps/test/logs/stdio

Example:


======================================================================
ERROR: test_complex_address_list (test.test_email.test_headerregistry.TestAddressHeader)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/test_email/test_headerregistry.py", line 1243, in test_complex_address_list
    h = self.make_header('to', source)
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/test/test_email/test_headerregistry.py", line 78, in make_header
    return self.factory(name, value)
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/email/headerregistry.py", line 586, in __call__
    return self[name](name, value)
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/email/headerregistry.py", line 197, in __new__
    cls.parse(value, kwds)
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/email/headerregistry.py", line 337, in parse
    kwds['parse_tree'] = address_list = cls.value_parser(value)
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/email/headerregistry.py", line 328, in value_parser
    address_list, value = parser.get_address_list(value)
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/email/_header_value_parser.py", line 2336, in get_address_list
    token, value = get_address(value)
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/email/_header_value_parser.py", line 2313, in get_address
    token, value = get_group(value)
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/email/_header_value_parser.py", line 2269, in get_group
    token, value = get_display_name(value)
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/email/_header_value_parser.py", line 2095, in get_display_name
    token, value = get_phrase(value)
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/email/_header_value_parser.py", line 1770, in get_phrase
    token, value = get_word(value)
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/email/_header_value_parser.py", line 1751, in get_word
    token, value = get_atom(value)
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/email/_header_value_parser.py", line 1668, in get_atom
    token, value = get_encoded_word(value)
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/email/_header_value_parser.py", line 1444, in get_encoded_word
    text, charset, lang, defects = _ew.decode('=?' + tok + '?=')
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/email/_encoded_words.py", line 166, in decode
    bstring, defects = _cte_decoders[cte](bstring)
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/email/_encoded_words.py", line 69, in decode_q
    return _q_byte_subber(encoded), []
  File "/root/buildarea/3.x.angelico-debian-amd64/build/Lib/email/_encoded_words.py", line 65, in <lambda>
    lambda m: bytes.fromhex(m.group(1)))
TypeError: fromhex() argument must be str, not bytes

----------
nosy: +haypo
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28992>
_______________________________________

From report at bugs.python.org  Wed Dec 21 07:04:39 2016
From: report at bugs.python.org (eryk sun)
Date: Wed, 21 Dec 2016 12:04:39 +0000
Subject: [issue29031] 'from module import *' and __all__
In-Reply-To: <1482307990.24.0.476248226278.issue29031@psf.upfronthosting.co.za>
Message-ID: <1482321879.13.0.596804950998.issue29031@psf.upfronthosting.co.za>


eryk sun added the comment:

Python 3 does not skip names in __all__ that start with an underscore. 

wintypes in 2.x uses `from ctypes import *`, so it needs to define __all__. In 3.x it uses `import ctypes`, so it doesn't define __all__, and the private names _COORD, _FILETIME, _LARGE_INTEGER, _POINTL, _RECTL, _SMALL_RECT, and _ULARGE_INTEGER are skipped by a star import. That said, why are these private names (and also "tag" names) defined? And why isn't COORD defined instead of or in addition to _COORD?

----------
nosy: +eryk sun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29031>
_______________________________________

From report at bugs.python.org  Wed Dec 21 07:09:16 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 21 Dec 2016 12:09:16 +0000
Subject: [issue28992] Use bytes.fromhex()
In-Reply-To: <1481920122.63.0.616252652526.issue28992@psf.upfronthosting.co.za>
Message-ID: <20161221120913.107800.18912.063ABC04@psf.io>


Roundup Robot added the comment:

New changeset 6ced540a92bc by Serhiy Storchaka in branch 'default':
Fixed a type error introduced in issue #28992.
https://hg.python.org/cpython/rev/6ced540a92bc

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28992>
_______________________________________

From report at bugs.python.org  Wed Dec 21 07:09:56 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 21 Dec 2016 12:09:56 +0000
Subject: [issue28992] Use bytes.fromhex()
In-Reply-To: <1481920122.63.0.616252652526.issue28992@psf.upfronthosting.co.za>
Message-ID: <1482322196.46.0.799066610046.issue28992@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Oh how could I make such error?! Thanks Victor.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28992>
_______________________________________

From report at bugs.python.org  Wed Dec 21 07:11:44 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Dec 2016 12:11:44 +0000
Subject: [issue28992] Use bytes.fromhex()
In-Reply-To: <1481920122.63.0.616252652526.issue28992@psf.upfronthosting.co.za>
Message-ID: <1482322304.41.0.355434217606.issue28992@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Serhiy: "Oh how could I make such error?! Thanks Victor.

It's simple: shit happens :-) Don't worry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28992>
_______________________________________

From report at bugs.python.org  Wed Dec 21 07:36:55 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Wed, 21 Dec 2016 12:36:55 +0000
Subject: [issue28762] configure links with lockf and F_LOCK is not declared in
 Android API 24
In-Reply-To: <1479723589.5.0.525775136475.issue28762@psf.upfronthosting.co.za>
Message-ID: <1482323815.5.0.894653558824.issue28762@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

FYI: Since Android NDK r14 beta1, F_LOCK is defined in unified headers. [1] In $ANDROID_NDK/sysroot/usr/include/bits/lockf.h:

#define F_ULOCK 0
#define F_LOCK 1
#define F_TLOCK 2
#define F_TEST 3

[1] https://android.googlesource.com/platform/ndk.git/+/master/docs/UnifiedHeaders.md

----------
nosy: +Chi Hsuan Yen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28762>
_______________________________________

From report at bugs.python.org  Wed Dec 21 07:55:07 2016
From: report at bugs.python.org (R. David Murray)
Date: Wed, 21 Dec 2016 12:55:07 +0000
Subject: [issue28968] xml rpc server fails with connection reset by peer error
 no 104
In-Reply-To: <1481709223.17.0.559234955094.issue28968@psf.upfronthosting.co.za>
Message-ID: <1482324907.69.0.732206561158.issue28968@psf.upfronthosting.co.za>


R. David Murray added the comment:

The python-list mailing list subscription info can be found on the mail.python.org web page.  It is also gatewayed to a usenet news group.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28968>
_______________________________________

From report at bugs.python.org  Wed Dec 21 09:19:07 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 21 Dec 2016 14:19:07 +0000
Subject: [issue29034] Fix memory leak in path_converter
In-Reply-To: <1482316498.7.0.932585385435.issue29034@psf.upfronthosting.co.za>
Message-ID: <1482329947.79.0.810221042209.issue29034@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Hmm, while considering Victor's comment, I find some new:

path->object refers to the original object o, it owns a borrowed reference. But when received a PathLike object, o is assigned the return value of __fspath__ and decrefed at end. So path->object could refer to a already freed object.

And the PyUnicode_AsWideCharString can't be simply replaced with PyUnicode_AsUnicodeAndSize since wo is decrefed and object->wide could then refer to freed memory.

The logic is complex and I get headache reading the code. Did I miss something?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29034>
_______________________________________

From report at bugs.python.org  Wed Dec 21 09:28:14 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Dec 2016 14:28:14 +0000
Subject: [issue29035] regrtest: simplify regex to match test names for the
 --fromfile option
Message-ID: <1482330494.19.0.986324681201.issue29035@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Lib/test/libregrtest/main.py uses a complex regex to find "test_builtin" in lines like '0:00:00 [  4/400] test_builtin -- test_dict took 1 sec'. Recently, I changed (change d8222c197831) the regex to support a filename containing a list of filenames. Example:

haypo at selma$ ls Lib/test/test_*xml*py >| list

haypo at selma$ cat list 
Lib/test/test_docxmlrpc.py
Lib/test/test_xml_dom_minicompat.py
Lib/test/test_xml_etree_c.py
Lib/test/test_xml_etree.py
Lib/test/test_xmlrpc_net.py
Lib/test/test_xmlrpc.py

haypo at selma$ ./python -m test --fromfile=list --list
test_docxmlrpc
test_xml_dom_minicompat
test_xml_etree_c
test_xml_etree
test_xmlrpc_net
test_xmlrpc

Serhiy sent me a private message to suggest to simply the regex. So here is a patch.

----------
components: Tests
files: regrtest_regex.patch
keywords: patch
messages: 283755
nosy: haypo, inada.naoki, serhiy.storchaka, xiang.zhang
priority: normal
severity: normal
status: open
title: regrtest: simplify regex to match test names for the --fromfile option
versions: Python 3.7
Added file: http://bugs.python.org/file45984/regrtest_regex.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29035>
_______________________________________

From report at bugs.python.org  Wed Dec 21 09:30:20 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Dec 2016 14:30:20 +0000
Subject: [issue29035] regrtest: simplify regex to match test names for the
 --fromfile option
In-Reply-To: <1482330494.19.0.986324681201.issue29035@psf.upfronthosting.co.za>
Message-ID: <1482330620.44.0.744537689609.issue29035@psf.upfronthosting.co.za>


STINNER Victor added the comment:

FYI initially my idea was to use a very strict to avoid false positives. But when I used the feature, I found that the regex is more annoying than helping (ex: I had to modify the regex to accept filenames with directories). So I now prefer to use a very simple regex matching "test_xxx" anywhere, to have something simple and convenient.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29035>
_______________________________________

From report at bugs.python.org  Wed Dec 21 09:52:43 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Dec 2016 14:52:43 +0000
Subject: [issue29034] Fix memory leak in path_converter
In-Reply-To: <1482329947.79.0.810221042209.issue29034@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwYx2ciAMUthk13FSpagTeWH9Cy_r2obVQ7iUPkueQBWZA@mail.gmail.com>


STINNER Victor added the comment:

> The logic is complex ...

Yeah, that's why I first proposed to add a dummy to_cleanup2 object.

Another option is to use your first patch.

I don't care much about the exact implementation :-) Maybe Serhiy has
a better understanding of the code and can help to decide on this
issue ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29034>
_______________________________________

From report at bugs.python.org  Wed Dec 21 09:54:58 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Dec 2016 14:54:58 +0000
Subject: [issue28762] configure links with lockf and F_LOCK is not declared in
 Android API 24
In-Reply-To: <1479723589.5.0.525775136475.issue28762@psf.upfronthosting.co.za>
Message-ID: <1482332098.4.0.323277462872.issue28762@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> The patch fixes the following error:

Do you mean that the patch adds posix.F_LOCK constant on Android?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28762>
_______________________________________

From report at bugs.python.org  Wed Dec 21 10:12:02 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 21 Dec 2016 15:12:02 +0000
Subject: [issue28762] configure links with lockf and F_LOCK is not declared in
 Android API 24
In-Reply-To: <1479723589.5.0.525775136475.issue28762@psf.upfronthosting.co.za>
Message-ID: <1482333122.84.0.804568317318.issue28762@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

No, the patch prevents posix.flock() to be defined on Android API 24 with android-ndk-r13. But I plan to change it so that the test is skipped when posix does not have the F_LOCK attribute as this problem is not worth a change in the build machinery. It makes even more sense now that android-ndk-r14 will be released with "Unified Headers". BTW thanks Chi Hsuan Yen for this important information.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28762>
_______________________________________

From report at bugs.python.org  Wed Dec 21 10:32:54 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 21 Dec 2016 15:32:54 +0000
Subject: [issue29034] Fix memory leak in path_converter
In-Reply-To: <1482316498.7.0.932585385435.issue29034@psf.upfronthosting.co.za>
Message-ID: <1482334374.98.0.494123857202.issue29034@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There are many ways to write a solution of the original issue. You can just add a number of "Py_DECREF(bytes)" (path_converter.patch), or add new variable to_cleanup2 (path_converter-v2.patch), or reuse to_cleanup (path_converter-to_cleanup.patch), or clean ups bytes (path_converter-bytes.patch). All these ways look equivalent.

The issue mentioned in msg283754 is more severe. It can be solved by making path->object referring an original argument (but some code checks the type of path->object), or making path->object owning a reference.

It seems to me that path->narrow can be not initialized for str path on Windows.

----------
nosy: +brett.cannon
Added file: http://bugs.python.org/file45985/path_converter-to_cleanup.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29034>
_______________________________________

From report at bugs.python.org  Wed Dec 21 10:33:12 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 21 Dec 2016 15:33:12 +0000
Subject: [issue29034] Fix memory leak in path_converter
In-Reply-To: <1482316498.7.0.932585385435.issue29034@psf.upfronthosting.co.za>
Message-ID: <1482334392.56.0.0644394135519.issue29034@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


Added file: http://bugs.python.org/file45986/path_converter-bytes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29034>
_______________________________________

From report at bugs.python.org  Wed Dec 21 10:44:23 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 21 Dec 2016 15:44:23 +0000
Subject: [issue29035] regrtest: simplify regex to match test names for the
 --fromfile option
In-Reply-To: <1482330494.19.0.986324681201.issue29035@psf.upfronthosting.co.za>
Message-ID: <1482335063.25.0.632509222547.issue29035@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Reading file names from a file looks misleading.

$ ls Lib/ctypes/test/*.py > list
$ head list
Lib/ctypes/test/__init__.py
Lib/ctypes/test/__main__.py
Lib/ctypes/test/test_anon.py
Lib/ctypes/test/test_array_in_pointer.py
Lib/ctypes/test/test_arrays.py
Lib/ctypes/test/test_as_parameter.py
Lib/ctypes/test/test_bitfields.py
Lib/ctypes/test/test_buffers.py
Lib/ctypes/test/test_bytes.py
Lib/ctypes/test/test_byteswap.py
$ ./python -m test --fromfile=list 
Run tests sequentially
0:00:00 [ 1/51] test_anon
test test_anon crashed -- Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/test/libregrtest/runtest.py", line 152, in runtest_inner
    the_module = importlib.import_module(abstest)
  File "/home/serhiy/py/cpython/Lib/importlib/__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 978, in _gcd_import
  File "<frozen importlib._bootstrap>", line 961, in _find_and_load
  File "<frozen importlib._bootstrap>", line 948, in _find_and_load_unlocked
ModuleNotFoundError: No module named 'test.test_anon'
...

I wouldn't add this feature unless support full file names.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29035>
_______________________________________

From report at bugs.python.org  Wed Dec 21 10:51:44 2016
From: report at bugs.python.org (Steve Dower)
Date: Wed, 21 Dec 2016 15:51:44 +0000
Subject: [issue29014] Python 3.5.2 installer doesn't register IDLE .py
 extensions on Windows 10
In-Reply-To: <1482147098.02.0.695368643489.issue29014@psf.upfronthosting.co.za>
Message-ID: <1482335504.19.0.176567565197.issue29014@psf.upfronthosting.co.za>


Steve Dower added the comment:

But you definitely have idle installed, right? The commands earlier made an assumption about your installation that could be wrong, so that would explain it.

I'm still not entirely clear whether you've done these steps yet:

1. Right-click a .py file and select Open With
1a. If this gives you a deeper menu, select Another App
2. Find the Python launcher in the window that appears and select it.
3. Select Always Open with this app check box
4. Click Open/ok/whatever button is on there

That should reset your personal customization back to the original shortcut.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29014>
_______________________________________

From report at bugs.python.org  Wed Dec 21 10:55:23 2016
From: report at bugs.python.org (Thomas Heller)
Date: Wed, 21 Dec 2016 15:55:23 +0000
Subject: [issue29031] 'from module import *' and __all__
In-Reply-To: <1482321879.13.0.596804950998.issue29031@psf.upfronthosting.co.za>
Message-ID: <de5772b4-6ebe-9396-84e3-a20425baeca6@ctypes.org>


Thomas Heller added the comment:

Thanks Martin and eryk for correcting me and finding the real cause of
the problem.

Am 21.12.2016 um 13:04 schrieb eryk sun:
> ...  the private names _COORD, _FILETIME, _LARGE_INTEGER,
> _POINTL, _RECTL, _SMALL_RECT, and _ULARGE_INTEGER are skipped by a
> star import. That said, why are these private names (and also "tag"
> names) defined? And why isn't COORD defined instead of or in addition
> to _COORD?

These 'private' names and "tag" names were defined for compatibility
with the windows SDK C header files.  I didn't want to apply
the Python 'private' convention to the C names, so they were added to
the __all__ list.
It was an oversight that COORD wasn't defined, I developed a different
solution for the windows SDK names afterwards, but my code (which I'm
porting to Python 3) still uses 'from ctypes.wintypes import *'
and stumbled over the regression just now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29031>
_______________________________________

From report at bugs.python.org  Wed Dec 21 11:00:47 2016
From: report at bugs.python.org (Akira Li)
Date: Wed, 21 Dec 2016 16:00:47 +0000
Subject: [issue28180] sys.getfilesystemencoding() should default to utf-8
In-Reply-To: <1474024622.65.0.838685461995.issue28180@psf.upfronthosting.co.za>
Message-ID: <1482336047.58.0.0678661407081.issue28180@psf.upfronthosting.co.za>


Changes by Akira Li <4kir4.1i at gmail.com>:


----------
nosy: +akira

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28180>
_______________________________________

From report at bugs.python.org  Wed Dec 21 11:15:12 2016
From: report at bugs.python.org (Ram Rachum)
Date: Wed, 21 Dec 2016 16:15:12 +0000
Subject: [issue29036] logging module: Add `full_module_name` to LogRecord
 details
Message-ID: <1482336912.68.0.293105867979.issue29036@psf.upfronthosting.co.za>


New submission from Ram Rachum:

LogRecord currently supplies `module` that you can show in your messages, but it's just the name of the module without the path. It'll be nice to have `full_module_name` that has the qualified name (e.g. foo.bar.baz instead of baz.)

Usually it's the logger's name, but not always.

----------
components: Library (Lib)
messages: 283764
nosy: cool-RR
priority: normal
severity: normal
status: open
title: logging module: Add `full_module_name` to LogRecord details
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29036>
_______________________________________

From report at bugs.python.org  Wed Dec 21 11:23:19 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 21 Dec 2016 16:23:19 +0000
Subject: [issue28538] _socket module cross-compilation error on android-24
In-Reply-To: <1477474733.85.0.0781476042155.issue28538@psf.upfronthosting.co.za>
Message-ID: <1482337399.68.0.966709585262.issue28538@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

These changes break the darwin platform, socket.if_nameindex() is not defined anymore. On Darwin, 'net/if.h' requires that 'sys/socket.h' be included beforehand (see the autoconf documentation).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28538>
_______________________________________

From report at bugs.python.org  Wed Dec 21 11:23:27 2016
From: report at bugs.python.org (Joshua Bronson)
Date: Wed, 21 Dec 2016 16:23:27 +0000
Subject: [issue28912] collections.abc.OrderedMapping
In-Reply-To: <1481238034.34.0.119082165821.issue28912@psf.upfronthosting.co.za>
Message-ID: <1482337407.47.0.796578285125.issue28912@psf.upfronthosting.co.za>


Joshua Bronson added the comment:

For the record, it looks like Victor Stinner suggested doing this in https://mail.python.org/pipermail/python-dev/2016-September/146349.html

Brett Cannon replied in https://mail.python.org/pipermail/python-dev/2016-September/146350.html to suggest adding "ordered mapping" to the glossary instead. I took a quick look at https://docs.python.org/3.6/glossary.html and don't see it there.

----------
nosy: +brett.cannon, haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28912>
_______________________________________

From report at bugs.python.org  Wed Dec 21 11:28:18 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Dec 2016 16:28:18 +0000
Subject: [issue28762] configure links with lockf and F_LOCK is not declared in
 Android API 24
In-Reply-To: <1479723589.5.0.525775136475.issue28762@psf.upfronthosting.co.za>
Message-ID: <1482337698.76.0.806264900491.issue28762@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Oh ok, the issue is more subtle than what I understood.

I reviewed test_posix_flock.patch and proposed some changes to the comment/doc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28762>
_______________________________________

From report at bugs.python.org  Wed Dec 21 11:31:38 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 21 Dec 2016 16:31:38 +0000
Subject: [issue28538] _socket module cross-compilation error on android-24
In-Reply-To: <1477474733.85.0.0781476042155.issue28538@psf.upfronthosting.co.za>
Message-ID: <20161221163134.20377.89826.1ACE8985@psf.io>


Roundup Robot added the comment:

New changeset f34dac552ad8 by Xavier de Gaye in branch '3.6':
Issue #28538: On Darwin net/if.h requires that sys/socket.h be included beforehand.
https://hg.python.org/cpython/rev/f34dac552ad8

New changeset c568b6ac5e89 by Xavier de Gaye in branch 'default':
Issue #28538: Merge 3.6.
https://hg.python.org/cpython/rev/c568b6ac5e89

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28538>
_______________________________________

From report at bugs.python.org  Wed Dec 21 11:32:33 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Dec 2016 16:32:33 +0000
Subject: [issue29035] regrtest: simplify regex to match test names for the
 --fromfile option
In-Reply-To: <1482335063.25.0.632509222547.issue29035@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZuJeRYfqSZ2R7zAXz2RgY9kPSHvDuuh_ALQg3U9Xd54A@mail.gmail.com>


STINNER Victor added the comment:

Ah right, "Lib/ctypes/test/test_anon.py" doesn't work. I don't think
that it's worth to support running directly such test. I don't think
that it's worth it to modify the regex to exclude this case.

--fromfile is written for developers who understand what they do, it's
just an helper. It doesn't prevent any kind of mistakes.

But please keep support for simple lists like "ls
Lib/test/test_*xml*py >| list", it's useful for me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29035>
_______________________________________

From report at bugs.python.org  Wed Dec 21 12:18:07 2016
From: report at bugs.python.org (Steve Dower)
Date: Wed, 21 Dec 2016 17:18:07 +0000
Subject: [issue23903] Generate PC/python3.def by scraping headers
In-Reply-To: <1428637761.13.0.348463350169.issue23903@psf.upfronthosting.co.za>
Message-ID: <1482340687.21.0.325328669941.issue23903@psf.upfronthosting.co.za>


Steve Dower added the comment:

Guess I should at least pose the question - Ned, would you consider the change in my patch for 3.6.0? Only the one file is affected, and it only contributes to one DLL that is (a) recommended, (b) not widely used and (c) very incompatible with the included headers.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23903>
_______________________________________

From report at bugs.python.org  Wed Dec 21 13:33:47 2016
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Wed, 21 Dec 2016 18:33:47 +0000
Subject: [issue16058] ConfigParser no longer deepcopy compatible in 2.7
In-Reply-To: <1348705133.3.0.138375656992.issue16058@psf.upfronthosting.co.za>
Message-ID: <1482345227.15.0.976781349957.issue16058@psf.upfronthosting.co.za>


?ukasz Langa added the comment:

Solved in 3.2+ by making it compatible with the Mapping protocol. So while you can't do deepcopy(), you can `parser2.read_dict(parser1)`.

----------
dependencies:  -Regex objects became uncopyable in 2.5
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16058>
_______________________________________

From report at bugs.python.org  Wed Dec 21 14:00:35 2016
From: report at bugs.python.org (A.B., Khalid)
Date: Wed, 21 Dec 2016 19:00:35 +0000
Subject: [issue29037] Python 2.7.13 prints version header and exits
 immediately on Windows 10 x64
Message-ID: <1482346835.39.0.82709495756.issue29037@psf.upfronthosting.co.za>


New submission from A.B., Khalid:

I updated my Python 2.7.12 to 2.7.13 on Windows 10 x64. When I run it in Windows command prompt shell, Python prints the version header and then exits immediately. Like so:

"""
E:\Users\thisuser>python
Python 2.7.13 (v2.7.13:a06454b1afa1, Dec 17 2016, 20:53:40) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.

E:\Users\thisuser>
"""

This did not happen before.

The same happens when Python is run from a powershell. I have no problems running ipython or jupyter notebook, however. And Python does the right thing when run under MSYS2, like so:

"""
$ python -i
Python 2.7.13 (v2.7.13:a06454b1afa1, Dec 17 2016, 20:53:40) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>>
"""

Could this be an encoding problem? Because MSYS2 is fairly new and I think it might be more friendly to the encoding issues related to Windows shell programming.

----------
components: Windows
messages: 283773
nosy: abkhd, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Python 2.7.13 prints version header and exits immediately on Windows 10 x64
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29037>
_______________________________________

From report at bugs.python.org  Wed Dec 21 14:00:56 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 21 Dec 2016 19:00:56 +0000
Subject: [issue29035] regrtest: simplify regex to match test names for the
 --fromfile option
In-Reply-To: <1482330494.19.0.986324681201.issue29035@psf.upfronthosting.co.za>
Message-ID: <1482346856.84.0.48804193894.issue29035@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> --fromfile is written for developers who understand what they do, it's
> just an helper.

I don't understand the use case of it ;) , but when you need it, the patch LGTM.

You can call just .group() instead of .group(0).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29035>
_______________________________________

From report at bugs.python.org  Wed Dec 21 14:29:17 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 21 Dec 2016 19:29:17 +0000
Subject: [issue28992] Use bytes.fromhex()
In-Reply-To: <1481920122.63.0.616252652526.issue28992@psf.upfronthosting.co.za>
Message-ID: <1482348557.42.0.347333721585.issue28992@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28992>
_______________________________________

From report at bugs.python.org  Wed Dec 21 14:35:42 2016
From: report at bugs.python.org (Daniel Bolgheroni)
Date: Wed, 21 Dec 2016 19:35:42 +0000
Subject: [issue29038] Duplicate entry for SSLContext.get_ca_certs() in ssl
Message-ID: <1482348942.9.0.649967135375.issue29038@psf.upfronthosting.co.za>


New submission from Daniel Bolgheroni:

There is a duplicate entry for SSLContext.get_ca_certs() in ssl section 17.3.3. They are not equal, and the one that appears first has a more detailed description.

----------
assignee: docs at python
components: Documentation
messages: 283775
nosy: dbolgheroni, docs at python
priority: normal
severity: normal
status: open
title: Duplicate entry for SSLContext.get_ca_certs() in ssl
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29038>
_______________________________________

From report at bugs.python.org  Wed Dec 21 14:48:45 2016
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 21 Dec 2016 19:48:45 +0000
Subject: [issue24672] shutil.rmtree fails on non ascii filenames
In-Reply-To: <1437381607.37.0.102405626215.issue24672@psf.upfronthosting.co.za>
Message-ID: <1482349725.62.0.0984295929313.issue24672@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

In https://github.com/pypa/setuptools/issues/706, I've addressed this additional concern.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24672>
_______________________________________

From report at bugs.python.org  Wed Dec 21 14:50:49 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 21 Dec 2016 19:50:49 +0000
Subject: [issue28538] _socket module cross-compilation error on android-24
In-Reply-To: <1477474733.85.0.0781476042155.issue28538@psf.upfronthosting.co.za>
Message-ID: <1482349849.91.0.236468106946.issue28538@psf.upfronthosting.co.za>


Changes by Xavier de Gaye <xdegaye at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28538>
_______________________________________

From report at bugs.python.org  Wed Dec 21 14:52:12 2016
From: report at bugs.python.org (Matteo Cafasso)
Date: Wed, 21 Dec 2016 19:52:12 +0000
Subject: [issue29039] Segmentation fault when using PyUnicode_FromString
Message-ID: <1482349932.8.0.094002567537.issue29039@psf.upfronthosting.co.za>


New submission from Matteo Cafasso:

The following code snippet:

----------------------------------------------
#include <stdio.h>
#include <Python.h>

int main()
{
    char *broken_string[8];
    char broken_char = 4294967252;

    sprintf(broken_string, "%c", broken_char);

    PyUnicode_FromString(broken_string);
}
----------------------------------------------

Produces a Segmentation Fault.

Is this behaviour the expected one? 

The real life example comes when reading a malformed path on a Ext4 filesystem. The read string causes PyUnicode_FromString to segfault.

----------
components: Extension Modules
messages: 283777
nosy: noxdafox
priority: normal
severity: normal
status: open
title: Segmentation fault when using PyUnicode_FromString
type: crash
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29039>
_______________________________________

From report at bugs.python.org  Wed Dec 21 15:11:01 2016
From: report at bugs.python.org (Sworddragon)
Date: Wed, 21 Dec 2016 20:11:01 +0000
Subject: [issue28180] sys.getfilesystemencoding() should default to utf-8
In-Reply-To: <1474024622.65.0.838685461995.issue28180@psf.upfronthosting.co.za>
Message-ID: <1482351061.74.0.234778741958.issue28180@psf.upfronthosting.co.za>


Changes by Sworddragon <sworddragon2 at aol.com>:


----------
nosy: +Sworddragon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28180>
_______________________________________

From report at bugs.python.org  Wed Dec 21 15:24:25 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 21 Dec 2016 20:24:25 +0000
Subject: [issue29040] building Android with android-ndk-r14
Message-ID: <1482351865.89.0.655034997181.issue29040@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

android-ndk-r14 introduces "Unified Headers" [1] and is planned to be released late january/early february 2017 [2].

__ANDROID_API__ is not anymore defined in 'android/api-level.h' that is currently included by Include/pyport.h, and is passed instead with -D__ANDROID_API__=$API when compiling. And 'android/api-level.h' is now used to set the API level to 10000 as a Magic version number for a current development build when __ANDROID_API__ is not defined (see attached file).

Adoption of android-ndk-r14 should be made with the following changes:
* Remove the include of <android/api-level.h> in Include/pyport.h.
* Update configure.ac to abort when __ANDROID__ is defined and __ANDROID_API__ is not defined.
* Revert the changes made in issues #28538 and #28762, android-ndk-r14 fixes the problems raised in these two issues.

[1] https://android.googlesource.com/platform/ndk.git/+/master/docs/UnifiedHeaders.md
[2] https://github.com/android-ndk/ndk/wiki

----------
components: Cross-Build
files: api-level.h
messages: 283778
nosy: Alex.Willmer, xdegaye
priority: normal
severity: normal
stage: needs patch
status: open
title: building Android with android-ndk-r14
type: compile error
versions: Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45987/api-level.h

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29040>
_______________________________________

From report at bugs.python.org  Wed Dec 21 15:26:05 2016
From: report at bugs.python.org (David)
Date: Wed, 21 Dec 2016 20:26:05 +0000
Subject: [issue29014] Python 3.5.2 installer doesn't register IDLE .py
 extensions on Windows 10
In-Reply-To: <1482147098.02.0.695368643489.issue29014@psf.upfronthosting.co.za>
Message-ID: <1482351965.63.0.677498372768.issue29014@psf.upfronthosting.co.za>


David added the comment:

Yes, I have IDLE installed, and Launcher is installed as well. I can open up IDLE from the shortcut, however I am not able to access it within "Open With" or "Default Programs" or "Change" (within Properties). I _can_ open up the file only if I open up IDLE first then click "File" and then "Open" of the .py file in question. But the process of doing that compared to just double-clicking the IDLE-associated .py file is enormous and a workaround I'm trying to avoid. 

I've done steps 1-4 on a clean installation however there is one thing missing: the Python Launcher. It does not appear in the list of programs to choose. I tried everything up to and including idle.bat. But I'm not going to use idle.bat, that is a workaround I'm also trying to avoid. I just want a correct installation. I think it has something to do with my OS preventing the Python Installer from tinkering with the "Open With" options. 

The original shortcut for a clean installation for me is the python run command in the command-prompt. I need to able to see the code in IDLE when I double click on a .py file. 

Thank you for your help.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29014>
_______________________________________

From report at bugs.python.org  Wed Dec 21 15:27:49 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 21 Dec 2016 20:27:49 +0000
Subject: [issue26865] Meta-issue: support of the android platform
In-Reply-To: <1461685011.99.0.617135447086.issue26865@psf.upfronthosting.co.za>
Message-ID: <1482352069.21.0.694294278648.issue26865@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

issue #29040: building Android with android-ndk-r14

----------
dependencies: +building Android with android-ndk-r14

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26865>
_______________________________________

From report at bugs.python.org  Wed Dec 21 15:33:03 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 21 Dec 2016 20:33:03 +0000
Subject: [issue28762] configure links with lockf and F_LOCK is not declared in
 Android API 24
In-Reply-To: <1479723589.5.0.525775136475.issue28762@psf.upfronthosting.co.za>
Message-ID: <1482352383.02.0.406822074019.issue28762@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Thanks for the review Victor.

I have created issue 29040: building Android with android-ndk-r14.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28762>
_______________________________________

From report at bugs.python.org  Wed Dec 21 15:38:14 2016
From: report at bugs.python.org (Gennady Kovalev)
Date: Wed, 21 Dec 2016 20:38:14 +0000
Subject: [issue28695] Add SSL_CTX_set_client_cert_engine
In-Reply-To: <1479207688.81.0.066994858547.issue28695@psf.upfronthosting.co.za>
Message-ID: <1482352694.75.0.509687478038.issue28695@psf.upfronthosting.co.za>


Gennady Kovalev added the comment:

Why not to call OPENSSL_config() to use openssl.cnf?

--- ./Modules/_ssl.c.orig       2016-12-21 23:30:36.277184891 +0300
+++ ./Modules/_ssl.c    2016-12-21 23:35:18.488508435 +0300
@@ -4514,6 +4514,8 @@
     PySocketModule = *socket_api;
 
     /* Init OpenSSL */
+    OPENSSL_config(NULL);
+
     SSL_load_error_strings();
     SSL_library_init();
 #ifdef WITH_THREAD

(Patch for example, for 3.5.2 source, not try to compile)

----------
nosy: +gik

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28695>
_______________________________________

From report at bugs.python.org  Wed Dec 21 15:41:52 2016
From: report at bugs.python.org (eryk sun)
Date: Wed, 21 Dec 2016 20:41:52 +0000
Subject: [issue29014] Python 3.5.2 installer doesn't register IDLE .py
 extensions on Windows 10
In-Reply-To: <1482147098.02.0.695368643489.issue29014@psf.upfronthosting.co.za>
Message-ID: <1482352912.13.0.881920685229.issue29014@psf.upfronthosting.co.za>


eryk sun added the comment:

There are many possible points of failure, so I'd like to get a clearer picture of your system configuration. Please download and run the attached batch file "dump_py_config.bat" and upload the "py_config.txt" file that it creates.

----------
Added file: http://bugs.python.org/file45988/dump_py_config.bat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29014>
_______________________________________

From report at bugs.python.org  Wed Dec 21 15:52:43 2016
From: report at bugs.python.org (Ned Deily)
Date: Wed, 21 Dec 2016 20:52:43 +0000
Subject: [issue23903] Generate PC/python3.def by scraping headers
In-Reply-To: <1428637761.13.0.348463350169.issue23903@psf.upfronthosting.co.za>
Message-ID: <1482353563.27.0.344998042183.issue23903@psf.upfronthosting.co.za>


Ned Deily added the comment:

I don't know enough about how python3.dll is used in the Windows world to ask the right questions.  One obvious one: would this change likely affect any third-party binaries already built for 3.6.0?  On the other hand, if we have to have one, it would be better to have a compatibility break at 3.6.0 rather than at 3.6.1.  I really don't want to take any more changes at this point for 3.6.0 but if you are convinced it is the right thing to do and won't break anything, get it in for 3.6.1 now and I'll reluctantly cherrypick it for 3.6.0.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23903>
_______________________________________

From report at bugs.python.org  Wed Dec 21 15:54:07 2016
From: report at bugs.python.org (eryk sun)
Date: Wed, 21 Dec 2016 20:54:07 +0000
Subject: [issue29014] Python 3.5.2 installer doesn't register IDLE .py
 extensions on Windows 10
In-Reply-To: <1482147098.02.0.695368643489.issue29014@psf.upfronthosting.co.za>
Message-ID: <1482353647.94.0.590248217056.issue29014@psf.upfronthosting.co.za>


Changes by eryk sun <eryksun at gmail.com>:


Removed file: http://bugs.python.org/file45988/dump_py_config.bat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29014>
_______________________________________

From report at bugs.python.org  Wed Dec 21 15:57:33 2016
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 21 Dec 2016 20:57:33 +0000
Subject: [issue29014] Python 3.5.2 installer doesn't register IDLE .py
 extensions on Windows 10
In-Reply-To: <1482147098.02.0.695368643489.issue29014@psf.upfronthosting.co.za>
Message-ID: <1482353853.94.0.587853184448.issue29014@psf.upfronthosting.co.za>


Changes by Eryk Sun <eryksun+pybugs at gmail.com>:


Added file: http://bugs.python.org/file45989/dump_py_config.bat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29014>
_______________________________________

From report at bugs.python.org  Wed Dec 21 16:09:38 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 21 Dec 2016 21:09:38 +0000
Subject: [issue28762] lockf() is available now on Android API level 24,
 but the F_LOCK macro is not defined
In-Reply-To: <1479723589.5.0.525775136475.issue28762@psf.upfronthosting.co.za>
Message-ID: <1482354578.11.0.749115415029.issue28762@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

New patch.
Please use autoreconf before running the patch (autoreconf instead of autoconf because the description of HAVE_LOCKF has been updated).

----------
title: configure links with lockf and F_LOCK is not declared in Android API 24 -> lockf() is available now on Android API level 24, but the F_LOCK macro is not defined
Added file: http://bugs.python.org/file45990/test_posix_lockf_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28762>
_______________________________________

From report at bugs.python.org  Wed Dec 21 16:22:58 2016
From: report at bugs.python.org (David)
Date: Wed, 21 Dec 2016 21:22:58 +0000
Subject: [issue29014] Python 3.5.2 installer doesn't register IDLE .py
 extensions on Windows 10
In-Reply-To: <1482147098.02.0.695368643489.issue29014@psf.upfronthosting.co.za>
Message-ID: <1482355378.21.0.987705190712.issue29014@psf.upfronthosting.co.za>


David added the comment:

Thank you for your help. Attached is the py_config.txt that your .bat file gave me.

----------
Added file: http://bugs.python.org/file45991/py_config.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29014>
_______________________________________

From report at bugs.python.org  Wed Dec 21 16:54:26 2016
From: report at bugs.python.org (Christoph Reiter)
Date: Wed, 21 Dec 2016 21:54:26 +0000
Subject: [issue29039] Segmentation fault when using PyUnicode_FromString
In-Reply-To: <1482349932.8.0.094002567537.issue29039@psf.upfronthosting.co.za>
Message-ID: <1482357266.34.0.263977185076.issue29039@psf.upfronthosting.co.za>


Christoph Reiter added the comment:

You're missing a call to Py_Initialize() [0]

[0] https://docs.python.org/3/c-api/init.html#c.Py_Initialize

----------
nosy: +lazka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29039>
_______________________________________

From report at bugs.python.org  Wed Dec 21 16:57:17 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 21 Dec 2016 21:57:17 +0000
Subject: [issue28762] lockf() is available now on Android API level 24,
 but the F_LOCK macro is not defined
In-Reply-To: <1482354578.11.0.749115415029.issue28762@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwacuXQ1kUEC=f1F82h58Kqy4JBXWTbc2GZdahmONJ8Dsw@mail.gmail.com>


STINNER Victor added the comment:

The new patch now looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28762>
_______________________________________

From report at bugs.python.org  Wed Dec 21 16:58:29 2016
From: report at bugs.python.org (Steve Dower)
Date: Wed, 21 Dec 2016 21:58:29 +0000
Subject: [issue29014] Python 3.5.2 installer doesn't register IDLE .py
 extensions on Windows 10
In-Reply-To: <1482147098.02.0.695368643489.issue29014@psf.upfronthosting.co.za>
Message-ID: <1482357509.21.0.0737552609278.issue29014@psf.upfronthosting.co.za>


Steve Dower added the comment:

It looks like PyCharm has taken over your shortcut:

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.py\UserChoice
    Hash    REG_SZ    55jxudRhknE=
    ProgId    REG_SZ    PyCharm2016.3

If you delete the entire "FileExts\.py" key with registry editor then it should reset back to either our launcher, or give you the ability to choose.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29014>
_______________________________________

From report at bugs.python.org  Wed Dec 21 17:06:29 2016
From: report at bugs.python.org (David)
Date: Wed, 21 Dec 2016 22:06:29 +0000
Subject: [issue29014] Python 3.5.2 installer doesn't register IDLE .py
 extensions on Windows 10
In-Reply-To: <1482147098.02.0.695368643489.issue29014@psf.upfronthosting.co.za>
Message-ID: <1482357989.61.0.257553760535.issue29014@psf.upfronthosting.co.za>


David added the comment:

Couple things: I installed PyCharm after all other options where exhausted. I needed to do some work on multiple projects. 

And also, I deleted .py key and it still doesn't show up. I tried associating it with idle.pyw and that didn't work either: Windows said it can't run that on my PC.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29014>
_______________________________________

From report at bugs.python.org  Wed Dec 21 17:16:22 2016
From: report at bugs.python.org (Steve Dower)
Date: Wed, 21 Dec 2016 22:16:22 +0000
Subject: [issue23903] Generate PC/python3.def by scraping headers
In-Reply-To: <1428637761.13.0.348463350169.issue23903@psf.upfronthosting.co.za>
Message-ID: <1482358582.54.0.692529690162.issue23903@psf.upfronthosting.co.za>


Steve Dower added the comment:

> would this change likely affect any third-party binaries already built for 3.6.0?  On the other hand, if we have to have one, it would be better to have a compatibility break at 3.6.0 rather than at 3.6.1.

Assuming we only make additive?changes, then nothing that currently exists will break. However,?extensions may then be built using 3.6.1 that will fail on earlier versions. This goes against the entire purpose of the limited?API - making the change for 3.6.0 at least means they will work for the entire 3.6 series.

This is one of those "all?options are bad" scenarios. Making the change today will prevent us from fixing the functions that should not have leaked into the limited API, but then again they've already leaked and people can?compile against them.

Perhaps the best approach is to?revise all functions in the limited API, restrict back to those that were in 3.3 and carefully add new ones from there. Then we just apologise for 3.5.[0-2] and 3.6.0 potentially producing invalid binaries and recommend getting a newer version to build with.

I've convinced myself that 3.6.0 is too soon to make the right fix here,?so it'll probably always be a bad version in this respect. Hopefully?by 3.6.1 we can fix up the limited API and make it?reliable again :(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23903>
_______________________________________

From report at bugs.python.org  Wed Dec 21 17:28:41 2016
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 21 Dec 2016 22:28:41 +0000
Subject: [issue29041] Reference leaks on Windows
Message-ID: <1482359321.76.0.526806281889.issue29041@psf.upfronthosting.co.za>


New submission from Zachary Ware:

Discussion in #29034 inspired me to run a refleak check on Windows, with the following results from a 32-bit build of the current 3.6 branch:

C:\cpython\3.6>PCbuild\build.bat -e -d
C:\cpython\3.6>python -m test -uall -R 3:3:refleak_log.txt --timeout=7200

...

24 tests failed:
    test_atexit test_capi test_concurrent_futures test_fileio
    test_functools test_glob test_idle test_io test_math
    test_multiprocessing_spawn test_ntpath test_os test_platform
    test_posixpath test_shutil test_ssl test_sys test_tarfile
    test_tempfile test_threading test_unicode_file_functions
    test_unittest test_warnings test_winconsoleio

1 test altered the execution environment:
    test_distutils

28 tests skipped:
    test_crypt test_curses test_dbm_gnu test_dbm_ndbm test_devpoll
    test_epoll test_fcntl test_fork1 test_gdb test_grp test_ioctl
    test_kqueue test_nis test_openpty test_ossaudiodev test_pipes
    test_poll test_posix test_pty test_pwd test_readline test_resource
    test_spwd test_syslog test_threadsignals test_wait3 test_wait4
    test_zipfile64

Total duration: 190 min 60 sec
Tests result: FAILURE

test_atexit leaked [12, 12, 12] references, sum=36
test_atexit leaked [4, 6, 6] memory blocks, sum=16
test_capi leaked [6, 6, 6] references, sum=18
test_capi leaked [2, 4, 4] memory blocks, sum=10
test_concurrent_futures leaked [792, 783, 765] references, sum=2340
test_concurrent_futures leaked [264, 263, 257] memory blocks, sum=784
test_fileio leaked [1, 2, 2] memory blocks, sum=5
test_functools leaked [0, 3, 2] memory blocks, sum=5
test_glob leaked [265, 266, 266] memory blocks, sum=797
test_idle leaked [471, 471, 471] references, sum=1413
test_idle leaked [209, 211, 211] memory blocks, sum=631
test_io leaked [2, 3, 3] memory blocks, sum=8
test_multiprocessing_spawn leaked [168, 117, 144] references, sum=429
test_multiprocessing_spawn leaked [55, 43, 50] memory blocks, sum=148
test_ntpath leaked [103, 104, 104] memory blocks, sum=311
test_os leaked [33, 33, 33] references, sum=99
test_os leaked [58, 60, 60] memory blocks, sum=178
test_platform leaked [12, 12, 12] references, sum=36
test_platform leaked [4, 6, 6] memory blocks, sum=16
test_posixpath leaked [3, 4, 4] memory blocks, sum=11
test_shutil leaked [5, 6, 6] memory blocks, sum=17
test_ssl leaked [3, 4, 4] memory blocks, sum=11
test_sys leaked [9, 9, 9] references, sum=27
test_sys leaked [3, 5, 5] memory blocks, sum=13
test_tarfile leaked [4, 5, 5] memory blocks, sum=14
test_tempfile leaked [82, 83, 83] memory blocks, sum=248
test_threading leaked [12, 12, 12] references, sum=36
test_threading leaked [4, 6, 6] memory blocks, sum=16
test_unicode_file_functions leaked [5, 6, 6] memory blocks, sum=17
test_winconsoleio leaked [38, 38, 38] references, sum=114
test_winconsoleio leaked [0, 1, 2] memory blocks, sum=3

----------
components: Windows
messages: 283792
nosy: haypo, paul.moore, serhiy.storchaka, steve.dower, tim.golden, xiang.zhang, zach.ware
priority: high
severity: normal
stage: needs patch
status: open
title: Reference leaks on Windows
type: resource usage
versions: Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29041>
_______________________________________

From report at bugs.python.org  Wed Dec 21 17:45:59 2016
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 21 Dec 2016 22:45:59 +0000
Subject: [issue29014] Python 3.5.2 installer doesn't register IDLE .py
 extensions on Windows 10
In-Reply-To: <1482147098.02.0.695368643489.issue29014@psf.upfronthosting.co.za>
Message-ID: <1482360359.66.0.880794210298.issue29014@psf.upfronthosting.co.za>


Eryk Sun added the comment:

Let's do a bit of house cleaning. Run the following commands in a command prompt:

    reg delete HKCU\SOFTWARE\Classes\.py /f
    reg delete HKCU\SOFTWARE\Classes\py_auto_file /f
    reg delete HKCU\SOFTWARE\Classes\Applications\python.exe /f
    reg delete HKCU\SOFTWARE\Classes\Applications\py.exe /f
    reg delete HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.py /f

HKCU\SOFTWARE\Classes\.py is selecting the PyCharm2016.3 ProgId. This takes precedence over HKLM\SOFTWARE\Classes\.py, the key that selects Python.File. I expect this causes Explorer to automatically reselect the PyCharm2016.3 ProgId. Deleting it in combination with deleting "...\Explorer\FileExts\.py" may fix the problem, i.e. restore the Edit with IDLE menu.

The "...\Applications\python.exe" and "...\Applications\py.exe" keys were created by manually associating with the given executable. Note how the open commands have the script path (%1) but no command-line arguments (%*). It's harmless to delete these keys.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29014>
_______________________________________

From report at bugs.python.org  Wed Dec 21 18:28:32 2016
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 21 Dec 2016 23:28:32 +0000
Subject: [issue29031] 'from module import *' and __all__
In-Reply-To: <1482307990.24.0.476248226278.issue29031@psf.upfronthosting.co.za>
Message-ID: <1482362912.86.0.434610607329.issue29031@psf.upfronthosting.co.za>


Changes by Eryk Sun <eryksun at gmail.com>:


----------
nosy: +eryksun
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29031>
_______________________________________

From report at bugs.python.org  Wed Dec 21 18:37:15 2016
From: report at bugs.python.org (David)
Date: Wed, 21 Dec 2016 23:37:15 +0000
Subject: [issue29014] Python 3.5.2 installer doesn't register IDLE .py
 extensions on Windows 10
In-Reply-To: <1482147098.02.0.695368643489.issue29014@psf.upfronthosting.co.za>
Message-ID: <1482363435.96.0.727915513603.issue29014@psf.upfronthosting.co.za>


David added the comment:

Couple things to note: I was not able to delete a couple of the keys. Regardless I've made some progress which I will outline in the next comment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29014>
_______________________________________

From report at bugs.python.org  Wed Dec 21 18:41:12 2016
From: report at bugs.python.org (David)
Date: Wed, 21 Dec 2016 23:41:12 +0000
Subject: [issue29014] Python 3.5.2 installer doesn't register IDLE .py
 extensions on Windows 10
In-Reply-To: <1482147098.02.0.695368643489.issue29014@psf.upfronthosting.co.za>
Message-ID: <1482363672.43.0.920274489808.issue29014@psf.upfronthosting.co.za>


David added the comment:

Following your instructions on key deletion, I have now 2 "Edit with IDLE" options now. The top one does *not* work. The second one, however, does work. But when I tried to associate the .py with idle (so it opens up in IDLE) it reverted back to the command-line run of the .py file and eliminated the "Edit with IDLE" options from the right-click menu. Very odd. 

Thank you so much for staying with this issue.

----------
Added file: http://bugs.python.org/file45992/progress so far.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29014>
_______________________________________

From report at bugs.python.org  Wed Dec 21 18:58:49 2016
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 21 Dec 2016 23:58:49 +0000
Subject: [issue29014] Python 3.5.2 installer doesn't register IDLE .py
 extensions on Windows 10
In-Reply-To: <1482147098.02.0.695368643489.issue29014@psf.upfronthosting.co.za>
Message-ID: <1482364729.02.0.330966777224.issue29014@psf.upfronthosting.co.za>


Eryk Sun added the comment:

To remove the broken "Edit with IDLE" entry, open an elevated (administrator) command prompt and run the following:

    reg delete "HKLM\SOFTWARE\Classes\Python.File\shell\Edit with IDLE" /f

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29014>
_______________________________________

From report at bugs.python.org  Wed Dec 21 19:02:50 2016
From: report at bugs.python.org (David)
Date: Thu, 22 Dec 2016 00:02:50 +0000
Subject: [issue29014] Python 3.5.2 installer doesn't register IDLE .py
 extensions on Windows 10
In-Reply-To: <1482147098.02.0.695368643489.issue29014@psf.upfronthosting.co.za>
Message-ID: <1482364970.33.0.79326847726.issue29014@psf.upfronthosting.co.za>


David added the comment:

I did that, and now all the options are gone.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29014>
_______________________________________

From report at bugs.python.org  Wed Dec 21 19:08:31 2016
From: report at bugs.python.org (David)
Date: Thu, 22 Dec 2016 00:08:31 +0000
Subject: [issue29014] Python 3.5.2 installer doesn't register IDLE .py
 extensions on Windows 10
In-Reply-To: <1482147098.02.0.695368643489.issue29014@psf.upfronthosting.co.za>
Message-ID: <1482365311.58.0.45246933679.issue29014@psf.upfronthosting.co.za>


David added the comment:

Also, just to clarify, I want this to be a regular installation of Python wherein I can associate .py files with IDLE (i.e. when I double click on a .py file, it takes me straight to the code) *as well as* having the option to "Edit with IDLE" when right-clicking on a .py file. For some reason, on this machine, I'm not able to replicate the same installation as on my other Windows machine not matter how much I try.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29014>
_______________________________________

From report at bugs.python.org  Wed Dec 21 19:08:50 2016
From: report at bugs.python.org (David)
Date: Thu, 22 Dec 2016 00:08:50 +0000
Subject: [issue29014] Python 3.5.2 installer doesn't register IDLE .py
 extensions on Windows 10
In-Reply-To: <1482147098.02.0.695368643489.issue29014@psf.upfronthosting.co.za>
Message-ID: <1482365330.4.0.29297708164.issue29014@psf.upfronthosting.co.za>


David added the comment:

Also, just to clarify, I want this to be a regular installation of Python wherein I can associate .py files with IDLE (i.e. when I double click on a .py file, it takes me straight to the code) *as well as* having the option to "Edit with IDLE" when right-clicking on a .py file. For some reason, on this machine, I'm not able to replicate the same installation as on my other Windows machine not matter how much I try.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29014>
_______________________________________

From report at bugs.python.org  Wed Dec 21 19:19:35 2016
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 22 Dec 2016 00:19:35 +0000
Subject: [issue29014] Python 3.5.2 installer doesn't register IDLE .py
 extensions on Windows 10
In-Reply-To: <1482147098.02.0.695368643489.issue29014@psf.upfronthosting.co.za>
Message-ID: <1482365975.09.0.933716289674.issue29014@psf.upfronthosting.co.za>


Eryk Sun added the comment:

> I did that, and now all the options are gone.

Removing the broken HKLM entry shouldn't have removed all of the options. The "Edit with IDLE" menu should be there as long as Python.File is selected for the file association. It's defined for the current user on your system, under the following key:

    HKCU\SOFTWARE\Classes\Python.File\Shell\editwithidle

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29014>
_______________________________________

From report at bugs.python.org  Wed Dec 21 19:30:37 2016
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 22 Dec 2016 00:30:37 +0000
Subject: [issue29014] Python 3.5.2 installer doesn't register IDLE .py
 extensions on Windows 10
In-Reply-To: <1482147098.02.0.695368643489.issue29014@psf.upfronthosting.co.za>
Message-ID: <1482366637.56.0.922597023455.issue29014@psf.upfronthosting.co.za>


Eryk Sun added the comment:

> I want this to be a regular installation of Python wherein I can 
> associate .py files with IDLE

That isn't a regular installation. It's not even an optional configuration, and never has been. You'd have to set that up manually. Are you looking to [-r]un files in IDLE by double clicking on them, or simply open them in the editor?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29014>
_______________________________________

From report at bugs.python.org  Wed Dec 21 19:44:29 2016
From: report at bugs.python.org (David)
Date: Thu, 22 Dec 2016 00:44:29 +0000
Subject: [issue29014] Python 3.5.2 installer doesn't register IDLE .py
 extensions on Windows 10
In-Reply-To: <1482147098.02.0.695368643489.issue29014@psf.upfronthosting.co.za>
Message-ID: <1482367469.63.0.445857353718.issue29014@psf.upfronthosting.co.za>


David added the comment:

Before re-installing Windows 10, I was able to open up all my .py files  by double-clicking on them and it would open them up in the IDLE (where I could edit the code manually and what have you). I'm not sure why it's never been a feature: I was doing that for many months.

----------
Added file: http://bugs.python.org/file45993/double clicking on .py should show this.PNG

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29014>
_______________________________________

From report at bugs.python.org  Wed Dec 21 20:31:38 2016
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 22 Dec 2016 01:31:38 +0000
Subject: [issue29014] Python 3.5.2 installer doesn't register IDLE .py
 extensions on Windows 10
In-Reply-To: <1482147098.02.0.695368643489.issue29014@psf.upfronthosting.co.za>
Message-ID: <1482370298.11.0.640858707546.issue29014@psf.upfronthosting.co.za>


Eryk Sun added the comment:

openwithidle_for_frostyelsa.reg adds an open command for the current user that opens the target file in IDLE. This will take precedence over the per-machine open command that executes the file using the launcher. 

It also adds "Run" and "Run as administrator" commands to execute the file using the launcher.

----------
Added file: http://bugs.python.org/file45994/openwithidle_for_frostyelsa.reg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29014>
_______________________________________

From report at bugs.python.org  Wed Dec 21 20:56:18 2016
From: report at bugs.python.org (David)
Date: Thu, 22 Dec 2016 01:56:18 +0000
Subject: [issue29014] Python 3.5.2 installer doesn't register IDLE .py
 extensions on Windows 10
In-Reply-To: <1482147098.02.0.695368643489.issue29014@psf.upfronthosting.co.za>
Message-ID: <1482371778.6.0.791342399781.issue29014@psf.upfronthosting.co.za>


David added the comment:

Thank you so much! This solved it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29014>
_______________________________________

From report at bugs.python.org  Wed Dec 21 22:45:16 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 22 Dec 2016 03:45:16 +0000
Subject: [issue29038] Duplicate entry for SSLContext.get_ca_certs() in ssl
In-Reply-To: <1482348942.9.0.649967135375.issue29038@psf.upfronthosting.co.za>
Message-ID: <1482378316.91.0.176880832413.issue29038@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

The codes in py2.7 looks same as in py3.4+, so make the doc same as in py3.4+.

----------
keywords: +patch
nosy: +christian.heimes, xiang.zhang
stage:  -> patch review
Added file: http://bugs.python.org/file45995/duplicate-doc-entry.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29038>
_______________________________________

From report at bugs.python.org  Wed Dec 21 23:02:55 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 22 Dec 2016 04:02:55 +0000
Subject: [issue29039] Segmentation fault when using PyUnicode_FromString
In-Reply-To: <1482349932.8.0.094002567537.issue29039@psf.upfronthosting.co.za>
Message-ID: <1482379375.37.0.814413068167.issue29039@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Just as Christoph said, you need to initialize first.

----------
nosy: +xiang.zhang
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29039>
_______________________________________

From report at bugs.python.org  Wed Dec 21 23:36:28 2016
From: report at bugs.python.org (Dolda2000)
Date: Thu, 22 Dec 2016 04:36:28 +0000
Subject: [issue29042] os.path.exists should not throw "Embedded NUL character"
 exception
Message-ID: <1482381388.92.0.462077532018.issue29042@psf.upfronthosting.co.za>


New submission from Dolda2000:

Currently, calling os.path.exists on a path which contains NUL characters behaves consistently with most file-system calls by throwing an exception:

>>> os.path.exists('\0')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.5/genericpath.py", line 19, in exists
    os.stat(path)
ValueError: embedded null byte

However, os.path.exists is supposed to be a predicate returning whether there exists a file named by the path; it does not specify any particular method or system call for doing the test, and so reflecting the behavior of the underlying syscall used is not obviously desirable. A path containing an embedded NUL character simply cannot name an existing file, and therefore os.path.exists should return False for such a path.

----------
components: Library (Lib)
messages: 283807
nosy: Dolda2000
priority: normal
severity: normal
status: open
title: os.path.exists should not throw "Embedded NUL character" exception
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29042>
_______________________________________

From report at bugs.python.org  Wed Dec 21 23:38:44 2016
From: report at bugs.python.org (Tadhg McDonald-Jensen)
Date: Thu, 22 Dec 2016 04:38:44 +0000
Subject: [issue29043] dict view string representations are misleading
Message-ID: <1482381524.94.0.618583923227.issue29043@psf.upfronthosting.co.za>


New submission from Tadhg McDonald-Jensen:

Currently the string representation for dictionary views are a bit misleading as they look like valid expression but isn't:

    >>> {'a':1, 'b':2}.keys()
    dict_keys(['b', 'a'])
    >>> dict_keys = type({}.keys()) #get a reference to the type
    >>> dict_keys(['b', 'a'])
    Traceback (most recent call last):
      File "<pyshell#24>", line 1, in <module>
        dict_keys(['b', 'a'])
    TypeError: cannot create 'dict_keys' instances


This seems inconsistent with the documentation for 'repr' 
https://docs.python.org/3/reference/datamodel.html#object.__repr__

"If at all possible, this should look like a valid Python expression that could be used to recreate an object with the same value (given an appropriate environment). If this is not possible, a string of the form <...some useful description...> should be returned."

So I'd think the representation for dictionary views should look something like this instead:

     <dict_keys ['a', 'b']>

to indicate that it cannot be reproduced by a simple expression but still shows it's contents.

----------
messages: 283808
nosy: Tadhg McDonald-Jensen
priority: normal
severity: normal
status: open
title: dict view string representations are misleading
type: behavior
versions: Python 2.7, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29043>
_______________________________________

From report at bugs.python.org  Wed Dec 21 23:44:06 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 22 Dec 2016 04:44:06 +0000
Subject: [issue28923] Nonexisting encoding specified in Tix.py
In-Reply-To: <1481304070.27.0.11719456506.issue28923@psf.upfronthosting.co.za>
Message-ID: <20161222044403.19592.51697.95C15E14@psf.io>


Roundup Robot added the comment:

New changeset ef03aff3b195 by Terry Jan Reedy in branch '2.7':
Issue 28923: Remove editor artifacts from Tix.py,
https://hg.python.org/cpython/rev/ef03aff3b195

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28923>
_______________________________________

From report at bugs.python.org  Wed Dec 21 23:57:30 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 22 Dec 2016 04:57:30 +0000
Subject: [issue29043] dict view string representations are misleading
In-Reply-To: <1482381524.94.0.618583923227.issue29043@psf.upfronthosting.co.za>
Message-ID: <1482382650.8.0.479762701131.issue29043@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

In this case, practicality beats purity.  We want to repr to show the contents of the dictionary (that improves usability).  The general rule that repr's need to round-trip is only a general rule and has many exceptions.  As of course, in this case, it isn't possible to reinstantiate.

This repr has been already been published and present long enough that it is set is stone (this ship sailed long ago, it is even present in Python 2.7).  Also, the proposed repr looks a little weird to my eyes and I don't think changing it would be of benefit to any one.

So, thank you for the suggestion, but I'm going to pass on this one.

----------
nosy: +rhettinger
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29043>
_______________________________________

From report at bugs.python.org  Thu Dec 22 00:04:27 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 22 Dec 2016 05:04:27 +0000
Subject: [issue28923] Nonexisting encoding specified in Tix.py
In-Reply-To: <1481304070.27.0.11719456506.issue28923@psf.upfronthosting.co.za>
Message-ID: <20161222050424.106931.50238.5C843D94@psf.io>


Roundup Robot added the comment:

New changeset eb8667196f93 by Terry Jan Reedy in branch '3.5':
Issue 28923: Remove editor artifacts from Tix.py.
https://hg.python.org/cpython/rev/eb8667196f93

New changeset 4a82412a3c51 by Terry Jan Reedy in branch '3.6':
Issue 28923: Remove editor artifacts from Tix.py,
https://hg.python.org/cpython/rev/4a82412a3c51

New changeset 41031fdc924a by Terry Jan Reedy in branch 'default':
Issue 28923: Remove editor artifacts from Tix.py,
https://hg.python.org/cpython/rev/41031fdc924a

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28923>
_______________________________________

From report at bugs.python.org  Thu Dec 22 00:08:07 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 22 Dec 2016 05:08:07 +0000
Subject: [issue28923] Nonexisting encoding specified in Tix.py
In-Reply-To: <1481304070.27.0.11719456506.issue28923@psf.upfronthosting.co.za>
Message-ID: <1482383287.93.0.461926900604.issue28923@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28923>
_______________________________________

From report at bugs.python.org  Thu Dec 22 00:00:08 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 22 Dec 2016 05:00:08 +0000
Subject: [issue29044] Use after free in string '%c' formater
Message-ID: <1482382808.01.0.0790799966286.issue29044@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

In string %c formater(formatchar), when receiving an integer-like objects, the return value is decrefed immediately before use.

----------
components: Interpreter Core
files: use-after-free.patch
keywords: patch
messages: 283811
nosy: haypo, xiang.zhang
priority: normal
severity: normal
stage: patch review
status: open
title: Use after free in string '%c' formater
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file45996/use-after-free.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29044>
_______________________________________

From report at bugs.python.org  Thu Dec 22 00:30:45 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 22 Dec 2016 05:30:45 +0000
Subject: [issue29044] Use after free in string '%c' formater
In-Reply-To: <1482382808.01.0.0790799966286.issue29044@psf.upfronthosting.co.za>
Message-ID: <1482384645.47.0.22029630968.issue29044@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM.

----------
assignee:  -> xiang.zhang
nosy: +serhiy.storchaka
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29044>
_______________________________________

From report at bugs.python.org  Thu Dec 22 01:06:20 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 22 Dec 2016 06:06:20 +0000
Subject: [issue29045] Outdated C api doc about Windows error
Message-ID: <1482386780.7.0.302567843382.issue29045@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

https://docs.python.org/3.7/c-api/exceptions.html#c.PyErr_SetFromWindowsErrWithFilename it stills refers to PyErr_SetFromWindowsErrWithFilenameObject but this function doesn't exist since Py3.4. I didn't find when and why it's deleted.

And https://docs.python.org/3.4/c-api/exceptions.html#c.PyErr_SetFromWindowsErr raises OSError instead of WindowsError.

----------
assignee: docs at python
components: Documentation
messages: 283814
nosy: docs at python, xiang.zhang
priority: normal
severity: normal
status: open
title: Outdated C api doc about Windows error
versions: Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29045>
_______________________________________

From report at bugs.python.org  Thu Dec 22 01:40:09 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Thu, 22 Dec 2016 06:40:09 +0000
Subject: [issue29040] building Android with android-ndk-r14
In-Reply-To: <1482351865.89.0.655034997181.issue29040@psf.upfronthosting.co.za>
Message-ID: <1482388809.96.0.624431520645.issue29040@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

Thanks for compiling up necessary changes for NDK r14! Seems that indicates future Python versions will require at least NDK r14 to build?

Another headache from unified headers is that it requires different --sysroot in compilation and linking. Currently setup.py/distutils does not cope with it well. See my dirty hack at [1] for an ad-hoc workaround.

[1] https://github.com/yan12125/python3-android/blob/master/mk/python/distutils-android-sysroot.patch

----------
nosy: +Chi Hsuan Yen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29040>
_______________________________________

From report at bugs.python.org  Thu Dec 22 02:10:46 2016
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 22 Dec 2016 07:10:46 +0000
Subject: [issue29045] Outdated C api doc about Windows error
In-Reply-To: <1482386780.7.0.302567843382.issue29045@psf.upfronthosting.co.za>
Message-ID: <1482390646.57.0.586885065545.issue29045@psf.upfronthosting.co.za>


Eryk Sun added the comment:

PyErr_SetFromWindowsErrWithFilenameObject was never implemented. See issue 11210.

Since 3.3 WindowsError is simply an alias for OSError. See PEP 3151.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29045>
_______________________________________

From report at bugs.python.org  Thu Dec 22 02:23:59 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 22 Dec 2016 07:23:59 +0000
Subject: [issue29044] Use after free in string '%c' formater
In-Reply-To: <1482384645.47.0.22029630968.issue29044@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwYN+E2iq3jxQOEDxjqAV3woYfPh5WMAKBDFMu1-uKKfYQ@mail.gmail.com>


STINNER Victor added the comment:

I reviewed the change and added minor comments. The change LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29044>
_______________________________________

From report at bugs.python.org  Thu Dec 22 02:24:32 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 22 Dec 2016 07:24:32 +0000
Subject: [issue29045] Outdated C api doc about Windows error
In-Reply-To: <1482386780.7.0.302567843382.issue29045@psf.upfronthosting.co.za>
Message-ID: <1482391472.08.0.879466461239.issue29045@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

> PyErr_SetFromWindowsErrWithFilenameObject was never implemented. See issue 11210.

> Since 3.3 WindowsError is simply an alias for OSError. See PEP 3151.

Ohh, thanks for the info. I don't find the implementation in 2.7 either.

----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29045>
_______________________________________

From report at bugs.python.org  Thu Dec 22 02:38:09 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 22 Dec 2016 07:38:09 +0000
Subject: [issue29044] Use after free in string '%c' formater
In-Reply-To: <1482382808.01.0.0790799966286.issue29044@psf.upfronthosting.co.za>
Message-ID: <20161222073805.20642.43308.7EF66088@psf.io>


Roundup Robot added the comment:

New changeset e572c323fe53 by Xiang Zhang in branch '3.5':
Issue #29044: Fix a use-after-free in string '%c' formatter.
https://hg.python.org/cpython/rev/e572c323fe53

New changeset cc61d1d45291 by Xiang Zhang in branch '3.6':
Issue #29044: Merge 3.5.
https://hg.python.org/cpython/rev/cc61d1d45291

New changeset a1d5388d5da9 by Xiang Zhang in branch 'default':
Issue #29044: Merge 3.6.
https://hg.python.org/cpython/rev/a1d5388d5da9

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29044>
_______________________________________

From report at bugs.python.org  Thu Dec 22 02:39:27 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 22 Dec 2016 07:39:27 +0000
Subject: [issue29044] Use after free in string '%c' formater
In-Reply-To: <1482382808.01.0.0790799966286.issue29044@psf.upfronthosting.co.za>
Message-ID: <1482392367.64.0.101396318357.issue29044@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Thanks Serhiy and Victor. The final commits applies the comments. :-)

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29044>
_______________________________________

From report at bugs.python.org  Thu Dec 22 03:54:01 2016
From: report at bugs.python.org (Christoph Reiter)
Date: Thu, 22 Dec 2016 08:54:01 +0000
Subject: [issue29042] os.path.exists should not throw "Embedded NUL character"
 exception
In-Reply-To: <1482381388.92.0.462077532018.issue29042@psf.upfronthosting.co.za>
Message-ID: <1482396841.66.0.998983003518.issue29042@psf.upfronthosting.co.za>


Christoph Reiter added the comment:

Raising in case no valid path is passed seems fine to me. There are other cases where it fails:

python3 -c "import os; os.path.exists('\ud83d')"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python3.5/genericpath.py", line 19, in exists
    os.stat(path)
UnicodeEncodeError: 'utf-8' codec can't encode character '\ud83d' in position 0: surrogates not allowed


LANG=C python3 -c "import os; os.path.exists('\xff')"       ~
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python3.5/genericpath.py", line 19, in exists
    os.stat(path)
UnicodeEncodeError: 'ascii' codec can't encode character '\xff' in position 0: ordinal not in range(128)

----------
nosy: +lazka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29042>
_______________________________________

From report at bugs.python.org  Thu Dec 22 04:11:00 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 22 Dec 2016 09:11:00 +0000
Subject: [issue29040] building Android with android-ndk-r14
In-Reply-To: <1482351865.89.0.655034997181.issue29040@psf.upfronthosting.co.za>
Message-ID: <1482397860.44.0.824250720976.issue29040@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

> Seems that indicates future Python versions will require at least NDK r14 to build?

Yes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29040>
_______________________________________

From report at bugs.python.org  Thu Dec 22 04:41:19 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 22 Dec 2016 09:41:19 +0000
Subject: [issue28762] lockf() is available now on Android API level 24,
 but the F_LOCK macro is not defined
In-Reply-To: <1479723589.5.0.525775136475.issue28762@psf.upfronthosting.co.za>
Message-ID: <20161222094116.4083.65819.BB2B6C6C@psf.io>


Roundup Robot added the comment:

New changeset 51b09b10d4f8 by Xavier de Gaye in branch '3.6':
Issue #28762: lockf() is available on Android API level 24, but the
https://hg.python.org/cpython/rev/51b09b10d4f8

New changeset 146157d91283 by Xavier de Gaye in branch 'default':
Issue #28762: Merge 3.6.
https://hg.python.org/cpython/rev/146157d91283

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28762>
_______________________________________

From report at bugs.python.org  Thu Dec 22 05:44:26 2016
From: report at bugs.python.org (Patrik Iselind)
Date: Thu, 22 Dec 2016 10:44:26 +0000
Subject: [issue29046] Coverage related documentation missing
Message-ID: <1482403466.51.0.435148590485.issue29046@psf.upfronthosting.co.za>


New submission from Patrik Iselind:

Is it possible to do coverage -j8 or similar? Cannot find any documentation on this. Coverage takes so long on the tests...

I checked https://docs.python.org/devguide/coverage.html

----------
assignee: docs at python
components: Documentation
messages: 283824
nosy: docs at python, patriki
priority: normal
severity: normal
status: open
title: Coverage related documentation missing
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29046>
_______________________________________

From report at bugs.python.org  Thu Dec 22 05:44:33 2016
From: report at bugs.python.org (Patrik Iselind)
Date: Thu, 22 Dec 2016 10:44:33 +0000
Subject: [issue29047] Where are the test results stored?
Message-ID: <1482403473.61.0.626919341446.issue29047@psf.upfronthosting.co.za>


New submission from Patrik Iselind:

I cannot find any documentation on where the test results are stored.

Looked at https://docs.python.org/devguide/runtests.html

----------
assignee: docs at python
components: Documentation
messages: 283825
nosy: docs at python, patriki
priority: normal
severity: normal
status: open
title: Where are the test results stored?
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29047>
_______________________________________

From report at bugs.python.org  Thu Dec 22 06:28:02 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 22 Dec 2016 11:28:02 +0000
Subject: [issue28762] lockf() is available now on Android API level 24,
 but the F_LOCK macro is not defined
In-Reply-To: <1479723589.5.0.525775136475.issue28762@psf.upfronthosting.co.za>
Message-ID: <1482406082.15.0.878903795382.issue28762@psf.upfronthosting.co.za>


Changes by Xavier de Gaye <xdegaye at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28762>
_______________________________________

From report at bugs.python.org  Thu Dec 22 06:48:50 2016
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Thu, 22 Dec 2016 11:48:50 +0000
Subject: [issue29046] Coverage related documentation missing
In-Reply-To: <1482403466.51.0.435148590485.issue29046@psf.upfronthosting.co.za>
Message-ID: <1482407330.29.0.127730116972.issue29046@psf.upfronthosting.co.za>


Jim Fasarakis-Hilliard added the comment:

The ``-j`` arguments isn't present for coverage from what I know.

What you can do is build coverage's C extension. That results in a pretty significant change in overall execution time. 

For information about coverage.py you should also look in the docs for it; you can forward any questions about its usage from there (see: http://coverage.readthedocs.io/en/coverage-4.2/#getting-help)

----------
nosy: +Jim Fasarakis-Hilliard

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29046>
_______________________________________

From report at bugs.python.org  Thu Dec 22 06:50:43 2016
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Thu, 22 Dec 2016 11:50:43 +0000
Subject: [issue29046] Coverage related documentation missing
In-Reply-To: <1482403466.51.0.435148590485.issue29046@psf.upfronthosting.co.za>
Message-ID: <1482407443.74.0.577956365388.issue29046@psf.upfronthosting.co.za>


Jim Fasarakis-Hilliard added the comment:

I suggest this issue be closed as it isn't really an omission, I don't think we should expect the devguide to document *all* of coverage's options. That's what its dedicated docs are for.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29046>
_______________________________________

From report at bugs.python.org  Thu Dec 22 06:56:16 2016
From: report at bugs.python.org (Patrik Iselind)
Date: Thu, 22 Dec 2016 11:56:16 +0000
Subject: [issue29048] Coverage influence tests, make some of them fail
Message-ID: <1482407776.18.0.223230024277.issue29048@psf.upfronthosting.co.za>


New submission from Patrik Iselind:

I checkout the latest tip from scratch.

When i run the tests i get the following results:
% ./python -m test -j
[...]
376 tests OK.

1 test altered the execution environment:
    test_site

27 tests skipped:
    test_bz2 test_ctypes test_curses test_dbm_gnu test_dbm_ndbm
    test_devpoll test_gdb test_kqueue test_lzma test_msilib
    test_ossaudiodev test_readline test_smtpnet test_socketserver
    test_sqlite test_startfile test_timeout test_tix test_tk
    test_ttk_guionly test_urllib2net test_urllibnet test_winconsoleio
    test_winreg test_winsound test_xmlrpc_net test_zipfile64

Total duration: 2 min 57 sec
Tests result: SUCCESS

Without any changes i run the tests again but this time under coverage. I get a completely different result:
% ./python ../coveragepy run --pylib Lib/test/regrtest.py
[...]
328 tests OK.

8 tests failed:
    test_exceptions test_frame test_ssl test_subprocess test_super
    test_traceback test_unittest test_xml_etree_c

41 tests altered the execution environment:
    test_asynchat test_asyncio test_asyncore test_capi
    test_concurrent_futures test_decimal test_distutils test_docxmlrpc
    test_email test_fork1 test_ftplib test_functools test_gc
    test_hashlib test_httplib test_httpservers test_imaplib
    test_import test_io test_json test_logging test_mailbox
    test_multiprocessing_fork test_multiprocessing_forkserver
    test_multiprocessing_spawn test_nntplib test_os test_poll
    test_poplib test_pydoc test_queue test_robotparser test_sched
    test_smtplib test_socket test_sys test_telnetlib
    test_threaded_import test_threadedtempfile test_threading
    test_xml_etree

27 tests skipped:
    test_bz2 test_ctypes test_curses test_dbm_gnu test_dbm_ndbm
    test_devpoll test_gdb test_kqueue test_lzma test_msilib
    test_ossaudiodev test_readline test_smtpnet test_socketserver
    test_sqlite test_startfile test_timeout test_tix test_tk
    test_ttk_guionly test_urllib2net test_urllibnet test_winconsoleio
    test_winreg test_winsound test_xmlrpc_net test_zipfile64

Total duration: 92 min 34 sec
Tests result: FAILURE

Is the reason for this difference known? Coverage shouldn't affect the outcome of the tests right?

----------
components: Tests
messages: 283828
nosy: patriki
priority: normal
severity: normal
status: open
title: Coverage influence tests, make some of them fail
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29048>
_______________________________________

From report at bugs.python.org  Thu Dec 22 06:56:44 2016
From: report at bugs.python.org (Patrik Iselind)
Date: Thu, 22 Dec 2016 11:56:44 +0000
Subject: [issue29046] Coverage related documentation missing
In-Reply-To: <1482403466.51.0.435148590485.issue29046@psf.upfronthosting.co.za>
Message-ID: <1482407804.24.0.0175043879585.issue29046@psf.upfronthosting.co.za>


Patrik Iselind added the comment:

Agree

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29046>
_______________________________________

From report at bugs.python.org  Thu Dec 22 07:00:44 2016
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 22 Dec 2016 12:00:44 +0000
Subject: [issue29049] Lazy GC tracking frame
Message-ID: <1482408044.82.0.398076651662.issue29049@psf.upfronthosting.co.za>


New submission from INADA Naoki:

Don't _PyObject_GC_TRACK(frame) before using it.
After evaluation is finished, do tracking only if refcnt is not one.

result without --enable-optimization:
$ ~/local/cpython/bin/pyperf compare_to default.json.gz patched.json.gz -G
Slower (15):
- scimark_sparse_mat_mult: 5.83 ms +- 0.03 ms -> 6.12 ms +- 0.35 ms: 1.05x slower (+5%)
- sympy_expand: 734 ms +- 21 ms -> 765 ms +- 40 ms: 1.04x slower (+4%)
- sympy_str: 327 ms +- 10 ms -> 339 ms +- 13 ms: 1.04x slower (+4%)
- scimark_fft: 498 ms +- 2 ms -> 512 ms +- 2 ms: 1.03x slower (+3%)
- scimark_monte_carlo: 172 ms +- 3 ms -> 175 ms +- 4 ms: 1.02x slower (+2%)
- chameleon: 17.6 ms +- 0.3 ms -> 17.9 ms +- 0.2 ms: 1.02x slower (+2%)
- telco: 11.3 ms +- 0.4 ms -> 11.5 ms +- 0.6 ms: 1.02x slower (+2%)
- logging_simple: 19.0 us +- 0.3 us -> 19.2 us +- 0.3 us: 1.01x slower (+1%)
- pickle_dict: 52.2 us +- 0.3 us -> 52.9 us +- 0.2 us: 1.01x slower (+1%)
- pickle_list: 6.86 us +- 0.04 us -> 6.94 us +- 0.05 us: 1.01x slower (+1%)
- pickle: 17.4 us +- 0.2 us -> 17.6 us +- 0.2 us: 1.01x slower (+1%)
- logging_silent: 556 ns +- 13 ns -> 561 ns +- 11 ns: 1.01x slower (+1%)
- sqlite_synth: 5.25 us +- 0.44 us -> 5.28 us +- 0.15 us: 1.01x slower (+1%)
- pidigits: 248 ms +- 2 ms -> 249 ms +- 2 ms: 1.00x slower (+0%)
- unpack_sequence: 73.5 ns +- 0.6 ns -> 73.8 ns +- 2.4 ns: 1.00x slower (+0%)

Faster (27):
- call_method_slots: 11.4 ms +- 0.1 ms -> 10.7 ms +- 0.1 ms: 1.07x faster (-6%)
- call_method: 11.5 ms +- 0.1 ms -> 10.8 ms +- 0.2 ms: 1.06x faster (-6%)
- call_simple: 10.7 ms +- 0.3 ms -> 10.1 ms +- 0.3 ms: 1.06x faster (-5%)
- regex_effbot: 4.08 ms +- 0.05 ms -> 3.97 ms +- 0.04 ms: 1.03x faster (-3%)
- regex_compile: 318 ms +- 11 ms -> 310 ms +- 10 ms: 1.03x faster (-3%)
- html5lib: 154 ms +- 4 ms -> 150 ms +- 4 ms: 1.03x faster (-3%)
- deltablue: 13.5 ms +- 0.5 ms -> 13.1 ms +- 0.4 ms: 1.03x faster (-3%)
- call_method_unknown: 13.1 ms +- 0.1 ms -> 12.8 ms +- 0.1 ms: 1.02x faster (-2%)
- richards: 131 ms +- 2 ms -> 128 ms +- 2 ms: 1.02x faster (-2%)
- meteor_contest: 170 ms +- 3 ms -> 167 ms +- 4 ms: 1.02x faster (-2%)
- sympy_integrate: 34.7 ms +- 0.7 ms -> 34.0 ms +- 0.2 ms: 1.02x faster (-2%)
- spectral_norm: 210 ms +- 2 ms -> 206 ms +- 2 ms: 1.02x faster (-2%)
- dulwich_log: 115 ms +- 1 ms -> 113 ms +- 2 ms: 1.01x faster (-1%)
- genshi_text: 54.1 ms +- 0.8 ms -> 53.4 ms +- 0.5 ms: 1.01x faster (-1%)
- 2to3: 511 ms +- 3 ms -> 505 ms +- 2 ms: 1.01x faster (-1%)
- pathlib: 28.8 ms +- 0.6 ms -> 28.5 ms +- 0.8 ms: 1.01x faster (-1%)
- xml_etree_parse: 199 ms +- 3 ms -> 198 ms +- 2 ms: 1.01x faster (-1%)
- hexiom: 17.9 ms +- 0.1 ms -> 17.7 ms +- 0.1 ms: 1.01x faster (-1%)
- mako: 35.1 ms +- 1.0 ms -> 34.9 ms +- 0.3 ms: 1.01x faster (-1%)
- nbody: 194 ms +- 1 ms -> 193 ms +- 1 ms: 1.01x faster (-1%)
- unpickle_pure_python: 634 us +- 15 us -> 630 us +- 10 us: 1.01x faster (-1%)
- unpickle_list: 6.16 us +- 0.06 us -> 6.13 us +- 0.05 us: 1.01x faster (-1%)
- genshi_xml: 113 ms +- 3 ms -> 112 ms +- 1 ms: 1.01x faster (-1%)
- json_dumps: 19.1 ms +- 0.3 ms -> 19.1 ms +- 0.2 ms: 1.00x faster (-0%)
- python_startup: 13.3 ms +- 0.1 ms -> 13.3 ms +- 0.1 ms: 1.00x faster (-0%)
- python_startup_no_site: 8.24 ms +- 0.06 ms -> 8.22 ms +- 0.04 ms: 1.00x faster (-0%)
- go: 421 ms +- 3 ms -> 421 ms +- 3 ms: 1.00x faster (-0%)

Benchmark hidden because not significant (22): chaos, crypto_pyaes, django_template, fannkuch, float, json_loads, logging_format, nqueens, pickle_pure_python, raytrace, regex_dna, regex_v8, scimark_lu, scimark_sor, sqlalchemy_declarative, sqlalchemy_imperative, sympy_sum, tornado_http, unpickle, xml_etree_generate, xml_etree_iterparse, xml_etree_process

----------
files: frame-lazy-track.patch
keywords: patch
messages: 283830
nosy: haypo, inada.naoki
priority: normal
severity: normal
stage: patch review
status: open
title: Lazy GC tracking frame
type: performance
Added file: http://bugs.python.org/file45997/frame-lazy-track.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29049>
_______________________________________

From report at bugs.python.org  Thu Dec 22 08:16:49 2016
From: report at bugs.python.org (Xavier Combelle)
Date: Thu, 22 Dec 2016 13:16:49 +0000
Subject: [issue28962] Crash when throwing an exception with a malicious
 __hash__ override
In-Reply-To: <1481646487.87.0.692050241508.issue28962@psf.upfronthosting.co.za>
Message-ID: <1482412609.02.0.49343470803.issue28962@psf.upfronthosting.co.za>


Xavier Combelle added the comment:

To my knowledge it is not the kind of arbitrary code which could segfault python code. It is far different for example that the fact by using bytecode magic you can segfault the interpreter, as this last case is explicitly warned in documentation.

----------
nosy: +xcombelle

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28962>
_______________________________________

From report at bugs.python.org  Thu Dec 22 08:22:27 2016
From: report at bugs.python.org (R. David Murray)
Date: Thu, 22 Dec 2016 13:22:27 +0000
Subject: [issue29047] Where are the test results stored?
In-Reply-To: <1482403473.61.0.626919341446.issue29047@psf.upfronthosting.co.za>
Message-ID: <1482412947.57.0.0148402854966.issue29047@psf.upfronthosting.co.za>


R. David Murray added the comment:

That's because tests results aren't stored anywhere.  The stdio output is the only output the tests produce.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29047>
_______________________________________

From report at bugs.python.org  Thu Dec 22 08:25:12 2016
From: report at bugs.python.org (R. David Murray)
Date: Thu, 22 Dec 2016 13:25:12 +0000
Subject: [issue29048] Coverage influence tests, make some of them fail
In-Reply-To: <1482407776.18.0.223230024277.issue29048@psf.upfronthosting.co.za>
Message-ID: <1482413112.44.0.376240434933.issue29048@psf.upfronthosting.co.za>


R. David Murray added the comment:

Ideally it should not, so these would be interesting bugs to investigate.

----------
nosy: +r.david.murray
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29048>
_______________________________________

From report at bugs.python.org  Thu Dec 22 08:38:19 2016
From: report at bugs.python.org (kevin)
Date: Thu, 22 Dec 2016 13:38:19 +0000
Subject: [issue29027] 3.5.2 compile error from ssl related.
In-Reply-To: <1482246944.19.0.555352966537.issue29027@psf.upfronthosting.co.za>
Message-ID: <1482413899.45.0.628297034297.issue29027@psf.upfronthosting.co.za>


kevin added the comment:

Hi Christian,
    Thanks for your reply.

The machine's information as following:

Platform: x86_64;

OS: ubuntu16.04;

Compiler: gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609;

Openssl version:OpenSSL 1.1.0c  10 Nov 2016.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29027>
_______________________________________

From report at bugs.python.org  Thu Dec 22 08:44:48 2016
From: report at bugs.python.org (Patrik Iselind)
Date: Thu, 22 Dec 2016 13:44:48 +0000
Subject: [issue29047] Where are the test results stored?
In-Reply-To: <1482403473.61.0.626919341446.issue29047@psf.upfronthosting.co.za>
Message-ID: <1482414288.92.0.415165723574.issue29047@psf.upfronthosting.co.za>


Patrik Iselind added the comment:

Is this something we could clarify in the docs?

I'd like to try and dip my toes in this.

Where can i find the source for
https://docs.python.org/devguide/runtests.html
?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29047>
_______________________________________

From report at bugs.python.org  Thu Dec 22 08:46:24 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 22 Dec 2016 13:46:24 +0000
Subject: [issue29048] Coverage influence tests, make some of them fail
In-Reply-To: <1482407776.18.0.223230024277.issue29048@psf.upfronthosting.co.za>
Message-ID: <1482414384.65.0.880166856209.issue29048@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Following patch fixes failures in test_ssl and test_subprocess.

----------
keywords: +patch
nosy: +serhiy.storchaka
stage:  -> patch review
Added file: http://bugs.python.org/file45998/coverity-tests-warnings.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29048>
_______________________________________

From report at bugs.python.org  Thu Dec 22 08:47:36 2016
From: report at bugs.python.org (Patrik Iselind)
Date: Thu, 22 Dec 2016 13:47:36 +0000
Subject: [issue29048] Coverage influence tests, make some of them fail
In-Reply-To: <1482407776.18.0.223230024277.issue29048@psf.upfronthosting.co.za>
Message-ID: <1482414456.04.0.879631476348.issue29048@psf.upfronthosting.co.za>


Patrik Iselind added the comment:

Are the tests that altered the execution environment something to bother with at all? Perhaps something for another issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29048>
_______________________________________

From report at bugs.python.org  Thu Dec 22 09:01:59 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 22 Dec 2016 14:01:59 +0000
Subject: [issue29047] Where are the test results stored?
In-Reply-To: <1482403473.61.0.626919341446.issue29047@psf.upfronthosting.co.za>
Message-ID: <1482415319.39.0.714470748883.issue29047@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

https://github.com/python/devguide/blob/github/runtests.rst

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29047>
_______________________________________

From report at bugs.python.org  Thu Dec 22 09:07:21 2016
From: report at bugs.python.org (Patrik Iselind)
Date: Thu, 22 Dec 2016 14:07:21 +0000
Subject: [issue29048] Coverage influence tests, make some of them fail
In-Reply-To: <1482407776.18.0.223230024277.issue29048@psf.upfronthosting.co.za>
Message-ID: <1482415641.97.0.0449767397684.issue29048@psf.upfronthosting.co.za>


Patrik Iselind added the comment:

The fixes for test_ssl and test_subprocess seem strange to me. All they do is sweep the messages under the rug. Then there is not really any point with the 'with' block, is there?

Without coverage those tests passed so i cannot really see how this adds up.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29048>
_______________________________________

From report at bugs.python.org  Thu Dec 22 09:15:21 2016
From: report at bugs.python.org (Patrik Iselind)
Date: Thu, 22 Dec 2016 14:15:21 +0000
Subject: [issue29047] Where are the test results stored?
In-Reply-To: <1482415319.39.0.714470748883.issue29047@psf.upfronthosting.co.za>
Message-ID: <CANzOjBg6w9JxN-GjW7UUYG+fFTV+oHB4TV59iJ6QFWawQQOfTQ@mail.gmail.com>


Patrik Iselind added the comment:

Great, thanks!

Patrik

Den 22 dec 2016 15:01 skrev "Eric V. Smith" <report at bugs.python.org>:

>
> Eric V. Smith added the comment:
>
> https://github.com/python/devguide/blob/github/runtests.rst
>
> ----------
> nosy: +eric.smith
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue29047>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29047>
_______________________________________

From report at bugs.python.org  Thu Dec 22 09:16:47 2016
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 22 Dec 2016 14:16:47 +0000
Subject: [issue28695] Add SSL_CTX_set_client_cert_engine
In-Reply-To: <1479207688.81.0.066994858547.issue28695@psf.upfronthosting.co.za>
Message-ID: <1482416207.15.0.935390830359.issue28695@psf.upfronthosting.co.za>


Christian Heimes added the comment:

OPENSSL_config() is deprecated. I'm going to wrap CONF_modules_load_file(), CONF_modules_load() and NCONF_load_bio().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28695>
_______________________________________

From report at bugs.python.org  Thu Dec 22 09:35:46 2016
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 22 Dec 2016 14:35:46 +0000
Subject: [issue29027] 3.5.2 compile error from ssl related.
In-Reply-To: <1482246944.19.0.555352966537.issue29027@psf.upfronthosting.co.za>
Message-ID: <1482417346.25.0.57801222215.issue29027@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Python 3.5.2 is not compatible with OpenSSL 1.1.0. You have to wait until 3.5.3 is released in about a month or downgrade OpenSSL to 1.0.2.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29027>
_______________________________________

From report at bugs.python.org  Thu Dec 22 09:42:29 2016
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 22 Dec 2016 14:42:29 +0000
Subject: [issue29049] Lazy GC tracking frame
In-Reply-To: <1482408044.82.0.398076651662.issue29049@psf.upfronthosting.co.za>
Message-ID: <1482417749.88.0.877491043908.issue29049@psf.upfronthosting.co.za>


INADA Naoki added the comment:

--enable-optimizations:
$ ~/local/cpython/bin/pyperf compare_to -G default.json patched.json
Slower (12):
- pickle_dict: 42.0 us +- 0.2 us -> 42.9 us +- 0.2 us: 1.02x slower (+2%)
- regex_dna: 228 ms +- 1 ms -> 233 ms +- 2 ms: 1.02x slower (+2%)
- unpickle_list: 4.83 us +- 0.04 us -> 4.93 us +- 0.05 us: 1.02x slower (+2%)
- nbody: 175 ms +- 1 ms -> 178 ms +- 1 ms: 1.02x slower (+2%)
- unpack_sequence: 72.3 ns +- 0.4 ns -> 73.5 ns +- 4.8 ns: 1.02x slower (+2%)
- scimark_sparse_mat_mult: 5.21 ms +- 0.09 ms -> 5.27 ms +- 0.04 ms: 1.01x slower (+1%)
- dulwich_log: 97.2 ms +- 1.2 ms -> 98.2 ms +- 1.4 ms: 1.01x slower (+1%)
- pickle_list: 5.69 us +- 0.04 us -> 5.73 us +- 0.07 us: 1.01x slower (+1%)
- logging_format: 18.4 us +- 0.4 us -> 18.5 us +- 0.4 us: 1.01x slower (+1%)
- meteor_contest: 148 ms +- 2 ms -> 149 ms +- 2 ms: 1.01x slower (+1%)
- sympy_sum: 133 ms +- 4 ms -> 134 ms +- 5 ms: 1.00x slower (+0%)
- python_startup: 12.3 ms +- 0.1 ms -> 12.3 ms +- 0.1 ms: 1.00x slower (+0%)

Faster (42):
- call_method_slots: 9.95 ms +- 0.33 ms -> 9.36 ms +- 0.38 ms: 1.06x faster (-6%)
- call_method: 10.3 ms +- 0.4 ms -> 9.80 ms +- 0.53 ms: 1.05x faster (-5%)
- pickle: 15.0 us +- 0.1 us -> 14.3 us +- 0.2 us: 1.05x faster (-5%)
- call_method_unknown: 11.6 ms +- 0.3 ms -> 11.1 ms +- 0.4 ms: 1.04x faster (-4%)
- spectral_norm: 195 ms +- 2 ms -> 188 ms +- 1 ms: 1.04x faster (-4%)
- pathlib: 24.4 ms +- 0.3 ms -> 23.7 ms +- 0.3 ms: 1.03x faster (-3%)
- json_dumps: 17.5 ms +- 0.5 ms -> 17.0 ms +- 0.3 ms: 1.03x faster (-3%)
- regex_v8: 34.4 ms +- 0.2 ms -> 33.5 ms +- 0.4 ms: 1.03x faster (-3%)
- call_simple: 9.26 ms +- 0.30 ms -> 9.01 ms +- 0.39 ms: 1.03x faster (-3%)
- logging_silent: 456 ns +- 5 ns -> 444 ns +- 6 ns: 1.03x faster (-3%)
- richards: 106 ms +- 2 ms -> 104 ms +- 2 ms: 1.02x faster (-2%)
- django_template: 206 ms +- 8 ms -> 202 ms +- 7 ms: 1.02x faster (-2%)
- sqlite_synth: 4.74 us +- 0.16 us -> 4.64 us +- 0.10 us: 1.02x faster (-2%)
- scimark_fft: 467 ms +- 3 ms -> 457 ms +- 16 ms: 1.02x faster (-2%)
- deltablue: 10.8 ms +- 0.2 ms -> 10.6 ms +- 0.2 ms: 1.02x faster (-2%)
- regex_compile: 269 ms +- 5 ms -> 263 ms +- 2 ms: 1.02x faster (-2%)
- genshi_xml: 98.5 ms +- 1.8 ms -> 96.7 ms +- 1.0 ms: 1.02x faster (-2%)
- sympy_expand: 615 ms +- 9 ms -> 604 ms +- 11 ms: 1.02x faster (-2%)
- tornado_http: 265 ms +- 4 ms -> 261 ms +- 4 ms: 1.02x faster (-2%)
- scimark_sor: 298 ms +- 3 ms -> 294 ms +- 3 ms: 1.02x faster (-2%)
- pickle_pure_python: 704 us +- 16 us -> 693 us +- 8 us: 1.02x faster (-1%)
- crypto_pyaes: 154 ms +- 1 ms -> 152 ms +- 1 ms: 1.02x faster (-1%)
- raytrace: 753 ms +- 8 ms -> 743 ms +- 8 ms: 1.01x faster (-1%)
- nqueens: 140 ms +- 1 ms -> 138 ms +- 1 ms: 1.01x faster (-1%)
- sympy_str: 277 ms +- 6 ms -> 274 ms +- 4 ms: 1.01x faster (-1%)
- regex_effbot: 4.03 ms +- 0.12 ms -> 3.98 ms +- 0.06 ms: 1.01x faster (-1%)
- html5lib: 130 ms +- 4 ms -> 129 ms +- 4 ms: 1.01x faster (-1%)
- sqlalchemy_declarative: 237 ms +- 3 ms -> 234 ms +- 3 ms: 1.01x faster (-1%)
- scimark_monte_carlo: 153 ms +- 2 ms -> 152 ms +- 1 ms: 1.01x faster (-1%)
- hexiom: 14.8 ms +- 0.1 ms -> 14.7 ms +- 0.1 ms: 1.01x faster (-1%)
- 2to3: 446 ms +- 2 ms -> 441 ms +- 2 ms: 1.01x faster (-1%)
- mako: 29.0 ms +- 0.1 ms -> 28.8 ms +- 0.2 ms: 1.01x faster (-1%)
- go: 346 ms +- 3 ms -> 343 ms +- 4 ms: 1.01x faster (-1%)
- float: 184 ms +- 3 ms -> 183 ms +- 2 ms: 1.01x faster (-1%)
- sqlalchemy_imperative: 49.2 ms +- 1.1 ms -> 48.7 ms +- 0.9 ms: 1.01x faster (-1%)
- genshi_text: 46.5 ms +- 0.7 ms -> 46.1 ms +- 0.5 ms: 1.01x faster (-1%)
- telco: 9.82 ms +- 0.38 ms -> 9.74 ms +- 0.17 ms: 1.01x faster (-1%)
- chaos: 162 ms +- 1 ms -> 161 ms +- 1 ms: 1.01x faster (-1%)
- sympy_integrate: 30.0 ms +- 0.2 ms -> 29.8 ms +- 0.2 ms: 1.01x faster (-1%)
- fannkuch: 709 ms +- 2 ms -> 705 ms +- 1 ms: 1.01x faster (-1%)
- scimark_lu: 322 ms +- 8 ms -> 320 ms +- 5 ms: 1.00x faster (-0%)
- json_loads: 36.0 us +- 0.2 us -> 36.0 us +- 0.2 us: 1.00x faster (-0%)

Benchmark hidden because not significant (10): chameleon, logging_simple, pidigits, python_startup_no_site, unpickle, unpickle_pure_python, xml_etree_generate, xml_etree_iterparse, xml_etree_parse, xml_etree_process

----------
Added file: http://bugs.python.org/file45999/patched.json.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29049>
_______________________________________

From report at bugs.python.org  Thu Dec 22 09:42:44 2016
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 22 Dec 2016 14:42:44 +0000
Subject: [issue29049] Lazy GC tracking frame
In-Reply-To: <1482408044.82.0.398076651662.issue29049@psf.upfronthosting.co.za>
Message-ID: <1482417764.32.0.963270582947.issue29049@psf.upfronthosting.co.za>


Changes by INADA Naoki <songofacandy at gmail.com>:


Added file: http://bugs.python.org/file46000/default.json.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29049>
_______________________________________

From report at bugs.python.org  Thu Dec 22 09:54:53 2016
From: report at bugs.python.org (Eric Appelt)
Date: Thu, 22 Dec 2016 14:54:53 +0000
Subject: [issue29026] time.time() documentation should mention UTC timezone
In-Reply-To: <1482243889.09.0.538886851254.issue29026@psf.upfronthosting.co.za>
Message-ID: <1482418493.92.0.280819664741.issue29026@psf.upfronthosting.co.za>


Eric Appelt added the comment:

I would be happy to work on a documentation patch for this - I'll try to have something up by tomorrow evening if no one beats me to it.

----------
nosy: +Eric Appelt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29026>
_______________________________________

From report at bugs.python.org  Thu Dec 22 10:12:55 2016
From: report at bugs.python.org (kevin)
Date: Thu, 22 Dec 2016 15:12:55 +0000
Subject: [issue29027] 3.5.2 compile error from ssl related.
In-Reply-To: <1482246944.19.0.555352966537.issue29027@psf.upfronthosting.co.za>
Message-ID: <1482419575.65.0.926856859934.issue29027@psf.upfronthosting.co.za>


kevin added the comment:

Hi Christian,

    This issue is resolved.

Thanks a lot.

----------
resolution: not a bug -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29027>
_______________________________________

From report at bugs.python.org  Thu Dec 22 10:27:57 2016
From: report at bugs.python.org (Eric Lafontaine)
Date: Thu, 22 Dec 2016 15:27:57 +0000
Subject: [issue28879] smtplib send_message should add Date header if it is
 missing, per RFC5322
In-Reply-To: <1480952895.22.0.418354723664.issue28879@psf.upfronthosting.co.za>
Message-ID: <1482420477.9.0.708993876793.issue28879@psf.upfronthosting.co.za>


Eric Lafontaine added the comment:

Hi David, Henning,

Sorry for the delay.  Here is the patch for python 2... but I find that adding an "example" just for RFC 5322 is kind of over-kill...

So I've made both :) please choose which one you prefer and let me know.  I personnally prefer to use the non-overkill (which is only a comment and a line of code).

David, I know you might not like it, but could you be my mentor?  I feel you have an understanding of messaging applications :).  I know you don't have much time, but I feel you're a big participant and you could delegate some tasks on to me.  

Regards,
Eric Lafontaine

- Implement a patch for the code to add a missing "Date" field if it doesn't exist .   (in review)
- Modify the documentation at the SMTPLib for the send_message to mention that it add missing date using the email.utils.formatdate 
- Modify the comment of the send_message code to mention RFC 5322 in there (ideally with the section of the RFC).  ( in review)
- Modify the example of Python 2 to present a RFC 5322 examples ( in review)

With this, I've done all I could... What else can I start to do to get reviewed?

----------
Added file: http://bugs.python.org/file46001/issue_28879_python2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28879>
_______________________________________

From report at bugs.python.org  Thu Dec 22 10:28:14 2016
From: report at bugs.python.org (Eric Lafontaine)
Date: Thu, 22 Dec 2016 15:28:14 +0000
Subject: [issue28879] smtplib send_message should add Date header if it is
 missing, per RFC5322
In-Reply-To: <1480952895.22.0.418354723664.issue28879@psf.upfronthosting.co.za>
Message-ID: <1482420494.37.0.787146257134.issue28879@psf.upfronthosting.co.za>


Eric Lafontaine added the comment:

overkill file

----------
Added file: http://bugs.python.org/file46002/issue_28879_python2_overkill.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28879>
_______________________________________

From report at bugs.python.org  Thu Dec 22 10:35:02 2016
From: report at bugs.python.org (R. David Murray)
Date: Thu, 22 Dec 2016 15:35:02 +0000
Subject: [issue28879] smtplib send_message should add Date header if it is
 missing, per RFC5322
In-Reply-To: <1480952895.22.0.418354723664.issue28879@psf.upfronthosting.co.za>
Message-ID: <1482420902.19.0.170284983833.issue28879@psf.upfronthosting.co.za>


R. David Murray added the comment:

I'm happy to comment on issues as far as mentoring goes, and yes email is my primary area of responsibility for CPython.  However, I don't have much free time, so getting to reviews is proving to be problematic.  There's a chance a might have some time this weekend, but no promises :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28879>
_______________________________________

From report at bugs.python.org  Thu Dec 22 10:38:41 2016
From: report at bugs.python.org (Eric Lafontaine)
Date: Thu, 22 Dec 2016 15:38:41 +0000
Subject: [issue28945] get_boundary invokes unquote twice
In-Reply-To: <1481547297.88.0.91240101349.issue28945@psf.upfronthosting.co.za>
Message-ID: <1482421121.06.0.126444138231.issue28945@psf.upfronthosting.co.za>


Eric Lafontaine added the comment:

Hi,

I would like to have a bigger set of user testing this patch before it gets approve... I really don't know all the extent to which it's a good/bad idea.  

The proposition was to not do the unquote in the rfc2231 collapse method.  It doesn't break anything on my machine on all the email tests... but I can't feel safe.

I also added the 2 test case for future support (multiline boundary and single line boundary).  It's basically the code I pasted on my answer on the 2016-12-20.

Let me know what you think.  Is it there we should stop doing it?

Regards,
Eric Lafontaine

----------
keywords: +patch
Added file: http://bugs.python.org/file46003/issue_28945.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28945>
_______________________________________

From report at bugs.python.org  Thu Dec 22 10:41:20 2016
From: report at bugs.python.org (Eric Lafontaine)
Date: Thu, 22 Dec 2016 15:41:20 +0000
Subject: [issue28945] get_boundary invokes unquote twice
In-Reply-To: <1481547297.88.0.91240101349.issue28945@psf.upfronthosting.co.za>
Message-ID: <1482421280.2.0.811011406323.issue28945@psf.upfronthosting.co.za>


Eric Lafontaine added the comment:

Hi,

I would like to thank you for keeping up with me.  I may not be easy at times, but please make me understand if it doesn't make sense :).

Thanks bpoaugust and David,
Eric Lafontaine

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28945>
_______________________________________

From report at bugs.python.org  Thu Dec 22 11:06:10 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 22 Dec 2016 16:06:10 +0000
Subject: [issue29048] Coverage influence tests, make some of them fail
In-Reply-To: <1482407776.18.0.223230024277.issue29048@psf.upfronthosting.co.za>
Message-ID: <1482422770.39.0.521015780606.issue29048@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +nedbat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29048>
_______________________________________

From report at bugs.python.org  Thu Dec 22 12:16:31 2016
From: report at bugs.python.org (bpoaugust)
Date: Thu, 22 Dec 2016 17:16:31 +0000
Subject: [issue28945] get_boundary (and get_filename) invokes unquote twice
In-Reply-To: <1481547297.88.0.91240101349.issue28945@psf.upfronthosting.co.za>
Message-ID: <1482426991.33.0.34036228414.issue28945@psf.upfronthosting.co.za>


bpoaugust added the comment:

I have just discovered the same problem with get_filename.
Not surprising as its code is basically the same as get_boundary.

Unix paths can contain anything, so it's not correct to remove special characters. [It's up to the receiving file system to decide how to deal with chars that are not valid for it; the original name must be passed unchanged]

If the quoting/unquoting is fixed for filenames, then it should be OK for the boundary as well.

I think collapse_rfc2231_value should assume that any unquoting has already been done, and should therefore not call utils.unquote at all.

The get_param() method by default unquotes both single strings and encoded triplets, so it's certainly the case that get_boundary and get_filename will pass an unquoted value to rfc2231, as will any other caller that calls get_param with the default parameters.

----------
title: get_boundary invokes unquote twice -> get_boundary (and get_filename) invokes unquote twice

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28945>
_______________________________________

From report at bugs.python.org  Thu Dec 22 12:25:02 2016
From: report at bugs.python.org (bpoaugust)
Date: Thu, 22 Dec 2016 17:25:02 +0000
Subject: [issue28945] get_boundary (and get_filename) invokes unquote twice
In-Reply-To: <1481547297.88.0.91240101349.issue28945@psf.upfronthosting.co.za>
Message-ID: <1482427502.18.0.88178243246.issue28945@psf.upfronthosting.co.za>


bpoaugust added the comment:

Note: it's easy to create test e-mails with attachments using mutt.

echo test | mutt -s "test" -a files... -- user at domain

I did some testing with the following names:

<>
><
""
"<abc>"
<"abc">
>abc<
">abc<"
>"abc"<

There are no doubt other awkward names one can devise; in particular it would be useful to generate similar names with non-ASCII characters in them to force the use of value triples.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28945>
_______________________________________

From report at bugs.python.org  Thu Dec 22 12:48:46 2016
From: report at bugs.python.org (Adam Williamson)
Date: Thu, 22 Dec 2016 17:48:46 +0000
Subject: [issue29050] xml.etree.ElementTree in Python 3.6 is incompatible with
 defusedxml
Message-ID: <1482428926.43.0.656400422228.issue29050@psf.upfronthosting.co.za>


New submission from Adam Williamson:

The changes made to xml.etree.ElementTree in this commit:

https://github.com/python/cpython/commit/12a626fae80a57752ccd91ad25b5a283e18154ec

break defusedxml , Christian Heimes' library of modified parsers that's intended to be safe for parsing untrusted input. As of now, it's not possible to have defusedxml working properly with Python 3.6; its ElementTree parsers cannot work properly.

Of course, defusedxml is an external library that does 'inappropriate' things (like fiddling around with internals of the xml library). So usually this should be considered just a problem for defusedxml to deal with somehow, and indeed I've reported it there: https://github.com/tiran/defusedxml/issues/3 . That report has more details on the precise problem.

I thought it was worthwhile reporting to Python itself as well, however, for a specific reason. The Python docs for the xml library explicitly cover and endorse the use of defusedxml:

"defusedxml is a pure Python package with modified subclasses of all stdlib XML parsers that prevent any potentially malicious operation. Use of this package is recommended for any server code that parses untrusted XML data." - https://docs.python.org/3.6/library/xml.html#the-defusedxml-and-defusedexpat-packages

so as things stand, the Python 3.6 docs will explicitly recommend people use a module which does not work with Python 3.6. Is this considered a serious problem?

It also looks to me (though I'm hardly an expert) as if it might be quite difficult and ugly to fix this on the defusedxml side, and the 'nicest' fix might actually be to tweak Python's xml module back a bit more to how it was in < 3.6 (but without losing the optimization from the commit in question) so it's easier for defusedxml to get at the internals it needs...but I could well be wrong about that.

Thanks!

----------
components: XML
messages: 283854
nosy: adamwill
priority: normal
severity: normal
status: open
title: xml.etree.ElementTree in Python 3.6 is incompatible with defusedxml
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29050>
_______________________________________

From report at bugs.python.org  Thu Dec 22 13:12:44 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 22 Dec 2016 18:12:44 +0000
Subject: [issue29050] xml.etree.ElementTree in Python 3.6 is incompatible with
 defusedxml
In-Reply-To: <1482428926.43.0.656400422228.issue29050@psf.upfronthosting.co.za>
Message-ID: <1482430364.79.0.819973810731.issue29050@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +christian.heimes, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29050>
_______________________________________

From report at bugs.python.org  Thu Dec 22 13:16:46 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 22 Dec 2016 18:16:46 +0000
Subject: [issue29050] xml.etree.ElementTree in Python 3.6 is incompatible with
 defusedxml
In-Reply-To: <1482428926.43.0.656400422228.issue29050@psf.upfronthosting.co.za>
Message-ID: <1482430606.77.0.753920501186.issue29050@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could you please provide an example of code that doesn't work with Python 3.6?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29050>
_______________________________________

From report at bugs.python.org  Thu Dec 22 13:25:03 2016
From: report at bugs.python.org (Ammar Askar)
Date: Thu, 22 Dec 2016 18:25:03 +0000
Subject: [issue29050] xml.etree.ElementTree in Python 3.6 is incompatible with
 defusedxml
In-Reply-To: <1482428926.43.0.656400422228.issue29050@psf.upfronthosting.co.za>
Message-ID: <1482431103.85.0.784558091158.issue29050@psf.upfronthosting.co.za>


Ammar Askar added the comment:

>From what I can tell from the failed travis run in defused, the problem is here:

https://github.com/tiran/defusedxml/blob/master/defusedxml/common.py#L129-L141

It's caused by it using the removed _IterParseIterator file (or rather a field that represents it that's set to None)

The full traceback can be found here:

https://travis-ci.org/tiran/defusedxml/jobs/154677920#L192-L203

----------
nosy: +ammar2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29050>
_______________________________________

From report at bugs.python.org  Thu Dec 22 13:34:28 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Thu, 22 Dec 2016 18:34:28 +0000
Subject: [issue29049] Lazy GC tracking frame
In-Reply-To: <1482408044.82.0.398076651662.issue29049@psf.upfronthosting.co.za>
Message-ID: <1482431668.68.0.632038184245.issue29049@psf.upfronthosting.co.za>


Changes by Josh Rosenberg <shadowranger+python at gmail.com>:


----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29049>
_______________________________________

From report at bugs.python.org  Thu Dec 22 14:01:15 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 22 Dec 2016 19:01:15 +0000
Subject: [issue29050] xml.etree.ElementTree in Python 3.6 is incompatible with
 defusedxml
In-Reply-To: <1482428926.43.0.656400422228.issue29050@psf.upfronthosting.co.za>
Message-ID: <1482433275.6.0.573275145007.issue29050@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think this can be fixed from defusedxml side:

    def iterparse(source, events=None, parser=None, forbid_dtd=False,
                  forbid_entities=True, forbid_external=True):
        if not parser:
            parser = DefusedXMLParser(target=_TreeBuilder(),
                                      forbid_dtd=forbid_dtd,
                                      forbid_entities=forbid_entities,
                                      forbid_external=forbid_external)
        return xml.etree.ElementTree.iterparse(source, events, parser)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29050>
_______________________________________

From report at bugs.python.org  Thu Dec 22 14:28:22 2016
From: report at bugs.python.org (Adam Williamson)
Date: Thu, 22 Dec 2016 19:28:22 +0000
Subject: [issue29050] xml.etree.ElementTree in Python 3.6 is incompatible with
 defusedxml
In-Reply-To: <1482428926.43.0.656400422228.issue29050@psf.upfronthosting.co.za>
Message-ID: <1482434902.31.0.252342642902.issue29050@psf.upfronthosting.co.za>


Adam Williamson added the comment:

Ammar: yep, that's correct. There's code in defused's ElementTree.py - _ get_py3_cls() - which passes different values to _generate_etree_functions based on the Python 3 version.

For Python 3.2+, defused 0.4.1 expects to use the _IterParseIterator class from xml ElementTree , but that got removed in 3.6, so if you just use defused 0.4.1 with Python 3.6, it asserts as soon as you try to import defusedxml.ElementTree at all:

>>> import defusedxml.ElementTree
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/tmp/defusedxml-0.4.1/defusedxml/ElementTree.py", line 62, in <module>
    _XMLParser, _iterparse, _IterParseIterator, ParseError = _get_py3_cls()
  File "/tmp/defusedxml-0.4.1/defusedxml/ElementTree.py", line 56, in _get_py3_cls
    _IterParseIterator = pure_pymod._IterParseIterator
AttributeError: module 'xml.etree.ElementTree' has no attribute '_IterParseIterator'

Christian made a change to make _get_py3_cls() pass None to _generate_etree_functions() so you can at least import defusedxml.ElementTree, but he didn't change _generate_etree_functions() at all so it just doesn't have a code path that handles this at all; for Python 3.2+ it's expecting to get a real iterator, not None, and it just breaks completely trying to use None as an iterator:

<mock-chroot> sh-4.3# echo "<xml></xml>" > test.xml
<mock-chroot> sh-4.3# python3
>>> import defusedxml.ElementTree
>>> parser = defusedxml.ElementTree.iterparse('test.xml')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/tmp/defusedxml-0.4.1/defusedxml/common.py", line 141, in iterparse
    return _IterParseIterator(source, events, parser, close_source)
TypeError: 'NoneType' object is not callable

Serhiy, thanks for the suggestion! We'll try that out.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29050>
_______________________________________

From report at bugs.python.org  Thu Dec 22 15:00:38 2016
From: report at bugs.python.org (Tim Smith)
Date: Thu, 22 Dec 2016 20:00:38 +0000
Subject: [issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew
 installs fragile
In-Reply-To: <1411623045.52.0.589017779939.issue22490@psf.upfronthosting.co.za>
Message-ID: <1482436838.94.0.527377078187.issue22490@psf.upfronthosting.co.za>


Tim Smith added the comment:

I spoke prematurely; I recently rediscovered that the persistence of __PYVENV_LAUNCHER__ poisons the sys.executable of virtualenv interpreters launched as a subprocess of another Python interpreter:

$ virtualenv -p python3 test
$ test/bin/python3 -c 'import sys; print(sys.executable)'
/Users/tim/test/bin/python3

$ /usr/local/bin/python3 -c 'import subprocess; subprocess.call(["/Users/tim/test/bin/python3", "-c", "import sys; print(sys.executable)"])'
/usr/local/bin/python3

$ /usr/local/bin/python3 -c 'import subprocess, os; del os.environ["__PYVENV_LAUNCHER__"]; subprocess.call(["/Users/tim/test/bin/python3", "-c", "import sys; print(sys.executable)"])'
/Users/tim/test/bin/python3

If __PYVENV_LAUNCHER__ can be unset before script execution begins, that seems ideal.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22490>
_______________________________________

From report at bugs.python.org  Thu Dec 22 15:03:44 2016
From: report at bugs.python.org (Adam Williamson)
Date: Thu, 22 Dec 2016 20:03:44 +0000
Subject: [issue29050] xml.etree.ElementTree in Python 3.6 is incompatible with
 defusedxml
In-Reply-To: <1482428926.43.0.656400422228.issue29050@psf.upfronthosting.co.za>
Message-ID: <1482437024.11.0.729669356712.issue29050@psf.upfronthosting.co.za>


Adam Williamson added the comment:

serhiy: so, the funny thing is this: your fix is ultimately a reversion. Though we have to dig way back into the bowels of defusedxml to see this. Specifically, to this commit!

https://github.com/tiran/defusedxml/commit/03d4fc6cf246a209c2cf892b33f5b6cf5af4ecbd

that's the point at which Christian introduced a divergence between Python 2 and Python 3 here, and essentially the same divergence remains between the `elif PY3:` and `else: # Python 2.7` blocks now. The Python 2.7 block in current defusedxml is in fact the same as your block, because `_iterparse` is just the parent `iterparse` function, as discovered by `_get_py3_cls()`.

So before applying your change, I kinda want to understand why Christian introduced this divergence in the first place. The commit message claims it's because Python 3.3 hid some pure python, but I don't quite understand that: https://github.com/python/cpython/blob/3.3/Lib/xml/etree/ElementTree.py looks like iterparse() was still perfectly available and usable for this purpose in 3.3, just as it was in 3.2 and still appears to be in 3.6.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29050>
_______________________________________

From report at bugs.python.org  Thu Dec 22 15:13:35 2016
From: report at bugs.python.org (Adam Williamson)
Date: Thu, 22 Dec 2016 20:13:35 +0000
Subject: [issue29050] xml.etree.ElementTree in Python 3.6 is incompatible with
 defusedxml
In-Reply-To: <1482428926.43.0.656400422228.issue29050@psf.upfronthosting.co.za>
Message-ID: <1482437615.92.0.629456279236.issue29050@psf.upfronthosting.co.za>


Adam Williamson added the comment:

Aha, so thanks to my colleague Patrick Uiterwijk, we see the problem. Since Python 3.3, Python doesn't actually use that pure-Python iterparse() function if it can instead replace it with a C version:

https://github.com/python/cpython/blob/3.3/Lib/xml/etree/ElementTree.py#L1705

"# Overwrite 'ElementTree.parse' and 'iterparse' to use the C XMLParser"

so the reason defusedxml wants to use _IterParseIterator on Python 3 is because if it just uses xml.etree.ElementTree.iterparse() it's getting the 'accelerated' C implementation, not the pure-Python implementation it wants.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29050>
_______________________________________

From report at bugs.python.org  Thu Dec 22 15:24:57 2016
From: report at bugs.python.org (Adam Williamson)
Date: Thu, 22 Dec 2016 20:24:57 +0000
Subject: [issue29050] xml.etree.ElementTree in Python 3.6 is incompatible with
 defusedxml
In-Reply-To: <1482428926.43.0.656400422228.issue29050@psf.upfronthosting.co.za>
Message-ID: <1482438297.51.0.683711596401.issue29050@psf.upfronthosting.co.za>


Adam Williamson added the comment:

Digging some more, it looks like *only* Python 3.3 went so far out of its way to hide the pure-Python iterparse() - the code was changed again in 3.4 and it doesn't do that any more. So I think a way forward here is to make the code that uses _IterParseIterator specific to Python 3.3, and use the Python 2.7 code (i.e. just use the iterparse() function) for 3.2 and 3.4+.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29050>
_______________________________________

From report at bugs.python.org  Thu Dec 22 15:42:34 2016
From: report at bugs.python.org (Adam Williamson)
Date: Thu, 22 Dec 2016 20:42:34 +0000
Subject: [issue29050] xml.etree.ElementTree in Python 3.6 is incompatible with
 defusedxml
In-Reply-To: <1482428926.43.0.656400422228.issue29050@psf.upfronthosting.co.za>
Message-ID: <1482439354.65.0.85513007202.issue29050@psf.upfronthosting.co.za>


Adam Williamson added the comment:

https://paste.fedoraproject.org/511245/14824393/ is my cut at a fix for this, gonna test it out now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29050>
_______________________________________

From report at bugs.python.org  Thu Dec 22 15:53:29 2016
From: report at bugs.python.org (Adam Williamson)
Date: Thu, 22 Dec 2016 20:53:29 +0000
Subject: [issue29050] xml.etree.ElementTree in Python 3.6 is incompatible with
 defusedxml
In-Reply-To: <1482428926.43.0.656400422228.issue29050@psf.upfronthosting.co.za>
Message-ID: <1482440009.3.0.900633049813.issue29050@psf.upfronthosting.co.za>


Adam Williamson added the comment:

https://github.com/tiran/defusedxml/pull/4 should fix this, I hope.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29050>
_______________________________________

From report at bugs.python.org  Thu Dec 22 17:47:25 2016
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Thu, 22 Dec 2016 22:47:25 +0000
Subject: [issue29002] typing.AnyStr doc is unclear about python2 unicode
 support
In-Reply-To: <1482018824.86.0.562219638154.issue29002@psf.upfronthosting.co.za>
Message-ID: <1482446845.57.0.253396555957.issue29002@psf.upfronthosting.co.za>


Changes by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
nosy: +levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29002>
_______________________________________

From report at bugs.python.org  Thu Dec 22 17:53:30 2016
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Thu, 22 Dec 2016 22:53:30 +0000
Subject: [issue29011] No entry Deque in typing.py
In-Reply-To: <1482128373.3.0.983889719325.issue29011@psf.upfronthosting.co.za>
Message-ID: <1482447210.49.0.745657857744.issue29011@psf.upfronthosting.co.za>


Changes by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
nosy: +levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29011>
_______________________________________

From report at bugs.python.org  Thu Dec 22 18:39:18 2016
From: report at bugs.python.org (Tim Smith)
Date: Thu, 22 Dec 2016 23:39:18 +0000
Subject: [issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew
 installs fragile
In-Reply-To: <1411623045.52.0.589017779939.issue22490@psf.upfronthosting.co.za>
Message-ID: <1482449958.12.0.830820064665.issue22490@psf.upfronthosting.co.za>


Tim Smith added the comment:

Since __PYVENV_LAUNCHER__ is consulted in site.py, it seems likely that the latest it can be deleted is in site.py. The attached patch does that.

----------
Added file: http://bugs.python.org/file46004/delete-venev-launcher.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22490>
_______________________________________

From report at bugs.python.org  Thu Dec 22 21:44:24 2016
From: report at bugs.python.org (Jim Jewett)
Date: Fri, 23 Dec 2016 02:44:24 +0000
Subject: [issue28968] xml rpc server fails with connection reset by peer error
 no 104
In-Reply-To: <1481709223.17.0.559234955094.issue28968@psf.upfronthosting.co.za>
Message-ID: <1482461064.41.0.96708594682.issue28968@psf.upfronthosting.co.za>


Jim Jewett added the comment:

When I see a message like that, it normally means there is a firewall getting in my way.

----------
nosy: +Jim.Jewett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28968>
_______________________________________

From report at bugs.python.org  Thu Dec 22 22:15:19 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 23 Dec 2016 03:15:19 +0000
Subject: [issue29038] Duplicate entry for SSLContext.get_ca_certs() in ssl
In-Reply-To: <1482348942.9.0.649967135375.issue29038@psf.upfronthosting.co.za>
Message-ID: <20161223031516.20560.90496.A6222F44@psf.io>


Roundup Robot added the comment:

New changeset 94900abda1a5 by Xiang Zhang in branch '2.7':
Issue #29038: Fix duplicate get_ca_certs() doc entry.
https://hg.python.org/cpython/rev/94900abda1a5

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29038>
_______________________________________

From report at bugs.python.org  Thu Dec 22 22:16:54 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 23 Dec 2016 03:16:54 +0000
Subject: [issue29038] Duplicate entry for SSLContext.get_ca_certs() in ssl
In-Reply-To: <1482348942.9.0.649967135375.issue29038@psf.upfronthosting.co.za>
Message-ID: <1482463014.63.0.889367168792.issue29038@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Thanks for the report Daniel!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29038>
_______________________________________

From report at bugs.python.org  Thu Dec 22 22:29:56 2016
From: report at bugs.python.org (Manish Singh)
Date: Fri, 23 Dec 2016 03:29:56 +0000
Subject: [issue28968] xml rpc server fails with connection reset by peer error
 no 104
In-Reply-To: <1481709223.17.0.559234955094.issue28968@psf.upfronthosting.co.za>
Message-ID: <1482463796.76.0.108894576601.issue28968@psf.upfronthosting.co.za>


Manish Singh added the comment:

Hi Jim,
Thank you for replying.

As you are suggesting that there is a firewall setting.

Then in that case every request should fail, right?

But in my case only few request fail(4 out 20 requests).

Have you seen my mail sent to python-dev group through gmail?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28968>
_______________________________________

From report at bugs.python.org  Thu Dec 22 22:45:28 2016
From: report at bugs.python.org (Manish Singh)
Date: Fri, 23 Dec 2016 03:45:28 +0000
Subject: [issue28968] xml rpc server fails with connection reset by peer error
 no 104
In-Reply-To: <1481709223.17.0.559234955094.issue28968@psf.upfronthosting.co.za>
Message-ID: <1482464728.85.0.385372445234.issue28968@psf.upfronthosting.co.za>


Manish Singh added the comment:

Below is the information sent to python-dev group....

=======================================================================

[ Issue ]
I have used xml rpc library with transport as http. My client and server are running on same host.

Some xml rpc requests fail with connection reset by peer error number. I have used xmlrpclib.ServerProxy() to call remote method on xml rpc server running on an ephemeral port.

This issue has happen many times.

log snippet,

  File "/usr/lib64/python2.6/xmlrpclib.py", line 1489, in __request
    verbose=self.__verbose
  File "/usr/lib64/python2.6/xmlrpclib.py", line 1237, in request
    errcode, errmsg, headers = h.getreply()
  File "/usr/lib64/python2.6/httplib.py", line 1064, in getreply
    response = self._conn.getresponse()
  File "/usr/lib64/python2.6/httplib.py", line 990, in getresponse
    response.begin()
  File "/usr/lib64/python2.6/httplib.py", line 391, in begin
    version, status, reason = self._read_status()
  File "/usr/lib64/python2.6/httplib.py", line 349, in _read_status
    line = self.fp.readline()
  File "/usr/lib64/python2.6/socket.py", line 433, in readline
    data = recv(1)
error: [Errno 104] Connection reset by peer

[ Test Environment ]
RHEL 6 with linux kernel 2.6.32-504.16.2.el6.
Python 2.6.6
glibc-2.12-1.149.7


[ Possible Reasons for it ]

1) The machine is connected to the network, and the network is not responsive. 
2) The other side of the connection is not running normally. 
3) There are not enough system resources available. Free up system resources if they are running low. 

Possibility for 1 and 2 are not applicable as it is loop back communication(Client and Server running on same machine).
For Possibility 3, I have already checked system resource and there are enough resources(80% RAM used, 20% cpu usage, around 10 GB RAM free).

I checked for other reasons and i found that this issue may be related with GIL,
Please refer this link,
http://stackoverflow.com/questions/383738/104-connection-reset-by-peer-socket-error-or-when-does-closing-a-socket-resu 

1> Can you please let me know, is it really a issue realted with GIL?
2> If yes, How to resolve this issue?
3> If no, what other reason may exists for such failure. [Note: Those rpc requests fail which return python's dictionary data to client]


========================================================================

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28968>
_______________________________________

From report at bugs.python.org  Thu Dec 22 23:58:55 2016
From: report at bugs.python.org (Eric Appelt)
Date: Fri, 23 Dec 2016 04:58:55 +0000
Subject: [issue29026] time.time() documentation should mention UTC timezone
In-Reply-To: <1482243889.09.0.538886851254.issue29026@psf.upfronthosting.co.za>
Message-ID: <1482469135.91.0.0792719689612.issue29026@psf.upfronthosting.co.za>


Eric Appelt added the comment:

I looked at the documentation and implementation and made a patch to hopefully clarify the issue. I also have some comments:

- The term "epoch" is actually defined at the top of the page with instructions for how to determine it, i.e. run "gmtime(0)".

- I added a definition for the term "seconds since the epoch" since this typically means the number of seconds that have elapsed since the epoch excluding leap seconds, although it may vary by platform.

- I'm a bit uncomfortable with potential confusion regarding Windows, since the Windows epoch begins on 1601, although we adjust it to 1970: https://github.com/python/cpython/blob/d739274e7b69f63263054cc24684e7e637264350/Python/pytime.c#L536-L539 I didn't add a note in the patch as I am not a windows developer, but I wonder if there could be some confusion.

- Even though its redundant with the top of the page, I added specific clarification to time.time() as it appears that most readers are going to navigate to that anchor specifically and not read the discussion of what we mean by "epoch" above.

- I need to test my assertion that Windows does not count leap seconds. I'm pretty sure but not 100% confident that I am correct from what I read, but I need to find someone with a windows machine tomorrow and actually check it. The windows documentation for the FILETIME structure suggests that leap seconds might be counted - https://msdn.microsoft.com/en-us/library/windows/desktop/ms724284(v=vs.85).aspx - but I think this is just an oversight in the documentation.

- Just out of personal curiousity does anyone have an example of a legacy UNIX system that counts leap seconds in the epoch? This seems tricky to do as I would presume that the OS would need some table that would be updated whenever the astronomers declare a new leap second.

----------
keywords: +patch
Added file: http://bugs.python.org/file46005/29026_unixtime_v1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29026>
_______________________________________

From report at bugs.python.org  Fri Dec 23 01:39:33 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 23 Dec 2016 06:39:33 +0000
Subject: [issue23903] Generate PC/python3.def by scraping headers
In-Reply-To: <1428637761.13.0.348463350169.issue23903@psf.upfronthosting.co.za>
Message-ID: <1482475173.61.0.591813923966.issue23903@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

PyCmpWrapper_Type is not defined.

Some underscored names are defined only in special builds (with Py_REF_DEBUG, Py_TRACE_REFS).

PyAST_* and PyNode_* functions are not documented, ast.h and node.h are private headers.

Names like _PyArg_Parse_SizeT shouldn't be removed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23903>
_______________________________________

From report at bugs.python.org  Fri Dec 23 03:39:36 2016
From: report at bugs.python.org (Pradeep)
Date: Fri, 23 Dec 2016 08:39:36 +0000
Subject: [issue12129] Document Object Model API - validation
In-Reply-To: <1305928931.2.0.716148568641.issue12129@psf.upfronthosting.co.za>
Message-ID: <1482482376.61.0.620677310361.issue12129@psf.upfronthosting.co.za>


Pradeep added the comment:

xml minidom.py needs extra validation in setAttributes for certain special characters depending on the attribute name. Attribute values cannot have special characters like <,> and cant be nested as described in the example below

element01 = doc.createElement('element01')
element01.setAttribute('attribute', "script><![CDATA[alert('script!');]]></script>")
doc.firstChild.appendChild(element01)

script shouldn't be allowed as a value for an attribute and I feel it should throw an exception (Value Exception) and as described above <,> shouldn't be allowed as attributes are more like key-value pairs. Could someone tell me if this is right? If it is, then minidom.py needs this extra level of validation for the same

----------
nosy: +pdeep5693

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12129>
_______________________________________

From report at bugs.python.org  Fri Dec 23 07:01:01 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Fri, 23 Dec 2016 12:01:01 +0000
Subject: [issue29051] Improve error reporting involving f-strings (PEP 498)
Message-ID: <1482494461.91.0.191852219403.issue29051@psf.upfronthosting.co.za>


New submission from Chi Hsuan Yen:

Here are the two examples I found confusing when playing with f-strings. The first one involves with a NameError:

$ cat test2
f'''
{
FOO
}
'''

$ python3.7m test2
Traceback (most recent call last):
  File "test2", line 5, in <module>
    '''
NameError: name 'FOO' is not defined


It would be better if the error reporter points to the actual line of the error:

$ python3.7m test2
Traceback (most recent call last):
  File "test2", line 3, in <module>
    FOO
NameError: name 'FOO' is not defined

The second one involves a SyntaxError:

$ cat test2 
f'''
{
a b c
}
'''

$ python3.7m test2
  File "<fstring>", line 2
    a b c
      ^
SyntaxError: invalid syntax

It would be better if the line number is relative to the file instead of the expression in f-strings:

$ python3.7m test2
  File "test2", line 3
    a b c
      ^
SyntaxError: invalid syntax

By the way, external checkers like pyflakes also suffers. They rely on ASTs. Nodes in f-strings have their lineno relative to the {...} expression instead of the whole code string. For example:

import ast

code = '''
f'{LOL}'
'''

for node in ast.walk(ast.parse(code, "<stdin>", "exec")):
    if isinstance(node, ast.Name):
        print(node.lineno)


Prints 1 instead of 2.

Another by the way, ruby reports correct line numbers:

$ cat test3 
"
#{
FOO
}
"

$ ruby test3 
test3:3:in `<main>': uninitialized constant FOO (NameError)


$ cat test3 
"
#{
@@
}
"

$ ruby test3
test3:3: `@@' without identifiers is not allowed as a class variable name
test3:3: syntax error, unexpected end-of-input


Added the author and the primary reviewer of issue24965.

----------
components: Interpreter Core
messages: 283874
nosy: Chi Hsuan Yen, eric.smith, martin.panter
priority: normal
severity: normal
status: open
title: Improve error reporting involving f-strings (PEP 498)
type: enhancement
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29051>
_______________________________________

From report at bugs.python.org  Fri Dec 23 07:11:24 2016
From: report at bugs.python.org (Karsten Tinnefeld)
Date: Fri, 23 Dec 2016 12:11:24 +0000
Subject: [issue29052] Detect Windows platform 32bit/64bit automatically
Message-ID: <1482495084.23.0.916471956703.issue29052@psf.upfronthosting.co.za>


New submission from Karsten Tinnefeld:

When navigating https://www.python.org/ with a browser, in the main menu fly-out Downloads/Download for Windows it suggests to download the 32 bit version of the current 2.x and 3.x releases (leaving out the information that the buttons provide 32 bit binaries).

Further, https://www.python.org/downloads/ repeats this pattern in its header area "Download the latest version for Windows".

May I suggest that, depending on the User-Agent header, the menu offers 64 bit versions of the interpreter and tools package by default in case the browser suggests it is running on a 64 bit platform?

According to own tests and http://www.useragentstring.com/pages/useragentstring.php, this should be possible with a regexp like '(WOW|x)64' on at least IE, FF, Chrome and Edge.

----------
assignee: docs at python
components: Documentation
messages: 283875
nosy: Karsten Tinnefeld, docs at python
priority: normal
severity: normal
status: open
title: Detect Windows platform 32bit/64bit automatically
type: enhancement
versions: Python 2.7, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29052>
_______________________________________

From report at bugs.python.org  Fri Dec 23 07:40:42 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 23 Dec 2016 12:40:42 +0000
Subject: [issue29052] Detect Windows platform 32bit/64bit automatically
In-Reply-To: <1482495084.23.0.916471956703.issue29052@psf.upfronthosting.co.za>
Message-ID: <1482496842.57.0.215126888318.issue29052@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks, it looks like a reasonable request to me, but the issue tracker for python.org is located at https://github.com/python/pythondotorg/issues Please open a new issue there (or send a pull request)

----------
nosy: +berker.peksag
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29052>
_______________________________________

From report at bugs.python.org  Fri Dec 23 08:08:33 2016
From: report at bugs.python.org (issuefinder)
Date: Fri, 23 Dec 2016 13:08:33 +0000
Subject: [issue29018] Misinformation when showing how slices work in The
 Tutorial
In-Reply-To: <1482182384.19.0.82503979706.issue29018@psf.upfronthosting.co.za>
Message-ID: <1482498513.25.0.161640801497.issue29018@psf.upfronthosting.co.za>


issuefinder added the comment:

You seem to be right.
Sorry about the incovenience.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29018>
_______________________________________

From report at bugs.python.org  Fri Dec 23 08:18:19 2016
From: report at bugs.python.org (Pam McA'Nulty)
Date: Fri, 23 Dec 2016 13:18:19 +0000
Subject: [issue14483] inspect.getsource fails to read a file of only comments
In-Reply-To: <1333461114.24.0.345526771392.issue14483@psf.upfronthosting.co.za>
Message-ID: <1482499099.35.0.727081888964.issue14483@psf.upfronthosting.co.za>


Changes by Pam McA'Nulty <pamela at mcanulty.org>:


----------
nosy: +Pam.McANulty

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14483>
_______________________________________

From report at bugs.python.org  Fri Dec 23 08:55:37 2016
From: report at bugs.python.org (R. David Murray)
Date: Fri, 23 Dec 2016 13:55:37 +0000
Subject: [issue29051] Improve error reporting involving f-strings (PEP 498)
In-Reply-To: <1482494461.91.0.191852219403.issue29051@psf.upfronthosting.co.za>
Message-ID: <1482501337.55.0.789465344475.issue29051@psf.upfronthosting.co.za>


R. David Murray added the comment:

These are not problems with f-strings in particular, they are problems in general with the way python parsing and error reporting happens.  The second is presumably (I haven't gotten around to understanding how f-strings work under the hood) an example of error reporting from a separately evaled string.

Improvements in this area are certainly welcome.  There is an open issue relevant to your first example, issue 12458.  I'm sure that f-strings complicate the solution at least slightly, but I think there are more fundamental pre-requisites to be addressed first in solving it.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29051>
_______________________________________

From report at bugs.python.org  Fri Dec 23 08:59:33 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 23 Dec 2016 13:59:33 +0000
Subject: [issue29051] Improve error reporting involving f-strings (PEP 498)
In-Reply-To: <1482494461.91.0.191852219403.issue29051@psf.upfronthosting.co.za>
Message-ID: <1482501573.53.0.895551661323.issue29051@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
dependencies: +Tracebacks should contain the first line of continuation lines

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29051>
_______________________________________

From report at bugs.python.org  Fri Dec 23 09:16:48 2016
From: report at bugs.python.org (bpoaugust)
Date: Fri, 23 Dec 2016 14:16:48 +0000
Subject: [issue29053] Implement >From_ decoding on input from mbox
Message-ID: <1482502608.45.0.127449678115.issue29053@psf.upfronthosting.co.za>


New submission from bpoaugust:

The email package implements mboxo From_ mangling on output by default.

However there is no provision to unmangle >From_ on input.

This means that it's not possible to import mboxo files correctly.

----------
components: email
messages: 283879
nosy: barry, bpoaugust, r.david.murray
priority: normal
severity: normal
status: open
title: Implement >From_ decoding on input from mbox
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29053>
_______________________________________

From report at bugs.python.org  Fri Dec 23 09:17:17 2016
From: report at bugs.python.org (Cornelius Diekmann)
Date: Fri, 23 Dec 2016 14:17:17 +0000
Subject: [issue29054] pty.py: pty.spawn hangs after client disconnect over nc
 (netcat)
Message-ID: <1482502637.76.0.304881442895.issue29054@psf.upfronthosting.co.za>


New submission from Cornelius Diekmann:

My OS: Debian GNU/Linux 8.6 (jessie)
Python 3.4.2
pty.py from Python-3.5.2/Lib (pty.py is just a tiny, portable python file which did not see many changes)


Bug Report

Steps to Reproduce:

I wrote a very simple python remote shell:

#!/usr/bin/env python3
import pty
pty.spawn('/bin/sh')


It can be run in a terminal (call it TermA) with `nc -e ./myfancypythonremoteshell.py -l -p 6699`
In a different terminal (call it TermB), I connect to my fancy remote shell with `nc 127.0.0.1 6699`.
The shell works fine. In TermB, I quit by pressing ctrl+c.

Observed Behavior: In TermA, the nc process, the python process, and the spawned /bin/sh still exist. They still occupy TermA.

Expected Behavior: The client in TermB has disconnected, /bin/sh in TermA can no longer read anything from stdin and it should close down. Ultimately, in TermA, nc should have exited successfully.

Fix: End the _copy loop in pty.py once EOF in STDIN is reached. Everything shuts itself down automatically. I included a small patch to demonstrate this behavior.

This patch is not meant to go straight into production. I have not verified if this behavior somehow breaks other use cases. This bug report is meant to document exactly one specific use case and supply exactly one line of code change for it.

This issue is related to issue26228. Actually, it is complementary. issue26228 wants to return if master_fd is EOF, this issue wants to return if stdin is EOF. Both behaviors together looks good to me. By the way, I hacked a hacky `assert False` into my patch as a placeholder for issue26228's proper handling of exec failures at that part of the code.

I suggest to combine the patches of this issue and issue26228.

----------
components: Library (Lib)
files: pty.patch
keywords: patch
messages: 283880
nosy: Cornelius Diekmann, martin.panter
priority: normal
severity: normal
status: open
title: pty.py: pty.spawn hangs after client disconnect over nc (netcat)
type: enhancement
versions: Python 3.4, Python 3.5
Added file: http://bugs.python.org/file46006/pty.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29054>
_______________________________________

From report at bugs.python.org  Fri Dec 23 09:21:39 2016
From: report at bugs.python.org (Sean Grider)
Date: Fri, 23 Dec 2016 14:21:39 +0000
Subject: [issue14483] inspect.getsource fails to read a file of only comments
In-Reply-To: <1333461114.24.0.345526771392.issue14483@psf.upfronthosting.co.za>
Message-ID: <1482502899.68.0.802177696102.issue14483@psf.upfronthosting.co.za>


Sean Grider added the comment:

I had forgotten all about this bug until I saw an email from Pam today.

The appears to still be some delay.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14483>
_______________________________________

From report at bugs.python.org  Fri Dec 23 09:27:34 2016
From: report at bugs.python.org (bpoaugust)
Date: Fri, 23 Dec 2016 14:27:34 +0000
Subject: [issue29053] Implement >From_ decoding on input from mbox
In-Reply-To: <1482502608.45.0.127449678115.issue29053@psf.upfronthosting.co.za>
Message-ID: <1482503254.41.0.763211387691.issue29053@psf.upfronthosting.co.za>


bpoaugust added the comment:

Is there any way to override the current behaviour?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29053>
_______________________________________

From report at bugs.python.org  Fri Dec 23 09:43:12 2016
From: report at bugs.python.org (R. David Murray)
Date: Fri, 23 Dec 2016 14:43:12 +0000
Subject: [issue29053] Implement >From_ decoding on input from mbox
In-Reply-To: <1482502608.45.0.127449678115.issue29053@psf.upfronthosting.co.za>
Message-ID: <1482504192.14.0.752198686925.issue29053@psf.upfronthosting.co.za>


R. David Murray added the comment:

Not easily.  Making the feedparser more pluggable is on my wish list, but at this point someone would have to fund me for work on the email package before I'd be able to even clear the backlog to think about it :)

I'd say accepting this as a new feature is a no-brainer, if you want to work on a patch.  Make enabling it a Policy option that defaults to the current behavior.

----------
stage:  -> needs patch
type: behavior -> enhancement
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29053>
_______________________________________

From report at bugs.python.org  Fri Dec 23 10:28:13 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 23 Dec 2016 15:28:13 +0000
Subject: [issue14483] inspect.getsource fails to read a file of only comments
In-Reply-To: <1333461114.24.0.345526771392.issue14483@psf.upfronthosting.co.za>
Message-ID: <1482506893.55.0.633164814602.issue14483@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14483>
_______________________________________

From report at bugs.python.org  Fri Dec 23 10:56:58 2016
From: report at bugs.python.org (then0rTh)
Date: Fri, 23 Dec 2016 15:56:58 +0000
Subject: [issue29055] random.choice on empty sequence should hide previous
 exception [patch]
Message-ID: <1482508618.0.0.189699213254.issue29055@psf.upfronthosting.co.za>


New submission from then0rTh:

Passing empty sequence to random.choice function leads to:


Traceback (most recent call last):
  ...
ValueError: number of bits must be greater than zero

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  ...
IndexError: Cannot choose from an empty sequence


* the ValueError doesn't add any useful information, only bloats stderr
* the "During handling" line indicates that something went wrong inside random.py


This patch uses `raise x from None` to hide the ValueError, resulting in much cleaner output.

-Tested on Python 3.7.0a0

----------
components: Library (Lib)
files: random_choice_errmsg.patch
keywords: patch
messages: 283884
nosy: mark.dickinson, rhettinger, then0rTh
priority: normal
severity: normal
status: open
title: random.choice on empty sequence should hide previous exception [patch]
type: behavior
versions: Python 3.7
Added file: http://bugs.python.org/file46007/random_choice_errmsg.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29055>
_______________________________________

From report at bugs.python.org  Fri Dec 23 10:59:48 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Dec 2016 15:59:48 +0000
Subject: [issue29026] time.time() documentation should mention UTC timezone
In-Reply-To: <1482243889.09.0.538886851254.issue29026@psf.upfronthosting.co.za>
Message-ID: <1482508788.85.0.298299819423.issue29026@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Another suggestion: mention localtime() and gmtime() in time() documentation to explain how to convert such timestamp to a more common date format.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29026>
_______________________________________

From report at bugs.python.org  Fri Dec 23 11:47:03 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Fri, 23 Dec 2016 16:47:03 +0000
Subject: [issue29055] random.choice on empty sequence should hide previous
 exception [patch]
In-Reply-To: <1482508618.0.0.189699213254.issue29055@psf.upfronthosting.co.za>
Message-ID: <1482511623.62.0.459687282202.issue29055@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

Seems reasonable to me.

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29055>
_______________________________________

From report at bugs.python.org  Fri Dec 23 12:22:30 2016
From: report at bugs.python.org (Eric Appelt)
Date: Fri, 23 Dec 2016 17:22:30 +0000
Subject: [issue29026] time.time() documentation should mention UTC timezone
In-Reply-To: <1482243889.09.0.538886851254.issue29026@psf.upfronthosting.co.za>
Message-ID: <1482513750.9.0.765484821661.issue29026@psf.upfronthosting.co.za>


Eric Appelt added the comment:

I had some checks performed on a Windows platform using the following snippet:

# valid for 2016
import time
def check():
    t = time.gmtime()
    print(46*86400*365 + 11*86400 + (t.tm_yday-1)*86400 + t.tm_hour*3600 + t.tm_min*60 + t.tm_sec)
    print(time.time())
    print(time.gmtime(0))
check()

This ensures that the time since the epoch is counted excluding leap seconds if the first two lines of output are approximately the same (to nearest second), and finally that the epoch is the Unix epoch.

On Python 3.6.0 (v3.6.0:41df79263a11, Dec 23 2016, 07:18:10) [MSC v.1900 32 bit (Intel)] on win32 I see:

1482502941
1482502941.9609053
time.struct_time(tm_year=1970, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=3, tm_yday=1, tm_isdst=0)

Unless there is major variation among windows versions on how FILETIMEs are calculated and the results of basic system calls, I feel fairly confident now that the calculation of time since the epoch in CPython is the same on Windows as it is in POSIX-compliant platforms.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29026>
_______________________________________

From report at bugs.python.org  Fri Dec 23 12:26:56 2016
From: report at bugs.python.org (Dan Passaro)
Date: Fri, 23 Dec 2016 17:26:56 +0000
Subject: [issue29056] logging.Formatter doesn't respect more than one
 formatException()
Message-ID: <1482514016.63.0.534341960628.issue29056@psf.upfronthosting.co.za>


New submission from Dan Passaro:

If two formatters maintain the default implementation of Formatter.format(), but
provide custom behavior for Formatter.formatException(), whichever
formatException() is called first and returns something truthy is the only
formatException() that is used.

This is due to a misplaced check for a cached value.  logging.Formatter.format()
sets (maybe monkey-patches?) an exc_text attribute onto the record it receives,
with a comment indicating it's to prevent needlessly re-formatting the
exception.  If this value is set, it avoids the call to formatException() and
just returns the exc_text attribute.

If this check for exc_text is moved to Formatter.formatException() instead, I am
sure this behavior will be fixed. I.e. Formatter.formatException()'s first few
lines turn into something like:

    if record.exc_text:
        return record.exc_text
    sio = cString.StringIO()
    # ... and so on (rest of current impl)

This way the default implementation still caches, and subclass implementation
changes still have an effect.

The only problem here is this method has no access to the record object. It's
not clear to me what is the best way to solve this.  I don't have experience
making changes to Python or projects of this size but these are my thoughts:

* Since the formatException() API is public it shouldn't be changed (e.g. to add
  record)
* Removing the caching might have a significant performance penalty for certain
  users, although I haven't really tested it
* Users who care can copy format() source code into their subclasses and remove
  the caching code. Alternatively, a class-level flag can be added to determine
  whether the cache should be used. Documentation in formatException() is added
  to indicate this issue. This seems like a very poor solution to me.
* Adding @functools.lru_cache() in front of the base implementation (after
  e.g. making it a staticmethod() or something like that) seems clean from a
  code POV but could negatively impact memory usage, and might also negatively
  impact CPU usage if the cache isn't effective.
* Adding `self._record = record` to format(), before the call to
  formatException(), probably has the lowest performance impact and is the
  change I'd lean towards personally, but seems like bad coding practice.

I've attached a script that demonstrates the buggy behavior. If someone can
weigh in on what a good strategy is to resolve this issue I'd be glad to supply
a patch.

----------
files: logging_formatter_exc_bug.py
messages: 283888
nosy: daniel.passaro
priority: normal
severity: normal
status: open
title: logging.Formatter doesn't respect more than one formatException()
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file46008/logging_formatter_exc_bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29056>
_______________________________________

From report at bugs.python.org  Fri Dec 23 12:37:29 2016
From: report at bugs.python.org (Pam McA'Nulty)
Date: Fri, 23 Dec 2016 17:37:29 +0000
Subject: [issue29057] Compiler failure on Mac OS X - sys/random.h
Message-ID: <1482514649.72.0.460227366509.issue29057@psf.upfronthosting.co.za>


New submission from Pam McA'Nulty:

make failed on Mac OS X including sys/random.h

It looks to be caused by this commit: https://github.com/python/cpython/commit/1958527a2c5dda766b1917ab563622434b3dad0d

Restoring the removed ifdefs solves the problem (see github PR)

Official patch to follow


Failure message.
```
In file included from Python/random.c:16:
/usr/include/sys/random.h:37:32: error: unknown type name 'u_int'
void read_random(void* buffer, u_int numBytes);
                               ^
/usr/include/sys/random.h:38:33: error: unknown type name 'u_int'
void read_frandom(void* buffer, u_int numBytes);
                                ^
/usr/include/sys/random.h:39:33: error: unknown type name 'u_int'
int  write_random(void* buffer, u_int numBytes);
                                ^
3 errors generated.
make: *** [Python/random.o] Error 1
```

----------
components: Build
messages: 283889
nosy: Pam.McANulty
priority: normal
pull_requests: 6
severity: normal
status: open
title: Compiler failure on Mac OS X - sys/random.h
type: compile error
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29057>
_______________________________________

From report at bugs.python.org  Fri Dec 23 12:43:02 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 23 Dec 2016 17:43:02 +0000
Subject: [issue29057] Compiler failure on Mac OS X - sys/random.h
In-Reply-To: <1482514649.72.0.460227366509.issue29057@psf.upfronthosting.co.za>
Message-ID: <1482514982.02.0.143079851018.issue29057@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
components: +macOS
nosy: +benjamin.peterson, mark.dickinson, ned.deily, rhettinger, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29057>
_______________________________________

From report at bugs.python.org  Fri Dec 23 13:16:02 2016
From: report at bugs.python.org (Ned Deily)
Date: Fri, 23 Dec 2016 18:16:02 +0000
Subject: [issue29057] Compiler failure on Mac OS X - sys/random.h
In-Reply-To: <1482514649.72.0.460227366509.issue29057@psf.upfronthosting.co.za>
Message-ID: <1482516962.2.0.286277981672.issue29057@psf.upfronthosting.co.za>


Ned Deily added the comment:

Pam, what version of macOS / OS X did this fail on?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29057>
_______________________________________

From report at bugs.python.org  Fri Dec 23 13:17:13 2016
From: report at bugs.python.org (Steve Dower)
Date: Fri, 23 Dec 2016 18:17:13 +0000
Subject: [issue23903] Generate PC/python3.def by scraping headers
In-Reply-To: <1428637761.13.0.348463350169.issue23903@psf.upfronthosting.co.za>
Message-ID: <1482517033.18.0.496182513764.issue23903@psf.upfronthosting.co.za>


Steve Dower added the comment:

> ast.h and node.h are private headers.

You're right, these should be excluded (possibly from the release too?)

I've been playing with the script in a separate context and I think I've?hit a few issues (though I have made some modifications, so YMMV). It's probably just as well we waited. I'll thoroughly validate it before coming back with a new patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23903>
_______________________________________

From report at bugs.python.org  Fri Dec 23 13:32:46 2016
From: report at bugs.python.org (Pam McA'Nulty)
Date: Fri, 23 Dec 2016 18:32:46 +0000
Subject: [issue29057] Compiler failure on Mac OS X - sys/random.h
In-Reply-To: <1482514649.72.0.460227366509.issue29057@psf.upfronthosting.co.za>
Message-ID: <1482517966.65.0.177651602796.issue29057@psf.upfronthosting.co.za>


Pam McA'Nulty added the comment:

Patch for fix

----------
keywords: +patch
Added file: http://bugs.python.org/file46009/Issue29057_random_include.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29057>
_______________________________________

From report at bugs.python.org  Fri Dec 23 13:35:43 2016
From: report at bugs.python.org (Pam McA'Nulty)
Date: Fri, 23 Dec 2016 18:35:43 +0000
Subject: [issue29057] Compiler failure on Mac OS X - sys/random.h
In-Reply-To: <1482514649.72.0.460227366509.issue29057@psf.upfronthosting.co.za>
Message-ID: <1482518143.36.0.403770984171.issue29057@psf.upfronthosting.co.za>


Pam McA'Nulty added the comment:

OSX: 10.11.6 (15G1212)
Xcode 8.2.1  Build version 8C1002

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29057>
_______________________________________

From report at bugs.python.org  Fri Dec 23 13:37:34 2016
From: report at bugs.python.org (Pam McA'Nulty)
Date: Fri, 23 Dec 2016 18:37:34 +0000
Subject: [issue14483] inspect.getsource fails to read a file of only comments
In-Reply-To: <1333461114.24.0.345526771392.issue14483@psf.upfronthosting.co.za>
Message-ID: <1482518254.59.0.581821613979.issue14483@psf.upfronthosting.co.za>


Pam McA'Nulty added the comment:

I just clicked "Random Issue" and it seemed to be an "easy" (ish) one - which is just what I'd like to tackle over xmas break :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14483>
_______________________________________

From report at bugs.python.org  Fri Dec 23 14:08:59 2016
From: report at bugs.python.org (Dan Passaro)
Date: Fri, 23 Dec 2016 19:08:59 +0000
Subject: [issue29056] logging.Formatter doesn't respect more than one
 formatException()
In-Reply-To: <1482514016.63.0.534341960628.issue29056@psf.upfronthosting.co.za>
Message-ID: <1482520139.91.0.499331171389.issue29056@psf.upfronthosting.co.za>


Dan Passaro added the comment:

Working around this issue can be done by overriding format() in subclasses like so:

    def format(self, record):
        record.exc_text = ''
        try:
            return super().format(record)
        finally:
            record.exc_text = ''

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29056>
_______________________________________

From report at bugs.python.org  Fri Dec 23 14:20:04 2016
From: report at bugs.python.org (Ned Deily)
Date: Fri, 23 Dec 2016 19:20:04 +0000
Subject: [issue29057] Compiler failure on Mac OS X - sys/random.h
In-Reply-To: <1482514649.72.0.460227366509.issue29057@psf.upfronthosting.co.za>
Message-ID: <1482520804.82.0.134538735946.issue29057@psf.upfronthosting.co.za>


Ned Deily added the comment:

Argh!  This is the third go-around on this problem, starting with the quick fix for macOS 10.12 in Issue28676 then on to Issue28932 where Benjamin added a more elaborate configure test when it broke OpenBSD, and now that causes builds on macOS versions earlier than 10.12 but newer than 10.4 or 10.5 to fail. (And, we haven't noticed it because, ATM, the only OS X buildbot active is a 10.4 one and the OpenBSD buildbot is down.)  Benjamin, if you could have a look, please, if I don't get to it first.

----------
assignee:  -> benjamin.peterson
nosy: +larry
priority: normal -> release blocker
stage:  -> patch review
versions: +Python 2.7, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29057>
_______________________________________

From report at bugs.python.org  Fri Dec 23 14:22:23 2016
From: report at bugs.python.org (R. David Murray)
Date: Fri, 23 Dec 2016 19:22:23 +0000
Subject: [issue14483] inspect.getsource fails to read a file of only comments
In-Reply-To: <1333461114.24.0.345526771392.issue14483@psf.upfronthosting.co.za>
Message-ID: <1482520943.1.0.338495204643.issue14483@psf.upfronthosting.co.za>


R. David Murray added the comment:

Well, there's nobody being paid for keeping track of bugs and responding, so things do slip through the cracks.  Pinging an issue after there's been a lack of response for a while is appropriate, if you notice it yourself :)  (Mark, while he was trying to be helpful, does not speak for the Python community.)

As far as the question of is this intentional, the answer is yes.  Presumably you are calling it on the 'main' function.  If you call it on the module, you will get all source lines from that module.  (You can't call it "on the file", the argument must be an object.)

You'll see why it is intentional for the 'main' case if you consider that while in Python whitespace is syntactically significant, this is *not* true for Python comments indentation, because comments are treated as if they *are* whitespace.  getsourcelines stops looking at sourcelines on the last line recorded in the lnotab for that function, so any subsequent comments are not considered part of the function.

So, I'm closing this as "not a bug" since it works as expected for me in both python 2.7 and 3.6.

Thanks for waking the issue up, Pam.  You have contributed to python by getting an open issue closed, but you'll have to find something else to work on during the break I'm afraid.

----------
nosy: +r.david.murray
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14483>
_______________________________________

From report at bugs.python.org  Fri Dec 23 14:38:41 2016
From: report at bugs.python.org (Pam McA'Nulty)
Date: Fri, 23 Dec 2016 19:38:41 +0000
Subject: [issue14483] inspect.getsource fails to read a file of only comments
In-Reply-To: <1333461114.24.0.345526771392.issue14483@psf.upfronthosting.co.za>
Message-ID: <1482521921.87.0.214591583834.issue14483@psf.upfronthosting.co.za>


Pam McA'Nulty added the comment:

Yeah, I looked at the code and saw what you described, David.  I think I'll see if there's a good place to mention this constraint in the docs and then I'll find another one (besides the macOS build issue I ran into when trying to build the latest master)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14483>
_______________________________________

From report at bugs.python.org  Fri Dec 23 14:40:39 2016
From: report at bugs.python.org (Cornelius Diekmann)
Date: Fri, 23 Dec 2016 19:40:39 +0000
Subject: [issue29054] pty.py: pty.spawn hangs after client disconnect over nc
 (netcat)
In-Reply-To: <1482502637.76.0.304881442895.issue29054@psf.upfronthosting.co.za>
Message-ID: <1482522039.04.0.654943904157.issue29054@psf.upfronthosting.co.za>


Cornelius Diekmann added the comment:

I wrote a proper patch for the issue of handling EOF in STDIN, including tests. My patch is against the github mirror head, but don't worry, the files I touch haven't been touched in recent years ;-)

I only tested on Linux. My patch only addresses the issue in this thread. It does not include the patch for issue26228. I still recommend to also merge the patch for issue26228 (but I don't have a FreeBSD box to test).

----------
versions: +Python 3.6, Python 3.7
Added file: http://bugs.python.org/file46010/pty.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29054>
_______________________________________

From report at bugs.python.org  Fri Dec 23 14:41:35 2016
From: report at bugs.python.org (Pam McA'Nulty)
Date: Fri, 23 Dec 2016 19:41:35 +0000
Subject: [issue29057] Compiler failure on Mac OS X - sys/random.h
In-Reply-To: <1482514649.72.0.460227366509.issue29057@psf.upfronthosting.co.za>
Message-ID: <1482522095.01.0.481716698315.issue29057@psf.upfronthosting.co.za>


Pam McA'Nulty added the comment:

I will say that, though my fix seems to work, it feels that the "right" place to put the fix is in ./configure.  

Sadly, I don't speak './configure', though I apparently remember enough C from 17 years ago to get this working.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29057>
_______________________________________

From report at bugs.python.org  Fri Dec 23 15:14:34 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 23 Dec 2016 20:14:34 +0000
Subject: [issue23903] Generate PC/python3.def by scraping headers
In-Reply-To: <1428637761.13.0.348463350169.issue23903@psf.upfronthosting.co.za>
Message-ID: <20161223201431.17833.85712.3784060F@psf.io>


Roundup Robot added the comment:

New changeset 9cb87e53e324 by Serhiy Storchaka in branch '3.5':
Sort and remove duplicates from PC/python3.def (issue #23903).
https://hg.python.org/cpython/rev/9cb87e53e324

New changeset 0927b5c80c50 by Serhiy Storchaka in branch '3.6':
Sort and remove duplicates from PC/python3.def (issue #23903).
https://hg.python.org/cpython/rev/0927b5c80c50

New changeset e64a82371d72 by Serhiy Storchaka in branch 'default':
Sort and remove duplicates from PC/python3.def (issue #23903).
https://hg.python.org/cpython/rev/e64a82371d72

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23903>
_______________________________________

From report at bugs.python.org  Fri Dec 23 15:28:51 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 23 Dec 2016 20:28:51 +0000
Subject: [issue23903] Generate PC/python3.def by scraping headers
In-Reply-To: <1428637761.13.0.348463350169.issue23903@psf.upfronthosting.co.za>
Message-ID: <1482524931.33.0.0667619538138.issue23903@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Reordered to make diffs easier for reviewing.

----------
Added file: http://bugs.python.org/file46011/python3def.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23903>
_______________________________________

From report at bugs.python.org  Fri Dec 23 15:47:17 2016
From: report at bugs.python.org (Andrea Grandi)
Date: Fri, 23 Dec 2016 20:47:17 +0000
Subject: [issue28695] Add SSL_CTX_set_client_cert_engine
In-Reply-To: <1479207688.81.0.066994858547.issue28695@psf.upfronthosting.co.za>
Message-ID: <1482526037.13.0.89277027598.issue28695@psf.upfronthosting.co.za>


Andrea Grandi added the comment:

What about using OPENSSL_init_crypto(OPENSSL_INIT_LOAD_CONFIG, NULL) instead of OPENSSL_config()?

----------
nosy: +Andrea Grandi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28695>
_______________________________________

From report at bugs.python.org  Fri Dec 23 17:30:43 2016
From: report at bugs.python.org (Cornelius Diekmann)
Date: Fri, 23 Dec 2016 22:30:43 +0000
Subject: [issue29054] pty.py: pty.spawn hangs after client disconnect over nc
 (netcat)
In-Reply-To: <1482502637.76.0.304881442895.issue29054@psf.upfronthosting.co.za>
Message-ID: <1482532243.65.0.936555244107.issue29054@psf.upfronthosting.co.za>


Cornelius Diekmann added the comment:

Removed git patch header from pty.patch to make python code review tool happy. Sorry, this is my first contribution.

----------
Added file: http://bugs.python.org/file46012/pty.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29054>
_______________________________________

From report at bugs.python.org  Fri Dec 23 17:37:13 2016
From: report at bugs.python.org (Cornelius Diekmann)
Date: Fri, 23 Dec 2016 22:37:13 +0000
Subject: [issue29054] pty.py: pty.spawn hangs after client disconnect over nc
 (netcat)
In-Reply-To: <1482502637.76.0.304881442895.issue29054@psf.upfronthosting.co.za>
Message-ID: <1482532633.91.0.0483159073947.issue29054@psf.upfronthosting.co.za>


Cornelius Diekmann added the comment:

Review tool still did not show the test_pty.py file. Sry.

----------
Added file: http://bugs.python.org/file46013/pty.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29054>
_______________________________________

From report at bugs.python.org  Fri Dec 23 17:47:57 2016
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Fri, 23 Dec 2016 22:47:57 +0000
Subject: [issue29051] Improve error reporting involving f-strings (PEP 498)
In-Reply-To: <1482494461.91.0.191852219403.issue29051@psf.upfronthosting.co.za>
Message-ID: <1482533277.49.0.787407373322.issue29051@psf.upfronthosting.co.za>


Changes by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
nosy: +levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29051>
_______________________________________

From report at bugs.python.org  Fri Dec 23 17:48:41 2016
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Fri, 23 Dec 2016 22:48:41 +0000
Subject: [issue28702] Confusing error message when None used in expressions,
 eg. "'NoneType' object has no attribute 'foo'"
In-Reply-To: <1479240283.12.0.750407106609.issue28702@psf.upfronthosting.co.za>
Message-ID: <1482533321.52.0.0784352407492.issue28702@psf.upfronthosting.co.za>


Changes by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
nosy: +levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28702>
_______________________________________

From report at bugs.python.org  Fri Dec 23 17:49:03 2016
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Fri, 23 Dec 2016 22:49:03 +0000
Subject: [issue28559] Unclear error message when raising wrong type of
 exceptions
In-Reply-To: <1477764991.61.0.67228056749.issue28559@psf.upfronthosting.co.za>
Message-ID: <1482533343.56.0.910427516122.issue28559@psf.upfronthosting.co.za>


Changes by Ivan Levkivskyi <levkivskyi at gmail.com>:


----------
nosy: +levkivskyi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28559>
_______________________________________

From report at bugs.python.org  Fri Dec 23 17:51:46 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 23 Dec 2016 22:51:46 +0000
Subject: [issue28997] test_readline.test_nonascii fails on Android
In-Reply-To: <1481965369.72.0.409169776064.issue28997@psf.upfronthosting.co.za>
Message-ID: <1482533506.07.0.844813962534.issue28997@psf.upfronthosting.co.za>


Martin Panter added the comment:

The basic idea of your patch may be reasonable, but something is not right. Imagine the locale is something other than UTF-8. The input code will now contain mojibake print("\xC3\xAB"), although the decode() call will translate the result back to the expected "\xEB".

I suggest this 2nd version of the patch. I used io.TextIOWrapper to use the locale encoding, and incorporated the other test character "\xEF". I also changed the preliminary test to call input() instead of relying on the interactive interpreter, quiet mode, etc.

Just to clarify, is the problem that Python (correctly) assumes UTF-8 encoding on Android, but Readline does not unless you tweak the environment variable? I.e. is Readline assuming ASCII or something and ignoring the test characters? If so, it sounds like this may be a more general problem with Gnu tools and libraries on Android.

----------
Added file: http://bugs.python.org/file46014/readline_multibyte.v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28997>
_______________________________________

From report at bugs.python.org  Fri Dec 23 18:29:46 2016
From: report at bugs.python.org (Steve Dower)
Date: Fri, 23 Dec 2016 23:29:46 +0000
Subject: [issue23903] Generate PC/python3.def by scraping headers
In-Reply-To: <1428637761.13.0.348463350169.issue23903@psf.upfronthosting.co.za>
Message-ID: <1482535786.5.0.739137222234.issue23903@psf.upfronthosting.co.za>


Steve Dower added the comment:

Good call.

I think I might actually replace the script with a build step that uses the C preprocessor to get all the names, then a script to generate the file. If someone who knows the POSIX build system can help out, we could generate a list on each build for various platforms and fail when it doesn't match what's committed.

Since the preprocessor doesn't have to generate valid code, we should be able to cross-compile for other platforms, though that's less critical.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23903>
_______________________________________

From report at bugs.python.org  Fri Dec 23 18:30:07 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 23 Dec 2016 23:30:07 +0000
Subject: [issue29057] Compiler failure on Mac OS X - sys/random.h
In-Reply-To: <1482514649.72.0.460227366509.issue29057@psf.upfronthosting.co.za>
Message-ID: <1482535807.45.0.400242537385.issue29057@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29057>
_______________________________________

From report at bugs.python.org  Fri Dec 23 18:32:32 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 23 Dec 2016 23:32:32 +0000
Subject: [issue28968] xml rpc server fails with connection reset by peer error
 no 104
In-Reply-To: <1481709223.17.0.559234955094.issue28968@psf.upfronthosting.co.za>
Message-ID: <1482535952.24.0.23482586298.issue28968@psf.upfronthosting.co.za>


Martin Panter added the comment:

Python 2.6 is quite old and doesn?t even receive security patches any more as far as I know. I would start by trying 2.7, or failing that, try backporting the changes from Issue 6267. My guess is this is related to persistent HTTP connections being dropped.

I don?t think the bug tracker is the right place to discuss 2.6 these days. Even if you can find someone interested in helping with 2.6, you may need to provide more information (e.g. client and server code) to produce the problem.

----------
nosy: +martin.panter
resolution:  -> out of date

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28968>
_______________________________________

From report at bugs.python.org  Fri Dec 23 18:35:28 2016
From: report at bugs.python.org (Cornelius Diekmann)
Date: Fri, 23 Dec 2016 23:35:28 +0000
Subject: [issue29054] pty.py: pty.spawn hangs after client disconnect over nc
 (netcat)
In-Reply-To: <1482502637.76.0.304881442895.issue29054@psf.upfronthosting.co.za>
Message-ID: <1482536128.36.0.889901097687.issue29054@psf.upfronthosting.co.za>


Cornelius Diekmann added the comment:

Make review tool happy by giving it less broken patch format :)
`make patchcheck` is already happy.
Sorry for the noise :(

----------
Added file: http://bugs.python.org/file46015/pty_and_tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29054>
_______________________________________

From report at bugs.python.org  Fri Dec 23 19:01:43 2016
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 24 Dec 2016 00:01:43 +0000
Subject: [issue29057] Compiler failure on Mac OS X - sys/random.h
In-Reply-To: <1482514649.72.0.460227366509.issue29057@psf.upfronthosting.co.za>
Message-ID: <1482537703.81.0.795427044241.issue29057@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29057>
_______________________________________

From report at bugs.python.org  Fri Dec 23 19:11:51 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 24 Dec 2016 00:11:51 +0000
Subject: [issue29058] Mark new limited C API
Message-ID: <1482538310.89.0.583492092721.issue29058@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Functions added to a limited API after 3.2 should be available only when Py_LIMITED_API is not defined or is set to corresponding hexadecimal Python version (e.g. 0x03050000).

Proposed patch makes following names available only for corresponding versions of a limited API.

Removed declaration: PyErr_SetExcWithArgsKwargs().

Excluded from stable ABI: _PyBytes_DecodeEscape(), PyInit_imp().

3.3: Py_hexdigits, PyImport_ExecCodeModuleObject(), PyImport_AddModuleObject(), PyImport_ImportFrozenModuleObject(), PyMemoryView_FromMemory(), PyModule_NewObject(), PyModule_GetNameObject(), PyObject_GenericSetDict(), PyErr_GetExcInfo(), PyErr_SetExcInfo(), PyErr_SetImportError(), PyParser_SimpleParseStringFlagsFilename(), PyThread_GetInfo(), PyUnicode_Substring(), PyUnicode_AsUCS4(), PyUnicode_AsUCS4Copy(), PyUnicode_GetLength(), PyUnicode_ReadChar(), PyUnicode_WriteChar(), PyUnicode_DecodeCodePageStateful(), PyUnicode_EncodeCodePage(), PyUnicode_DecodeLocaleAndSize(), PyUnicode_DecodeLocale(), PyUnicode_EncodeLocale(), PyUnicode_FindChar(), and a number of OSError subclasses.

3.4: PyErr_SetFromErrnoWithFilenameObjects(), PyErr_SetExcFromWindowsErrWithFilenameObjects().

3.5: PyNumber_MatrixMultiply(), PyNumber_InPlaceMatrixMultiply(), PyCodec_NameReplaceErrors(), Py_DecodeLocale(), Py_EncodeLocale(), PyImport_ImportModuleLevelObject(), PyObject_Calloc(), PyExc_StopAsyncIteration, PyExc_RecursionError, PyMem_Calloc(), 
a number of PyODict_* macros.

3.6: Py_FileSystemDefaultEncodeErrors, PyOS_FSPath(), PyExc_ModuleNotFoundError, PyErr_SetImportErrorSubclass(), PyErr_ResourceWarning().

However it may be better that some was added to stable ABI by mistake. Py_hexdigits looks as a stuff for internal use, PyThread_GetInfo() and PyODict_* macros are not documented.

----------
components: Interpreter Core
files: limited-api.patch
keywords: patch
messages: 283910
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Mark new limited C API
versions: Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file46016/limited-api.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29058>
_______________________________________

From report at bugs.python.org  Fri Dec 23 19:12:50 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 24 Dec 2016 00:12:50 +0000
Subject: [issue23903] Generate PC/python3.def by scraping headers
In-Reply-To: <1428637761.13.0.348463350169.issue23903@psf.upfronthosting.co.za>
Message-ID: <1482538370.74.0.551894307244.issue23903@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See also issue29058.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23903>
_______________________________________

From report at bugs.python.org  Fri Dec 23 20:25:23 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 24 Dec 2016 01:25:23 +0000
Subject: [issue29054] pty.py: pty.spawn hangs after client disconnect over nc
 (netcat)
In-Reply-To: <1482502637.76.0.304881442895.issue29054@psf.upfronthosting.co.za>
Message-ID: <1482542723.6.0.616411308802.issue29054@psf.upfronthosting.co.za>


Martin Panter added the comment:

This is a change in behaviour of the _copy() loop: it will stop as soon as EOF is read from the parent?s input, and immediately close the terminal master. Unpatched, the loop continues to read output from the child, until the child closes the terminal slave.

I agree that your new behaviour may be desired in some cases, but you need to respect backwards compatibility. With your patch, things will no longer work robustly when the child ?has the last word?, i.e. it writes output and exits without reading any (extra) input. Simple example: the child prints a message, but the parent has no input:

python -c 'import pty; pty.spawn("./message.py")' < /dev/null

Any new functionality would also need documenting. (If you want to suggest some wording to document the existing behaviour better, that would also be welcome :)

----------
versions:  -Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29054>
_______________________________________

From report at bugs.python.org  Fri Dec 23 20:33:11 2016
From: report at bugs.python.org (Joseph Hackman)
Date: Sat, 24 Dec 2016 01:33:11 +0000
Subject: [issue29059] Windows: Python not using ANSI compatible console
Message-ID: <1482543191.02.0.407458515739.issue29059@psf.upfronthosting.co.za>


New submission from Joseph Hackman:

On windows, Python does not request that Windows enable VT100 for console output for Python.

That is to say that ANSI codes such as \033[91m will function on Mac and Linux Pythons, but not Windows.

As there is no good interface in core Python to the kernel32 console operations (and there probably shouldn't be, it would be better to be consistent), I suggest just flipping the bit at startup on Windows.

I would be happy to submit a patch, but seek guidance on the best location for addition of code to 'at startup iff a tty is attached'.

The following code solves the issue:
import platform
if platform.system().lower() == 'windows':
    from ctypes import windll, c_int, byref
    stdout_handle = windll.kernel32.GetStdHandle(c_int(-11))
    mode = c_int(0)
    windll.kernel32.GetConsoleMode(c_int(stdout_handle), byref(mode))
    mode = c_int(mode.value | 4)
    windll.kernel32.SetConsoleMode(c_int(stdout_handle), mode)

Please see:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms686033(v=vs.85).aspx (Search for ENABLE_VIRTUAL_TERMINAL_PROCESSING)
https://msdn.microsoft.com/en-us/library/windows/desktop/ms683231(v=vs.85).aspx (As for why stdout is -11 on Windows)

----------
components: Windows
messages: 283913
nosy: joseph.hackman, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows: Python not using ANSI compatible console
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29059>
_______________________________________

From report at bugs.python.org  Fri Dec 23 20:54:40 2016
From: report at bugs.python.org (bpoaugust)
Date: Sat, 24 Dec 2016 01:54:40 +0000
Subject: [issue29053] Implement >From_ decoding on input from mbox
In-Reply-To: <1482502608.45.0.127449678115.issue29053@psf.upfronthosting.co.za>
Message-ID: <1482544480.09.0.392309132641.issue29053@psf.upfronthosting.co.za>


bpoaugust added the comment:

Attached please find patch which works for me.

To use it independently of email, do something like:

messages = mailbox.mbox(filename, MboxoFactory)

where:

class MboxoFactory(mailbox.mboxMessage):
    def __init__(self, message=None):
        super().__init__(message=MboxoReader(message))

HTH

----------
Added file: http://bugs.python.org/file46017/mboxo_patch.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29053>
_______________________________________

From report at bugs.python.org  Fri Dec 23 21:57:27 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 24 Dec 2016 02:57:27 +0000
Subject: [issue19756] test_nntplib: sporadic failures,
 network isses? server down?
In-Reply-To: <1385316451.32.0.948186129781.issue19756@psf.upfronthosting.co.za>
Message-ID: <1482548247.39.0.525101246668.issue19756@psf.upfronthosting.co.za>


Martin Panter added the comment:

Multi-connect.patch is a smaller patch that changes setUpClass() ? setUp(), so that each test method creates a new NNTP connection. The downside is all the reconnecting slows the test execution from 42 s down to 115 s, which is why I would like to move the testing to a local server.

----------
versions: +Python 3.7
Added file: http://bugs.python.org/file46018/multi-connect.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19756>
_______________________________________

From report at bugs.python.org  Fri Dec 23 22:13:53 2016
From: report at bugs.python.org (Daz)
Date: Sat, 24 Dec 2016 03:13:53 +0000
Subject: [issue29060] Changing the installation location still adds AppData
 filepaths that do not exist to the path variable on Windows 10
Message-ID: <1482549233.73.0.705523991357.issue29060@psf.upfronthosting.co.za>


New submission from Daz:

New to python issue tracking; prone to ignorance.

I'm on Windows 10. I noticed after checking to add Python to my path variable and then changing the location from AppData's directory that after the installation, the filepaths associated with AppData were added to the path variable. The new path and any would-be associated filepaths were not added to the path variable.

Thanks in advance if you can at least let me know if this is typical or a problem.

----------
components: Installation
messages: 283916
nosy: Dazc
priority: normal
severity: normal
status: open
title: Changing the installation location still adds AppData filepaths that do not exist to the path variable on Windows 10
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29060>
_______________________________________

From report at bugs.python.org  Fri Dec 23 22:18:14 2016
From: report at bugs.python.org (Daz)
Date: Sat, 24 Dec 2016 03:18:14 +0000
Subject: [issue29060] Changing the installation location still adds AppData
 filepaths that do not exist to the path variable on Windows 10
In-Reply-To: <1482549233.73.0.705523991357.issue29060@psf.upfronthosting.co.za>
Message-ID: <1482549494.13.0.535670420252.issue29060@psf.upfronthosting.co.za>


Daz added the comment:

New to python issue tracking; prone to ignorance.

I'm on Windows 10. I noticed after checking to add Python to my path variable and then changing the location from AppData's directory that after the installation, the filepaths associated with AppData were added to the path variable.

Thanks in advance if you can at least let me know if this is typical or a problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29060>
_______________________________________

From report at bugs.python.org  Fri Dec 23 22:52:19 2016
From: report at bugs.python.org (Zachary Ware)
Date: Sat, 24 Dec 2016 03:52:19 +0000
Subject: [issue29060] Changing the installation location still adds AppData
 filepaths that do not exist to the path variable on Windows 10
In-Reply-To: <1482549233.73.0.705523991357.issue29060@psf.upfronthosting.co.za>
Message-ID: <1482551539.19.0.947345827842.issue29060@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
assignee:  -> steve.dower
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29060>
_______________________________________

From report at bugs.python.org  Fri Dec 23 23:27:07 2016
From: report at bugs.python.org (Karen Tracey)
Date: Sat, 24 Dec 2016 04:27:07 +0000
Subject: [issue15795] Zipfile.extractall does not preserve file permissions
In-Reply-To: <1346106964.12.0.723201722432.issue15795@psf.upfronthosting.co.za>
Message-ID: <1482553627.77.0.0169249093551.issue15795@psf.upfronthosting.co.za>


Karen Tracey added the comment:

Note the zipfile being processed may have been created on a non-Unix system, and the external_attr value can't be usefully interpreted as permission bits when the value at _CD_CREATE_SYSTEM (https://hg.python.org/cpython/file/default/Lib/zipfile.py#l107) in the central directory entry is not Unix (3). Patches so far don't seem to guard against mistakenly assuming a foreign-system external_attr value can be interpreted as Unix permission bits.

(At present github is delivering zipfiles of repos with a create system value of 0 and external_attr values of 0.)

----------
nosy: +kmtracey

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15795>
_______________________________________

From report at bugs.python.org  Sat Dec 24 00:00:13 2016
From: report at bugs.python.org (Carl George)
Date: Sat, 24 Dec 2016 05:00:13 +0000
Subject: [issue10740] sqlite3 module breaks transactions and potentially
 corrupts data
In-Reply-To: <1292868135.81.0.257293444934.issue10740@psf.upfronthosting.co.za>
Message-ID: <1482555613.08.0.687292083724.issue10740@psf.upfronthosting.co.za>


Carl George added the comment:

While attempting to build a Python 3.6 RPM for RHEL/CentOS 6, I noticed the following warning.

*** WARNING: renaming "_sqlite3" since importing it failed: build/lib.linux-i686-3.6-pydebug/_sqlite3.cpython-36dm-i386-linux-gnu.so: undefined symbol: sqlite3_stmt_readonly

The resolution of this issue introduced usage of the sqlite3_stmt_readonly interface.  That interface wasn't added to sqlite until 3.7.4 (http://www.sqlite.org/releaselog/3_7_4.html).  My RPM build failed because RHEL/CentOS 6 only has sqlite 3.6.20.  I understand that Python can't support old libraries forever, but can this minimum sqlite version be noted somewhere in the documentation?

----------
nosy: +carlwgeorge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10740>
_______________________________________

From report at bugs.python.org  Sat Dec 24 00:21:37 2016
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 24 Dec 2016 05:21:37 +0000
Subject: [issue29057] Compiler failure on Mac OS X - sys/random.h
In-Reply-To: <1482514649.72.0.460227366509.issue29057@psf.upfronthosting.co.za>
Message-ID: <1482556897.39.0.896309349245.issue29057@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

So, if sys/random.h can't be included without error why does the configure check for it work?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29057>
_______________________________________

From report at bugs.python.org  Sat Dec 24 00:23:33 2016
From: report at bugs.python.org (R. David Murray)
Date: Sat, 24 Dec 2016 05:23:33 +0000
Subject: [issue10740] sqlite3 module breaks transactions and potentially
 corrupts data
In-Reply-To: <1292868135.81.0.257293444934.issue10740@psf.upfronthosting.co.za>
Message-ID: <1482557013.7.0.383688467552.issue10740@psf.upfronthosting.co.za>


R. David Murray added the comment:

Please open a new issue for this request.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10740>
_______________________________________

From report at bugs.python.org  Sat Dec 24 00:28:40 2016
From: report at bugs.python.org (Steve Dower)
Date: Sat, 24 Dec 2016 05:28:40 +0000
Subject: [issue29060] Changing the installation location still adds AppData
 filepaths that do not exist to the path variable on Windows 10
In-Reply-To: <1482549233.73.0.705523991357.issue29060@psf.upfronthosting.co.za>
Message-ID: <1482557320.46.0.0439149455912.issue29060@psf.upfronthosting.co.za>


Steve Dower added the comment:

You should have a set of log files in your %TEMP% directory. Could you zip them up and attach to this issue? That should show whether the installer got confused about something.

Note that if you install the launcher but not for all users (the other check box on the first page) you can't actually reconfigure where it installs to, and it will be put on PATH, so you may be seeing that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29060>
_______________________________________

From report at bugs.python.org  Sat Dec 24 01:24:43 2016
From: report at bugs.python.org (Brian Nenninger)
Date: Sat, 24 Dec 2016 06:24:43 +0000
Subject: [issue29061] secrets.randbelow(-1) hangs
Message-ID: <1482560683.53.0.415654381831.issue29061@psf.upfronthosting.co.za>


New submission from Brian Nenninger:

secrets.randbelow(-1) causes the interpreter to hang. It should presumably raise an exception like secrets.randbelow(0) does. This is on Mac OS X 10.11.6, shell transcript below.

=========================================================

$ python3
Python 3.6.0 (v3.6.0:41df79263a11, Dec 22 2016, 17:23:13) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import secrets
>>> secrets.randbelow(1)
0
>>> secrets.randbelow(0)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/secrets.py", line 29, in randbelow
    return _sysrand._randbelow(exclusive_upper_bound)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/random.py", line 232, in _randbelow
    r = getrandbits(k)          # 0 <= r < 2**k
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/random.py", line 678, in getrandbits
    raise ValueError('number of bits must be greater than zero')
ValueError: number of bits must be greater than zero
>>> secrets.randbelow(-1)

(hangs using 100% CPU until aborted)

----------
components: Library (Lib)
messages: 283923
nosy: Brian Nenninger
priority: normal
severity: normal
status: open
title: secrets.randbelow(-1) hangs
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29061>
_______________________________________

From report at bugs.python.org  Sat Dec 24 01:45:34 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 24 Dec 2016 06:45:34 +0000
Subject: [issue28971] nntplib is broken when responses are longer than _MAXLINE
In-Reply-To: <1481716454.12.0.730668429479.issue28971@psf.upfronthosting.co.za>
Message-ID: <1482561934.23.0.705865609078.issue28971@psf.upfronthosting.co.za>


Martin Panter added the comment:

Max_over_line.patch is my attempt: Keep the original _MAXLINES = 2048 code, but override it with _MAX_OVER_LINE = 64000 when reading OVER response lines. I also added a test case.

----------
Added file: http://bugs.python.org/file46019/max_over_line.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28971>
_______________________________________

From report at bugs.python.org  Sat Dec 24 01:53:57 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 24 Dec 2016 06:53:57 +0000
Subject: [issue28971] nntplib is broken when responses are longer than _MAXLINE
In-Reply-To: <1481716454.12.0.730668429479.issue28971@psf.upfronthosting.co.za>
Message-ID: <1482562437.09.0.10722429444.issue28971@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


Removed file: http://bugs.python.org/file46019/max_over_line.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28971>
_______________________________________

From report at bugs.python.org  Sat Dec 24 01:54:18 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 24 Dec 2016 06:54:18 +0000
Subject: [issue28971] nntplib is broken when responses are longer than _MAXLINE
In-Reply-To: <1481716454.12.0.730668429479.issue28971@psf.upfronthosting.co.za>
Message-ID: <1482562458.85.0.621413994651.issue28971@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


Added file: http://bugs.python.org/file46020/max_over_line.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28971>
_______________________________________

From report at bugs.python.org  Sat Dec 24 02:36:29 2016
From: report at bugs.python.org (Ned Deily)
Date: Sat, 24 Dec 2016 07:36:29 +0000
Subject: [issue29061] secrets.randbelow(-1) hangs
In-Reply-To: <1482560683.53.0.415654381831.issue29061@psf.upfronthosting.co.za>
Message-ID: <1482564989.52.0.232702352348.issue29061@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
nosy: +rhettinger, steven.daprano
priority: normal -> high
stage:  -> needs patch
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29061>
_______________________________________

From report at bugs.python.org  Sat Dec 24 03:18:25 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 24 Dec 2016 08:18:25 +0000
Subject: [issue28960] Small typo in Thread.join docs
In-Reply-To: <1481636284.79.0.913462681395.issue28960@psf.upfronthosting.co.za>
Message-ID: <20161224081822.5888.94151.0989B8A8@psf.io>


Roundup Robot added the comment:

New changeset 9347d0b2ee08 by Martin Panter in branch '3.5':
Issue #28960: Drop comma attached to dash in Thread.join() description
https://hg.python.org/cpython/rev/9347d0b2ee08

New changeset d70fcf1866ad by Martin Panter in branch '3.6':
Issue #28960: Merge Thread.join() doc from 3.5
https://hg.python.org/cpython/rev/d70fcf1866ad

New changeset cefcfacd87e4 by Martin Panter in branch 'default':
Issue #28960: Merge Thread.join() doc from 3.6
https://hg.python.org/cpython/rev/cefcfacd87e4

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28960>
_______________________________________

From report at bugs.python.org  Sat Dec 24 03:18:25 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 24 Dec 2016 08:18:25 +0000
Subject: [issue29004] binascii.crc_hqx() implements CRC-CCITT
In-Reply-To: <1482058351.49.0.0302572495626.issue29004@psf.upfronthosting.co.za>
Message-ID: <20161224081822.5888.76805.336221E3@psf.io>


Roundup Robot added the comment:

New changeset a33472f8a2c6 by Martin Panter in branch '3.5':
Issue #29004: Document binascii.crc_hqx() implements CRC-CCITT
https://hg.python.org/cpython/rev/a33472f8a2c6

New changeset 52db2072e88b by Martin Panter in branch '3.6':
Issue #29004: Merge crc_hqx() doc from 3.5
https://hg.python.org/cpython/rev/52db2072e88b

New changeset 3af3702b2f0a by Martin Panter in branch 'default':
Issue #29004: Merge crc_hqx() doc from 3.6
https://hg.python.org/cpython/rev/3af3702b2f0a

New changeset 5ae6102270df by Martin Panter in branch '2.7':
Issue #29004: Document binascii.crc_hqx() implements CRC-CCITT
https://hg.python.org/cpython/rev/5ae6102270df

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29004>
_______________________________________

From report at bugs.python.org  Sat Dec 24 03:49:31 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 24 Dec 2016 08:49:31 +0000
Subject: [issue1446619] extended slice behavior inconsistent with docs
Message-ID: <20161224084928.26751.95754.6F9021F6@psf.io>


Roundup Robot added the comment:

New changeset b0b17b41edfc by Martin Panter in branch '3.5':
Issue #1446619: Account for negative slice direction in description
https://hg.python.org/cpython/rev/b0b17b41edfc

New changeset 031af2160094 by Martin Panter in branch '3.6':
Issue #1446619: Merge slicing description from 3.5
https://hg.python.org/cpython/rev/031af2160094

New changeset 4383d403aaef by Martin Panter in branch 'default':
Issue #1446619: Merge slicing description from 3.6
https://hg.python.org/cpython/rev/4383d403aaef

New changeset d63a11bd98ce by Martin Panter in branch '2.7':
Issue #1446619: Account for negative slice direction in description
https://hg.python.org/cpython/rev/d63a11bd98ce

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1446619>
_______________________________________

From report at bugs.python.org  Sat Dec 24 03:57:46 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 24 Dec 2016 08:57:46 +0000
Subject: [issue28960] Small typo in Thread.join docs
In-Reply-To: <1481636284.79.0.913462681395.issue28960@psf.upfronthosting.co.za>
Message-ID: <1482569866.41.0.0591137255663.issue28960@psf.upfronthosting.co.za>


Martin Panter added the comment:

I agree the second patch is more correct. This undoes the change as it was introduced in revision c4cf1b886d6b and matches the Python 2 text.

----------
nosy: +martin.panter
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28960>
_______________________________________

From report at bugs.python.org  Sat Dec 24 04:17:50 2016
From: report at bugs.python.org (Brendan Donegan)
Date: Sat, 24 Dec 2016 09:17:50 +0000
Subject: [issue29061] secrets.randbelow(-1) hangs
In-Reply-To: <1482560683.53.0.415654381831.issue29061@psf.upfronthosting.co.za>
Message-ID: <1482571070.89.0.735575627193.issue29061@psf.upfronthosting.co.za>


Brendan Donegan added the comment:

Reproducible on Linux as well, I think I know where the issue is and will try to submit a patch soon.

----------
nosy: +brendan-donegan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29061>
_______________________________________

From report at bugs.python.org  Sat Dec 24 04:21:43 2016
From: report at bugs.python.org (Frank Millman)
Date: Sat, 24 Dec 2016 09:21:43 +0000
Subject: [issue29062] Documentation link error
Message-ID: <1482571303.3.0.781602557285.issue29062@psf.upfronthosting.co.za>


New submission from Frank Millman:

If you call up online documentation for Python3.6, and select modules>h>hashlib, it takes you to 15.2. hashlib ? BLAKE2 hash functions

It should take you to 15.1. hashlib ? Secure hashes and message digests

----------
assignee: docs at python
components: Documentation
messages: 283930
nosy: docs at python, frankmillman
priority: normal
severity: normal
status: open
title: Documentation link error
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29062>
_______________________________________

From report at bugs.python.org  Sat Dec 24 04:39:22 2016
From: report at bugs.python.org (Brendan Donegan)
Date: Sat, 24 Dec 2016 09:39:22 +0000
Subject: [issue29061] secrets.randbelow(-1) hangs
In-Reply-To: <1482560683.53.0.415654381831.issue29061@psf.upfronthosting.co.za>
Message-ID: <1482572362.82.0.689106458748.issue29061@psf.upfronthosting.co.za>


Brendan Donegan added the comment:

Ok, here it is. My first code patch in Python. 

Basically the existing code was depending on bit_length to DTRT and raise a ValueError, but negative numbers have a positive bit length. Then when it hits:

234             while r >= n:                                                        
235                 r = getrandbits(k)  

It just spins on that as r is always going to be greater than a negative number.

I tried not to be too clever so just put a guard early in the function. This has the added advantage of giving us a clearer error message.

----------
keywords: +patch
Added file: http://bugs.python.org/file46021/issue_29061_randbelow.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29061>
_______________________________________

From report at bugs.python.org  Sat Dec 24 04:40:11 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 24 Dec 2016 09:40:11 +0000
Subject: [issue29062] hashlib documentation link error
In-Reply-To: <1482571303.3.0.781602557285.issue29062@psf.upfronthosting.co.za>
Message-ID: <1482572411.06.0.00295726463999.issue29062@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +christian.heimes, georg.brandl, gregory.p.smith
title: Documentation link error -> hashlib documentation link error
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29062>
_______________________________________

From report at bugs.python.org  Sat Dec 24 04:48:35 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 24 Dec 2016 09:48:35 +0000
Subject: [issue13886] readline-related test_builtin failure
In-Reply-To: <1327659819.71.0.475160045664.issue13886@psf.upfronthosting.co.za>
Message-ID: <1482572915.72.0.216089700609.issue13886@psf.upfronthosting.co.za>


Martin Panter added the comment:

Hi Xavier, I was about to push input-readline.v2.patch, but I thought it might be good to check with you first if this causes problems with Android, based on my experience with Issue 28997. With the patch applied, test.test_builtin.PtyTests.test_input_tty_non_ascii() will call the input() function twice, with and without Readline enabled. It inputs non-ASCII data in into a pseudoterminal, and expects to see it in the function return value. Perhaps we may need to skip the Readline half of the test on Android.

----------
nosy: +xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13886>
_______________________________________

From report at bugs.python.org  Sat Dec 24 04:51:30 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 24 Dec 2016 09:51:30 +0000
Subject: [issue1446619] extended slice behavior inconsistent with docs
Message-ID: <1482573090.12.0.992994231922.issue1446619@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1446619>
_______________________________________

From report at bugs.python.org  Sat Dec 24 04:51:35 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 24 Dec 2016 09:51:35 +0000
Subject: [issue29004] binascii.crc_hqx() implements CRC-CCITT
In-Reply-To: <1482058351.49.0.0302572495626.issue29004@psf.upfronthosting.co.za>
Message-ID: <1482573095.92.0.950768608508.issue29004@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for the help Serhiy

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29004>
_______________________________________

From report at bugs.python.org  Sat Dec 24 05:06:38 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 24 Dec 2016 10:06:38 +0000
Subject: [issue28978] a redundant right parentheses in the EBNF rules of
 parameter_list
In-Reply-To: <1481803174.61.0.122563860327.issue28978@psf.upfronthosting.co.za>
Message-ID: <1482573998.33.0.597854420891.issue28978@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
stage:  -> needs patch
versions: +Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28978>
_______________________________________

From report at bugs.python.org  Sat Dec 24 05:09:27 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 24 Dec 2016 10:09:27 +0000
Subject: [issue22942] Language Reference - optional comma
In-Reply-To: <1416945158.04.0.329806790258.issue22942@psf.upfronthosting.co.za>
Message-ID: <1482574167.97.0.87010529175.issue22942@psf.upfronthosting.co.za>


Martin Panter added the comment:

Issue 28978 covers the parameter list syntax (Bug 1 + plus another problem).

----------
dependencies: +a redundant right  parentheses in the EBNF rules of parameter_list

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22942>
_______________________________________

From report at bugs.python.org  Sat Dec 24 05:28:01 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 24 Dec 2016 10:28:01 +0000
Subject: [issue28954] Incorrect EBNF rule of keywords_arguments
In-Reply-To: <1481595766.74.0.577639992265.issue28954@psf.upfronthosting.co.za>
Message-ID: <20161224102758.79374.49938.C2C3628A@psf.io>


Roundup Robot added the comment:

New changeset 3f94e3c7dcc5 by Martin Panter in branch '3.5':
Issue #28954: Add missing comma to keyword argument syntax
https://hg.python.org/cpython/rev/3f94e3c7dcc5

New changeset ef53ef8e09e5 by Martin Panter in branch '3.6':
Issue #28954: Merge keyword argument syntax from 3.5
https://hg.python.org/cpython/rev/ef53ef8e09e5

New changeset 8e311f109b22 by Martin Panter in branch 'default':
Issue #28954: Merge keyword argument syntax from 3.6
https://hg.python.org/cpython/rev/8e311f109b22

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28954>
_______________________________________

From report at bugs.python.org  Sat Dec 24 05:41:01 2016
From: report at bugs.python.org (bpoaugust)
Date: Sat, 24 Dec 2016 10:41:01 +0000
Subject: [issue29020] collapse_rfc2231_value has inconsistent unquoting
In-Reply-To: <1482193812.46.0.729778317823.issue29020@psf.upfronthosting.co.za>
Message-ID: <1482576061.0.0.10946762523.issue29020@psf.upfronthosting.co.za>


bpoaugust added the comment:

Another case is get_filename.

The second call to unquote will only change the incoming parameter if the original value was enclosed in <> or "". This is not a common scenario, and was only discovered because a mailer used the form <<<abcd>>> as a boundary marker (yes, this is invalid). So existing tests are unlikely to notice any difference.

Note that it is wrong to unquote more times than the original value has been quoted. So the only possible reason for keeping unquote in the function is if unquote has not already been called on a quoted value. (It is not possible to tell from the parameter whether or not it is currently quoted).

The two sample callers are get_boundary and get_filename.
Both pass the value already unquoted.

This method should be fixed to remove the unquote calls.
If there is a caller (is there one?) that does not unquote the value first, then that needs to be fixed as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29020>
_______________________________________

From report at bugs.python.org  Sat Dec 24 05:41:49 2016
From: report at bugs.python.org (Decorater)
Date: Sat, 24 Dec 2016 10:41:49 +0000
Subject: [issue29063] Fix timemodule compile warnings.
Message-ID: <1482576109.57.0.29725831282.issue29063@psf.upfronthosting.co.za>


New submission from Decorater:

I fixed some Possible Loss of Data warnings. but only the ones for timemodule. There are still some others when building the 64 bit version however.

I added some comments that can be removed in another patch if desired otherwise it should look good for now for this module.

----------
components: Build, Interpreter Core, Windows
files: timemodule.patch-1.patch
keywords: patch
messages: 283937
nosy: Decorater, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Fix timemodule compile warnings.
versions: Python 3.7
Added file: http://bugs.python.org/file46022/timemodule.patch-1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29063>
_______________________________________

From report at bugs.python.org  Sat Dec 24 05:42:03 2016
From: report at bugs.python.org (Decorater)
Date: Sat, 24 Dec 2016 10:42:03 +0000
Subject: [issue29063] Fixed timemodule compile warnings.
In-Reply-To: <1482576109.57.0.29725831282.issue29063@psf.upfronthosting.co.za>
Message-ID: <1482576123.65.0.643860406121.issue29063@psf.upfronthosting.co.za>


Changes by Decorater <seandhunt_7 at yahoo.com>:


----------
title: Fix timemodule compile warnings. -> Fixed timemodule compile warnings.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29063>
_______________________________________

From report at bugs.python.org  Sat Dec 24 05:53:53 2016
From: report at bugs.python.org (Patrik Iselind)
Date: Sat, 24 Dec 2016 10:53:53 +0000
Subject: [issue29047] Where are the test results stored?
In-Reply-To: <1482403473.61.0.626919341446.issue29047@psf.upfronthosting.co.za>
Message-ID: <1482576833.42.0.032606372065.issue29047@psf.upfronthosting.co.za>


Patrik Iselind added the comment:

Made a pull request for this

----------
pull_requests: +7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29047>
_______________________________________

From report at bugs.python.org  Sat Dec 24 05:55:17 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 24 Dec 2016 10:55:17 +0000
Subject: [issue28954] Incorrect EBNF rule of keywords_arguments
In-Reply-To: <1481595766.74.0.577639992265.issue28954@psf.upfronthosting.co.za>
Message-ID: <1482576917.67.0.82313156462.issue28954@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for finding this Woo!

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28954>
_______________________________________

From report at bugs.python.org  Sat Dec 24 05:55:29 2016
From: report at bugs.python.org (Patrik Iselind)
Date: Sat, 24 Dec 2016 10:55:29 +0000
Subject: [issue29047] Where are the test results stored?
In-Reply-To: <1482403473.61.0.626919341446.issue29047@psf.upfronthosting.co.za>
Message-ID: <1482576929.42.0.0219787222395.issue29047@psf.upfronthosting.co.za>


Changes by Patrik Iselind <patrik.mrx at gmail.com>:


----------
pull_requests:  -7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29047>
_______________________________________

From report at bugs.python.org  Sat Dec 24 05:58:06 2016
From: report at bugs.python.org (Patrik Iselind)
Date: Sat, 24 Dec 2016 10:58:06 +0000
Subject: [issue29047] Where are the test results stored?
In-Reply-To: <1482403473.61.0.626919341446.issue29047@psf.upfronthosting.co.za>
Message-ID: <1482577086.18.0.350190733485.issue29047@psf.upfronthosting.co.za>


Patrik Iselind added the comment:

Cannot figure out how to add the link to the GitHub PR field. Adding link here instead.

https://github.com/python/devguide/pull/88

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29047>
_______________________________________

From report at bugs.python.org  Sat Dec 24 06:19:25 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 24 Dec 2016 11:19:25 +0000
Subject: [issue29049] Lazy GC tracking frame
In-Reply-To: <1482408044.82.0.398076651662.issue29049@psf.upfronthosting.co.za>
Message-ID: <20161224111922.79498.9642.F4A29427@psf.io>


Roundup Robot added the comment:

New changeset f5eb0c4f5d37 by INADA Naoki in branch 'default':
Issue #29049: Call _PyObject_GC_TRACK() lazily when calling Python function.
https://hg.python.org/cpython/rev/f5eb0c4f5d37

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29049>
_______________________________________

From report at bugs.python.org  Sat Dec 24 06:19:56 2016
From: report at bugs.python.org (INADA Naoki)
Date: Sat, 24 Dec 2016 11:19:56 +0000
Subject: [issue29049] Lazy GC tracking frame
In-Reply-To: <1482408044.82.0.398076651662.issue29049@psf.upfronthosting.co.za>
Message-ID: <1482578396.05.0.934156870159.issue29049@psf.upfronthosting.co.za>


Changes by INADA Naoki <songofacandy at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29049>
_______________________________________

From report at bugs.python.org  Sat Dec 24 06:22:46 2016
From: report at bugs.python.org (INADA Naoki)
Date: Sat, 24 Dec 2016 11:22:46 +0000
Subject: [issue29049] Lazy GC tracking frame
In-Reply-To: <1482408044.82.0.398076651662.issue29049@psf.upfronthosting.co.za>
Message-ID: <1482578566.54.0.900219060101.issue29049@psf.upfronthosting.co.za>


INADA Naoki added the comment:

(Rietveld shows 500 error when replying.)

> Minor style note: Use Py_REFCNT here to simplify?

Fixed when committing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29049>
_______________________________________

From report at bugs.python.org  Sat Dec 24 06:38:41 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 24 Dec 2016 11:38:41 +0000
Subject: [issue28815] test_socket fails if /proc/modules is existent but not
 readable
In-Reply-To: <1480263378.99.0.648069549511.issue28815@psf.upfronthosting.co.za>
Message-ID: <20161224113838.26768.75998.91E861E1@psf.io>


Roundup Robot added the comment:

New changeset 7889d7a771c7 by Martin Panter in branch '3.5':
Issue #28815: Skip TIPC tests if /proc/modules is not readable
https://hg.python.org/cpython/rev/7889d7a771c7

New changeset 48b9d9cdfe3b by Martin Panter in branch '3.6':
Issue #28815: Merge test_socket fix from 3.5
https://hg.python.org/cpython/rev/48b9d9cdfe3b

New changeset 7ceacac48cd2 by Martin Panter in branch 'default':
Issue #28815: Merge test_socket fix from 3.6
https://hg.python.org/cpython/rev/7ceacac48cd2

New changeset 41a99a2a7198 by Martin Panter in branch '2.7':
Issue #28815: Skip TIPC tests if /proc/modules is not readable
https://hg.python.org/cpython/rev/41a99a2a7198

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28815>
_______________________________________

From report at bugs.python.org  Sat Dec 24 06:43:37 2016
From: report at bugs.python.org (Patrik Iselind)
Date: Sat, 24 Dec 2016 11:43:37 +0000
Subject: [issue29048] Coverage influence tests, make some of them fail
In-Reply-To: <1482407776.18.0.223230024277.issue29048@psf.upfronthosting.co.za>
Message-ID: <1482579817.25.0.385820947134.issue29048@psf.upfronthosting.co.za>


Patrik Iselind added the comment:

As an example, the difference for test_exceptions:

$ ./python ../coveragepy run --pylib --source=exceptions Lib/test/regrtest.py test_exceptions
Run tests sequentially
0:00:00 [1/1] test_exceptions
Exception ignored in: <bound method ExceptionTests.test_unraisable.<locals>.BrokenDel.__del__ of <test.test_exceptions.ExceptionTests.test_unraisable.<locals>.BrokenDel object at 0x7f9feefc1c88>>
Traceback (most recent call last):
  File "/home/irina/patrik/cpython/Lib/test/test_exceptions.py", line 1024, in __del__
    raise exc
ValueError: del is broken
Exception ignored in: <object repr() failed>
Traceback (most recent call last):
  File "/home/irina/patrik/cpython/Lib/test/test_exceptions.py", line 1024, in __del__
    raise exc
ValueError: del is broken
Exception ignored in: <bound method ExceptionTests.test_unraisable.<locals>.BrokenExceptionDel.__del__ of <test.test_exceptions.ExceptionTests.test_unraisable.<locals>.BrokenExceptionDel object at 0x7f9feefc3d58>>
Traceback (most recent call last):
  File "/home/irina/patrik/cpython/Lib/test/test_exceptions.py", line 1034, in __del__
    raise exc
test.test_exceptions.BrokenStrException: <exception str() failed>
test test_exceptions failed -- multiple errors occurred; run in verbose mode for details
test_exceptions failed

1 test failed:
    test_exceptions

Total duration: 1 sec
Tests result: FAILURE
Coverage.py warning: Module exceptions was never imported.
Coverage.py warning: No data was collected.



$ ./python -m test -v test_exceptions
== CPython 3.7.0a0 (default:8e311f109b22, Dec 24 2016, 12:26:43) [GCC 5.4.0 20160609]
==   Linux-4.4.0-53-generic-x86_64-with-debian-stretch-sid little-endian
==   hash algorithm: siphash24 64bit
==  cwd: /home/irina/patrik/cpython/build/test_python_17521
==  encodings: locale=UTF-8, FS=utf-8
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0)
Run tests sequentially
0:00:00 [1/1] test_exceptions
testAttributes (test.test_exceptions.ExceptionTests) ... ok
testChainingAttrs (test.test_exceptions.ExceptionTests) ... ok
testChainingDescriptors (test.test_exceptions.ExceptionTests) ... ok
testExceptionCleanupNames (test.test_exceptions.ExceptionTests) ... ok
testExceptionCleanupState (test.test_exceptions.ExceptionTests) ... ok
testInfiniteRecursion (test.test_exceptions.ExceptionTests) ... ok
testInvalidAttrs (test.test_exceptions.ExceptionTests) ... ok
testInvalidTraceback (test.test_exceptions.ExceptionTests) ... ok
testKeywordArgs (test.test_exceptions.ExceptionTests) ... ok
testNoneClearsTracebackAttr (test.test_exceptions.ExceptionTests) ... ok
testRaising (test.test_exceptions.ExceptionTests) ... ok
testSettingException (test.test_exceptions.ExceptionTests) ... ok
testSyntaxErrorMessage (test.test_exceptions.ExceptionTests) ... ok
testSyntaxErrorOffset (test.test_exceptions.ExceptionTests) ... ok
testWithTraceback (test.test_exceptions.ExceptionTests) ... ok
test_3114 (test.test_exceptions.ExceptionTests) ... ok
test_MemoryError (test.test_exceptions.ExceptionTests) ... ok
test_WindowsError (test.test_exceptions.ExceptionTests) ... ok
test_badisinstance (test.test_exceptions.ExceptionTests) ... ok
test_errno_ENOTDIR (test.test_exceptions.ExceptionTests) ... ok
test_exception_target_in_nested_scope (test.test_exceptions.ExceptionTests) ... ok
test_exception_with_doc (test.test_exceptions.ExceptionTests) ... ok
test_generator_close_cleanup_exc_state (test.test_exceptions.ExceptionTests) ... ok
test_generator_del_cleanup_exc_state (test.test_exceptions.ExceptionTests) ... ok
test_generator_doesnt_retain_old_exc (test.test_exceptions.ExceptionTests) ... ok
test_generator_finalizing_and_exc_info (test.test_exceptions.ExceptionTests) ... ok
test_generator_leaking (test.test_exceptions.ExceptionTests) ... ok
test_generator_leaking2 (test.test_exceptions.ExceptionTests) ... ok
test_generator_leaking3 (test.test_exceptions.ExceptionTests) ... ok
test_generator_leaking4 (test.test_exceptions.ExceptionTests) ... ok
test_generator_next_cleanup_exc_state (test.test_exceptions.ExceptionTests) ... ok
test_generator_send_cleanup_exc_state (test.test_exceptions.ExceptionTests) ... ok
test_generator_throw_cleanup_exc_state (test.test_exceptions.ExceptionTests) ... ok
test_memory_error_cleanup (test.test_exceptions.ExceptionTests) ... ok
test_recursion_error_cleanup (test.test_exceptions.ExceptionTests) ... ok
test_str (test.test_exceptions.ExceptionTests) ... ok
test_unhandled (test.test_exceptions.ExceptionTests) ... ok
test_unicode_change_attributes (test.test_exceptions.ExceptionTests) ... ok
test_unicode_errors_no_object (test.test_exceptions.ExceptionTests) ... ok
test_unraisable (test.test_exceptions.ExceptionTests) ... ok
test_windows_message (test.test_exceptions.ExceptionTests)
Should fill in unknown error code in Windows error message ... skipped 'test specific to Windows'
test_attributes (test.test_exceptions.ImportErrorTests) ... ok
test_non_str_argument (test.test_exceptions.ImportErrorTests) ... ok
test_reset_attributes (test.test_exceptions.ImportErrorTests) ... ok

----------------------------------------------------------------------
Ran 44 tests in 0.156s

OK (skipped=1)
1 test OK.

Total duration: 302 ms
Tests result: SUCCESS

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29048>
_______________________________________

From report at bugs.python.org  Sat Dec 24 07:05:36 2016
From: report at bugs.python.org (Patrik Iselind)
Date: Sat, 24 Dec 2016 12:05:36 +0000
Subject: [issue29048] Coverage influence tests, make some of them fail
In-Reply-To: <1482407776.18.0.223230024277.issue29048@psf.upfronthosting.co.za>
Message-ID: <1482581136.0.0.464949316111.issue29048@psf.upfronthosting.co.za>


Patrik Iselind added the comment:

I've been looking into test_exceptions, why it fails. The reason seems to be that when the tests are executed under coverage, then they get nothing on the line that says the following in test_unraisable().

```python
report = stderr.getvalue()
```
So coverage steal strerr in this case, and the test's thunder.

A way to get around this would be to not let the test rely in stderr but instead catch the exception and unfold it as a string for testing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29048>
_______________________________________

From report at bugs.python.org  Sat Dec 24 07:23:40 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 24 Dec 2016 12:23:40 +0000
Subject: [issue28815] test_socket fails if /proc/modules is existent but not
 readable
In-Reply-To: <1480263378.99.0.648069549511.issue28815@psf.upfronthosting.co.za>
Message-ID: <1482582220.29.0.27615268452.issue28815@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Wouldn't be more pythonic to catch (FileNotFoundError, IsADirectoryError, PermissionError) instead of checking errno?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28815>
_______________________________________

From report at bugs.python.org  Sat Dec 24 07:51:08 2016
From: report at bugs.python.org (Ned Batchelder)
Date: Sat, 24 Dec 2016 12:51:08 +0000
Subject: [issue29048] Coverage influence tests, make some of them fail
In-Reply-To: <1482407776.18.0.223230024277.issue29048@psf.upfronthosting.co.za>
Message-ID: <1482583868.33.0.980139195786.issue29048@psf.upfronthosting.co.za>


Ned Batchelder added the comment:

I doubt very very much that coverage.py is stealing stderr.  Many many test suites would have this problem if that were true.  More likely is that somehow __del__ is not being invoked when you need it to be.

I tried running the tests under coverage also, and did not see this behavior. I don't have a build tree of the latest code, but I ran it on 3.6.0.  The tests passed both with and without coverage measurement (output below).  I would like to understand why you are seeing the results you are.

$ mkvirtualenv -p python3.6 issue29048
Running virtualenv with interpreter /usr/local/bin/python3.6
Using base prefix '/usr/local/pythonz/pythons/CPython-3.6.0'
New python executable in issue29048/bin/python3.6
Also creating executable in issue29048/bin/python
Installing setuptools, pip, wheel...done.
Collecting pip
  Using cached pip-9.0.1-py2.py3-none-any.whl
Collecting setuptools
  Using cached setuptools-32.2.0-py2.py3-none-any.whl
Installing collected packages: pip, setuptools
  Found existing installation: pip 7.1.2
    Uninstalling pip-7.1.2:
      Successfully uninstalled pip-7.1.2
  Found existing installation: setuptools 18.2
    Uninstalling setuptools-18.2:
      Successfully uninstalled setuptools-18.2
Successfully installed pip-9.0.1 setuptools-32.2.0
(issue29048)$ pip install coverage
Collecting coverage
Installing collected packages: coverage
Successfully installed coverage-4.2
(issue29048)$ python3.6 -m test -v test_exceptions
== CPython 3.6.0 (default, Dec 23 2016, 07:11:25) [GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
==   Darwin-14.5.0-x86_64-i386-64bit little-endian
==   hash algorithm: siphash24 64bit
==  cwd: /private/var/folders/j2/gr3cj3jn63s5q8g3bjvw57hm0000gp/T/test_python_20266
==  encodings: locale=UTF-8, FS=utf-8
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0)
Run tests sequentially
0:00:00 [1/1] test_exceptions
testAttributes (test.test_exceptions.ExceptionTests) ... ok
testChainingAttrs (test.test_exceptions.ExceptionTests) ... ok
testChainingDescriptors (test.test_exceptions.ExceptionTests) ... ok
testExceptionCleanupNames (test.test_exceptions.ExceptionTests) ... ok
testExceptionCleanupState (test.test_exceptions.ExceptionTests) ... ok
testInfiniteRecursion (test.test_exceptions.ExceptionTests) ... ok
testInvalidAttrs (test.test_exceptions.ExceptionTests) ... ok
testInvalidTraceback (test.test_exceptions.ExceptionTests) ... ok
testKeywordArgs (test.test_exceptions.ExceptionTests) ... ok
testNoneClearsTracebackAttr (test.test_exceptions.ExceptionTests) ... ok
testRaising (test.test_exceptions.ExceptionTests) ... ok
testSettingException (test.test_exceptions.ExceptionTests) ... ok
testSyntaxErrorMessage (test.test_exceptions.ExceptionTests) ... ok
testSyntaxErrorOffset (test.test_exceptions.ExceptionTests) ... ok
testWithTraceback (test.test_exceptions.ExceptionTests) ... ok
test_3114 (test.test_exceptions.ExceptionTests) ... ok
test_MemoryError (test.test_exceptions.ExceptionTests) ... ok
test_WindowsError (test.test_exceptions.ExceptionTests) ... ok
test_badisinstance (test.test_exceptions.ExceptionTests) ... ok
test_errno_ENOTDIR (test.test_exceptions.ExceptionTests) ... ok
test_exception_target_in_nested_scope (test.test_exceptions.ExceptionTests) ... ok
test_exception_with_doc (test.test_exceptions.ExceptionTests) ... ok
test_generator_close_cleanup_exc_state (test.test_exceptions.ExceptionTests) ... ok
test_generator_del_cleanup_exc_state (test.test_exceptions.ExceptionTests) ... ok
test_generator_doesnt_retain_old_exc (test.test_exceptions.ExceptionTests) ... ok
test_generator_finalizing_and_exc_info (test.test_exceptions.ExceptionTests) ... ok
test_generator_leaking (test.test_exceptions.ExceptionTests) ... ok
test_generator_leaking2 (test.test_exceptions.ExceptionTests) ... ok
test_generator_leaking3 (test.test_exceptions.ExceptionTests) ... ok
test_generator_leaking4 (test.test_exceptions.ExceptionTests) ... ok
test_generator_next_cleanup_exc_state (test.test_exceptions.ExceptionTests) ... ok
test_generator_send_cleanup_exc_state (test.test_exceptions.ExceptionTests) ... ok
test_generator_throw_cleanup_exc_state (test.test_exceptions.ExceptionTests) ... ok
test_memory_error_cleanup (test.test_exceptions.ExceptionTests) ... ok
test_recursion_error_cleanup (test.test_exceptions.ExceptionTests) ... ok
test_str (test.test_exceptions.ExceptionTests) ... ok
test_unhandled (test.test_exceptions.ExceptionTests) ... ok
test_unicode_change_attributes (test.test_exceptions.ExceptionTests) ... ok
test_unicode_errors_no_object (test.test_exceptions.ExceptionTests) ... ok
test_unraisable (test.test_exceptions.ExceptionTests) ... ok
test_windows_message (test.test_exceptions.ExceptionTests)
Should fill in unknown error code in Windows error message ... skipped 'test specific to Windows'
test_attributes (test.test_exceptions.ImportErrorTests) ... ok
test_non_str_argument (test.test_exceptions.ImportErrorTests) ... ok

----------------------------------------------------------------------
Ran 43 tests in 0.027s

OK (skipped=1)
1 test OK.

Total duration: 64 ms
Tests result: SUCCESS
(issue29048)$ python -m coverage run --pylib -m test -v test_exceptions
== CPython 3.6.0 (default, Dec 23 2016, 07:11:25) [GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
==   Darwin-14.5.0-x86_64-i386-64bit little-endian
==   hash algorithm: siphash24 64bit
==  cwd: /private/var/folders/j2/gr3cj3jn63s5q8g3bjvw57hm0000gp/T/test_python_20270
==  encodings: locale=UTF-8, FS=utf-8
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0)
Run tests sequentially
0:00:00 [1/1] test_exceptions
testAttributes (test.test_exceptions.ExceptionTests) ... ok
testChainingAttrs (test.test_exceptions.ExceptionTests) ... ok
testChainingDescriptors (test.test_exceptions.ExceptionTests) ... ok
testExceptionCleanupNames (test.test_exceptions.ExceptionTests) ... ok
testExceptionCleanupState (test.test_exceptions.ExceptionTests) ... ok
testInfiniteRecursion (test.test_exceptions.ExceptionTests) ... ok
testInvalidAttrs (test.test_exceptions.ExceptionTests) ... ok
testInvalidTraceback (test.test_exceptions.ExceptionTests) ... ok
testKeywordArgs (test.test_exceptions.ExceptionTests) ... ok
testNoneClearsTracebackAttr (test.test_exceptions.ExceptionTests) ... ok
testRaising (test.test_exceptions.ExceptionTests) ... ok
testSettingException (test.test_exceptions.ExceptionTests) ... ok
testSyntaxErrorMessage (test.test_exceptions.ExceptionTests) ... ok
testSyntaxErrorOffset (test.test_exceptions.ExceptionTests) ... ok
testWithTraceback (test.test_exceptions.ExceptionTests) ... ok
test_3114 (test.test_exceptions.ExceptionTests) ... ok
test_MemoryError (test.test_exceptions.ExceptionTests) ... ok
test_WindowsError (test.test_exceptions.ExceptionTests) ... ok
test_badisinstance (test.test_exceptions.ExceptionTests) ... ok
test_errno_ENOTDIR (test.test_exceptions.ExceptionTests) ... ok
test_exception_target_in_nested_scope (test.test_exceptions.ExceptionTests) ... ok
test_exception_with_doc (test.test_exceptions.ExceptionTests) ... ok
test_generator_close_cleanup_exc_state (test.test_exceptions.ExceptionTests) ... ok
test_generator_del_cleanup_exc_state (test.test_exceptions.ExceptionTests) ... ok
test_generator_doesnt_retain_old_exc (test.test_exceptions.ExceptionTests) ... ok
test_generator_finalizing_and_exc_info (test.test_exceptions.ExceptionTests) ... ok
test_generator_leaking (test.test_exceptions.ExceptionTests) ... ok
test_generator_leaking2 (test.test_exceptions.ExceptionTests) ... ok
test_generator_leaking3 (test.test_exceptions.ExceptionTests) ... ok
test_generator_leaking4 (test.test_exceptions.ExceptionTests) ... ok
test_generator_next_cleanup_exc_state (test.test_exceptions.ExceptionTests) ... ok
test_generator_send_cleanup_exc_state (test.test_exceptions.ExceptionTests) ... ok
test_generator_throw_cleanup_exc_state (test.test_exceptions.ExceptionTests) ... ok
test_memory_error_cleanup (test.test_exceptions.ExceptionTests) ... ok
test_recursion_error_cleanup (test.test_exceptions.ExceptionTests) ... ok
test_str (test.test_exceptions.ExceptionTests) ... ok
test_unhandled (test.test_exceptions.ExceptionTests) ... ok
test_unicode_change_attributes (test.test_exceptions.ExceptionTests) ... ok
test_unicode_errors_no_object (test.test_exceptions.ExceptionTests) ... ok
test_unraisable (test.test_exceptions.ExceptionTests) ... ok
test_windows_message (test.test_exceptions.ExceptionTests)
Should fill in unknown error code in Windows error message ... skipped 'test specific to Windows'
test_attributes (test.test_exceptions.ImportErrorTests) ... ok
test_non_str_argument (test.test_exceptions.ImportErrorTests) ... ok

----------------------------------------------------------------------
Ran 43 tests in 0.036s

OK (skipped=1)
1 test OK.

Total duration: 95 ms
Tests result: SUCCESS
(issue29048)$ python -m coverage report
Name                                                                                       Stmts   Miss  Cover
--------------------------------------------------------------------------------------------------------------
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/_bootlocale.py                         17     13    24%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/_collections_abc.py                   562    546     3%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/_osx_support.py                       210    161    23%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/_sysconfigdata_m_darwin_darwin.py       1      0   100%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/_weakrefset.py                        146    109    25%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/abc.py                                 92     65    29%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/argparse.py                          1187    757    36%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/base64.py                             315    268    15%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/codecs.py                             398    377     5%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/collections/__init__.py               677    650     4%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/contextlib.py                         163    140    14%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/difflib.py                            669    606     9%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/email/__init__.py                      14      8    43%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/email/base64mime.py                    40     26    35%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/email/charset.py                      122     78    36%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/email/encoders.py                      28     19    32%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/email/errors.py                        37      7    81%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/email/header.py                       310    258    17%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/email/quoprimime.py                   115     83    28%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/encodings/__init__.py                  76     43    43%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/encodings/latin_1.py                   19     18     5%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/enum.py                               438    248    43%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/functools.py                          443    421     5%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/genericpath.py                         72     50    31%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/gettext.py                            389    323    17%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/gzip.py                               349    298    15%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/importlib/__init__.py                  99     96     3%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/importlib/_bootstrap.py               631    445    29%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/importlib/_bootstrap_external.py      711    528    26%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/importlib/util.py                     147    140     5%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/ipaddress.py                          904    597    34%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/linecache.py                          102     55    46%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/locale.py                             399    357    11%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/logging/__init__.py                   769    521    32%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/logging/handlers.py                   663    534    19%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/lzma.py                               135    130     4%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/multiprocessing/process.py            163    162     1%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/nntplib.py                            559    457    18%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/os.py                                 536    489     9%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/platform.py                           580    466    20%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/posixpath.py                          320    222    31%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/pprint.py                             419    351    16%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/queue.py                              111     76    32%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/quopri.py                             168    150    11%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/random.py                             346    329     5%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/re.py                                 153    125    18%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/shutil.py                             619    600     3%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/socket.py                             403    396     2%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/sre_compile.py                        401    151    62%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/sre_parse.py                          758    460    39%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/ssl.py                                571    426    25%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/string.py                             153    114    25%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/subprocess.py                         794    671    15%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/sysconfig.py                          376    246    35%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/tempfile.py                           395    258    35%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/test/__init__.py                        0      0   100%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/test/__main__.py                        2      0   100%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/test/libregrtest/__init__.py            3      0   100%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/test/libregrtest/cmdline.py           127     52    59%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/test/libregrtest/main.py              335    163    51%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/test/libregrtest/refleak.py           186    122    34%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/test/libregrtest/runtest.py           146     62    58%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/test/libregrtest/save_env.py          189     68    64%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/test/libregrtest/setup.py              68     21    69%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/test/support/__init__.py             1289    902    30%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/test/test_exceptions.py               765     93    88%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/threading.py                          575    572     1%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/tokenize.py                           473    438     7%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/traceback.py                          247    185    25%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/types.py                              155    152     2%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/unittest/__init__.py                   15      3    80%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/unittest/case.py                      753    413    45%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/unittest/loader.py                    295    226    23%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/unittest/main.py                      149    122    18%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/unittest/result.py                    128     66    48%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/unittest/runner.py                    159     51    68%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/unittest/signals.py                    47     33    30%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/unittest/suite.py                     220     81    63%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/unittest/util.py                      130    107    18%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/urllib/__init__.py                      0      0   100%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/urllib/error.py                        34     19    44%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/urllib/response.py                     43     26    40%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/warnings.py                           331    300     9%
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/weakref.py                            379    342    10%
--------------------------------------------------------------------------------------------------------------
TOTAL                                                                                      26517  19743    26%
(issue29048)$

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29048>
_______________________________________

From report at bugs.python.org  Sat Dec 24 07:52:42 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 24 Dec 2016 12:52:42 +0000
Subject: [issue29062] hashlib documentation link error
In-Reply-To: <1482571303.3.0.781602557285.issue29062@psf.upfronthosting.co.za>
Message-ID: <1482583962.18.0.0853020443155.issue29062@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Is the https://docs.python.org/3/library/crypto.html section messed up? Two hashlib entries and some other bad entries?

----------
nosy: +xiang.zhang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29062>
_______________________________________

From report at bugs.python.org  Sat Dec 24 07:55:02 2016
From: report at bugs.python.org (kevin)
Date: Sat, 24 Dec 2016 12:55:02 +0000
Subject: [issue29064] Package numpy can't be used normally
Message-ID: <1482584102.8.0.443531506198.issue29064@psf.upfronthosting.co.za>


New submission from kevin:

I used package numpy,but encounter the following error:

Traceback (most recent call last):
  File "rgbtoyuv.py", line 2, in <module>
    import numpy as np
  File "/usr/local/lib/python3.5/site-packages/numpy-1.11.2-py3.5-linux-x86_64.egg/numpy/__init__.py", line 163, in <module>
    from . import random
  File "/usr/local/lib/python3.5/site-packages/numpy-1.11.2-py3.5-linux-x86_64.egg/numpy/random/__init__.py", line 99, in <module>
    from .mtrand import *
ImportError: /usr/local/lib/python3.5/site-packages/numpy-1.11.2-py3.5-linux-x86_64.egg/numpy/random/mtrand.cpython-35m-x86_64-linux-gnu.so: undefined symbol: PyFPE_jbuf

I have download the numpy install package,and installed.

Platform ubuntu16.04 x86_64

python version: 3.5.2

numpy version:1.11.2 and try to version:1.9.0 also,but installed failed.

Please help me find the reason,thanks a lot.

----------
components: Library (Lib)
messages: 283949
nosy: kevin.zhai80
priority: normal
severity: normal
status: open
title: Package numpy can't be used normally
type: resource usage
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29064>
_______________________________________

From report at bugs.python.org  Sat Dec 24 08:13:27 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 24 Dec 2016 13:13:27 +0000
Subject: [issue29064] Package numpy can't be used normally
In-Reply-To: <1482584102.8.0.443531506198.issue29064@psf.upfronthosting.co.za>
Message-ID: <1482585207.39.0.744012892109.issue29064@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Hi kevin. This tracker is used to report problems about CPython. Your problem seems related to numpy and you'd better go to numpy's tracker to ask for help. :-)

----------
nosy: +xiang.zhang
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29064>
_______________________________________

From report at bugs.python.org  Sat Dec 24 08:40:56 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 24 Dec 2016 13:40:56 +0000
Subject: [issue28815] test_socket fails if /proc/modules is existent but not
 readable
In-Reply-To: <1480263378.99.0.648069549511.issue28815@psf.upfronthosting.co.za>
Message-ID: <1482586856.59.0.180952191981.issue28815@psf.upfronthosting.co.za>


Martin Panter added the comment:

That would be possible in Python 3, not Python 2 though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28815>
_______________________________________

From report at bugs.python.org  Sat Dec 24 08:59:24 2016
From: report at bugs.python.org (Cornelius Diekmann)
Date: Sat, 24 Dec 2016 13:59:24 +0000
Subject: [issue29054] pty.py: pty.spawn hangs after client disconnect over nc
 (netcat)
In-Reply-To: <1482502637.76.0.304881442895.issue29054@psf.upfronthosting.co.za>
Message-ID: <1482587964.64.0.56067093248.issue29054@psf.upfronthosting.co.za>


Cornelius Diekmann added the comment:

Thank you Martin very much. To resolve this issue, I decided to document the current behavior and add test cases for it. No change in behavior is introduced. This hopefully allows to close this issue. The test cases for the current behavior ensure that we can (at some point in the future) add some different behavior without breaking backwards compatibility.

Fixed: Observed behavior is now expected+documented behavior. Improved test cases.

Happy Holidays!

----------
Added file: http://bugs.python.org/file46023/test_pty_and_doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29054>
_______________________________________

From report at bugs.python.org  Sat Dec 24 09:04:57 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 24 Dec 2016 14:04:57 +0000
Subject: [issue28997] test_readline.test_nonascii fails on Android
In-Reply-To: <1481965369.72.0.409169776064.issue28997@psf.upfronthosting.co.za>
Message-ID: <1482588297.3.0.948095492859.issue28997@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

With your patch Martin, test_nonascii is skipped on Android when LANG is not set and the issue is fixed.

> Just to clarify, is the problem that Python (correctly) assumes UTF-8 encoding on Android, but Readline does not unless you tweak the environment variable?

Readline (correctly) uses the locale environment variables to set eight-bit mode (see function _rl_init_eightbit() in Readline nls.c) and when the LC_CTYPE category is C or POSIX, eight-bit characters are discarded on input and a bell character ('\x07') is echoed instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28997>
_______________________________________

From report at bugs.python.org  Sat Dec 24 10:25:44 2016
From: report at bugs.python.org (Pam McA'Nulty)
Date: Sat, 24 Dec 2016 15:25:44 +0000
Subject: [issue29057] Compiler failure on Mac OS X - sys/random.h
In-Reply-To: <1482514649.72.0.460227366509.issue29057@psf.upfronthosting.co.za>
Message-ID: <1482593144.04.0.887861342098.issue29057@psf.upfronthosting.co.za>


Pam McA'Nulty added the comment:

Good question.

It looks like there are 3 defines getting checked:
HAVE_SYS_RANDOM_H and either HAVE_GETRANDOM or HAVE_GETENTROPY

The previous issue seemed to be that you could have HAVE_GETRANDOM and/or HAVE_GETENTROPY be set, but still not have a sys/random.h, so a check was added for HAVE_SYS_RANDOM_H.  However, on macs, you can HAVE_SYS_RANDOM_H, but still not have either HAVE_GETRANDOM or HAVE_GETENTROPY.

This _probably_ implies that the sys/random.h that's present isn't conformant enough for the compiler settings and my mac's os and/or xcode.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29057>
_______________________________________

From report at bugs.python.org  Sat Dec 24 10:26:59 2016
From: report at bugs.python.org (Pam McA'Nulty)
Date: Sat, 24 Dec 2016 15:26:59 +0000
Subject: [issue29057] Compiler failure on Mac OS X - sys/random.h
In-Reply-To: <1482514649.72.0.460227366509.issue29057@psf.upfronthosting.co.za>
Message-ID: <1482593219.4.0.900022331085.issue29057@psf.upfronthosting.co.za>


Pam McA'Nulty added the comment:

New patch to make consistent wrt use of "defined()"

----------
Added file: http://bugs.python.org/file46024/Issue29057_random_include-v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29057>
_______________________________________

From report at bugs.python.org  Sat Dec 24 10:36:37 2016
From: report at bugs.python.org (kevin)
Date: Sat, 24 Dec 2016 15:36:37 +0000
Subject: [issue29064] Package numpy can't be used normally
In-Reply-To: <1482584102.8.0.443531506198.issue29064@psf.upfronthosting.co.za>
Message-ID: <1482593797.32.0.107851544453.issue29064@psf.upfronthosting.co.za>


kevin added the comment:

Hi Xiang?
    Thanks for your information.

----------
resolution: third party -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29064>
_______________________________________

From report at bugs.python.org  Sat Dec 24 10:39:56 2016
From: report at bugs.python.org (Patrik Iselind)
Date: Sat, 24 Dec 2016 15:39:56 +0000
Subject: [issue29048] Coverage influence tests, make some of them fail
In-Reply-To: <1482583868.33.0.980139195786.issue29048@psf.upfronthosting.co.za>
Message-ID: <CANzOjBjPGmbTehP4qsapPXwqfKb4tT4e19Qc3JA0mfEVH+VaGw@mail.gmail.com>


Patrik Iselind added the comment:

i use the latest code. perhaps something for introduced after 3.6?

Patrik

Den 24 dec 2016 13:51 skrev "Ned Batchelder" <report at bugs.python.org>:

>
> Ned Batchelder added the comment:
>
> I doubt very very much that coverage.py is stealing stderr.  Many many
> test suites would have this problem if that were true.  More likely is that
> somehow __del__ is not being invoked when you need it to be.
>
> I tried running the tests under coverage also, and did not see this
> behavior. I don't have a build tree of the latest code, but I ran it on
> 3.6.0.  The tests passed both with and without coverage measurement (output
> below).  I would like to understand why you are seeing the results you are.
>
> $ mkvirtualenv -p python3.6 issue29048
> Running virtualenv with interpreter /usr/local/bin/python3.6
> Using base prefix '/usr/local/pythonz/pythons/CPython-3.6.0'
> New python executable in issue29048/bin/python3.6
> Also creating executable in issue29048/bin/python
> Installing setuptools, pip, wheel...done.
> Collecting pip
>   Using cached pip-9.0.1-py2.py3-none-any.whl
> Collecting setuptools
>   Using cached setuptools-32.2.0-py2.py3-none-any.whl
> Installing collected packages: pip, setuptools
>   Found existing installation: pip 7.1.2
>     Uninstalling pip-7.1.2:
>       Successfully uninstalled pip-7.1.2
>   Found existing installation: setuptools 18.2
>     Uninstalling setuptools-18.2:
>       Successfully uninstalled setuptools-18.2
> Successfully installed pip-9.0.1 setuptools-32.2.0
> (issue29048)$ pip install coverage
> Collecting coverage
> Installing collected packages: coverage
> Successfully installed coverage-4.2
> (issue29048)$ python3.6 -m test -v test_exceptions
> == CPython 3.6.0 (default, Dec 23 2016, 07:11:25) [GCC 4.2.1 Compatible
> Apple LLVM 7.0.2 (clang-700.1.81)]
> ==   Darwin-14.5.0-x86_64-i386-64bit little-endian
> ==   hash algorithm: siphash24 64bit
> ==  cwd: /private/var/folders/j2/gr3cj3jn63s5q8g3bjvw57hm0000gp
> /T/test_python_20266
> ==  encodings: locale=UTF-8, FS=utf-8
> Testing with flags: sys.flags(debug=0, inspect=0, interactive=0,
> optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0,
> ignore_environment=0, verbose=0, bytes_warning=0, quiet=0,
> hash_randomization=1, isolated=0)
> Run tests sequentially
> 0:00:00 [1/1] test_exceptions
> testAttributes (test.test_exceptions.ExceptionTests) ... ok
> testChainingAttrs (test.test_exceptions.ExceptionTests) ... ok
> testChainingDescriptors (test.test_exceptions.ExceptionTests) ... ok
> testExceptionCleanupNames (test.test_exceptions.ExceptionTests) ... ok
> testExceptionCleanupState (test.test_exceptions.ExceptionTests) ... ok
> testInfiniteRecursion (test.test_exceptions.ExceptionTests) ... ok
> testInvalidAttrs (test.test_exceptions.ExceptionTests) ... ok
> testInvalidTraceback (test.test_exceptions.ExceptionTests) ... ok
> testKeywordArgs (test.test_exceptions.ExceptionTests) ... ok
> testNoneClearsTracebackAttr (test.test_exceptions.ExceptionTests) ... ok
> testRaising (test.test_exceptions.ExceptionTests) ... ok
> testSettingException (test.test_exceptions.ExceptionTests) ... ok
> testSyntaxErrorMessage (test.test_exceptions.ExceptionTests) ... ok
> testSyntaxErrorOffset (test.test_exceptions.ExceptionTests) ... ok
> testWithTraceback (test.test_exceptions.ExceptionTests) ... ok
> test_3114 (test.test_exceptions.ExceptionTests) ... ok
> test_MemoryError (test.test_exceptions.ExceptionTests) ... ok
> test_WindowsError (test.test_exceptions.ExceptionTests) ... ok
> test_badisinstance (test.test_exceptions.ExceptionTests) ... ok
> test_errno_ENOTDIR (test.test_exceptions.ExceptionTests) ... ok
> test_exception_target_in_nested_scope (test.test_exceptions.ExceptionTests)
> ... ok
> test_exception_with_doc (test.test_exceptions.ExceptionTests) ... ok
> test_generator_close_cleanup_exc_state (test.test_exceptions.ExceptionTests)
> ... ok
> test_generator_del_cleanup_exc_state (test.test_exceptions.ExceptionTests)
> ... ok
> test_generator_doesnt_retain_old_exc (test.test_exceptions.ExceptionTests)
> ... ok
> test_generator_finalizing_and_exc_info (test.test_exceptions.ExceptionTests)
> ... ok
> test_generator_leaking (test.test_exceptions.ExceptionTests) ... ok
> test_generator_leaking2 (test.test_exceptions.ExceptionTests) ... ok
> test_generator_leaking3 (test.test_exceptions.ExceptionTests) ... ok
> test_generator_leaking4 (test.test_exceptions.ExceptionTests) ... ok
> test_generator_next_cleanup_exc_state (test.test_exceptions.ExceptionTests)
> ... ok
> test_generator_send_cleanup_exc_state (test.test_exceptions.ExceptionTests)
> ... ok
> test_generator_throw_cleanup_exc_state (test.test_exceptions.ExceptionTests)
> ... ok
> test_memory_error_cleanup (test.test_exceptions.ExceptionTests) ... ok
> test_recursion_error_cleanup (test.test_exceptions.ExceptionTests) ... ok
> test_str (test.test_exceptions.ExceptionTests) ... ok
> test_unhandled (test.test_exceptions.ExceptionTests) ... ok
> test_unicode_change_attributes (test.test_exceptions.ExceptionTests) ...
> ok
> test_unicode_errors_no_object (test.test_exceptions.ExceptionTests) ... ok
> test_unraisable (test.test_exceptions.ExceptionTests) ... ok
> test_windows_message (test.test_exceptions.ExceptionTests)
> Should fill in unknown error code in Windows error message ... skipped
> 'test specific to Windows'
> test_attributes (test.test_exceptions.ImportErrorTests) ... ok
> test_non_str_argument (test.test_exceptions.ImportErrorTests) ... ok
>
> ----------------------------------------------------------------------
> Ran 43 tests in 0.027s
>
> OK (skipped=1)
> 1 test OK.
>
> Total duration: 64 ms
> Tests result: SUCCESS
> (issue29048)$ python -m coverage run --pylib -m test -v test_exceptions
> == CPython 3.6.0 (default, Dec 23 2016, 07:11:25) [GCC 4.2.1 Compatible
> Apple LLVM 7.0.2 (clang-700.1.81)]
> ==   Darwin-14.5.0-x86_64-i386-64bit little-endian
> ==   hash algorithm: siphash24 64bit
> ==  cwd: /private/var/folders/j2/gr3cj3jn63s5q8g3bjvw57hm0000gp
> /T/test_python_20270
> ==  encodings: locale=UTF-8, FS=utf-8
> Testing with flags: sys.flags(debug=0, inspect=0, interactive=0,
> optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0,
> ignore_environment=0, verbose=0, bytes_warning=0, quiet=0,
> hash_randomization=1, isolated=0)
> Run tests sequentially
> 0:00:00 [1/1] test_exceptions
> testAttributes (test.test_exceptions.ExceptionTests) ... ok
> testChainingAttrs (test.test_exceptions.ExceptionTests) ... ok
> testChainingDescriptors (test.test_exceptions.ExceptionTests) ... ok
> testExceptionCleanupNames (test.test_exceptions.ExceptionTests) ... ok
> testExceptionCleanupState (test.test_exceptions.ExceptionTests) ... ok
> testInfiniteRecursion (test.test_exceptions.ExceptionTests) ... ok
> testInvalidAttrs (test.test_exceptions.ExceptionTests) ... ok
> testInvalidTraceback (test.test_exceptions.ExceptionTests) ... ok
> testKeywordArgs (test.test_exceptions.ExceptionTests) ... ok
> testNoneClearsTracebackAttr (test.test_exceptions.ExceptionTests) ... ok
> testRaising (test.test_exceptions.ExceptionTests) ... ok
> testSettingException (test.test_exceptions.ExceptionTests) ... ok
> testSyntaxErrorMessage (test.test_exceptions.ExceptionTests) ... ok
> testSyntaxErrorOffset (test.test_exceptions.ExceptionTests) ... ok
> testWithTraceback (test.test_exceptions.ExceptionTests) ... ok
> test_3114 (test.test_exceptions.ExceptionTests) ... ok
> test_MemoryError (test.test_exceptions.ExceptionTests) ... ok
> test_WindowsError (test.test_exceptions.ExceptionTests) ... ok
> test_badisinstance (test.test_exceptions.ExceptionTests) ... ok
> test_errno_ENOTDIR (test.test_exceptions.ExceptionTests) ... ok
> test_exception_target_in_nested_scope (test.test_exceptions.ExceptionTests)
> ... ok
> test_exception_with_doc (test.test_exceptions.ExceptionTests) ... ok
> test_generator_close_cleanup_exc_state (test.test_exceptions.ExceptionTests)
> ... ok
> test_generator_del_cleanup_exc_state (test.test_exceptions.ExceptionTests)
> ... ok
> test_generator_doesnt_retain_old_exc (test.test_exceptions.ExceptionTests)
> ... ok
> test_generator_finalizing_and_exc_info (test.test_exceptions.ExceptionTests)
> ... ok
> test_generator_leaking (test.test_exceptions.ExceptionTests) ... ok
> test_generator_leaking2 (test.test_exceptions.ExceptionTests) ... ok
> test_generator_leaking3 (test.test_exceptions.ExceptionTests) ... ok
> test_generator_leaking4 (test.test_exceptions.ExceptionTests) ... ok
> test_generator_next_cleanup_exc_state (test.test_exceptions.ExceptionTests)
> ... ok
> test_generator_send_cleanup_exc_state (test.test_exceptions.ExceptionTests)
> ... ok
> test_generator_throw_cleanup_exc_state (test.test_exceptions.ExceptionTests)
> ... ok
> test_memory_error_cleanup (test.test_exceptions.ExceptionTests) ... ok
> test_recursion_error_cleanup (test.test_exceptions.ExceptionTests) ... ok
> test_str (test.test_exceptions.ExceptionTests) ... ok
> test_unhandled (test.test_exceptions.ExceptionTests) ... ok
> test_unicode_change_attributes (test.test_exceptions.ExceptionTests) ...
> ok
> test_unicode_errors_no_object (test.test_exceptions.ExceptionTests) ... ok
> test_unraisable (test.test_exceptions.ExceptionTests) ... ok
> test_windows_message (test.test_exceptions.ExceptionTests)
> Should fill in unknown error code in Windows error message ... skipped
> 'test specific to Windows'
> test_attributes (test.test_exceptions.ImportErrorTests) ... ok
> test_non_str_argument (test.test_exceptions.ImportErrorTests) ... ok
>
> ----------------------------------------------------------------------
> Ran 43 tests in 0.036s
>
> OK (skipped=1)
> 1 test OK.
>
> Total duration: 95 ms
> Tests result: SUCCESS
> (issue29048)$ python -m coverage report
> Name
>                  Stmts   Miss  Cover
> ------------------------------------------------------------
> --------------------------------------------------
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/_bootlocale.py
>                      17     13    24%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/_collections_abc.py
>                  562    546     3%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/_osx_support.py
>                    210    161    23%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/_
> sysconfigdata_m_darwin_darwin.py       1      0   100%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/_weakrefset.py
>                     146    109    25%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/abc.py
>                      92     65    29%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/argparse.py
>                   1187    757    36%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/base64.py
>                    315    268    15%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/codecs.py
>                    398    377     5%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/collections/__init__.py
>              677    650     4%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/contextlib.py
>                    163    140    14%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/difflib.py
>                     669    606     9%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/email/__init__.py
>                     14      8    43%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/email/base64mime.py
>                   40     26    35%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/email/charset.py
>                     122     78    36%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/email/encoders.py
>                     28     19    32%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/email/errors.py
>                     37      7    81%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/email/header.py
>                    310    258    17%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/email/quoprimime.py
>                  115     83    28%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/encodings/__init__.py
>                 76     43    43%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/encodings/latin_1.py
>                  19     18     5%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/enum.py
>                    438    248    43%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/functools.py
>                     443    421     5%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/genericpath.py
>                      72     50    31%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/gettext.py
>                     389    323    17%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/gzip.py
>                    349    298    15%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/importlib/__init__.py
>                 99     96     3%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/importlib/_bootstrap.py
>              631    445    29%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/
> importlib/_bootstrap_external.py      711    528    26%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/importlib/util.py
>                    147    140     5%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/ipaddress.py
>                     904    597    34%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/linecache.py
>                     102     55    46%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/locale.py
>                    399    357    11%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/logging/__init__.py
>                  769    521    32%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/logging/handlers.py
>                  663    534    19%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/lzma.py
>                    135    130     4%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/multiprocessing/process.py
>           163    162     1%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/nntplib.py
>                     559    457    18%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/os.py
>                    536    489     9%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/platform.py
>                    580    466    20%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/posixpath.py
>                     320    222    31%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/pprint.py
>                    419    351    16%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/queue.py
>                     111     76    32%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/quopri.py
>                    168    150    11%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/random.py
>                    346    329     5%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/re.py
>                    153    125    18%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/shutil.py
>                    619    600     3%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/socket.py
>                    403    396     2%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/sre_compile.py
>                     401    151    62%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/sre_parse.py
>                     758    460    39%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/ssl.py
>                     571    426    25%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/string.py
>                    153    114    25%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/subprocess.py
>                    794    671    15%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/sysconfig.py
>                     376    246    35%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/tempfile.py
>                    395    258    35%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/test/__init__.py
>                       0      0   100%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/test/__main__.py
>                       2      0   100%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/test/libregrtest/__init__.py
>           3      0   100%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/test/libregrtest/cmdline.py
>          127     52    59%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/test/libregrtest/main.py
>             335    163    51%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/test/libregrtest/refleak.py
>          186    122    34%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/test/libregrtest/runtest.py
>          146     62    58%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/test/libregrtest/save_env.py
>         189     68    64%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/test/libregrtest/setup.py
>             68     21    69%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/test/support/__init__.py
>            1289    902    30%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/test/test_exceptions.py
>              765     93    88%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/threading.py
>                     575    572     1%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/tokenize.py
>                    473    438     7%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/traceback.py
>                     247    185    25%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/types.py
>                     155    152     2%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/unittest/__init__.py
>                  15      3    80%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/unittest/case.py
>                     753    413    45%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/unittest/loader.py
>                   295    226    23%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/unittest/main.py
>                     149    122    18%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/unittest/result.py
>                   128     66    48%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/unittest/runner.py
>                   159     51    68%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/unittest/signals.py
>                   47     33    30%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/unittest/suite.py
>                    220     81    63%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/unittest/util.py
>                     130    107    18%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/urllib/__init__.py
>                     0      0   100%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/urllib/error.py
>                     34     19    44%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/urllib/response.py
>                    43     26    40%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/warnings.py
>                    331    300     9%
> /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/weakref.py
>                     379    342    10%
> ------------------------------------------------------------
> --------------------------------------------------
> TOTAL
>                 26517  19743    26%
> (issue29048)$
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue29048>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29048>
_______________________________________

From report at bugs.python.org  Sat Dec 24 10:41:04 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 24 Dec 2016 15:41:04 +0000
Subject: [issue29064] Package numpy can't be used normally
In-Reply-To: <1482584102.8.0.443531506198.issue29064@psf.upfronthosting.co.za>
Message-ID: <1482594064.04.0.489576699634.issue29064@psf.upfronthosting.co.za>


Changes by Xiang Zhang <angwerzx at 126.com>:


----------
resolution:  -> third party
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29064>
_______________________________________

From report at bugs.python.org  Sat Dec 24 11:28:21 2016
From: report at bugs.python.org (Patrik Iselind)
Date: Sat, 24 Dec 2016 16:28:21 +0000
Subject: [issue29048] Coverage influence tests, make some of them fail
In-Reply-To: <CANzOjBjPGmbTehP4qsapPXwqfKb4tT4e19Qc3JA0mfEVH+VaGw@mail.gmail.com>
Message-ID: <CANzOjBhuQana_FdAu0Aq=w5pbJ+-w9w-ya4nDyeuNgcv40vg_g@mail.gmail.com>


Patrik Iselind added the comment:

report doesn't contain any text when run under coverage. something made the
text not appear...

Patrik

Den 24 dec 2016 16:39 skrev "Patrik Iselind" <report at bugs.python.org>:

>
> Patrik Iselind added the comment:
>
> i use the latest code. perhaps something for introduced after 3.6?
>
> Patrik
>
> Den 24 dec 2016 13:51 skrev "Ned Batchelder" <report at bugs.python.org>:
>
> >
> > Ned Batchelder added the comment:
> >
> > I doubt very very much that coverage.py is stealing stderr.  Many many
> > test suites would have this problem if that were true.  More likely is
> that
> > somehow __del__ is not being invoked when you need it to be.
> >
> > I tried running the tests under coverage also, and did not see this
> > behavior. I don't have a build tree of the latest code, but I ran it on
> > 3.6.0.  The tests passed both with and without coverage measurement
> (output
> > below).  I would like to understand why you are seeing the results you
> are.
> >
> > $ mkvirtualenv -p python3.6 issue29048
> > Running virtualenv with interpreter /usr/local/bin/python3.6
> > Using base prefix '/usr/local/pythonz/pythons/CPython-3.6.0'
> > New python executable in issue29048/bin/python3.6
> > Also creating executable in issue29048/bin/python
> > Installing setuptools, pip, wheel...done.
> > Collecting pip
> >   Using cached pip-9.0.1-py2.py3-none-any.whl
> > Collecting setuptools
> >   Using cached setuptools-32.2.0-py2.py3-none-any.whl
> > Installing collected packages: pip, setuptools
> >   Found existing installation: pip 7.1.2
> >     Uninstalling pip-7.1.2:
> >       Successfully uninstalled pip-7.1.2
> >   Found existing installation: setuptools 18.2
> >     Uninstalling setuptools-18.2:
> >       Successfully uninstalled setuptools-18.2
> > Successfully installed pip-9.0.1 setuptools-32.2.0
> > (issue29048)$ pip install coverage
> > Collecting coverage
> > Installing collected packages: coverage
> > Successfully installed coverage-4.2
> > (issue29048)$ python3.6 -m test -v test_exceptions
> > == CPython 3.6.0 (default, Dec 23 2016, 07:11:25) [GCC 4.2.1 Compatible
> > Apple LLVM 7.0.2 (clang-700.1.81)]
> > ==   Darwin-14.5.0-x86_64-i386-64bit little-endian
> > ==   hash algorithm: siphash24 64bit
> > ==  cwd: /private/var/folders/j2/gr3cj3jn63s5q8g3bjvw57hm0000gp
> > /T/test_python_20266
> > ==  encodings: locale=UTF-8, FS=utf-8
> > Testing with flags: sys.flags(debug=0, inspect=0, interactive=0,
> > optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0,
> > ignore_environment=0, verbose=0, bytes_warning=0, quiet=0,
> > hash_randomization=1, isolated=0)
> > Run tests sequentially
> > 0:00:00 [1/1] test_exceptions
> > testAttributes (test.test_exceptions.ExceptionTests) ... ok
> > testChainingAttrs (test.test_exceptions.ExceptionTests) ... ok
> > testChainingDescriptors (test.test_exceptions.ExceptionTests) ... ok
> > testExceptionCleanupNames (test.test_exceptions.ExceptionTests) ... ok
> > testExceptionCleanupState (test.test_exceptions.ExceptionTests) ... ok
> > testInfiniteRecursion (test.test_exceptions.ExceptionTests) ... ok
> > testInvalidAttrs (test.test_exceptions.ExceptionTests) ... ok
> > testInvalidTraceback (test.test_exceptions.ExceptionTests) ... ok
> > testKeywordArgs (test.test_exceptions.ExceptionTests) ... ok
> > testNoneClearsTracebackAttr (test.test_exceptions.ExceptionTests) ... ok
> > testRaising (test.test_exceptions.ExceptionTests) ... ok
> > testSettingException (test.test_exceptions.ExceptionTests) ... ok
> > testSyntaxErrorMessage (test.test_exceptions.ExceptionTests) ... ok
> > testSyntaxErrorOffset (test.test_exceptions.ExceptionTests) ... ok
> > testWithTraceback (test.test_exceptions.ExceptionTests) ... ok
> > test_3114 (test.test_exceptions.ExceptionTests) ... ok
> > test_MemoryError (test.test_exceptions.ExceptionTests) ... ok
> > test_WindowsError (test.test_exceptions.ExceptionTests) ... ok
> > test_badisinstance (test.test_exceptions.ExceptionTests) ... ok
> > test_errno_ENOTDIR (test.test_exceptions.ExceptionTests) ... ok
> > test_exception_target_in_nested_scope (test.test_exceptions.
> ExceptionTests)
> > ... ok
> > test_exception_with_doc (test.test_exceptions.ExceptionTests) ... ok
> > test_generator_close_cleanup_exc_state (test.test_exceptions.
> ExceptionTests)
> > ... ok
> > test_generator_del_cleanup_exc_state (test.test_exceptions.
> ExceptionTests)
> > ... ok
> > test_generator_doesnt_retain_old_exc (test.test_exceptions.
> ExceptionTests)
> > ... ok
> > test_generator_finalizing_and_exc_info (test.test_exceptions.
> ExceptionTests)
> > ... ok
> > test_generator_leaking (test.test_exceptions.ExceptionTests) ... ok
> > test_generator_leaking2 (test.test_exceptions.ExceptionTests) ... ok
> > test_generator_leaking3 (test.test_exceptions.ExceptionTests) ... ok
> > test_generator_leaking4 (test.test_exceptions.ExceptionTests) ... ok
> > test_generator_next_cleanup_exc_state (test.test_exceptions.
> ExceptionTests)
> > ... ok
> > test_generator_send_cleanup_exc_state (test.test_exceptions.
> ExceptionTests)
> > ... ok
> > test_generator_throw_cleanup_exc_state (test.test_exceptions.
> ExceptionTests)
> > ... ok
> > test_memory_error_cleanup (test.test_exceptions.ExceptionTests) ... ok
> > test_recursion_error_cleanup (test.test_exceptions.ExceptionTests) ...
> ok
> > test_str (test.test_exceptions.ExceptionTests) ... ok
> > test_unhandled (test.test_exceptions.ExceptionTests) ... ok
> > test_unicode_change_attributes (test.test_exceptions.ExceptionTests) ...
> > ok
> > test_unicode_errors_no_object (test.test_exceptions.ExceptionTests) ...
> ok
> > test_unraisable (test.test_exceptions.ExceptionTests) ... ok
> > test_windows_message (test.test_exceptions.ExceptionTests)
> > Should fill in unknown error code in Windows error message ... skipped
> > 'test specific to Windows'
> > test_attributes (test.test_exceptions.ImportErrorTests) ... ok
> > test_non_str_argument (test.test_exceptions.ImportErrorTests) ... ok
> >
> > ----------------------------------------------------------------------
> > Ran 43 tests in 0.027s
> >
> > OK (skipped=1)
> > 1 test OK.
> >
> > Total duration: 64 ms
> > Tests result: SUCCESS
> > (issue29048)$ python -m coverage run --pylib -m test -v test_exceptions
> > == CPython 3.6.0 (default, Dec 23 2016, 07:11:25) [GCC 4.2.1 Compatible
> > Apple LLVM 7.0.2 (clang-700.1.81)]
> > ==   Darwin-14.5.0-x86_64-i386-64bit little-endian
> > ==   hash algorithm: siphash24 64bit
> > ==  cwd: /private/var/folders/j2/gr3cj3jn63s5q8g3bjvw57hm0000gp
> > /T/test_python_20270
> > ==  encodings: locale=UTF-8, FS=utf-8
> > Testing with flags: sys.flags(debug=0, inspect=0, interactive=0,
> > optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0,
> > ignore_environment=0, verbose=0, bytes_warning=0, quiet=0,
> > hash_randomization=1, isolated=0)
> > Run tests sequentially
> > 0:00:00 [1/1] test_exceptions
> > testAttributes (test.test_exceptions.ExceptionTests) ... ok
> > testChainingAttrs (test.test_exceptions.ExceptionTests) ... ok
> > testChainingDescriptors (test.test_exceptions.ExceptionTests) ... ok
> > testExceptionCleanupNames (test.test_exceptions.ExceptionTests) ... ok
> > testExceptionCleanupState (test.test_exceptions.ExceptionTests) ... ok
> > testInfiniteRecursion (test.test_exceptions.ExceptionTests) ... ok
> > testInvalidAttrs (test.test_exceptions.ExceptionTests) ... ok
> > testInvalidTraceback (test.test_exceptions.ExceptionTests) ... ok
> > testKeywordArgs (test.test_exceptions.ExceptionTests) ... ok
> > testNoneClearsTracebackAttr (test.test_exceptions.ExceptionTests) ... ok
> > testRaising (test.test_exceptions.ExceptionTests) ... ok
> > testSettingException (test.test_exceptions.ExceptionTests) ... ok
> > testSyntaxErrorMessage (test.test_exceptions.ExceptionTests) ... ok
> > testSyntaxErrorOffset (test.test_exceptions.ExceptionTests) ... ok
> > testWithTraceback (test.test_exceptions.ExceptionTests) ... ok
> > test_3114 (test.test_exceptions.ExceptionTests) ... ok
> > test_MemoryError (test.test_exceptions.ExceptionTests) ... ok
> > test_WindowsError (test.test_exceptions.ExceptionTests) ... ok
> > test_badisinstance (test.test_exceptions.ExceptionTests) ... ok
> > test_errno_ENOTDIR (test.test_exceptions.ExceptionTests) ... ok
> > test_exception_target_in_nested_scope (test.test_exceptions.
> ExceptionTests)
> > ... ok
> > test_exception_with_doc (test.test_exceptions.ExceptionTests) ... ok
> > test_generator_close_cleanup_exc_state (test.test_exceptions.
> ExceptionTests)
> > ... ok
> > test_generator_del_cleanup_exc_state (test.test_exceptions.
> ExceptionTests)
> > ... ok
> > test_generator_doesnt_retain_old_exc (test.test_exceptions.
> ExceptionTests)
> > ... ok
> > test_generator_finalizing_and_exc_info (test.test_exceptions.
> ExceptionTests)
> > ... ok
> > test_generator_leaking (test.test_exceptions.ExceptionTests) ... ok
> > test_generator_leaking2 (test.test_exceptions.ExceptionTests) ... ok
> > test_generator_leaking3 (test.test_exceptions.ExceptionTests) ... ok
> > test_generator_leaking4 (test.test_exceptions.ExceptionTests) ... ok
> > test_generator_next_cleanup_exc_state (test.test_exceptions.
> ExceptionTests)
> > ... ok
> > test_generator_send_cleanup_exc_state (test.test_exceptions.
> ExceptionTests)
> > ... ok
> > test_generator_throw_cleanup_exc_state (test.test_exceptions.
> ExceptionTests)
> > ... ok
> > test_memory_error_cleanup (test.test_exceptions.ExceptionTests) ... ok
> > test_recursion_error_cleanup (test.test_exceptions.ExceptionTests) ...
> ok
> > test_str (test.test_exceptions.ExceptionTests) ... ok
> > test_unhandled (test.test_exceptions.ExceptionTests) ... ok
> > test_unicode_change_attributes (test.test_exceptions.ExceptionTests) ...
> > ok
> > test_unicode_errors_no_object (test.test_exceptions.ExceptionTests) ...
> ok
> > test_unraisable (test.test_exceptions.ExceptionTests) ... ok
> > test_windows_message (test.test_exceptions.ExceptionTests)
> > Should fill in unknown error code in Windows error message ... skipped
> > 'test specific to Windows'
> > test_attributes (test.test_exceptions.ImportErrorTests) ... ok
> > test_non_str_argument (test.test_exceptions.ImportErrorTests) ... ok
> >
> > ----------------------------------------------------------------------
> > Ran 43 tests in 0.036s
> >
> > OK (skipped=1)
> > 1 test OK.
> >
> > Total duration: 95 ms
> > Tests result: SUCCESS
> > (issue29048)$ python -m coverage report
> > Name
> >                  Stmts   Miss  Cover
> > ------------------------------------------------------------
> > --------------------------------------------------
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/_bootlocale.py
> >                      17     13    24%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/_
> collections_abc.py
> >                  562    546     3%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/_osx_support.py
> >                    210    161    23%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/_
> > sysconfigdata_m_darwin_darwin.py       1      0   100%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/_weakrefset.py
> >                     146    109    25%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/abc.py
> >                      92     65    29%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/argparse.py
> >                   1187    757    36%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/base64.py
> >                    315    268    15%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/codecs.py
> >                    398    377     5%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/
> collections/__init__.py
> >              677    650     4%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/contextlib.py
> >                    163    140    14%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/difflib.py
> >                     669    606     9%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/email/__init__.py
> >                     14      8    43%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/
> email/base64mime.py
> >                   40     26    35%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/email/charset.py
> >                     122     78    36%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/email/encoders.py
> >                     28     19    32%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/email/errors.py
> >                     37      7    81%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/email/header.py
> >                    310    258    17%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/
> email/quoprimime.py
> >                  115     83    28%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/
> encodings/__init__.py
> >                 76     43    43%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/
> encodings/latin_1.py
> >                  19     18     5%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/enum.py
> >                    438    248    43%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/functools.py
> >                     443    421     5%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/genericpath.py
> >                      72     50    31%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/gettext.py
> >                     389    323    17%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/gzip.py
> >                    349    298    15%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/
> importlib/__init__.py
> >                 99     96     3%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/
> importlib/_bootstrap.py
> >              631    445    29%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/
> > importlib/_bootstrap_external.py      711    528    26%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/importlib/util.py
> >                    147    140     5%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/ipaddress.py
> >                     904    597    34%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/linecache.py
> >                     102     55    46%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/locale.py
> >                    399    357    11%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/
> logging/__init__.py
> >                  769    521    32%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/
> logging/handlers.py
> >                  663    534    19%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/lzma.py
> >                    135    130     4%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/
> multiprocessing/process.py
> >           163    162     1%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/nntplib.py
> >                     559    457    18%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/os.py
> >                    536    489     9%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/platform.py
> >                    580    466    20%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/posixpath.py
> >                     320    222    31%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/pprint.py
> >                    419    351    16%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/queue.py
> >                     111     76    32%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/quopri.py
> >                    168    150    11%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/random.py
> >                    346    329     5%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/re.py
> >                    153    125    18%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/shutil.py
> >                    619    600     3%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/socket.py
> >                    403    396     2%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/sre_compile.py
> >                     401    151    62%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/sre_parse.py
> >                     758    460    39%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/ssl.py
> >                     571    426    25%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/string.py
> >                    153    114    25%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/subprocess.py
> >                    794    671    15%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/sysconfig.py
> >                     376    246    35%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/tempfile.py
> >                    395    258    35%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/test/__init__.py
> >                       0      0   100%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/test/__main__.py
> >                       2      0   100%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/
> test/libregrtest/__init__.py
> >           3      0   100%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/
> test/libregrtest/cmdline.py
> >          127     52    59%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/
> test/libregrtest/main.py
> >             335    163    51%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/
> test/libregrtest/refleak.py
> >          186    122    34%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/
> test/libregrtest/runtest.py
> >          146     62    58%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/
> test/libregrtest/save_env.py
> >         189     68    64%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/
> test/libregrtest/setup.py
> >             68     21    69%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/
> test/support/__init__.py
> >            1289    902    30%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/
> test/test_exceptions.py
> >              765     93    88%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/threading.py
> >                     575    572     1%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/tokenize.py
> >                    473    438     7%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/traceback.py
> >                     247    185    25%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/types.py
> >                     155    152     2%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/
> unittest/__init__.py
> >                  15      3    80%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/unittest/case.py
> >                     753    413    45%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/
> unittest/loader.py
> >                   295    226    23%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/unittest/main.py
> >                     149    122    18%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/
> unittest/result.py
> >                   128     66    48%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/
> unittest/runner.py
> >                   159     51    68%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/
> unittest/signals.py
> >                   47     33    30%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/unittest/suite.py
> >                    220     81    63%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/unittest/util.py
> >                     130    107    18%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/
> urllib/__init__.py
> >                     0      0   100%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/urllib/error.py
> >                     34     19    44%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/
> urllib/response.py
> >                    43     26    40%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/warnings.py
> >                    331    300     9%
> > /usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/weakref.py
> >                     379    342    10%
> > ------------------------------------------------------------
> > --------------------------------------------------
> > TOTAL
> >                 26517  19743    26%
> > (issue29048)$
> >
> > ----------
> >
> > _______________________________________
> > Python tracker <report at bugs.python.org>
> > <http://bugs.python.org/issue29048>
> > _______________________________________
> >
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue29048>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29048>
_______________________________________

From report at bugs.python.org  Sat Dec 24 11:37:31 2016
From: report at bugs.python.org (Ned Batchelder)
Date: Sat, 24 Dec 2016 16:37:31 +0000
Subject: [issue29048] Coverage influence tests, make some of them fail
In-Reply-To: <1482407776.18.0.223230024277.issue29048@psf.upfronthosting.co.za>
Message-ID: <1482597451.35.0.268950741049.issue29048@psf.upfronthosting.co.za>


Ned Batchelder added the comment:

Are you sure the code that tried to print to stderr was even run? It's in a __del__ method, which is notorious for being affected by surprising things.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29048>
_______________________________________

From report at bugs.python.org  Sat Dec 24 11:40:54 2016
From: report at bugs.python.org (Patrik Iselind)
Date: Sat, 24 Dec 2016 16:40:54 +0000
Subject: [issue29048] Coverage influence tests, make some of them fail
In-Reply-To: <1482597451.35.0.268950741049.issue29048@psf.upfronthosting.co.za>
Message-ID: <CANzOjBgoAwPS_MK_ndvFhsqYb_AdjTiz+Lt9SoB9BY1z173onA@mail.gmail.com>


Patrik Iselind added the comment:

yes, I'm sure. i printed markings around where the text should have been.

Patrik

Den 24 dec 2016 17:37 skrev "Ned Batchelder" <report at bugs.python.org>:

>
> Ned Batchelder added the comment:
>
> Are you sure the code that tried to print to stderr was even run? It's in
> a __del__ method, which is notorious for being affected by surprising
> things.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue29048>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29048>
_______________________________________

From report at bugs.python.org  Sat Dec 24 11:59:08 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 24 Dec 2016 16:59:08 +0000
Subject: [issue13886] readline-related test_builtin failure
In-Reply-To: <1327659819.71.0.475160045664.issue13886@psf.upfronthosting.co.za>
Message-ID: <1482598748.08.0.4421202294.issue13886@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Thanks for waiting for a run of the patch on Android.
Indeed, test_input_tty_non_ascii fails with this patch on Android when LANG is not set and is ok when LANG=en_US.UTF-8. As you are suggesting, the test is ok when skipping the Readline half of the test. This may be done by adding 'is_android' in the 'from test.support import ...' statement and updating the test with:

    if readline and not is_android:
        tests.append(True)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13886>
_______________________________________

From report at bugs.python.org  Sat Dec 24 12:09:47 2016
From: report at bugs.python.org (Patrik Iselind)
Date: Sat, 24 Dec 2016 17:09:47 +0000
Subject: [issue29048] Coverage influence tests, make some of them fail
In-Reply-To: <1482407776.18.0.223230024277.issue29048@psf.upfronthosting.co.za>
Message-ID: <1482599387.54.0.831450908856.issue29048@psf.upfronthosting.co.za>


Patrik Iselind added the comment:

For clarity, this is what i get in the test_exceptions test when i've applied the attached diff.

$ ./python -m test -v test_exceptions
== CPython 3.7.0a0 (default:8e311f109b22, Dec 24 2016, 12:26:43) [GCC 5.4.0 20160609]
==   Linux-4.4.0-53-generic-x86_64-with-debian-stretch-sid little-endian
==   hash algorithm: siphash24 64bit
==  cwd: /home/irina/patrik/cpython/build/test_python_19104
==  encodings: locale=UTF-8, FS=utf-8
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0)
Run tests sequentially
0:00:00 [1/1] test_exceptions
testAttributes (test.test_exceptions.ExceptionTests) ... ok
testChainingAttrs (test.test_exceptions.ExceptionTests) ... ok
testChainingDescriptors (test.test_exceptions.ExceptionTests) ... ok
testExceptionCleanupNames (test.test_exceptions.ExceptionTests) ... ok
testExceptionCleanupState (test.test_exceptions.ExceptionTests) ... ok
testInfiniteRecursion (test.test_exceptions.ExceptionTests) ... ok
testInvalidAttrs (test.test_exceptions.ExceptionTests) ... ok
testInvalidTraceback (test.test_exceptions.ExceptionTests) ... ok
testKeywordArgs (test.test_exceptions.ExceptionTests) ... ok
testNoneClearsTracebackAttr (test.test_exceptions.ExceptionTests) ... ok
testRaising (test.test_exceptions.ExceptionTests) ... ok
testSettingException (test.test_exceptions.ExceptionTests) ... ok
testSyntaxErrorMessage (test.test_exceptions.ExceptionTests) ... ok
testSyntaxErrorOffset (test.test_exceptions.ExceptionTests) ... ok
testWithTraceback (test.test_exceptions.ExceptionTests) ... ok
test_3114 (test.test_exceptions.ExceptionTests) ... ok
test_MemoryError (test.test_exceptions.ExceptionTests) ... ok
test_WindowsError (test.test_exceptions.ExceptionTests) ... ok
test_badisinstance (test.test_exceptions.ExceptionTests) ... ok
test_errno_ENOTDIR (test.test_exceptions.ExceptionTests) ... ok
test_exception_target_in_nested_scope (test.test_exceptions.ExceptionTests) ... ok
test_exception_with_doc (test.test_exceptions.ExceptionTests) ... ok
test_generator_close_cleanup_exc_state (test.test_exceptions.ExceptionTests) ... ok
test_generator_del_cleanup_exc_state (test.test_exceptions.ExceptionTests) ... ok
test_generator_doesnt_retain_old_exc (test.test_exceptions.ExceptionTests) ... ok
test_generator_finalizing_and_exc_info (test.test_exceptions.ExceptionTests) ... ok
test_generator_leaking (test.test_exceptions.ExceptionTests) ... ok
test_generator_leaking2 (test.test_exceptions.ExceptionTests) ... ok
test_generator_leaking3 (test.test_exceptions.ExceptionTests) ... ok
test_generator_leaking4 (test.test_exceptions.ExceptionTests) ... ok
test_generator_next_cleanup_exc_state (test.test_exceptions.ExceptionTests) ... ok
test_generator_send_cleanup_exc_state (test.test_exceptions.ExceptionTests) ... ok
test_generator_throw_cleanup_exc_state (test.test_exceptions.ExceptionTests) ... ok
test_memory_error_cleanup (test.test_exceptions.ExceptionTests) ... ok
test_recursion_error_cleanup (test.test_exceptions.ExceptionTests) ... ok
test_str (test.test_exceptions.ExceptionTests) ... ok
test_unhandled (test.test_exceptions.ExceptionTests) ... ok
test_unicode_change_attributes (test.test_exceptions.ExceptionTests) ... ok
test_unicode_errors_no_object (test.test_exceptions.ExceptionTests) ... ok
test_unraisable (test.test_exceptions.ExceptionTests) ... BEGINBEGINBEGINBEGINBEGIN
Exception ignored in: <bound method ExceptionTests.test_unraisable.<locals>.BrokenDel.__del__ of <test.test_exceptions.ExceptionTests.test_unraisable.<locals>.BrokenDel object at 0x7f4313a41ef8>>
Traceback (most recent call last):
  File "/home/irina/patrik/cpython/Lib/test/test_exceptions.py", line 1024, in __del__
    raise exc
ValueError: del is broken

ENDENDENDENDENDENDENDEND
BEGINBEGINBEGINBEGINBEGIN
Exception ignored in: <object repr() failed>
Traceback (most recent call last):
  File "/home/irina/patrik/cpython/Lib/test/test_exceptions.py", line 1024, in __del__
    raise exc
ValueError: del is broken

ENDENDENDENDENDENDENDEND
BEGINBEGINBEGINBEGINBEGIN
Exception ignored in: <bound method ExceptionTests.test_unraisable.<locals>.BrokenExceptionDel.__del__ of <test.test_exceptions.ExceptionTests.test_unraisable.<locals>.BrokenExceptionDel object at 0x7f4313a41ef8>>
Traceback (most recent call last):
  File "/home/irina/patrik/cpython/Lib/test/test_exceptions.py", line 1034, in __del__
    raise exc
test.test_exceptions.BrokenStrException: <exception str() failed>

ENDENDENDENDENDENDENDEND
ok
test_windows_message (test.test_exceptions.ExceptionTests)
Should fill in unknown error code in Windows error message ... skipped 'test specific to Windows'
test_attributes (test.test_exceptions.ImportErrorTests) ... ok
test_non_str_argument (test.test_exceptions.ImportErrorTests) ... ok
test_reset_attributes (test.test_exceptions.ImportErrorTests) ... ok

----------------------------------------------------------------------
Ran 44 tests in 0.158s

OK (skipped=1)
1 test OK.

Total duration: 363 ms
Tests result: SUCCESS




$ ./python ../coveragepy run --pylib --source=exceptions Lib/test/regrtest.py test_exceptions
Run tests sequentially
0:00:00 [1/1] test_exceptions
Exception ignored in: <bound method ExceptionTests.test_unraisable.<locals>.BrokenDel.__del__ of <test.test_exceptions.ExceptionTests.test_unraisable.<locals>.BrokenDel object at 0x7f1c67de69b0>>
Traceback (most recent call last):
  File "/home/irina/patrik/cpython/Lib/test/test_exceptions.py", line 1024, in __del__
    raise exc
ValueError: del is broken
BEGINBEGINBEGINBEGINBEGIN

ENDENDENDENDENDENDENDEND
Exception ignored in: <object repr() failed>
Traceback (most recent call last):
  File "/home/irina/patrik/cpython/Lib/test/test_exceptions.py", line 1024, in __del__
    raise exc
ValueError: del is broken
BEGINBEGINBEGINBEGINBEGIN

ENDENDENDENDENDENDENDEND
Exception ignored in: <bound method ExceptionTests.test_unraisable.<locals>.BrokenExceptionDel.__del__ of <test.test_exceptions.ExceptionTests.test_unraisable.<locals>.BrokenExceptionDel object at 0x7f1c67de6f60>>
Traceback (most recent call last):
  File "/home/irina/patrik/cpython/Lib/test/test_exceptions.py", line 1034, in __del__
    raise exc
test.test_exceptions.BrokenStrException: <exception str() failed>
BEGINBEGINBEGINBEGINBEGIN

ENDENDENDENDENDENDENDEND
test test_exceptions failed -- multiple errors occurred; run in verbose mode for details
test_exceptions failed

1 test failed:
    test_exceptions

Total duration: 1 sec
Tests result: FAILURE
Coverage.py warning: Module exceptions was never imported.
Coverage.py warning: No data was collected.



Somehow stuff is no longer ending up in stderr. That empty line is most likely the report that get printed when its value is "".

----------
Added file: http://bugs.python.org/file46025/no-stderr.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29048>
_______________________________________

From report at bugs.python.org  Sat Dec 24 12:13:29 2016
From: report at bugs.python.org (Patrik Iselind)
Date: Sat, 24 Dec 2016 17:13:29 +0000
Subject: [issue29048] Coverage influence tests, make some of them fail
In-Reply-To: <1482407776.18.0.223230024277.issue29048@psf.upfronthosting.co.za>
Message-ID: <1482599609.66.0.00578397484847.issue29048@psf.upfronthosting.co.za>


Patrik Iselind added the comment:

I'd like to clarify that the file i just attached, no-stderr.diff, is in no way a suggestion for a fix. It's just my way of conveying what i see.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29048>
_______________________________________

From report at bugs.python.org  Sat Dec 24 12:34:07 2016
From: report at bugs.python.org (Patrik Iselind)
Date: Sat, 24 Dec 2016 17:34:07 +0000
Subject: [issue1116520] Prefix search is filesystem-centric
Message-ID: <1482600847.43.0.122381400467.issue1116520@psf.upfronthosting.co.za>


Patrik Iselind added the comment:

How much smaller would the stdlib for 3.5 become if you compress it with zip?

----------
nosy: +patriki

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1116520>
_______________________________________

From report at bugs.python.org  Sat Dec 24 12:50:38 2016
From: report at bugs.python.org (Patrik Iselind)
Date: Sat, 24 Dec 2016 17:50:38 +0000
Subject: [issue1116520] Prefix search is filesystem-centric
In-Reply-To: <1482600847.43.0.122381400467.issue1116520@psf.upfronthosting.co.za>
Message-ID: <CANzOjBh1b_EBRF27Hd6g7ob1i31koM+WTzg40SmRMBht=BbAHg@mail.gmail.com>


Patrik Iselind added the comment:

What about the performance penalty for zipping stdlib? is it significant?

When would you like to zip stdlib? For embedded systems with limited disk
space?

Patrik Iselind

On Sat, Dec 24, 2016 at 6:34 PM, Patrik Iselind <report at bugs.python.org>
wrote:

>
> Patrik Iselind added the comment:
>
> How much smaller would the stdlib for 3.5 become if you compress it with
> zip?
>
> ----------
> nosy: +patriki
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue1116520>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1116520>
_______________________________________

From report at bugs.python.org  Sat Dec 24 12:56:32 2016
From: report at bugs.python.org (Patrik Iselind)
Date: Sat, 24 Dec 2016 17:56:32 +0000
Subject: [issue29047] Where are the test results stored?
In-Reply-To: <1482403473.61.0.626919341446.issue29047@psf.upfronthosting.co.za>
Message-ID: <1482602192.88.0.0846650585403.issue29047@psf.upfronthosting.co.za>


Patrik Iselind added the comment:

My GitHub PR got closed. So closing this issue as well.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29047>
_______________________________________

From report at bugs.python.org  Sat Dec 24 13:01:24 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 24 Dec 2016 18:01:24 +0000
Subject: [issue29047] Where are the test results stored?
In-Reply-To: <1482403473.61.0.626919341446.issue29047@psf.upfronthosting.co.za>
Message-ID: <1482602484.39.0.0304003542857.issue29047@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
stage:  -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29047>
_______________________________________

From report at bugs.python.org  Sat Dec 24 13:01:36 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 24 Dec 2016 18:01:36 +0000
Subject: [issue29047] Where are the test results stored?
In-Reply-To: <1482403473.61.0.626919341446.issue29047@psf.upfronthosting.co.za>
Message-ID: <1482602496.25.0.651466095114.issue29047@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
versions:  -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29047>
_______________________________________

From report at bugs.python.org  Sat Dec 24 13:14:41 2016
From: report at bugs.python.org (Ned Batchelder)
Date: Sat, 24 Dec 2016 18:14:41 +0000
Subject: [issue29048] Coverage influence tests, make some of them fail
In-Reply-To: <1482407776.18.0.223230024277.issue29048@psf.upfronthosting.co.za>
Message-ID: <1482603281.72.0.1722688184.issue29048@psf.upfronthosting.co.za>


Ned Batchelder added the comment:

Can you show the output of "coverage debug sys"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29048>
_______________________________________

From report at bugs.python.org  Sat Dec 24 13:25:33 2016
From: report at bugs.python.org (Patrik Iselind)
Date: Sat, 24 Dec 2016 18:25:33 +0000
Subject: [issue29048] Coverage influence tests, make some of them fail
In-Reply-To: <1482407776.18.0.223230024277.issue29048@psf.upfronthosting.co.za>
Message-ID: <1482603933.15.0.614373009486.issue29048@psf.upfronthosting.co.za>


Patrik Iselind added the comment:

Sure, here you go.

$ ./python ../coveragepy debug sys
-- sys -------------------------------------------------------
              version: 4.3a0
             coverage: ../coveragepy/coverage/__init__.py
           cover_dirs: /home/irina/patrik/coveragepy/coverage
           pylib_dirs: /home/irina/patrik/cpython/Lib
               tracer: PyTracer
 plugins.file_tracers: -none-
         config_files: .coveragerc
                       setup.cfg
                       tox.ini
         configs_read: -none-
            data_path: /home/irina/patrik/cpython/.coverage
               python: 3.7.0a0 (default:7ceacac48cd2+, Dec 24 2016, 19:08:24) [GCC 5.4.0 20160609]
             platform: Linux-4.4.0-53-generic-x86_64-with-debian-stretch-sid
       implementation: CPython
           executable: /home/irina/patrik/cpython/python
                  cwd: /home/irina/patrik/cpython
                 path: 
                       /usr/local/lib/python37.zip
                       /home/irina/patrik/cpython/Lib
                       /home/irina/patrik/cpython/build/lib.linux-x86_64-3.7
          environment: -none-
         command_line: ../coveragepy/coverage/__main__.py debug sys
         source_match: -none-
    source_pkgs_match: -none-
        include_match: -none-
           omit_match: -none-
          cover_match: /home/irina/patrik/coveragepy/coverage
          pylib_match: /home/irina/patrik/cpython/Lib

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29048>
_______________________________________

From report at bugs.python.org  Sat Dec 24 13:39:57 2016
From: report at bugs.python.org (Patrik Iselind)
Date: Sat, 24 Dec 2016 18:39:57 +0000
Subject: [issue29048] Coverage influence tests, make some of them fail
In-Reply-To: <1482407776.18.0.223230024277.issue29048@psf.upfronthosting.co.za>
Message-ID: <1482604797.69.0.365098938069.issue29048@psf.upfronthosting.co.za>


Patrik Iselind added the comment:

@nedbat, do you know of a revision where coverage doesn't influence the tests? If so, which one? Perhaps i can perform a bisect search to find when this went bad.

I'm testing the latest tip/head. So that's one part of the bisect.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29048>
_______________________________________

From report at bugs.python.org  Sat Dec 24 14:26:47 2016
From: report at bugs.python.org (Ned Batchelder)
Date: Sat, 24 Dec 2016 19:26:47 +0000
Subject: [issue29048] Coverage influence tests, make some of them fail
In-Reply-To: <1482407776.18.0.223230024277.issue29048@psf.upfronthosting.co.za>
Message-ID: <1482607607.87.0.402992891785.issue29048@psf.upfronthosting.co.za>


Ned Batchelder added the comment:

I don't believe this is coverage.py's fault, so I don't have an answer to your question.  There is no revision of coverage.py that *does* swallow stderr.  Also, as you can see from the test output, it isn't swallowed, it's not being captured where it should be captured, but it is appearing on the terminal.  I see more than 60 uses of captured_stderr in the Python test suite. If coverage.py were swallowing stderr, I would expect dozens of test failures.  The problem is more subtle.

If you want, you can bisect against any revision of coverage.py you like, perhaps the released 4.2?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29048>
_______________________________________

From report at bugs.python.org  Sat Dec 24 14:32:13 2016
From: report at bugs.python.org (Patrik Iselind)
Date: Sat, 24 Dec 2016 19:32:13 +0000
Subject: [issue29048] Coverage influence tests, make some of them fail
In-Reply-To: <1482607607.87.0.402992891785.issue29048@psf.upfronthosting.co.za>
Message-ID: <CANzOjBh478DoXYne5kjsHHjrjLow0K1Fg-ZfQb37F6c7KDE2EQ@mail.gmail.com>


Patrik Iselind added the comment:

OK, for now. Let's disregard my idea that stderr is swallowed. At some
point these test might have worked under coverage.

I was more thinking to bisect cpython. Perhaps i can find a revision that
works.

Patrik

Den 24 dec 2016 20:26 skrev "Ned Batchelder" <report at bugs.python.org>:

>
> Ned Batchelder added the comment:
>
> I don't believe this is coverage.py's fault, so I don't have an answer to
> your question.  There is no revision of coverage.py that *does* swallow
> stderr.  Also, as you can see from the test output, it isn't swallowed,
> it's not being captured where it should be captured, but it is appearing on
> the terminal.  I see more than 60 uses of captured_stderr in the Python
> test suite. If coverage.py were swallowing stderr, I would expect dozens of
> test failures.  The problem is more subtle.
>
> If you want, you can bisect against any revision of coverage.py you like,
> perhaps the released 4.2?
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue29048>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29048>
_______________________________________

From report at bugs.python.org  Sat Dec 24 15:49:59 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 24 Dec 2016 20:49:59 +0000
Subject: [issue23903] Generate PC/python3.def by scraping headers
In-Reply-To: <1428637761.13.0.348463350169.issue23903@psf.upfronthosting.co.za>
Message-ID: <1482612599.12.0.374520776613.issue23903@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a shell script that uses the C preprocessor and other Unix tools to generate PC/python3.def. It doesn't add PyAST_* and PyNode_* functions and doesn't remove PyArg_VaParse* functions. But it still removes some names that are no longer used in public interface, but should be kept in the stable ABI for compatibility. E.g. PyCFunction_New (now it is a macro expanded to PyCFunction_NewEx) or _PyTrash_deposit_object (invoked by the macros before 3.2.4). It seems to me that this is unavoidable, and the resulting file must be manually edited.

----------
dependencies: +Mark new limited C API
Added file: http://bugs.python.org/file46026/genpython3def.sh

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23903>
_______________________________________

From report at bugs.python.org  Sat Dec 24 16:24:13 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 24 Dec 2016 21:24:13 +0000
Subject: [issue23903] Generate PC/python3.def by scraping headers
In-Reply-To: <1428637761.13.0.348463350169.issue23903@psf.upfronthosting.co.za>
Message-ID: <1482614653.33.0.45292717429.issue23903@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Following patch against 3.6 just adds new names to PC/python3.def. The only removed names are PyExc_MemoryErrorInst and PyUnicode_SetDefaultEncoding. They don't exist in 3.x.

----------
Added file: http://bugs.python.org/file46027/python3def-3.6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23903>
_______________________________________

From report at bugs.python.org  Sat Dec 24 16:34:18 2016
From: report at bugs.python.org (Daz)
Date: Sat, 24 Dec 2016 21:34:18 +0000
Subject: [issue29060] Changing the installation location still adds AppData
 filepaths that do not exist to the path variable on Windows 10
In-Reply-To: <1482557320.46.0.0439149455912.issue29060@psf.upfronthosting.co.za>
Message-ID: <CAM33J2AjSEbTpmLSRsZRyha_GUOs2L6zG3RoPRSN08bcVghxZQ@mail.gmail.com>


Daz added the comment:

You're right. It was the launcher I was viewing. On the first page, I
unchecked installing the launcher for all users. Thanks for pointing out
that distinction.

Happy holidays.

On Dec 24, 2016 12:28 AM, "Steve Dower" <report at bugs.python.org> wrote:

>
> Steve Dower added the comment:
>
> You should have a set of log files in your %TEMP% directory. Could you zip
> them up and attach to this issue? That should show whether the installer
> got confused about something.
>
> Note that if you install the launcher but not for all users (the other
> check box on the first page) you can't actually reconfigure where it
> installs to, and it will be put on PATH, so you may be seeing that.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue29060>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29060>
_______________________________________

From report at bugs.python.org  Sat Dec 24 17:10:34 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 24 Dec 2016 22:10:34 +0000
Subject: [issue29049] Lazy GC tracking frame
In-Reply-To: <1482408044.82.0.398076651662.issue29049@psf.upfronthosting.co.za>
Message-ID: <1482617434.49.0.243747634811.issue29049@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Please wrap private functions in #ifndef Py_LIMITED_API/#endif.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29049>
_______________________________________

From report at bugs.python.org  Sat Dec 24 17:28:08 2016
From: report at bugs.python.org (Utku Gultopu)
Date: Sat, 24 Dec 2016 22:28:08 +0000
Subject: [issue29065] SSL module problem on Python 3.6.0 and macOS Sierra
Message-ID: <1482618488.69.0.324323347363.issue29065@psf.upfronthosting.co.za>


New submission from Utku Gultopu:

It seems like ssl module is not working for me:

(virtualenv) user at host:~$ python
Python 3.6.0 (v3.6.0:41df79263a11, Dec 22 2016, 17:23:13) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import ssl
>>> import socket
>>> context = ssl.create_default_context()
>>> conn = context.wrap_socket(socket.socket(socket.AF_INET), server_hostname="www.python.org")
>>> conn.connect(("www.python.org", 443))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/ssl.py", line 1093, in connect
    self._real_connect(addr, False)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/ssl.py", line 1084, in _real_connect
    self.do_handshake()
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/ssl.py", line 1061, in do_handshake
    self._sslobj.do_handshake()
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/ssl.py", line 683, in do_handshake
    self._sslobj.do_handshake()
ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:749)
>>> 

It seems like a problem with OpenSSL in Sierra itself. Because the following command does not work either:

(virtualenv) user at host:~$ openssl s_client -connect www.python.org:443
CONNECTED(00000003)
depth=1 /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 Extended Validation Server CA
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
 0 s:/businessCategory=Private Organization/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Delaware/serialNumber=3359300/street=16 Allen Rd/postalCode=03894-4801/C=US/ST=NH/L=Wolfeboro/O=Python Software Foundation/CN=www.python.org
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 Extended Validation Server CA
 1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 Extended Validation Server CA
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIIWjCCB0KgAwIBAgIQCXCW7BLw16II/CMOsOFe/jANBgkqhkiG9w0BAQsFADB1
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMTQwMgYDVQQDEytEaWdpQ2VydCBTSEEyIEV4dGVuZGVk
IFZhbGlkYXRpb24gU2VydmVyIENBMB4XDTE2MDYyOTAwMDAwMFoXDTE4MDkyNzEy
MDAwMFowgfgxHTAbBgNVBA8TFFByaXZhdGUgT3JnYW5pemF0aW9uMRMwEQYLKwYB
BAGCNzwCAQMTAlVTMRkwFwYLKwYBBAGCNzwCAQITCERlbGF3YXJlMRAwDgYDVQQF
EwczMzU5MzAwMRQwEgYDVQQJEwsxNiBBbGxlbiBSZDETMBEGA1UEERMKMDM4OTQt
NDgwMTELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAk5IMRIwEAYDVQQHEwlXb2xmZWJv
cm8xIzAhBgNVBAoTGlB5dGhvbiBTb2Z0d2FyZSBGb3VuZGF0aW9uMRcwFQYDVQQD
Ew53d3cucHl0aG9uLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB
AMpgUlIza25mor2AW20yRs8uHtRJs0kXpMF2zATQjhYAgfpqjoKugoWBlMrLCFQj
G/Aq8W7pT4WWHCb9Nv2QGdnIEapxi5HSfxc3b1HIRmJDdfxsc2Y4dATfgzIS4wNw
jDM9tmYcMZMKZVdW4WxurQIka8r3tBFP944yAllRn8uuFVXSDYALkZOiiWxuMYKA
q40hYrDhWO53uKk23HNBo5Kgfvcj3t0ZcMSkzekClxyxgyS1nnkNWIdEEMCP/FFU
UXrQt0MEtkmfc++6Ps2SEiHL2T4MEqY8eE0ss6Mvmt+yzy8QsZOArrpxv7l8OwBO
5yB0LU3ByoQan1O/upeNclkCAwEAAaOCBGAwggRcMB8GA1UdIwQYMBaAFD3TUKXW
oK3u80pgCmXTIdT4+NYPMB0GA1UdDgQWBBTL2ztKcGS38IxHEASJaOzwHuUqljCC
AQsGA1UdEQSCAQIwgf+CDnd3dy5weXRob24ub3Jngg9kb2NzLnB5dGhvbi5vcmeC
D2J1Z3MucHl0aG9uLm9yZ4IPd2lraS5weXRob24ub3Jngg1oZy5weXRob24ub3Jn
gg9tYWlsLnB5dGhvbi5vcmeCD3B5cGkucHl0aG9uLm9yZ4IUcGFja2FnaW5nLnB5
dGhvbi5vcmeCEGxvZ2luLnB5dGhvbi5vcmeCEmRpc2N1c3MucHl0aG9uLm9yZ4IM
dXMucHljb24ub3JnggdweXBpLmlvggxkb2NzLnB5cGkuaW+CCHB5cGkub3Jngg1k
b2NzLnB5cGkub3Jngg9kb25hdGUucHlwaS5vcmcwDgYDVR0PAQH/BAQDAgWgMB0G
A1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjB1BgNVHR8EbjBsMDSgMqAwhi5o
dHRwOi8vY3JsMy5kaWdpY2VydC5jb20vc2hhMi1ldi1zZXJ2ZXItZzEuY3JsMDSg
MqAwhi5odHRwOi8vY3JsNC5kaWdpY2VydC5jb20vc2hhMi1ldi1zZXJ2ZXItZzEu
Y3JsMEsGA1UdIAREMEIwNwYJYIZIAYb9bAIBMCowKAYIKwYBBQUHAgEWHGh0dHBz
Oi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwBwYFZ4EMAQEwgYgGCCsGAQUFBwEBBHww
ejAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuZGlnaWNlcnQuY29tMFIGCCsGAQUF
BzAChkZodHRwOi8vY2FjZXJ0cy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyRXh0
ZW5kZWRWYWxpZGF0aW9uU2VydmVyQ0EuY3J0MAwGA1UdEwEB/wQCMAAwggF9Bgor
BgEEAdZ5AgQCBIIBbQSCAWkBZwB2AKS5CZC0GFgUh7sTosxncAo8NZgE+RvfuON3
zQ7IDdwQAAABVkgj4a8AAAQDAEcwRQIhAMhsxamO6hrRjfNmH4Yj/cnJo72cmTHm
rSlEi0FHilNtAiB/tDiULYh6rf9H5eKmrV8PRsvFNSflBsQIIF1VejnWrwB2AGj2
mPgfZIK+OozuuSgdTPxxUV1nk9RE0QpnrLtPT/vEAAABVkgj4XYAAAQDAEcwRQIg
Ygh+rvtk2KQd2CRaM+whfGgc6waZACSMgwzYVmOZr9sCIQDGs78IDIoPZhNBGfIK
xXQdq8DwAjahQboXeJWx/AfAxQB1AFYUBpov18Ls0/XhvUSyPsdGdrm8mRFcwO+U
mFXWidDdAAABVkgj4dkAAAQDAEYwRAIgMOOdrhZ0280XsmWuLt7fcFnwtRIu42j7
WmRrQ2NlJLUCIG5Z6vzlhvFNIhN67A0G/hrRH7hzJ13/elILZcjZYJQqMA0GCSqG
SIb3DQEBCwUAA4IBAQCuDt1T9tBxAVYp2u10uONL6FTHQlgguQCiN5ANmjp6dUAq
2I1nCgZB9nxhGUFOsdiQ5DFDgJ0xTAgwF4nWAyXEHKjyacoaUOh3Zq7A62r5+0eE
P3XDNKIN2TWF3+djFneND/uqqpDGo2bMdcm9l0dvktUP9xQXIZBBkOMJZfXSxh0/
7H+bDizx+bq/5Dwv97fs770UCz5LqGRuIUaZQvBQblsP5QoBaKEYW5Hsmfu9FWbW
0qreV7KHFp7ONBSKFUefbG0Q37O8oTPr7JnMxTvdUcthJOLcN9IHo2StTzv3Wru0
5njv0zLw7zwePKc9YJ1YBLmLj7vPxyy/XoW8+8hI
-----END CERTIFICATE-----
subject=/businessCategory=Private Organization/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Delaware/serialNumber=3359300/street=16 Allen Rd/postalCode=03894-4801/C=US/ST=NH/L=Wolfeboro/O=Python Software Foundation/CN=www.python.org
issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 Extended Validation Server CA
---
No client certificate CA names sent
---
SSL handshake has read 3524 bytes and written 456 bytes
---
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES128-SHA
    Session-ID: 239A88888D772216EDDD8C204996A901BAD27D50B929E6A626955472456077B6
    Session-ID-ctx: 
    Master-Key: FB1EAC13FFD2F42DA5BF0364E3A08A869DD129389374416B6574F6D852692888F991B79027143A81963FA7594FFB85BD
    Key-Arg   : None
    Start Time: 1482618121
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

Connecting to `www.python.org` (or any other secure site) works on web browsers. Also, `DigiCert High Assurance EV Root CA` exists in the System Roots section of Keychain.

I guess the problem might be that ssl module does not use the Keychain, like `openssl` command.

Regards

----------
assignee: christian.heimes
components: SSL, macOS
messages: 283976
nosy: christian.heimes, ned.deily, ronaldoussoren, ugultopu
priority: normal
severity: normal
status: open
title: SSL module problem on Python 3.6.0 and macOS Sierra
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29065>
_______________________________________

From report at bugs.python.org  Sat Dec 24 19:35:34 2016
From: report at bugs.python.org (INADA Naoki)
Date: Sun, 25 Dec 2016 00:35:34 +0000
Subject: [issue29049] Lazy GC tracking frame
In-Reply-To: <1482408044.82.0.398076651662.issue29049@psf.upfronthosting.co.za>
Message-ID: <1482626134.44.0.781179525627.issue29049@psf.upfronthosting.co.za>


INADA Naoki added the comment:

> Please wrap private functions in #ifndef Py_LIMITED_API/#endif.

No problem.  Whole Include/frameobject.h is wrapped by Py_LIMITED_API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29049>
_______________________________________

From report at bugs.python.org  Sat Dec 24 20:19:51 2016
From: report at bugs.python.org (INADA Naoki)
Date: Sun, 25 Dec 2016 01:19:51 +0000
Subject: [issue29062] hashlib documentation link error
In-Reply-To: <1482571303.3.0.781602557285.issue29062@psf.upfronthosting.co.za>
Message-ID: <1482628791.55.0.381703835433.issue29062@psf.upfronthosting.co.za>


INADA Naoki added the comment:

1. remove `.. module:: hashlib` from Doc/library/hashlib-blake2.rst
2. merge Doc/library/hashlib-blake2.rst content into Doc/library/hashlib.rst

Hmm, which is better?

----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29062>
_______________________________________

From report at bugs.python.org  Sat Dec 24 20:25:19 2016
From: report at bugs.python.org (INADA Naoki)
Date: Sun, 25 Dec 2016 01:25:19 +0000
Subject: [issue29059] Windows: Python not using ANSI compatible console
In-Reply-To: <1482543191.02.0.407458515739.issue29059@psf.upfronthosting.co.za>
Message-ID: <1482629119.48.0.409022038693.issue29059@psf.upfronthosting.co.za>


INADA Naoki added the comment:

Is it a global state, or application specific state?
In other words, if Python enables VT100, doesn't it remain after os._exit(1)?

If it is global state of console, why Python should change it?
Shouldn't user who want to use VT100 enable it before starting Python?

----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29059>
_______________________________________

From report at bugs.python.org  Sat Dec 24 21:35:34 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 25 Dec 2016 02:35:34 +0000
Subject: [issue25591] refactor imaplib tests
In-Reply-To: <1447107407.81.0.130095933409.issue25591@psf.upfronthosting.co.za>
Message-ID: <20161225023529.17238.71699.31284042@psf.io>


Roundup Robot added the comment:

New changeset 75f9cca86fa1 by R David Murray in branch '3.5':
#25591: improve imap tests.
https://hg.python.org/cpython/rev/75f9cca86fa1

New changeset 4663466b0d66 by R David Murray in branch '3.6':
Merge: #25591: improve imap tests.
https://hg.python.org/cpython/rev/4663466b0d66

New changeset 93d8cce449eb by R David Murray in branch 'default':
Merge: #25591: improve imap tests.
https://hg.python.org/cpython/rev/93d8cce449eb

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25591>
_______________________________________

From report at bugs.python.org  Sat Dec 24 21:39:55 2016
From: report at bugs.python.org (R. David Murray)
Date: Sun, 25 Dec 2016 02:39:55 +0000
Subject: [issue25591] refactor imaplib tests
In-Reply-To: <1447107407.81.0.130095933409.issue25591@psf.upfronthosting.co.za>
Message-ID: <1482633595.66.0.312640697552.issue25591@psf.upfronthosting.co.za>


R. David Murray added the comment:

Committed.  FYI, I did have to make a few tweaks.  There were several lines longer than 80 characters still that I wrapped.  The tests failed with -W error:BytesWarning, something I normally run the tests with.  That required a fix to the library (a decode on the error message...if anyone is depending on the error message being bytes instead of string I'm sorry, but I doubt anyone is.  And finally, committing to 3.6 required adding the 'r' prefix to some of the tests regexes to eliminate the invalid escape warnings.

Thanks for your patience and persistence, Maciej.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25591>
_______________________________________

From report at bugs.python.org  Sat Dec 24 21:58:08 2016
From: report at bugs.python.org (Joseph Hackman)
Date: Sun, 25 Dec 2016 02:58:08 +0000
Subject: [issue29059] Windows: Python not using ANSI compatible console
In-Reply-To: <1482543191.02.0.407458515739.issue29059@psf.upfronthosting.co.za>
Message-ID: <1482634688.03.0.960121514342.issue29059@psf.upfronthosting.co.za>


Joseph Hackman added the comment:

The flag is application specific. I.e. a python program that writes to console  using ansi codes, when used on windows, will just display the codes. If the Output is redireced to file and then the file is printed to console using a console tool, the colors will show instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29059>
_______________________________________

From report at bugs.python.org  Sat Dec 24 22:07:28 2016
From: report at bugs.python.org (INADA Naoki)
Date: Sun, 25 Dec 2016 03:07:28 +0000
Subject: [issue28293] Don't completely dump the regex cache when full
In-Reply-To: <1475038169.86.0.21816130335.issue28293@psf.upfronthosting.co.za>
Message-ID: <1482635248.8.0.32025305651.issue28293@psf.upfronthosting.co.za>


INADA Naoki added the comment:

LGTM for re_cache_ordered_dict_popitem.patch

----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28293>
_______________________________________

From report at bugs.python.org  Sat Dec 24 22:11:29 2016
From: report at bugs.python.org (Ned Deily)
Date: Sun, 25 Dec 2016 03:11:29 +0000
Subject: [issue29065] SSL module problem on Python 3.6.0 and macOS Sierra
In-Reply-To: <1482618488.69.0.324323347363.issue29065@psf.upfronthosting.co.za>
Message-ID: <1482635489.74.0.0040886668584.issue29065@psf.upfronthosting.co.za>


Ned Deily added the comment:

>From the output you supplied, you appear to be using Python 3.6.0 from the python.org macOS binary installer.  Please read the ReadMe.rtf file for the installer which should have been displayed when you installed Python 3.6; a copy of it is also installed in /Applications/Python 3.6.  You can read it by double-clicking on the icon in the Finder or by entering the following shell command:

open "/Applications/Python 3.6/ReadMe.rtf"

In it, the section on "Certificate verification and OpenSSL" notes that, as of the 3.6.0 installer, the Python supplied no longer links with the deprecated Apple-supplied system OpenSSL libraries but rather supplies a private copy of OpenSSL 1.0.2 which does not automatically access the system default root certificates.  "For 3.6.0, a sample command script is included in /Applications/Python 3.6 to install a curated bundle of default root certificates from the third-party certifi package (https://pypi.python.org/pypi/certifi).  If you choose to use certifi, you should consider subscribing to the project's email update service to be notified when the certificate bundle is updated."  You can run the command script by double-clicking on it or by entering the shell command:

open "/Applications/Python 3.6/Install Certificates.command"

If necessary, you can adapt the script for other options rather than using the certifi-supplied bundle.  For later releases, other standard options will likely be provided.

I don't understand your comment that using the system openssl command doesn't work, e.g. "openssl s_client -connect www.python.org:443".  The output you supply appears to show it working as expected.  But, in any case, that's not relevant to the Python 3.6 usage as different OpenSSL versions and libraries are being used.

Also note that this description only applies to the Python 3.6 supplied by the python.org macOS installer.  mscOS Pythons supplied by third-party distributors likely link with each distributor's version of OpenSSL and follow their root certificate policies.

----------
assignee: christian.heimes -> 
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29065>
_______________________________________

From report at bugs.python.org  Sat Dec 24 22:33:40 2016
From: report at bugs.python.org (Ned Deily)
Date: Sun, 25 Dec 2016 03:33:40 +0000
Subject: [issue29065] SSL module problem on Python 3.6.0 and macOS Sierra
In-Reply-To: <1482618488.69.0.324323347363.issue29065@psf.upfronthosting.co.za>
Message-ID: <1482636820.59.0.757208603428.issue29065@psf.upfronthosting.co.za>


Ned Deily added the comment:

I've also added a note to the release downloads "Notes on this release" section:

"macOS users: If you are using the Python 3.6 from the python.org binary installer linked on this page, please carefully read the Important Information displayed during installation; this information is also available after installation by clicking on /Applications/Python 3.6/ReadMe.rtf. There is important information there about changes in the 3.6.0 installer-supplied Python, particularly with regard to SSL certificate validation."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29065>
_______________________________________

From report at bugs.python.org  Sun Dec 25 01:47:58 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 25 Dec 2016 06:47:58 +0000
Subject: [issue29062] hashlib documentation link error
In-Reply-To: <1482571303.3.0.781602557285.issue29062@psf.upfronthosting.co.za>
Message-ID: <1482648478.81.0.889928871378.issue29062@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Replace ".. module" with ".. currentmodule".

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29062>
_______________________________________

From report at bugs.python.org  Sun Dec 25 02:07:23 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 25 Dec 2016 07:07:23 +0000
Subject: [issue1116520] Prefix search is filesystem-centric
Message-ID: <1482649643.22.0.899776809949.issue1116520@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at gmail.com>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1116520>
_______________________________________

From report at bugs.python.org  Sun Dec 25 02:38:55 2016
From: report at bugs.python.org (Utku Gultopu)
Date: Sun, 25 Dec 2016 07:38:55 +0000
Subject: [issue29066] PIP doesn't honor --trusted-host or --cert options
Message-ID: <1482651535.67.0.15058500735.issue29066@psf.upfronthosting.co.za>


New submission from Utku Gultopu:

Steps to Reproduce
==================
1. Install Python 3.6.0 on macOS Sierra, using the macOS binary installer from python.org.
2. Don't install any SSL certificates.
3. Run `pip install -U channels`. It will fail.
4. Run `pip install -U --trusted-host pypi.python.org channels`. It will fail too.
5. Run `pip --cert ~/cacert.pem install -U channels` (where `cacert.pem` is [this](https://curl.haxx.se/ca/cacert.pem).) It will fail too.

Expected Results
================
Command at number 3 to fail, commands at number 4 and 5 to succeed.

Actual Results
==============
Commands at number 3, 4 and 5 fail.

Version Info
============
Python 3.6.0 (v3.6.0:41df79263a11, Dec 22 2016, 17:23:13) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin

macOS Sierra 10.12

pip 9.0.1 from /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/site-packages (python 3.6)

Related Issues
=============
29065

Explanation
===========
I installed Python 3.6.0 on macOS Sierra, using the macOS binary installer from python.org.

Initially, I didn't install the necessary certificates by running the script /Applications/Python 3.6/Install Certificates.command.

When I wanted to install a module where PIP establishes an SSL connection during installation, I got an SSL: CERTIFICATE_VERIFY_FAILED error, as expected.

Command at step 3:

(virtualenv) user at host:~/Documents/virtualenv$ pip install -U channels
Collecting channels
  Downloading channels-0.17.3-py2.py3-none-any.whl (53kB)
    100% |????????????????????????????????| 61kB 299kB/s 
Requirement already up-to-date: Django>=1.8 in ./lib/python3.6/site-packages (from channels)
Collecting asgiref>=0.13 (from channels)
  Downloading asgiref-1.0.0-py2.py3-none-any.whl
Collecting daphne>=0.14.1 (from channels)
  Downloading daphne-0.15.0-py2.py3-none-any.whl
Collecting six (from asgiref>=0.13->channels)
  Using cached six-1.10.0-py2.py3-none-any.whl
Collecting twisted>=16.0 (from daphne>=0.14.1->channels)
  Downloading Twisted-16.6.0.tar.bz2 (3.0MB)
    100% |????????????????????????????????| 3.0MB 265kB/s 
    Complete output from command python setup.py egg_info:
    Download error on https://pypi.python.org/simple/incremental/: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:749) -- Some packages may not be found!
    Couldn't find index page for 'incremental' (maybe misspelled?)
    Download error on https://pypi.python.org/simple/: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:749) -- Some packages may not be found!
    No local packages or working download links found for incremental>=16.10.1
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "/private/var/folders/45/r4yr9bbj29dfbtxqv75_785m0000gn/T/pip-build-o5qosaie/twisted/setup.py", line 21, in <module>
        setuptools.setup(**_setup["getSetupArgs"]())
      File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/distutils/core.py", line 108, in setup
        _setup_distribution = dist = klass(attrs)
      File "/Users/user/Documents/virtualenv/lib/python3.6/site-packages/setuptools/dist.py", line 316, in __init__
        self.fetch_build_eggs(attrs['setup_requires'])
      File "/Users/user/Documents/virtualenv/lib/python3.6/site-packages/setuptools/dist.py", line 371, in fetch_build_eggs
        replace_conflicting=True,
      File "/Users/user/Documents/virtualenv/lib/python3.6/site-packages/pkg_resources/__init__.py", line 846, in resolve
        dist = best[req.key] = env.best_match(req, ws, installer)
      File "/Users/user/Documents/virtualenv/lib/python3.6/site-packages/pkg_resources/__init__.py", line 1118, in best_match
        return self.obtain(req, installer)
      File "/Users/user/Documents/virtualenv/lib/python3.6/site-packages/pkg_resources/__init__.py", line 1130, in obtain
        return installer(requirement)
      File "/Users/user/Documents/virtualenv/lib/python3.6/site-packages/setuptools/dist.py", line 439, in fetch_build_egg
        return cmd.easy_install(req)
      File "/Users/user/Documents/virtualenv/lib/python3.6/site-packages/setuptools/command/easy_install.py", line 668, in easy_install
        raise DistutilsError(msg)
    distutils.errors.DistutilsError: Could not find suitable distribution for Requirement.parse('incremental>=16.10.1')
    
    ----------------------------------------
Command "python setup.py egg_info" failed with error code 1 in /private/var/folders/45/r4yr9bbj29dfbtxqv75_785m0000gn/T/pip-build-o5qosaie/twisted/

Command at step 4:

(virtualenv) user at host:~/Documents/virtualenv$ pip install -U --trusted-host pypi.python.org channels
Collecting channels
  Downloading channels-0.17.3-py2.py3-none-any.whl (53kB)
    100% |????????????????????????????????| 61kB 291kB/s 
Requirement already up-to-date: Django>=1.8 in ./lib/python3.6/site-packages (from channels)
Collecting asgiref>=0.13 (from channels)
  Downloading asgiref-1.0.0-py2.py3-none-any.whl
Collecting daphne>=0.14.1 (from channels)
  Downloading daphne-0.15.0-py2.py3-none-any.whl
Collecting six (from asgiref>=0.13->channels)
  Downloading six-1.10.0-py2.py3-none-any.whl
Collecting twisted>=16.0 (from daphne>=0.14.1->channels)
  Downloading Twisted-16.6.0.tar.bz2 (3.0MB)
    100% |????????????????????????????????| 3.0MB 359kB/s 
    Complete output from command python setup.py egg_info:
    Download error on https://pypi.python.org/simple/incremental/: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:749) -- Some packages may not be found!
    Couldn't find index page for 'incremental' (maybe misspelled?)
    Download error on https://pypi.python.org/simple/: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:749) -- Some packages may not be found!
    No local packages or working download links found for incremental>=16.10.1
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "/private/var/folders/45/r4yr9bbj29dfbtxqv75_785m0000gn/T/pip-build-6fteuyi9/twisted/setup.py", line 21, in <module>
        setuptools.setup(**_setup["getSetupArgs"]())
      File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/distutils/core.py", line 108, in setup
        _setup_distribution = dist = klass(attrs)
      File "/Users/user/Documents/virtualenv/lib/python3.6/site-packages/setuptools/dist.py", line 316, in __init__
        self.fetch_build_eggs(attrs['setup_requires'])
      File "/Users/user/Documents/virtualenv/lib/python3.6/site-packages/setuptools/dist.py", line 371, in fetch_build_eggs
        replace_conflicting=True,
      File "/Users/user/Documents/virtualenv/lib/python3.6/site-packages/pkg_resources/__init__.py", line 846, in resolve
        dist = best[req.key] = env.best_match(req, ws, installer)
      File "/Users/user/Documents/virtualenv/lib/python3.6/site-packages/pkg_resources/__init__.py", line 1118, in best_match
        return self.obtain(req, installer)
      File "/Users/user/Documents/virtualenv/lib/python3.6/site-packages/pkg_resources/__init__.py", line 1130, in obtain
        return installer(requirement)
      File "/Users/user/Documents/virtualenv/lib/python3.6/site-packages/setuptools/dist.py", line 439, in fetch_build_egg
        return cmd.easy_install(req)
      File "/Users/user/Documents/virtualenv/lib/python3.6/site-packages/setuptools/command/easy_install.py", line 668, in easy_install
        raise DistutilsError(msg)
    distutils.errors.DistutilsError: Could not find suitable distribution for Requirement.parse('incremental>=16.10.1')
    
    ----------------------------------------
Command "python setup.py egg_info" failed with error code 1 in /private/var/folders/45/r4yr9bbj29dfbtxqv75_785m0000gn/T/pip-build-6fteuyi9/twisted/

Command at step 5:

(virtualenv) user at host:~/Documents/virtualenv$ pip --cert ~/cacert.pem install -U channels
Collecting channels
  Using cached channels-0.17.3-py2.py3-none-any.whl
Collecting asgiref>=0.13 (from channels)
  Using cached asgiref-1.0.0-py2.py3-none-any.whl
Collecting daphne>=0.14.1 (from channels)
  Using cached daphne-0.15.0-py2.py3-none-any.whl
Requirement already up-to-date: Django>=1.8 in ./lib/python3.6/site-packages (from channels)
Collecting six (from asgiref>=0.13->channels)
  Using cached six-1.10.0-py2.py3-none-any.whl
Collecting twisted>=16.0 (from daphne>=0.14.1->channels)
  Using cached Twisted-16.6.0.tar.bz2
    Complete output from command python setup.py egg_info:
    Download error on https://pypi.python.org/simple/incremental/: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:749) -- Some packages may not be found!
    Couldn't find index page for 'incremental' (maybe misspelled?)
    Download error on https://pypi.python.org/simple/: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:749) -- Some packages may not be found!
    No local packages or working download links found for incremental>=16.10.1
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "/private/var/folders/45/r4yr9bbj29dfbtxqv75_785m0000gn/T/pip-build-_c6zb9_v/twisted/setup.py", line 21, in <module>
        setuptools.setup(**_setup["getSetupArgs"]())
      File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/distutils/core.py", line 108, in setup
        _setup_distribution = dist = klass(attrs)
      File "/Users/user/Documents/virtualenv/lib/python3.6/site-packages/setuptools/dist.py", line 316, in __init__
        self.fetch_build_eggs(attrs['setup_requires'])
      File "/Users/user/Documents/virtualenv/lib/python3.6/site-packages/setuptools/dist.py", line 371, in fetch_build_eggs
        replace_conflicting=True,
      File "/Users/user/Documents/virtualenv/lib/python3.6/site-packages/pkg_resources/__init__.py", line 846, in resolve
        dist = best[req.key] = env.best_match(req, ws, installer)
      File "/Users/user/Documents/virtualenv/lib/python3.6/site-packages/pkg_resources/__init__.py", line 1118, in best_match
        return self.obtain(req, installer)
      File "/Users/user/Documents/virtualenv/lib/python3.6/site-packages/pkg_resources/__init__.py", line 1130, in obtain
        return installer(requirement)
      File "/Users/user/Documents/virtualenv/lib/python3.6/site-packages/setuptools/dist.py", line 439, in fetch_build_egg
        return cmd.easy_install(req)
      File "/Users/user/Documents/virtualenv/lib/python3.6/site-packages/setuptools/command/easy_install.py", line 668, in easy_install
        raise DistutilsError(msg)
    distutils.errors.DistutilsError: Could not find suitable distribution for Requirement.parse('incremental>=16.10.1')
    
    ----------------------------------------
Command "python setup.py egg_info" failed with error code 1 in /private/var/folders/45/r4yr9bbj29dfbtxqv75_785m0000gn/T/pip-build-_c6zb9_v/twisted/

----------
assignee: christian.heimes
components: SSL, macOS
messages: 283987
nosy: christian.heimes, ned.deily, ronaldoussoren, ugultopu
priority: normal
severity: normal
status: open
title: PIP doesn't honor --trusted-host or --cert options
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29066>
_______________________________________

From report at bugs.python.org  Sun Dec 25 02:45:04 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 25 Dec 2016 07:45:04 +0000
Subject: [issue29049] Lazy GC tracking frame
In-Reply-To: <1482408044.82.0.398076651662.issue29049@psf.upfronthosting.co.za>
Message-ID: <1482651904.27.0.0581011163212.issue29049@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Ah, sorry. Then it LGTM.

Do you have a microbenchmark that exposes a maximal effect of this change?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29049>
_______________________________________

From report at bugs.python.org  Sun Dec 25 03:25:57 2016
From: report at bugs.python.org (amig)
Date: Sun, 25 Dec 2016 08:25:57 +0000
Subject: [issue29067] Source archive: wrong directory attributes
Message-ID: <1482654357.71.0.854296911958.issue29067@psf.upfronthosting.co.za>


New submission from amig:

In Python-3.6.0.tgz and Python-3.6.0.tar.xz the folders inside have attributes drwxr--r-- instaed of drwxrwxr-x. This leads to setting the user #501 as an owner while unpacking the archives in a folder owned by root with sudo and therefore access denial.

----------
components: Build
messages: 283989
nosy: amig
priority: normal
severity: normal
status: open
title: Source archive: wrong directory attributes
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29067>
_______________________________________

From report at bugs.python.org  Sun Dec 25 04:40:01 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 25 Dec 2016 09:40:01 +0000
Subject: [issue28998] Unifying Long Integers and Integers in 2.7
In-Reply-To: <1481967458.92.0.739722865425.issue28998@psf.upfronthosting.co.za>
Message-ID: <1482658801.25.0.382307263655.issue28998@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Added checks for errors in C code (they are needed even without supporting Python longs, PyInt_AsLong() can fail with Python ints) and a fast path for Python longs in PyInt_AsLong() (avoid creating temporary Python int).

----------
assignee:  -> serhiy.storchaka
Added file: http://bugs.python.org/file46028/py2_int_long_2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28998>
_______________________________________

From report at bugs.python.org  Sun Dec 25 04:40:05 2016
From: report at bugs.python.org (Karsten Tinnefeld)
Date: Sun, 25 Dec 2016 09:40:05 +0000
Subject: [issue29052] Detect Windows platform 32bit/64bit automatically
In-Reply-To: <1482496842.57.0.215126888318.issue29052@psf.upfronthosting.co.za>
Message-ID: <a044cf72-53ca-7c46-e932-a1fd2d7003cb@gmail.com>


Karsten Tinnefeld added the comment:

Thanks. Opened at https://github.com/python/pythondotorg/issues/1044

Karsten
-- 
Karsten Tinnefeld <K.Tinnefeld at gmail.com>
Dortmund, Germany

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29052>
_______________________________________

From report at bugs.python.org  Sun Dec 25 07:49:04 2016
From: report at bugs.python.org (Ned Deily)
Date: Sun, 25 Dec 2016 12:49:04 +0000
Subject: [issue29067] Source archive: wrong directory attributes
In-Reply-To: <1482654357.71.0.854296911958.issue29067@psf.upfronthosting.co.za>
Message-ID: <1482670144.38.0.995966618959.issue29067@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
assignee:  -> ned.deily
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29067>
_______________________________________

From report at bugs.python.org  Sun Dec 25 08:24:22 2016
From: report at bugs.python.org (Ned Deily)
Date: Sun, 25 Dec 2016 13:24:22 +0000
Subject: [issue29066] PIP doesn't honor --trusted-host or --cert options
In-Reply-To: <1482651535.67.0.15058500735.issue29066@psf.upfronthosting.co.za>
Message-ID: <1482672262.71.0.979253452836.issue29066@psf.upfronthosting.co.za>


Ned Deily added the comment:

The issue here seems to be the way Twisted installs its dependencies.  It looks like Twisted is calling setuptools directly and thus probably "losing" the certificate-related arguments from the original pip call.  (It all works correctly if do you the default root certificates setup as suggested in the installer readme.)  If you want to pursue the issue, I suggest checking with the Twisted project (https://twistedmatrix.com/).

----------
assignee: christian.heimes -> 
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29066>
_______________________________________

From report at bugs.python.org  Sun Dec 25 08:52:32 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Sun, 25 Dec 2016 13:52:32 +0000
Subject: [issue29068] Fix example code for PyErr_Fetch
Message-ID: <1482673952.94.0.428755110908.issue29068@psf.upfronthosting.co.za>


New submission from Chi Hsuan Yen:

Remove an extra *

The typo is there in 3.5~3.7 branches. 2.7 branch does not have this example.

Nosy the two major commiters to Python/errors.c

----------
assignee: docs at python
components: Documentation
files: PyErr_Fetch-fix.patch
keywords: patch
messages: 283993
nosy: Chi Hsuan Yen, docs at python, martin.panter, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Fix example code for PyErr_Fetch
versions: Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file46029/PyErr_Fetch-fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29068>
_______________________________________

From report at bugs.python.org  Sun Dec 25 08:54:46 2016
From: report at bugs.python.org (Dany Jalil)
Date: Sun, 25 Dec 2016 13:54:46 +0000
Subject: [issue25778] winreg.EnumValue does not truncate strings correctly
In-Reply-To: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za>
Message-ID: <1482674086.56.0.551696683263.issue25778@psf.upfronthosting.co.za>


Changes by Dany Jalil <danyjalilg at gmail.com>:


Added file: http://bugs.python.org/file46030/IMG-20161224-WA0004.jpg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25778>
_______________________________________

From report at bugs.python.org  Sun Dec 25 08:55:03 2016
From: report at bugs.python.org (Dany Jalil)
Date: Sun, 25 Dec 2016 13:55:03 +0000
Subject: [issue25778] winreg.EnumValue does not truncate strings correctly
In-Reply-To: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za>
Message-ID: <1482674103.1.0.728431176171.issue25778@psf.upfronthosting.co.za>


Changes by Dany Jalil <danyjalilg at gmail.com>:


Added file: http://bugs.python.org/file46031/IMG-20161224-WA0004.jpg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25778>
_______________________________________

From report at bugs.python.org  Sun Dec 25 08:58:50 2016
From: report at bugs.python.org (Dany Jalil)
Date: Sun, 25 Dec 2016 13:58:50 +0000
Subject: [issue25778] winreg.EnumValue does not truncate strings correctly
In-Reply-To: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za>
Message-ID: <1482674330.93.0.119478267235.issue25778@psf.upfronthosting.co.za>


Changes by Dany Jalil <danyjalilg at gmail.com>:


Added file: http://bugs.python.org/file46032/IMG-20161224-WA0004.jpg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25778>
_______________________________________

From report at bugs.python.org  Sun Dec 25 09:21:12 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 25 Dec 2016 14:21:12 +0000
Subject: [issue29068] Fix example code for PyErr_Fetch
In-Reply-To: <1482673952.94.0.428755110908.issue29068@psf.upfronthosting.co.za>
Message-ID: <1482675672.86.0.546855159942.issue29068@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM. Thank you for your contribution Chi Hsuan Yen.

----------
assignee: docs at python -> serhiy.storchaka
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29068>
_______________________________________

From report at bugs.python.org  Sun Dec 25 09:24:34 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 25 Dec 2016 14:24:34 +0000
Subject: [issue29068] Fix example code for PyErr_Fetch
In-Reply-To: <1482673952.94.0.428755110908.issue29068@psf.upfronthosting.co.za>
Message-ID: <20161225142431.107561.75177.40228826@psf.io>


Roundup Robot added the comment:

New changeset 34e7b9879e60 by Serhiy Storchaka in branch '3.5':
Issue #29068: Fixed a typo in PyErr_Fetch example.
https://hg.python.org/cpython/rev/34e7b9879e60

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29068>
_______________________________________

From report at bugs.python.org  Sun Dec 25 09:24:58 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 25 Dec 2016 14:24:58 +0000
Subject: [issue29068] Fix example code for PyErr_Fetch
In-Reply-To: <1482673952.94.0.428755110908.issue29068@psf.upfronthosting.co.za>
Message-ID: <1482675898.95.0.911743948154.issue29068@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29068>
_______________________________________

From report at bugs.python.org  Sun Dec 25 09:28:02 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Sun, 25 Dec 2016 14:28:02 +0000
Subject: [issue27659] Prohibit implicit C function declarations
In-Reply-To: <1469948678.43.0.816389049938.issue27659@psf.upfronthosting.co.za>
Message-ID: <1482676082.35.0.0649679133632.issue27659@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

(Re-use the existing issue)

Here's a patch that tries to add -Werror=implicit-function-declaration to $BASECFLAGS.

This is useful for cross-compiling. When a function is missing, the error jumps out during the build time rather than runtime.

Tested configurations:
* Arch Linux x86_64 native build
* macOS Sierra native build
* Android ARM, API 21 cross build

I'd like to hear some ideas from macOS experts as in my memory macOS's build system is fragile than that on Linux.

----------
components: +Build
nosy: +ned.deily, ronaldoussoren
title: Check for the existence of crypt() -> Prohibit implicit C function declarations
type: compile error -> enhancement
Added file: http://bugs.python.org/file46033/prohibit-implicit-function-declarations.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27659>
_______________________________________

From report at bugs.python.org  Sun Dec 25 10:38:32 2016
From: report at bugs.python.org (paka)
Date: Sun, 25 Dec 2016 15:38:32 +0000
Subject: [issue29069] Default PyPI URL in docs is not what is really in code
Message-ID: <1482680312.49.0.384857389372.issue29069@psf.upfronthosting.co.za>


New submission from paka:

Currently https://docs.python.org/3.7/distutils/packageindex.html#the-pypirc-file says that URL of the PyPI server defaults to https://www.python.org/pypi. That URL does not work.

Lib/distutils/config.py defines DEFAULT_REPOSITORY as https://upload.pypi.org/legacy/, so I'm attaching a patch for docs to update to current default.

I might be wrong about value that must be in docs, so guidance is appreciated :)

----------
assignee: docs at python
components: Distutils, Documentation
files: fix-pypi-url.patch
keywords: patch
messages: 283997
nosy: docs at python, dstufft, eric.araujo, paka
priority: normal
severity: normal
status: open
title: Default PyPI URL in docs is not what is really in code
versions: Python 3.7
Added file: http://bugs.python.org/file46034/fix-pypi-url.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29069>
_______________________________________

From report at bugs.python.org  Sun Dec 25 11:02:58 2016
From: report at bugs.python.org (Steve Dower)
Date: Sun, 25 Dec 2016 16:02:58 +0000
Subject: [issue29059] Windows: Python not using ANSI compatible console
In-Reply-To: <1482543191.02.0.407458515739.issue29059@psf.upfronthosting.co.za>
Message-ID: <1482681778.45.0.898566634029.issue29059@psf.upfronthosting.co.za>


Steve Dower added the comment:

Great suggestion. If someone is willing to contribute the work then we can consider it for 3.7.

If you need this functionality sooner, either ctypes or colorama should allow you to use it on existing releases.

----------
type: behavior -> enhancement
versions: +Python 3.7 -Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29059>
_______________________________________

From report at bugs.python.org  Sun Dec 25 11:05:51 2016
From: report at bugs.python.org (Steve Dower)
Date: Sun, 25 Dec 2016 16:05:51 +0000
Subject: [issue29059] Windows: Python not using ANSI compatible console
In-Reply-To: <1482543191.02.0.407458515739.issue29059@psf.upfronthosting.co.za>
Message-ID: <1482681951.39.0.51012194942.issue29059@psf.upfronthosting.co.za>


Steve Dower added the comment:

Oh, and it should go in the WinConsoleIO class, needs to be written in C, and probably needs a short PEP explaining why it has to be on by default and can't be turned on by programs that need it. I'm sure the discussion will lead to other ideas as well (perhaps posting on python-ideas is a good start? Though there may not be a lot of discussion for a Windows-centric suggestion like this.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29059>
_______________________________________

From report at bugs.python.org  Sun Dec 25 11:11:09 2016
From: report at bugs.python.org (Donald Stufft)
Date: Sun, 25 Dec 2016 16:11:09 +0000
Subject: [issue29066] PIP doesn't honor --trusted-host or --cert options
In-Reply-To: <1482651535.67.0.15058500735.issue29066@psf.upfronthosting.co.za>
Message-ID: <1482682269.32.0.874089078731.issue29066@psf.upfronthosting.co.za>


Donald Stufft added the comment:

Yea, this is from ``setup_requires`` keyword argument in ``setup.py``. I suspect we're going to see a lot of errors like this from people with 3.6 on the OSX Installers.

----------
nosy: +dstufft

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29066>
_______________________________________

From report at bugs.python.org  Sun Dec 25 11:31:59 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 25 Dec 2016 16:31:59 +0000
Subject: [issue1116520] Prefix search is filesystem-centric
Message-ID: <1482683519.44.0.973333051687.issue1116520@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Originally zip file importing was faster than standard importing from disk because of the fewer stat calls, but importlib caches such things so I don't know if it's still beneficial. As for space savings, I have no idea; you can try zipping the files yourself to find out the space savings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1116520>
_______________________________________

From report at bugs.python.org  Sun Dec 25 11:43:38 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 25 Dec 2016 16:43:38 +0000
Subject: [issue27659] Prohibit implicit C function declarations
In-Reply-To: <1482676082.35.0.0649679133632.issue27659@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwap9MpBQYp=NVpG=bOWG6-U_PdSoFpB7hF81vtMfUYHSA@mail.gmail.com>


STINNER Victor added the comment:

Would it be possible to not add this option for third party extensions?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27659>
_______________________________________

From report at bugs.python.org  Sun Dec 25 11:43:45 2016
From: report at bugs.python.org (Cornelius Diekmann)
Date: Sun, 25 Dec 2016 16:43:45 +0000
Subject: [issue29070] Integration tests for pty.spawn on Linux and all other
 platforms
Message-ID: <1482684225.17.0.467768789806.issue29070@psf.upfronthosting.co.za>


New submission from Cornelius Diekmann:

As Martin Panter noted, "it doesn?t look like pty.spawn() is tested at all" [issue26228]. So I wrote some very basic integration tests for pty.spawn.

They work perfectly on my Linux machine. Line 4 of the library module under test (pty.py) states: "Only tested on Linux." I don't like this comment ;-)

There are two possibilities how to proceed from here:
1) The tests work perfectly on all other platforms: then we can remove this comment from pty.py.
2) The tests fail on other platforms: then we can finally document where this module is expected to work and where not.

In either case, I need some help by non-Linux users to run theses tests and document their success/failure and whether we have a bug on the specific platform (i.e. pty.spawn should work but does not) or whether the tests should be skipped (i.e. platform does not support ptys at all).

It would be really awesome if some *BSD and Windows users would join the nosy list :-)

Happy Holidays!

----------
components: Cross-Build, Tests
files: PtyLinuxIntegrtionTest.patch
keywords: patch
messages: 284003
nosy: Alex.Willmer, Cornelius Diekmann, chris.torek, martin.panter
priority: normal
severity: normal
status: open
title: Integration tests for pty.spawn on Linux and all other platforms
type: enhancement
versions: Python 3.7
Added file: http://bugs.python.org/file46035/PtyLinuxIntegrtionTest.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29070>
_______________________________________

From report at bugs.python.org  Sun Dec 25 12:05:06 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Sun, 25 Dec 2016 17:05:06 +0000
Subject: [issue27659] Prohibit implicit C function declarations
In-Reply-To: <1469948678.43.0.816389049938.issue27659@psf.upfronthosting.co.za>
Message-ID: <1482685506.78.0.45086180119.issue27659@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

> Would it be possible to not add this option for third party extensions?

Good suggestion. Just use $CFLAGS_NODIST instead of $BASECFLAGS.

----------
Added file: http://bugs.python.org/file46036/prohibit-implicit-function-declarations.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27659>
_______________________________________

From report at bugs.python.org  Sun Dec 25 12:47:22 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 25 Dec 2016 17:47:22 +0000
Subject: [issue25778] winreg.EnumValue does not truncate strings correctly
In-Reply-To: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za>
Message-ID: <1482688042.77.0.282249321601.issue25778@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Removed file: http://bugs.python.org/file46030/IMG-20161224-WA0004.jpg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25778>
_______________________________________

From report at bugs.python.org  Sun Dec 25 12:47:27 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 25 Dec 2016 17:47:27 +0000
Subject: [issue25778] winreg.EnumValue does not truncate strings correctly
In-Reply-To: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za>
Message-ID: <1482688047.42.0.106178314916.issue25778@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Removed file: http://bugs.python.org/file46031/IMG-20161224-WA0004.jpg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25778>
_______________________________________

From report at bugs.python.org  Sun Dec 25 12:47:30 2016
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 25 Dec 2016 17:47:30 +0000
Subject: [issue25778] winreg.EnumValue does not truncate strings correctly
In-Reply-To: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za>
Message-ID: <1482688050.96.0.612226570586.issue25778@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Removed file: http://bugs.python.org/file46032/IMG-20161224-WA0004.jpg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25778>
_______________________________________

From report at bugs.python.org  Sun Dec 25 12:48:03 2016
From: report at bugs.python.org (Patrik Iselind)
Date: Sun, 25 Dec 2016 17:48:03 +0000
Subject: [issue1116520] Prefix search is filesystem-centric
In-Reply-To: <1482683519.44.0.973333051687.issue1116520@psf.upfronthosting.co.za>
Message-ID: <dcda1ef7-614b-3184-81a1-796617a457a3@gmail.com>


Patrik Iselind added the comment:

Is it enough to include everything in the Lib folder, excluding 
__pycache__, site-packages and the test folder in Lib? Would that be 
representative enough?

Patrik Iselind

Den 2016-12-25 kl. 17:31, skrev Brett Cannon:
> Brett Cannon added the comment:
>
> Originally zip file importing was faster than standard importing from disk because of the fewer stat calls, but importlib caches such things so I don't know if it's still beneficial. As for space savings, I have no idea; you can try zipping the files yourself to find out the space savings.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue1116520>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1116520>
_______________________________________

From report at bugs.python.org  Sun Dec 25 13:22:00 2016
From: report at bugs.python.org (Steve Holden)
Date: Sun, 25 Dec 2016 18:22:00 +0000
Subject: [issue1116520] Prefix search is filesystem-centric
In-Reply-To: <dcda1ef7-614b-3184-81a1-796617a457a3@gmail.com>
Message-ID: <CAMofdRAwxQsRmeB+Rj8Q+uV2pZaGXR6Tdqn=+JMTG62hF2gALA@mail.gmail.com>


Steve Holden added the comment:

Don't forget that the built-in modules may need to be available before the
zipimporter is. A long time ago (when sys.metapath was introduced) I
experimented with imports from non-filesystem sources and that hit me until
I realised what was going on.

S

Steve Holden

On Sun, Dec 25, 2016 at 5:48 PM, Patrik Iselind <report at bugs.python.org>
wrote:

>
> Patrik Iselind added the comment:
>
> Is it enough to include everything in the Lib folder, excluding
> __pycache__, site-packages and the test folder in Lib? Would that be
> representative enough?
>
> Patrik Iselind
>
> Den 2016-12-25 kl. 17:31, skrev Brett Cannon:
> > Brett Cannon added the comment:
> >
> > Originally zip file importing was faster than standard importing from
> disk because of the fewer stat calls, but importlib caches such things so I
> don't know if it's still beneficial. As for space savings, I have no idea;
> you can try zipping the files yourself to find out the space savings.
> >
> > ----------
> >
> > _______________________________________
> > Python tracker <report at bugs.python.org>
> > <http://bugs.python.org/issue1116520>
> > _______________________________________
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue1116520>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1116520>
_______________________________________

From report at bugs.python.org  Sun Dec 25 13:23:39 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 25 Dec 2016 18:23:39 +0000
Subject: [issue29049] Lazy GC tracking frame
In-Reply-To: <1482408044.82.0.398076651662.issue29049@psf.upfronthosting.co.za>
Message-ID: <1482690219.61.0.263911224839.issue29049@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Perhaps this change caused reference leaks:

test_exceptions leaked [1227, 1227, 1227] references, sum=3681
test_exceptions leaked [342, 344, 344] memory blocks, sum=1030
test_capi leaked [6043, 6043, 6043] references, sum=18129
test_capi leaked [1715, 1717, 1717] memory blocks, sum=5149
test_cgi leaked [68, 68, 68] references, sum=204
test_cgi leaked [34, 34, 35] memory blocks, sum=103
test_collections leaked [0, -7, 8] memory blocks, sum=1
test_contextlib leaked [2162, 2162, 2162] references, sum=6486
test_contextlib leaked [635, 637, 637] memory blocks, sum=1909
test_functools leaked [0, 3, 1] memory blocks, sum=4
test_importlib leaked [3068, 3068, 3068] references, sum=9204
test_importlib leaked [936, 938, 938] memory blocks, sum=2812
test_inspect leaked [34, 34, 34] references, sum=102
test_inspect leaked [10, 11, 10] memory blocks, sum=31
test_os leaked [182, 182, 182] references, sum=546
test_os leaked [112, 112, 112] memory blocks, sum=336
test_ssl leaked [3403, 3406, 3406] references, sum=10215
test_ssl leaked [977, 980, 980] memory blocks, sum=2937
test_threading leaked [12086, 12086, 12086] references, sum=36258
test_threading leaked [3430, 3432, 3432] memory blocks, sum=10294
test_timeout leaked [701, 701, 701] references, sum=2103
test_timeout leaked [203, 204, 204] memory blocks, sum=611
test_xml_etree leaked [3937, 3937, 3937] references, sum=11811
test_xml_etree leaked [1517, 1520, 1521] memory blocks, sum=4558
test_xml_etree_c leaked [354, 354, 354] references, sum=1062
test_xml_etree_c leaked [216, 217, 217] memory blocks, sum=650
test_yield_from leaked [33, 33, 33] references, sum=99
test_yield_from leaked [8, 8, 8] memory blocks, sum=24

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29049>
_______________________________________

From report at bugs.python.org  Sun Dec 25 13:24:12 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 25 Dec 2016 18:24:12 +0000
Subject: [issue29049] Lazy GC tracking frame
In-Reply-To: <1482408044.82.0.398076651662.issue29049@psf.upfronthosting.co.za>
Message-ID: <1482690252.23.0.899127846047.issue29049@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29049>
_______________________________________

From report at bugs.python.org  Sun Dec 25 16:00:39 2016
From: report at bugs.python.org (Steve Dower)
Date: Sun, 25 Dec 2016 21:00:39 +0000
Subject: [issue29058] Mark new limited C API
In-Reply-To: <1482538310.89.0.583492092721.issue29058@psf.upfronthosting.co.za>
Message-ID: <1482699639.47.0.218336735893.issue29058@psf.upfronthosting.co.za>


Steve Dower added the comment:

Those changes all look good to me, though it's a shame we can't leave some of those functions?out altogether.

----------
nosy: +steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29058>
_______________________________________

From report at bugs.python.org  Sun Dec 25 18:09:18 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 25 Dec 2016 23:09:18 +0000
Subject: [issue29058] Mark new limited C API
In-Reply-To: <1482538310.89.0.583492092721.issue29058@psf.upfronthosting.co.za>
Message-ID: <1482707358.82.0.520568691436.issue29058@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Actually PyODict_Check, PyODict_CheckExact, and PyODict_SIZE should be excluded from limited API. These macros are expanded to the code that don't work with limited API (needed PyODict_Type and PyDictObject). PyODict_HasKey is expanded to syntactically invalid code.

----------
nosy: +eric.snow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29058>
_______________________________________

From report at bugs.python.org  Sun Dec 25 20:16:18 2016
From: report at bugs.python.org (Kenzie Togami)
Date: Mon, 26 Dec 2016 01:16:18 +0000
Subject: [issue29071] IDLE doesn't highlight f-strings properly
Message-ID: <1482714978.44.0.603392455768.issue29071@psf.upfronthosting.co.za>


New submission from Kenzie Togami:

IDLE doesn't highlight f-strings like r-strings or u-strings. See the attached screenshot.

----------
assignee: terry.reedy
components: IDLE
files: python_idle_3.6_bug.png
messages: 284010
nosy: Kenzie Togami, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE doesn't highlight f-strings properly
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file46037/python_idle_3.6_bug.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29071>
_______________________________________

From report at bugs.python.org  Sun Dec 25 20:40:14 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 26 Dec 2016 01:40:14 +0000
Subject: [issue1116520] Prefix search is filesystem-centric
Message-ID: <1482716414.14.0.964039974326.issue1116520@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Note that Steve Dower made some significant changes to sys.path initialisation on Windows in Python 3.6 that could potentially be generalised to other platforms: https://docs.python.org/3/using/windows.html#finding-modules

(There's nothing inherently Windows specific about them, they're mainly useful for the case of embedding CPython inside a larger application)

One of those was to allow pythonXY.zip to be used as a sentinel indicating the location of PYTHONHOME.

----------
nosy: +steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1116520>
_______________________________________

From report at bugs.python.org  Sun Dec 25 22:40:04 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 26 Dec 2016 03:40:04 +0000
Subject: [issue29049] Lazy GC tracking frame
In-Reply-To: <1482408044.82.0.398076651662.issue29049@psf.upfronthosting.co.za>
Message-ID: <1482723604.56.0.122604326862.issue29049@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

On my PC, this patch also introduces two tests failure:

FAIL: test_log_destroyed_pending_task (test.test_asyncio.test_tasks.CTask_CFuture_SubclassTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/angwer/cpython/Lib/test/test_asyncio/test_tasks.py", line 1823, in test_log_destroyed_pending_task
    self.assertEqual(Task.all_tasks(loop=self.loop), set())
AssertionError: Items in the first set but not the second:
<Task pending coro=<BaseTaskTests.test_log_destroyed_pending_task.<locals>.kill_me() running at /home/angwer/cpython/Lib/test/test_asyncio/test_tasks.py:1796> wait_for=<Future pending cb=[<TaskWakeupMethWrapper object at 0x7f649f135f18>()] created at /home/angwer/cpython/Lib/test/test_asyncio/test_tasks.py:2001> created at /home/angwer/cpython/Lib/test/test_asyncio/test_tasks.py:83>

======================================================================
FAIL: test_log_destroyed_pending_task (test.test_asyncio.test_tasks.CTask_CFuture_Tests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/angwer/cpython/Lib/test/test_asyncio/test_tasks.py", line 1823, in test_log_destroyed_pending_task
    self.assertEqual(Task.all_tasks(loop=self.loop), set())
AssertionError: Items in the first set but not the second:
<Task pending coro=<BaseTaskTests.test_log_destroyed_pending_task.<locals>.kill_me() running at /home/angwer/cpython/Lib/test/test_asyncio/test_tasks.py:1796> wait_for=<Future pending cb=[<TaskWakeupMethWrapper object at 0x7f649f135498>()] created at /home/angwer/cpython/Lib/test/test_asyncio/test_tasks.py:86> created at /home/angwer/cpython/Lib/asyncio/base_events.py:287>

======================================================================
FAIL: test_log_destroyed_pending_task (test.test_asyncio.test_tasks.CTask_PyFuture_Tests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/angwer/cpython/Lib/test/test_asyncio/test_tasks.py", line 1823, in test_log_destroyed_pending_task
    self.assertEqual(Task.all_tasks(loop=self.loop), set())
AssertionError: Items in the first set but not the second:
<Task pending coro=<BaseTaskTests.test_log_destroyed_pending_task.<locals>.kill_me() running at /home/angwer/cpython/Lib/test/test_asyncio/test_tasks.py:1796> wait_for=<Future pending cb=[<TaskWakeupMethWrapper object at 0x7f649f135d98>()] created at /home/angwer/cpython/Lib/test/test_asyncio/test_tasks.py:86> created at /home/angwer/cpython/Lib/asyncio/base_events.py:287>

======================================================================
FAIL: test_log_destroyed_pending_task (test.test_asyncio.test_tasks.PyTask_CFuture_Tests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/angwer/cpython/Lib/test/test_asyncio/test_tasks.py", line 1823, in test_log_destroyed_pending_task
    self.assertEqual(Task.all_tasks(loop=self.loop), set())
AssertionError: Items in the first set but not the second:
<Task pending coro=<BaseTaskTests.test_log_destroyed_pending_task.<locals>.kill_me() running at /home/angwer/cpython/Lib/test/test_asyncio/test_tasks.py:1796> wait_for=<Future pending cb=[Task._wakeup()] created at /home/angwer/cpython/Lib/test/test_asyncio/test_tasks.py:86> created at /home/angwer/cpython/Lib/asyncio/base_events.py:287>

======================================================================
FAIL: test_log_destroyed_pending_task (test.test_asyncio.test_tasks.PyTask_PyFuture_SubclassTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/angwer/cpython/Lib/test/test_asyncio/test_tasks.py", line 1823, in test_log_destroyed_pending_task
    self.assertEqual(Task.all_tasks(loop=self.loop), set())
AssertionError: Items in the first set but not the second:
<Task pending coro=<BaseTaskTests.test_log_destroyed_pending_task.<locals>.kill_me() running at /home/angwer/cpython/Lib/test/test_asyncio/test_tasks.py:1796> wait_for=<Future pending cb=[add_subclass_tests.<locals>.Task._wakeup()] created at /home/angwer/cpython/Lib/test/test_asyncio/test_tasks.py:2001> created at /home/angwer/cpython/Lib/test/test_asyncio/test_tasks.py:83>

======================================================================
FAIL: test_log_destroyed_pending_task (test.test_asyncio.test_tasks.PyTask_PyFuture_Tests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/angwer/cpython/Lib/test/test_asyncio/test_tasks.py", line 1823, in test_log_destroyed_pending_task
    self.assertEqual(Task.all_tasks(loop=self.loop), set())
AssertionError: Items in the first set but not the second:
<Task pending coro=<BaseTaskTests.test_log_destroyed_pending_task.<locals>.kill_me() running at /home/angwer/cpython/Lib/test/test_asyncio/test_tasks.py:1796> wait_for=<Future pending cb=[Task._wakeup()] created at /home/angwer/cpython/Lib/test/test_asyncio/test_tasks.py:86> created at /home/angwer/cpython/Lib/asyncio/base_events.py:287>

======================================================================
FAIL: test_refcycle (test.test_generators.FinalizationTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/angwer/cpython/Lib/test/test_generators.py", line 54, in test_refcycle
    self.assertTrue(finalized)
AssertionError: False is not true

test test_generators failed
test_generators failed

2 tests failed:
    test_asyncio test_generators

Total duration: 17 sec
Tests result: FAILURE

----------
nosy: +xiang.zhang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29049>
_______________________________________

From report at bugs.python.org  Mon Dec 26 01:40:49 2016
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 26 Dec 2016 06:40:49 +0000
Subject: [issue29049] Lazy GC tracking frame
In-Reply-To: <1482408044.82.0.398076651662.issue29049@psf.upfronthosting.co.za>
Message-ID: <1482734449.37.0.51644297168.issue29049@psf.upfronthosting.co.za>


Changes by INADA Naoki <songofacandy at gmail.com>:


Added file: http://bugs.python.org/file46038/29049-fix-generator-refleak.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29049>
_______________________________________

From report at bugs.python.org  Mon Dec 26 01:49:49 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 26 Dec 2016 06:49:49 +0000
Subject: [issue29049] Lazy GC tracking frame
In-Reply-To: <1482408044.82.0.398076651662.issue29049@psf.upfronthosting.co.za>
Message-ID: <1482734989.03.0.888143304953.issue29049@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

I don't have time study the patches. But 29049-fix-generator-refleak.patch fixes the two test failures on my PC. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29049>
_______________________________________

From report at bugs.python.org  Mon Dec 26 01:57:53 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 26 Dec 2016 06:57:53 +0000
Subject: [issue29049] Lazy GC tracking frame
In-Reply-To: <1482408044.82.0.398076651662.issue29049@psf.upfronthosting.co.za>
Message-ID: <1482735473.65.0.884723935398.issue29049@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM.

It seems to me, that the part with Py_DECREF should be pushed to older branches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29049>
_______________________________________

From report at bugs.python.org  Mon Dec 26 02:15:00 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 26 Dec 2016 07:15:00 +0000
Subject: [issue29071] IDLE doesn't highlight f-strings properly
In-Reply-To: <1482714978.44.0.603392455768.issue29071@psf.upfronthosting.co.za>
Message-ID: <1482736500.96.0.208839817408.issue29071@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
stage:  -> test needed
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29071>
_______________________________________

From report at bugs.python.org  Mon Dec 26 03:53:33 2016
From: report at bugs.python.org (=?utf-8?b?5YqJ5YqN5bOw?=)
Date: Mon, 26 Dec 2016 08:53:33 +0000
Subject: [issue29072] the message of help(os.environ.setdefault) have some
 error
Message-ID: <1482742413.83.0.382615378598.issue29072@psf.upfronthosting.co.za>


New submission from ???:

the message `D.setdefault(k[,d])', compiler inform SyntaxError: invalid syntax. I think that it woulld be D.setdefault([k, d]).

----------
assignee: docs at python
components: Documentation
messages: 284015
nosy: docs at python, ???
priority: normal
severity: normal
status: open
title: the message of help(os.environ.setdefault) have some error
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29072>
_______________________________________

From report at bugs.python.org  Mon Dec 26 04:01:56 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 26 Dec 2016 09:01:56 +0000
Subject: [issue29049] Lazy GC tracking frame
In-Reply-To: <1482408044.82.0.398076651662.issue29049@psf.upfronthosting.co.za>
Message-ID: <20161226090153.79676.54707.8B4092D0@psf.io>


Roundup Robot added the comment:

New changeset d6913acb31e3 by INADA Naoki in branch 'default':
Issue #29049: Fix refleak introduced by f5eb0c4f5d37.
https://hg.python.org/cpython/rev/d6913acb31e3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29049>
_______________________________________

From report at bugs.python.org  Mon Dec 26 04:51:11 2016
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 26 Dec 2016 09:51:11 +0000
Subject: [issue29049] Lazy GC tracking frame
In-Reply-To: <1482408044.82.0.398076651662.issue29049@psf.upfronthosting.co.za>
Message-ID: <1482745871.56.0.589911979103.issue29049@psf.upfronthosting.co.za>


INADA Naoki added the comment:

> It seems to me, that the part with Py_DECREF should be pushed to older branches.

PyCoro_New() and PyGen_NewWithQualName() steals f reference, and DECREF when error.
So Py_DECREF is not needed when (gen == NULL). My patch was wrong.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29049>
_______________________________________

From report at bugs.python.org  Mon Dec 26 04:52:44 2016
From: report at bugs.python.org (Fabio Sangiovanni)
Date: Mon, 26 Dec 2016 09:52:44 +0000
Subject: [issue29073] bytearray.__mod__() truncates on first \x00
Message-ID: <1482745964.51.0.352448624616.issue29073@psf.upfronthosting.co.za>


New submission from Fabio Sangiovanni:

Originally posted by Russell Keith-Magee on Twitter:
https://twitter.com/freakboy3742/status/812609675283681280

Reproduced successfully on Python 3.5.2

>>> x = bytearray(1)
>>> y = {}
>>> x % y
Python3.5: bytearray(b'')
Python3.6: bytearray(b'\x00')

also:
>>> bytearray([0,1]) % {} # same with [], (), range(42)
bytearray(b'')
>>> bytearray([1,0]) % {}
bytearray(b'\x01')

----------
components: Interpreter Core
messages: 284018
nosy: sanjioh
priority: normal
severity: normal
status: open
title: bytearray.__mod__() truncates on first \x00
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29073>
_______________________________________

From report at bugs.python.org  Mon Dec 26 04:54:51 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 26 Dec 2016 09:54:51 +0000
Subject: [issue29049] Lazy GC tracking frame
In-Reply-To: <1482408044.82.0.398076651662.issue29049@psf.upfronthosting.co.za>
Message-ID: <20161226095448.20315.21439.16E445D2@psf.io>


Roundup Robot added the comment:

New changeset 5f3ac68f34f2 by INADA Naoki in branch 'default':
Issue #29049: Remove unnecessary Py_DECREF
https://hg.python.org/cpython/rev/5f3ac68f34f2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29049>
_______________________________________

From report at bugs.python.org  Mon Dec 26 05:00:29 2016
From: report at bugs.python.org (Russell Keith-Magee)
Date: Mon, 26 Dec 2016 10:00:29 +0000
Subject: [issue29073] bytearray.__mod__() truncates on first \x00
In-Reply-To: <1482745964.51.0.352448624616.issue29073@psf.upfronthosting.co.za>
Message-ID: <1482746429.94.0.309332977144.issue29073@psf.upfronthosting.co.za>


Russell Keith-Magee added the comment:

Since I was named dropped; it's worth pointing out that this has evidently been fixed - intentionally or otherwise - in 3.6.

It wasn't an issue in 3.4 and earlier because __mod__ wasn't implemented for bytestrings.

----------
nosy: +freakboy3742

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29073>
_______________________________________

From report at bugs.python.org  Mon Dec 26 05:31:23 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 26 Dec 2016 10:31:23 +0000
Subject: [issue29073] bytearray.__mod__() truncates on first \x00
In-Reply-To: <1482745964.51.0.352448624616.issue29073@psf.upfronthosting.co.za>
Message-ID: <1482748283.09.0.685115605461.issue29073@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Indeed, there is an inconsistency between bytes and bytearray in 3.5:

>>> b'a\0b' % ()
b'a\x00b'
>>> bytearray(b'a\0b') % ()
bytearray(b'a')

It was unintentionally fixed in issue25399.

Proposed patch fixes the issue.

----------
keywords: +patch
nosy: +ethan.furman, haypo, serhiy.storchaka
stage:  -> patch review
Added file: http://bugs.python.org/file46039/bytearray_format_nul.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29073>
_______________________________________

From report at bugs.python.org  Mon Dec 26 05:48:49 2016
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 26 Dec 2016 10:48:49 +0000
Subject: [issue29062] hashlib documentation link error
In-Reply-To: <1482571303.3.0.781602557285.issue29062@psf.upfronthosting.co.za>
Message-ID: <1482749329.89.0.21622503008.issue29062@psf.upfronthosting.co.za>


INADA Naoki added the comment:

I like currentmodule directive.

----------
keywords: +patch
Added file: http://bugs.python.org/file46040/29062-currentmodule.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29062>
_______________________________________

From report at bugs.python.org  Mon Dec 26 06:19:07 2016
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 26 Dec 2016 11:19:07 +0000
Subject: [issue29049] Lazy GC tracking frame
In-Reply-To: <1482408044.82.0.398076651662.issue29049@psf.upfronthosting.co.za>
Message-ID: <1482751147.78.0.104314903633.issue29049@psf.upfronthosting.co.za>


Changes by INADA Naoki <songofacandy at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29049>
_______________________________________

From report at bugs.python.org  Mon Dec 26 06:45:15 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 26 Dec 2016 11:45:15 +0000
Subject: [issue29070] Integration tests for pty.spawn on Linux and all other
 platforms
In-Reply-To: <1482684225.17.0.467768789806.issue29070@psf.upfronthosting.co.za>
Message-ID: <1482752715.97.0.974047207042.issue29070@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
components:  -Cross-Build
stage:  -> patch review
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29070>
_______________________________________

From report at bugs.python.org  Mon Dec 26 07:00:29 2016
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 26 Dec 2016 12:00:29 +0000
Subject: [issue27671] FAQ: len() is still function for good reason.
In-Reply-To: <1470214886.13.0.870924776007.issue27671@psf.upfronthosting.co.za>
Message-ID: <1482753629.88.0.459083965449.issue27671@psf.upfronthosting.co.za>


INADA Naoki added the comment:

I can't write long English document.
Can I quote Guido's mail instead?

----------
keywords: +patch
Added file: http://bugs.python.org/file46041/faq-function-method.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27671>
_______________________________________

From report at bugs.python.org  Mon Dec 26 07:32:41 2016
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 26 Dec 2016 12:32:41 +0000
Subject: [issue10614] ZipFile: add a filename_encoding argument
In-Reply-To: <1291362121.18.0.976785403189.issue10614@psf.upfronthosting.co.za>
Message-ID: <1482755561.77.0.191090138839.issue10614@psf.upfronthosting.co.za>


Changes by INADA Naoki <songofacandy at gmail.com>:


----------
components: +Library (Lib) -Extension Modules
stage:  -> patch review
versions: +Python 3.6, Python 3.7 -Python 3.2, Python 3.3
Added file: http://bugs.python.org/file46042/10614-zipfile-encoding.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10614>
_______________________________________

From report at bugs.python.org  Mon Dec 26 07:33:48 2016
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 26 Dec 2016 12:33:48 +0000
Subject: [issue10614] ZipFile: add a filename_encoding argument
In-Reply-To: <1291362121.18.0.976785403189.issue10614@psf.upfronthosting.co.za>
Message-ID: <1482755628.44.0.539346608235.issue10614@psf.upfronthosting.co.za>


Changes by INADA Naoki <songofacandy at gmail.com>:


Removed file: http://bugs.python.org/file46042/10614-zipfile-encoding.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10614>
_______________________________________

From report at bugs.python.org  Mon Dec 26 07:41:55 2016
From: report at bugs.python.org (iMath)
Date: Mon, 26 Dec 2016 12:41:55 +0000
Subject: [issue29074] repr doesn't give full result for this re math result
Message-ID: <1482756115.08.0.598245159081.issue29074@psf.upfronthosting.co.za>


New submission from iMath:

I tested with Python 3.5.2 (v3.5.2:4def2a2901a5, Jun 25 2016, 22:01:18) [MSC v.1900 32 bit (Intel)] on win32

re.search(r'http://v.pptv.com/show/.*?\.html.+', 'http://v.pptv.com/show/2bwkox9SS4nsatI.html?rcc_src=P5') 
does give a match, but it show the result 
<_sre.SRE_Match object; span=(0, 54), match='http://v.pptv.com/show/2bwkox9SS4nsatI.html?rcc_s>
missing rc=P5' in IDLE

BTW, py2.7 works fine

----------
components: Regular Expressions
messages: 284024
nosy: ezio.melotti, mrabarnett, redstone-cold
priority: normal
severity: normal
status: open
title: repr doesn't give full result for this re math result
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29074>
_______________________________________

From report at bugs.python.org  Mon Dec 26 07:49:30 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 26 Dec 2016 12:49:30 +0000
Subject: [issue10614] ZipFile: add a filename_encoding argument
In-Reply-To: <1291362121.18.0.976785403189.issue10614@psf.upfronthosting.co.za>
Message-ID: <1482756570.61.0.281826384536.issue10614@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See also issue28080.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10614>
_______________________________________

From report at bugs.python.org  Mon Dec 26 08:02:11 2016
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 26 Dec 2016 13:02:11 +0000
Subject: [issue10614] ZipFile: add a filename_encoding argument
In-Reply-To: <1291362121.18.0.976785403189.issue10614@psf.upfronthosting.co.za>
Message-ID: <1482757331.16.0.318269738773.issue10614@psf.upfronthosting.co.za>


Changes by INADA Naoki <songofacandy at gmail.com>:


Added file: http://bugs.python.org/file46043/10614-zipfile-encoding.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10614>
_______________________________________

From report at bugs.python.org  Mon Dec 26 08:06:43 2016
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 26 Dec 2016 13:06:43 +0000
Subject: [issue10614] ZipFile: add a filename_encoding argument
In-Reply-To: <1291362121.18.0.976785403189.issue10614@psf.upfronthosting.co.za>
Message-ID: <1482757603.51.0.239348372043.issue10614@psf.upfronthosting.co.za>


INADA Naoki added the comment:

Thanks. Patch posted in issue28080 looks better than mine.

----------
stage: patch review -> 
superseder:  -> Allow reading member names with bogus encodings in zipfile

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10614>
_______________________________________

From report at bugs.python.org  Mon Dec 26 08:10:11 2016
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 26 Dec 2016 13:10:11 +0000
Subject: [issue28080] Allow reading member names with bogus encodings in
 zipfile
In-Reply-To: <1473620375.38.0.155906896901.issue28080@psf.upfronthosting.co.za>
Message-ID: <1482757811.92.0.72164810335.issue28080@psf.upfronthosting.co.za>


Changes by INADA Naoki <songofacandy at gmail.com>:


----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28080>
_______________________________________

From report at bugs.python.org  Mon Dec 26 08:13:06 2016
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 26 Dec 2016 13:13:06 +0000
Subject: [issue26787] test_distutils fails when configured --with-lto
In-Reply-To: <1460874085.6.0.334729464026.issue26787@psf.upfronthosting.co.za>
Message-ID: <1482757986.27.0.716112462026.issue26787@psf.upfronthosting.co.za>


INADA Naoki added the comment:

LGTM

----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26787>
_______________________________________

From report at bugs.python.org  Mon Dec 26 08:26:56 2016
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 26 Dec 2016 13:26:56 +0000
Subject: [issue26758] Unnecessary format string handling for no argument slot
 wrappers in typeobject.c
In-Reply-To: <1460649796.07.0.143785441525.issue26758@psf.upfronthosting.co.za>
Message-ID: <1482758816.45.0.224500742904.issue26758@psf.upfronthosting.co.za>


INADA Naoki added the comment:

fixed via https://hg.python.org/cpython/rev/adcd9131b7c6

----------
nosy: +inada.naoki
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26758>
_______________________________________

From report at bugs.python.org  Mon Dec 26 08:29:49 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 26 Dec 2016 13:29:49 +0000
Subject: [issue28080] Allow reading member names with bogus encodings in
 zipfile
In-Reply-To: <1473620375.38.0.155906896901.issue28080@psf.upfronthosting.co.za>
Message-ID: <1482758989.48.0.920431096721.issue28080@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

A ZipFile can be read when open in not read-only mode. Thus the encoding argument should be accepted when mode != 'r'.

It would be weird to read file names and write new entries with different encodings. Thus the encoding argument should affect output encoding too.

You have named the new ZipFile attribute metadataEncoding. Indeed, I missed this, and other developers missed this when ported to Python 3, but the specification says, that the UTF-8 bit affect not just the encoding of file names, but the encoding of comments. Thus a file comment must be a string, and be decoded with the same encoding as a file name. Currently it is of type bytes. I don't know what is the best way to resolve this issue without breaking backward compatibility. Perhaps add the text_comment property.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28080>
_______________________________________

From report at bugs.python.org  Mon Dec 26 08:37:15 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 26 Dec 2016 13:37:15 +0000
Subject: [issue29062] hashlib documentation link error
In-Reply-To: <1482571303.3.0.781602557285.issue29062@psf.upfronthosting.co.za>
Message-ID: <1482759435.05.0.0691551032162.issue29062@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I didn't tested my suggestion. If it solves the issue and makes all related references correct, feel free to push the patch Inada.

----------
assignee: docs at python -> inada.naoki
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29062>
_______________________________________

From report at bugs.python.org  Mon Dec 26 09:15:50 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 26 Dec 2016 14:15:50 +0000
Subject: [issue29072] the message of help(os.environ.setdefault) have some
 error
In-Reply-To: <1482742413.83.0.382615378598.issue29072@psf.upfronthosting.co.za>
Message-ID: <1482761750.2.0.14857179293.issue29072@psf.upfronthosting.co.za>


R. David Murray added the comment:

The documented syntax is correct.  The '[]' are part of the syntax *specification*, not the syntax itself.  They indicate an optional argument, just as they do in most syntax diagrams.

----------
nosy: +r.david.murray
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29072>
_______________________________________

From report at bugs.python.org  Mon Dec 26 10:32:30 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 26 Dec 2016 15:32:30 +0000
Subject: [issue29056] logging.Formatter doesn't respect more than one
 formatException()
In-Reply-To: <1482514016.63.0.534341960628.issue29056@psf.upfronthosting.co.za>
Message-ID: <1482766350.97.0.495659862411.issue29056@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29056>
_______________________________________

From report at bugs.python.org  Mon Dec 26 10:43:14 2016
From: report at bugs.python.org (Matthew Barnett)
Date: Mon, 26 Dec 2016 15:43:14 +0000
Subject: [issue29074] repr doesn't give full result for this re math result
In-Reply-To: <1482756115.08.0.598245159081.issue29074@psf.upfronthosting.co.za>
Message-ID: <1482766994.29.0.0428743159437.issue29074@psf.upfronthosting.co.za>


Matthew Barnett added the comment:

See issue 17087: "Improve the repr for regular expression match objects".

It was decided that it might be a bad idea to show the entire matched portion of the string because it could be very long, so it's shown truncated if necessary.

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29074>
_______________________________________

From report at bugs.python.org  Mon Dec 26 11:08:56 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 26 Dec 2016 16:08:56 +0000
Subject: [issue29074] repr doesn't give full result for this re math result
In-Reply-To: <1482756115.08.0.598245159081.issue29074@psf.upfronthosting.co.za>
Message-ID: <1482768536.9.0.910689101313.issue29074@psf.upfronthosting.co.za>


R. David Murray added the comment:

If it is truncated, should it end with '...' or [...]?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29074>
_______________________________________

From report at bugs.python.org  Mon Dec 26 13:00:41 2016
From: report at bugs.python.org (Steve Dower)
Date: Mon, 26 Dec 2016 18:00:41 +0000
Subject: [issue29075] Update WINVER to Windows 7
Message-ID: <1482775241.44.0.333291277311.issue29075@psf.upfronthosting.co.za>


New submission from Steve Dower:

Windows Vista SP2 is out of support by the time that Python 3.7 releases (see PEP 0537 and [1]), so we should do the following tasks:

*  update the definition of Py_WINVER in PC/pyconfig.h to 0x0601 _WIN32_WINNT_WIN7
* remove any dynamic API imports that are not required on Win7 (I don't think?there are many, if any)
* remove pre-Win7 supportedOS elements from PC/python.manifest
* block Windows Vista in the installer

We may also be able to take advantage of new flags, particularly related to security (I think LoadLibrary[Ex] got new flags).

If there's anything else we need to do, post it here so we don't forget.

References:
[1]: https://support.microsoft.com/en-us/lifecycle/search?alpha=Windows%20Vista%20Service%20Pack%202

----------
components: Windows
messages: 284034
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Update WINVER to Windows 7
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29075>
_______________________________________

From report at bugs.python.org  Mon Dec 26 13:00:54 2016
From: report at bugs.python.org (Steve Dower)
Date: Mon, 26 Dec 2016 18:00:54 +0000
Subject: [issue29075] Remove Windows Vista support
In-Reply-To: <1482775241.44.0.333291277311.issue29075@psf.upfronthosting.co.za>
Message-ID: <1482775254.35.0.218006398774.issue29075@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at python.org>:


----------
title: Update WINVER to Windows 7 -> Remove Windows Vista support

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29075>
_______________________________________

From report at bugs.python.org  Mon Dec 26 13:37:35 2016
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 26 Dec 2016 18:37:35 +0000
Subject: [issue29056] logging.Formatter doesn't respect more than one
 formatException()
In-Reply-To: <1482514016.63.0.534341960628.issue29056@psf.upfronthosting.co.za>
Message-ID: <1482777455.28.0.573413537431.issue29056@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

I don't consider this a bug, as the logging documentation for the Handler.format() method states:

"Note that the formatted exception information is cached in attribute exc_text. This is useful because the exception information can be pickled and sent across the wire, but you should be careful if you have more than one Formatter subclass which customizes the formatting of exception information. In this case, you will have to clear the cached value after a formatter has done its formatting, so that the next formatter to handle the event doesn?t use the cached value but recalculates it afresh."

So, your suggested workaround is following the approach suggested in the documentation.

We could change the implementation to allow a cache_exception_text attribute (defaulting to True, set in the Handler class), then it could be set to False for individual instances by application developers. This does introduce another attribute to the handler class, so this would have to be added in 3.7 and not in 3.6. I'm not sure it's worth making this change, because the use case for it is not that common.

----------
resolution:  -> not a bug
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29056>
_______________________________________

From report at bugs.python.org  Mon Dec 26 13:46:40 2016
From: report at bugs.python.org (Elias Zamaria)
Date: Mon, 26 Dec 2016 18:46:40 +0000
Subject: [issue29076] Python 3.6 installer doesn't update "python3" shell
 command
Message-ID: <1482778000.76.0.584407589583.issue29076@psf.upfronthosting.co.za>


New submission from Elias Zamaria:

I have a Mac running OS X 10.11.6, Python 3.5.2, and fish 2.3.1. I installed Python 3.6.0, and everything seemed to work fine. However, I typed "python3" in my shell and it started Python 3.5.2.

I restarted my shell and typed "python3", and it still started Python 3.5.2. I ran "which python3" and it told me "/Library/Frameworks/Python.framework/Versions/3.5/bin/python3".

I ran "echo $PATH" and it told me "/Library/Frameworks/Python.framework/Versions/3.5/bin", among other directories that seem unrelated to Python.

I thought that maybe the installer updated my ~/.bash_profile, assuming that I am using bash like most people, but I looked in that file, and the only things affecting my path that look Python-related are adding the directories "/Library/Frameworks/Python.framework/Versions/2.7/bin" and "/Library/Frameworks/Python.framework/Versions/3.5/bin".

I re-ran the installer, clicked the "Customize" button, made sure that the "Shell profile updater" checkbox was checked, and ran "python3", and it started Python 3.5.2.

I can probably fix this by adding the right directory to my $PATH, but I think it is a bug if the installer doesn't make that change for me, or even try to make the change.

----------
components: Installation, macOS
messages: 284036
nosy: elias, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Python 3.6 installer doesn't update "python3" shell command
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29076>
_______________________________________

From report at bugs.python.org  Mon Dec 26 13:46:59 2016
From: report at bugs.python.org (Elias Zamaria)
Date: Mon, 26 Dec 2016 18:46:59 +0000
Subject: [issue29076] Python 3.6 installer doesn't update "python3" shell
 command
In-Reply-To: <1482778000.76.0.584407589583.issue29076@psf.upfronthosting.co.za>
Message-ID: <1482778019.03.0.143659893127.issue29076@psf.upfronthosting.co.za>


Changes by Elias Zamaria <mikez302 at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29076>
_______________________________________

From report at bugs.python.org  Mon Dec 26 13:59:34 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 26 Dec 2016 18:59:34 +0000
Subject: [issue29058] Mark new limited C API
In-Reply-To: <1482538310.89.0.583492092721.issue29058@psf.upfronthosting.co.za>
Message-ID: <1482778774.8.0.576760191994.issue29058@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Updated patch removes PyODict_HasKey() at all, removes PyODict_Check(), PyODict_CheckExact(), PyODict_SIZE() and Py_hexdigits from stable API.

----------
Added file: http://bugs.python.org/file46044/limited-api-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29058>
_______________________________________

From report at bugs.python.org  Mon Dec 26 14:19:02 2016
From: report at bugs.python.org (Steve Wills)
Date: Mon, 26 Dec 2016 19:19:02 +0000
Subject: [issue29077] build failure when enabling dtrace on FreeBSD
Message-ID: <1482779942.39.0.346100216113.issue29077@psf.upfronthosting.co.za>


New submission from Steve Wills:

When enabling dtrace support via the --with-dtrace configure flag, build fails on FreeBSD with this message:

/usr/sbin/dtrace  -o Include/pydtrace_probes.h -h -s
dtrace: option requires an argument -- s

Looks like line 882 of Makefile.pre.in:

    882         $(DTRACE) $(DFLAGS) -o $@ -h -s $<

changing this to:

    882         $(DTRACE) $(DFLAGS) -o $@ -h -s $(srcdir)/Include/pydtrace.d

avoids that issue. Note that bmake is being used here.

After this however, another issue is encountered during linking:

Python/ceval.o: In function `_PyEval_EvalFrameDefault':
Python/ceval.c:(.text+0xc94): undefined reference to `__dtraceenabled_python___function__entry'
Python/ceval.c:(.text+0xcdd): undefined reference to `__dtrace_python___function__entry'
Python/ceval.c:(.text+0xff0): undefined reference to `__dtraceenabled_python___line'
Python/ceval.c:(.text+0x109f): undefined reference to `__dtrace_python___line'
Python/ceval.c:(.text+0x125e): undefined reference to `__dtraceenabled_python___line'
Python/ceval.c:(.text+0x12e5): undefined reference to `__dtraceenabled_python___line'
Python/ceval.c:(.text+0x1358): undefined reference to `__dtraceenabled_python___line'
Python/ceval.c:(.text+0x13f2): undefined reference to `__dtraceenabled_python___line'
Python/ceval.c:(.text+0x146c): undefined reference to `__dtraceenabled_python___line'
Python/ceval.o:Python/ceval.c:(.text+0x14de): more undefined references to `__dtraceenabled_python___line' follow
Python/ceval.o: In function `_PyEval_EvalFrameDefault':
Python/ceval.c:(.text+0x87f2): undefined reference to `__dtraceenabled_python___function__return'
Python/ceval.c:(.text+0x8833): undefined reference to `__dtrace_python___function__return'
Modules/gcmodule.o: In function `collect':
Modules/gcmodule.c:(.text+0x380): undefined reference to `__dtraceenabled_python___gc__start'
Modules/gcmodule.c:(.text+0x38c): undefined reference to `__dtrace_python___gc__start'
Modules/gcmodule.c:(.text+0xe1b): undefined reference to `__dtraceenabled_python___gc__done'
Modules/gcmodule.c:(.text+0xe2a): undefined reference to `__dtrace_python___gc__done'

which I believe is due to dtrace -G modifying Python/ceval.o and Modules/gcmodule.o. 

Finally, note that all calls to dtrace -G or dtrace -h on FreeBSD 11.0 should have -xnolibs added to enable use without the DTrace kernel modules loaded. Otherwise dtrace processes the /usr/lib/dtrace scripts unnecessarily, and errors out when it tries to talk to the DTrace kernel code, causing build failure in a jail.

(I can provide patches, but suspect you have preferences about how the build system work that I'm not aware of, so wanted to explain before patching in ways that aren't satisfactory.)

----------
messages: 284038
nosy: swills
priority: normal
severity: normal
status: open
title: build failure when enabling dtrace on FreeBSD
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29077>
_______________________________________

From report at bugs.python.org  Mon Dec 26 14:49:49 2016
From: report at bugs.python.org (Steve Dower)
Date: Mon, 26 Dec 2016 19:49:49 +0000
Subject: [issue23903] Generate PC/python3.def by scraping headers
In-Reply-To: <1428637761.13.0.348463350169.issue23903@psf.upfronthosting.co.za>
Message-ID: <1482781789.43.0.850183062436.issue23903@psf.upfronthosting.co.za>


Steve Dower added the comment:

Those macros like PyCFunction_New actually need to become functions again, since we need real exports to forward them to the right place. Converting stable API functions to macros breaks the ABI, since modules compiled against the old one can no longer link to newer versions, and modules compiled against newer ones cannot link to older versions.

I'll?try and figure out a way we can compile those functions directly into python3.dll, since that's going to leave us with the best ability to use macros for non-stable API builds. We will, however, need to update the header files to define actual?functions rather than macros when Py_LIMITED_API is set.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23903>
_______________________________________

From report at bugs.python.org  Mon Dec 26 14:54:57 2016
From: report at bugs.python.org (Ned Deily)
Date: Mon, 26 Dec 2016 19:54:57 +0000
Subject: [issue29076] Python 3.6 installer doesn't update "python3" shell
 command
In-Reply-To: <1482778000.76.0.584407589583.issue29076@psf.upfronthosting.co.za>
Message-ID: <1482782097.56.0.0296183158079.issue29076@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
assignee:  -> ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29076>
_______________________________________

From report at bugs.python.org  Mon Dec 26 14:55:22 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 26 Dec 2016 19:55:22 +0000
Subject: [issue28682] Bytes support in os.fwalk()
In-Reply-To: <1479029050.5.0.426622691368.issue28682@psf.upfronthosting.co.za>
Message-ID: <1482782122.73.0.221889239146.issue28682@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +neologix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28682>
_______________________________________

From report at bugs.python.org  Mon Dec 26 15:06:10 2016
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 26 Dec 2016 20:06:10 +0000
Subject: [issue19542] WeakValueDictionary bug in setdefault()&pop()
In-Reply-To: <1384073464.47.0.0676946313386.issue19542@psf.upfronthosting.co.za>
Message-ID: <1482782770.23.0.981574943023.issue19542@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis added the comment:

Newly added test_threaded_weak_valued_pop() triggers ignored KeyError exceptions (on all branches):

$ python3.7 -m test -v test_weakref
...
0:00:00 [1/1] test_weakref
...
test_make_weak_keyed_dict_from_dict (test.test_weakref.MappingTestCase) ... ok
test_make_weak_keyed_dict_from_weak_keyed_dict (test.test_weakref.MappingTestCase) ... ok
test_make_weak_keyed_dict_repr (test.test_weakref.MappingTestCase) ... ok
test_make_weak_valued_dict_from_dict (test.test_weakref.MappingTestCase) ... ok
test_make_weak_valued_dict_from_weak_valued_dict (test.test_weakref.MappingTestCase) ... ok
test_make_weak_valued_dict_misc (test.test_weakref.MappingTestCase) ... ok
test_make_weak_valued_dict_repr (test.test_weakref.MappingTestCase) ... ok
test_threaded_weak_valued_pop (test.test_weakref.MappingTestCase) ... Exception ignored in: <function WeakValueDictionary.__init__.<locals>.remove at 0x7fb20612bb70>
Traceback (most recent call last):
  File "/usr/lib64/python3.7/weakref.py", line 114, in remove
    del self.data[wr.key]
KeyError: (10,)
Exception ignored in: <function WeakValueDictionary.__init__.<locals>.remove at 0x7fb20612bb70>
Traceback (most recent call last):
  File "/usr/lib64/python3.7/weakref.py", line 114, in remove
    del self.data[wr.key]
KeyError: (10,)
Exception ignored in: <function WeakValueDictionary.__init__.<locals>.remove at 0x7fb20612bb70>
Traceback (most recent call last):
  File "/usr/lib64/python3.7/weakref.py", line 114, in remove
    del self.data[wr.key]
KeyError: (10,)
Exception ignored in: <function WeakValueDictionary.__init__.<locals>.remove at 0x7fb20612bb70>
Traceback (most recent call last):
  File "/usr/lib64/python3.7/weakref.py", line 114, in remove
    del self.data[wr.key]
KeyError: (10,)
Exception ignored in: <function WeakValueDictionary.__init__.<locals>.remove at 0x7fb20612bb70>
Traceback (most recent call last):
  File "/usr/lib64/python3.7/weakref.py", line 114, in remove
    del self.data[wr.key]
KeyError: (10,)
Exception ignored in: <function WeakValueDictionary.__init__.<locals>.remove at 0x7fb20612bb70>
Traceback (most recent call last):
  File "/usr/lib64/python3.7/weakref.py", line 114, in remove
    del self.data[wr.key]
KeyError: (10,)
Exception ignored in: <function WeakValueDictionary.__init__.<locals>.remove at 0x7fb20612bb70>
Traceback (most recent call last):
  File "/usr/lib64/python3.7/weakref.py", line 114, in remove
    del self.data[wr.key]
KeyError: (10,)
ok
test_threaded_weak_valued_setdefault (test.test_weakref.MappingTestCase) ... ok
test_weak_keyed_bad_delitem (test.test_weakref.MappingTestCase) ... ok
test_weak_keyed_cascading_deletes (test.test_weakref.MappingTestCase) ... ok
test_weak_keyed_delitem (test.test_weakref.MappingTestCase) ... ok
test_weak_keyed_dict_popitem (test.test_weakref.MappingTestCase) ... ok
test_weak_keyed_dict_setdefault (test.test_weakref.MappingTestCase) ... ok
test_weak_keyed_dict_update (test.test_weakref.MappingTestCase) ... ok
test_weak_keyed_iters (test.test_weakref.MappingTestCase) ... ok
test_weak_keyed_len_cycles (test.test_weakref.MappingTestCase) ... ok
test_weak_keyed_len_race (test.test_weakref.MappingTestCase) ... ok
test_weak_keys (test.test_weakref.MappingTestCase) ... ok
test_weak_keys_destroy_while_iterating (test.test_weakref.MappingTestCase) ... ok
test_weak_valued_delitem (test.test_weakref.MappingTestCase) ... ok
test_weak_valued_dict_popitem (test.test_weakref.MappingTestCase) ... ok
test_weak_valued_dict_setdefault (test.test_weakref.MappingTestCase) ... ok
test_weak_valued_dict_update (test.test_weakref.MappingTestCase) ... ok
test_weak_valued_iters (test.test_weakref.MappingTestCase) ... ok
test_weak_valued_len_cycles (test.test_weakref.MappingTestCase) ... ok
test_weak_valued_len_race (test.test_weakref.MappingTestCase) ... ok
test_weak_values (test.test_weakref.MappingTestCase) ... ok
test_weak_values_destroy_while_iterating (test.test_weakref.MappingTestCase) ... ok
...

----------------------------------------------------------------------
Ran 116 tests in 3.641s
...

----------
nosy: +Arfrever
resolution: fixed -> 
status: closed -> open
versions: +Python 3.7 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19542>
_______________________________________

From report at bugs.python.org  Mon Dec 26 15:06:51 2016
From: report at bugs.python.org (Ned Deily)
Date: Mon, 26 Dec 2016 20:06:51 +0000
Subject: [issue29076] Python 3.6 installer doesn't update "python3" shell
 command
In-Reply-To: <1482778000.76.0.584407589583.issue29076@psf.upfronthosting.co.za>
Message-ID: <1482782811.58.0.971243421277.issue29076@psf.upfronthosting.co.za>


Ned Deily added the comment:

Can you check what the permissions and ownership are on your existing .bash_profile file?  Also, as you suspected, the installer's profile updater script does not currently look for fish initialization files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29076>
_______________________________________

From report at bugs.python.org  Mon Dec 26 15:09:00 2016
From: report at bugs.python.org (Ned Deily)
Date: Mon, 26 Dec 2016 20:09:00 +0000
Subject: [issue29077] build failure when enabling dtrace on FreeBSD
In-Reply-To: <1482779942.39.0.346100216113.issue29077@psf.upfronthosting.co.za>
Message-ID: <1482782940.84.0.304105139751.issue29077@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
components: +Build
nosy: +lukasz.langa
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29077>
_______________________________________

From report at bugs.python.org  Mon Dec 26 15:15:52 2016
From: report at bugs.python.org (Dhushyanth Ramasamy)
Date: Mon, 26 Dec 2016 20:15:52 +0000
Subject: [issue29078] Example in Section 8.1.5 time Objects is broken
Message-ID: <1482783352.26.0.821424852315.issue29078@psf.upfronthosting.co.za>


New submission from Dhushyanth Ramasamy:

The example doesn't import timedelta. This causes an error when attempting to run the example in the interactive window.

----------
assignee: docs at python
components: Documentation
files: datetime.patch
keywords: patch
messages: 284042
nosy: docs at python, rdhushyanth
priority: normal
severity: normal
status: open
title: Example in Section 8.1.5 time Objects is broken
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file46045/datetime.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29078>
_______________________________________

From report at bugs.python.org  Mon Dec 26 15:16:37 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 26 Dec 2016 20:16:37 +0000
Subject: [issue23903] Generate PC/python3.def by scraping headers
In-Reply-To: <1428637761.13.0.348463350169.issue23903@psf.upfronthosting.co.za>
Message-ID: <1482783397.86.0.750293845919.issue23903@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

They do. Functions PyCFunction_New, _PyTrash_deposit_object etc are compiled and exported even if they don't represented in headers.

Actually we can remove the PyCFunction_New function since it was converted to to a macro before Python 3.0 (faabd9867fb8). No one Python 3 extension uses it. But this is separate issue. _PyTrash_deposit_object was used in 3.2.3 and should be kept for binary compatibility.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23903>
_______________________________________

From report at bugs.python.org  Mon Dec 26 15:17:52 2016
From: report at bugs.python.org (Ammar Askar)
Date: Mon, 26 Dec 2016 20:17:52 +0000
Subject: [issue29028] Use-After-Free in PyString_FromStringAndSize() of
 stringobject.c
In-Reply-To: <1482247531.75.0.221402980867.issue29028@psf.upfronthosting.co.za>
Message-ID: <1482783472.57.0.455483100883.issue29028@psf.upfronthosting.co.za>


Ammar Askar added the comment:

The proposed patch fixes this, not sure if a regression test is appropriate here.

Here's a more minimal example that demonstrates the exact problem:
```
class Index():
    def __index__(self):
        global a
        a.append("2")
        return 999

a = bytearray(b"1")
buf = buffer(a)
s = buf[:1:Index()] 
# buf[Index():x:x] or buf[x:x:Index()] will also crash
```

The problem doesn't show up when doing buffer[x:Index()] or [Index():x] because this syntax calls the sq_slice method implemented by buffer object which is passed the indexes as numbers.

However when using slice notation with three arguments, the equivilant of these lines of code is executed:
```
slice_object = slice(x, Index(), x)
buffer[slice_object]
```

During the `buffer[slice_object]`, a call is made in the slice object to find the indexes of the slice. This calls into the __index__ method of the Index class which mutates the underlying storage behind the buffer. However, buffer's subscript method stores the underyling storage in a local variable before calling the GetIndices method (assuming the object won't be mutated) which means that when it returns, it returns a pointer to an older portion of memory.

I took a quick look at listobject, stringobject, unicodeobject, tupleobject and bytearrayobject's subscript methods and it seems they all only access their members after the call to PySlice_GetIndices, so I think they should be fine.

memoryview objects cause a `BufferError: Existing exports of data: object cannot be re-sized` error so Py3 should be fine.

----------
keywords: +needs review, patch
nosy: +ammar2
stage:  -> patch review
Added file: http://bugs.python.org/file46046/buffer-use-after-free-fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29028>
_______________________________________

From report at bugs.python.org  Mon Dec 26 15:29:11 2016
From: report at bugs.python.org (Ammar Askar)
Date: Mon, 26 Dec 2016 20:29:11 +0000
Subject: [issue29028] Use-After-Free in PyString_FromStringAndSize() of
 stringobject.c
In-Reply-To: <1482247531.75.0.221402980867.issue29028@psf.upfronthosting.co.za>
Message-ID: <1482784151.92.0.291051325661.issue29028@psf.upfronthosting.co.za>


Changes by Ammar Askar <ammar at ammaraskar.com>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29028>
_______________________________________

From report at bugs.python.org  Mon Dec 26 15:46:14 2016
From: report at bugs.python.org (Georg Mischler)
Date: Mon, 26 Dec 2016 20:46:14 +0000
Subject: [issue29079] pathlib.resolve() causes infinite loop on Windows
Message-ID: <1482785174.29.0.0980303906914.issue29079@psf.upfronthosting.co.za>


New submission from Georg Mischler:

When pathlib.resolve() is invoked on Windows(10) with an absolute path including a non-existing drive, it gets caught in an infinite loop.

To reproduce:
Select a drive letter that doesn't exist on the system (in my case H:).
Run the following line of code:
    pathlib.Path('h:\\').resolve()

Expected result:
returns the input string unchanged.

Actual result:
pathlib.resolve() ends up in an infinite loop, repeatedly calling _getfinalpathname() on the same string.

----------
components: Library (Lib), Windows
messages: 284045
nosy: Georg Mischler, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: pathlib.resolve() causes infinite loop on Windows
type: behavior
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29079>
_______________________________________

From report at bugs.python.org  Mon Dec 26 15:58:47 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 26 Dec 2016 20:58:47 +0000
Subject: [issue19542] WeakValueDictionary bug in setdefault()&pop()
In-Reply-To: <1384073464.47.0.0676946313386.issue19542@psf.upfronthosting.co.za>
Message-ID: <1482785927.2.0.29254335598.issue19542@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

This is expected, because of https://bugs.python.org/issue28427

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19542>
_______________________________________

From report at bugs.python.org  Mon Dec 26 15:58:59 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 26 Dec 2016 20:58:59 +0000
Subject: [issue19542] WeakValueDictionary bug in setdefault()&pop()
In-Reply-To: <1384073464.47.0.0676946313386.issue19542@psf.upfronthosting.co.za>
Message-ID: <1482785939.4.0.315470665827.issue19542@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19542>
_______________________________________

From report at bugs.python.org  Mon Dec 26 16:02:29 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 26 Dec 2016 21:02:29 +0000
Subject: [issue29079] pathlib.resolve() causes infinite loop on Windows
In-Reply-To: <1482785174.29.0.0980303906914.issue29079@psf.upfronthosting.co.za>
Message-ID: <1482786149.81.0.76580494843.issue29079@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29079>
_______________________________________

From report at bugs.python.org  Mon Dec 26 16:38:37 2016
From: report at bugs.python.org (Steve Dower)
Date: Mon, 26 Dec 2016 21:38:37 +0000
Subject: [issue23903] Generate PC/python3.def by scraping headers
In-Reply-To: <1428637761.13.0.348463350169.issue23903@psf.upfronthosting.co.za>
Message-ID: <1482788317.18.0.813339397553.issue23903@psf.upfronthosting.co.za>


Steve Dower added the comment:

Attached a patch that integrates generation into the build of python3.dll. There are also a couple of fixes for headers to retain functions/data that were previously exported.

The patch includes an updated python3.def file, though I expect that will go away and we'll check in the python3.txt file that is generated on build (which includes the return type). That way we can?fail builds that modify the file (regardless of platform) and require an explicit step when adding to the stable API.

There are still a few functions towards the end of python3.def that I need to figure out how to deal with.?(Also, my sort script doesn't quite match the result from however Serhiy sorted it last, but it's as close as I could get.)

----------
Added file: http://bugs.python.org/file46047/23903_1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23903>
_______________________________________

From report at bugs.python.org  Mon Dec 26 16:41:00 2016
From: report at bugs.python.org (Steve Dower)
Date: Mon, 26 Dec 2016 21:41:00 +0000
Subject: [issue29079] pathlib.resolve() causes infinite loop on Windows
In-Reply-To: <1482785174.29.0.0980303906914.issue29079@psf.upfronthosting.co.za>
Message-ID: <1482788460.18.0.291764231912.issue29079@psf.upfronthosting.co.za>


Steve Dower added the comment:

We should break out of the "while True" loop in _WindowsFlavour.resolve when joining with ".." doesn't result in a different path.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29079>
_______________________________________

From report at bugs.python.org  Mon Dec 26 16:41:08 2016
From: report at bugs.python.org (Steve Dower)
Date: Mon, 26 Dec 2016 21:41:08 +0000
Subject: [issue29079] pathlib.resolve() causes infinite loop on Windows
In-Reply-To: <1482785174.29.0.0980303906914.issue29079@psf.upfronthosting.co.za>
Message-ID: <1482788468.92.0.906388625887.issue29079@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at python.org>:


----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29079>
_______________________________________

From report at bugs.python.org  Mon Dec 26 18:10:43 2016
From: report at bugs.python.org (Elias Zamaria)
Date: Mon, 26 Dec 2016 23:10:43 +0000
Subject: [issue29076] Python 3.6 installer doesn't update "python3" shell
 command
In-Reply-To: <1482778000.76.0.584407589583.issue29076@psf.upfronthosting.co.za>
Message-ID: <1482793843.53.0.207728149507.issue29076@psf.upfronthosting.co.za>


Elias Zamaria added the comment:

I just ran "ls -l ~/.bash_profile" and got the following output:

-rw-r--r--+ 1 Elias  staff  1057 Jul  2 11:04 /Users/Elias/.bash_profile

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29076>
_______________________________________

From report at bugs.python.org  Mon Dec 26 18:30:46 2016
From: report at bugs.python.org (Ned Deily)
Date: Mon, 26 Dec 2016 23:30:46 +0000
Subject: [issue29076] Python 3.6 installer doesn't update "python3" shell
 command
In-Reply-To: <1482778000.76.0.584407589583.issue29076@psf.upfronthosting.co.za>
Message-ID: <1482795046.27.0.460790270469.issue29076@psf.upfronthosting.co.za>


Ned Deily added the comment:

Thanks for the info.  The '+' is the ls output indicates there is extended security information for .bash_profile, probably an access control list entry that affects it.  I suspect that might be the reason that .bash_profile does not get updated by the installer script; it seems to work for me but there are certainly a lot of different configurations the script has to deal with.  Try "ls -le .bash_profile'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29076>
_______________________________________

From report at bugs.python.org  Mon Dec 26 18:38:36 2016
From: report at bugs.python.org (Ammar Askar)
Date: Mon, 26 Dec 2016 23:38:36 +0000
Subject: [issue29071] IDLE doesn't highlight f-strings properly
In-Reply-To: <1482714978.44.0.603392455768.issue29071@psf.upfronthosting.co.za>
Message-ID: <1482795516.5.0.571650345846.issue29071@psf.upfronthosting.co.za>


Ammar Askar added the comment:

I've attached a patch that colorizes f-strings.

The issue is marked as "test needed" which the dev guide says "... reporter should post a script or instructions to let a triager or developer reproduce the issue." 

Steps to re-create are to open an IDLE window and type in the code
```
f"123"
F"123"
u"123"
```
and notice the colorization difference.

----------
keywords: +patch
nosy: +ammar2
stage: test needed -> patch review
Added file: http://bugs.python.org/file46048/idle-f-string-highlight.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29071>
_______________________________________

From report at bugs.python.org  Mon Dec 26 18:40:58 2016
From: report at bugs.python.org (Elias Zamaria)
Date: Mon, 26 Dec 2016 23:40:58 +0000
Subject: [issue29076] Python 3.6 installer doesn't update "python3" shell
 command
In-Reply-To: <1482778000.76.0.584407589583.issue29076@psf.upfronthosting.co.za>
Message-ID: <1482795658.13.0.931146322632.issue29076@psf.upfronthosting.co.za>


Elias Zamaria added the comment:

I just ran "ls -le ~/.bash_profile" and got this result:

-rw-r--r--+ 1 Elias  staff  1057 Jul  2 11:04 /Users/Elias/.bash_profile
 0: user:_spotlight inherited allow read,execute,readattr,readextattr,readsecurity

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29076>
_______________________________________

From report at bugs.python.org  Mon Dec 26 20:47:19 2016
From: report at bugs.python.org (Ned Deily)
Date: Tue, 27 Dec 2016 01:47:19 +0000
Subject: [issue29076] Python 3.6 installer doesn't update "python3" shell
 command
In-Reply-To: <1482778000.76.0.584407589583.issue29076@psf.upfronthosting.co.za>
Message-ID: <1482803239.15.0.617250681488.issue29076@psf.upfronthosting.co.za>


Ned Deily added the comment:

OK, that shouldn't be an issue.  I'm just guessing at this point since nothing has changed in the profile updater script in a long time over many releases.  I'm assuming you are running the installer under the same user name (Elias) and that Elias is an admin user.  Fortunately, you can run the script manually  since a copy is installed in /Applications/Python 3.6.  Try double-clicking on the "Update Shell Profile.command" file there and see what shows up in the ensuing terminal window.  If it now works, try restoring the original file:

mv ~/.bash_profile.pysave ~/.bash_profile

and rerun the installer and, and before quitting the installer, checking the installer log output (CMD-L and then selecting the all messages option) for clues.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29076>
_______________________________________

From report at bugs.python.org  Mon Dec 26 20:57:18 2016
From: report at bugs.python.org (Ned Deily)
Date: Tue, 27 Dec 2016 01:57:18 +0000
Subject: [issue29076] Python 3.6 installer doesn't update "python3" shell
 command
In-Reply-To: <1482778000.76.0.584407589583.issue29076@psf.upfronthosting.co.za>
Message-ID: <1482803838.38.0.482452288152.issue29076@psf.upfronthosting.co.za>


Ned Deily added the comment:

Ah!  If you have made "fish" your default shell, the updater script should fail with the message "Sorry, I don't know how to patch ... shells".  Perhaps your default shell was still bash back when you previously installed Python 3.5 and 2.7?  If so, then the issue is simply that the updater script doesn't support fish.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29076>
_______________________________________

From report at bugs.python.org  Mon Dec 26 22:20:01 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 27 Dec 2016 03:20:01 +0000
Subject: [issue29062] hashlib documentation link error
In-Reply-To: <1482571303.3.0.781602557285.issue29062@psf.upfronthosting.co.za>
Message-ID: <20161227031958.80407.60659.0174A99C@psf.io>


Roundup Robot added the comment:

New changeset 1970c9ea8572 by INADA Naoki in branch 'default':
Issue #29062: doc: Fix hashlib module index conflict
https://hg.python.org/cpython/rev/1970c9ea8572

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29062>
_______________________________________

From report at bugs.python.org  Mon Dec 26 22:28:27 2016
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 27 Dec 2016 03:28:27 +0000
Subject: [issue29062] hashlib documentation link error
In-Reply-To: <1482571303.3.0.781602557285.issue29062@psf.upfronthosting.co.za>
Message-ID: <1482809307.36.0.83102734851.issue29062@psf.upfronthosting.co.za>


Changes by INADA Naoki <songofacandy at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29062>
_______________________________________

From report at bugs.python.org  Mon Dec 26 23:06:45 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 27 Dec 2016 04:06:45 +0000
Subject: [issue29078] Example in Section 8.1.5 time Objects is broken
In-Reply-To: <1482783352.26.0.821424852315.issue29078@psf.upfronthosting.co.za>
Message-ID: <1482811605.89.0.778209828422.issue29078@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

LGTM.

Thanks for your work Dhushyanth! It's appreciated if you could sign the CLA: https://www.python.org/psf/contrib/contrib-form/.

----------
assignee: docs at python -> xiang.zhang
nosy: +xiang.zhang
stage:  -> commit review
versions:  -Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29078>
_______________________________________

From report at bugs.python.org  Mon Dec 26 23:11:54 2016
From: report at bugs.python.org (Dhushyanth Ramasamy)
Date: Tue, 27 Dec 2016 04:11:54 +0000
Subject: [issue29078] Example in Section 8.1.5 time Objects is broken
In-Reply-To: <1482783352.26.0.821424852315.issue29078@psf.upfronthosting.co.za>
Message-ID: <1482811914.75.0.0941453628181.issue29078@psf.upfronthosting.co.za>


Dhushyanth Ramasamy added the comment:

Hi Xiang,
Signed the CLA, but looks like it may take two days to reflect.

----------
Added file: http://bugs.python.org/file46049/Python Contributor Agreement Form - signed.pdf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29078>
_______________________________________

From report at bugs.python.org  Mon Dec 26 23:33:55 2016
From: report at bugs.python.org (Philip Lee)
Date: Tue, 27 Dec 2016 04:33:55 +0000
Subject: [issue29074] repr doesn't give full result for this re math result
In-Reply-To: <1482768536.9.0.910689101313.issue29074@psf.upfronthosting.co.za>
Message-ID: <545ec860.14c.1593e8df4a1.Coremail.redstone-cold@163.com>


Philip Lee added the comment:

I think so, the current behavior is  misleading 

?2016?12?27 00?08?, "R. David Murray"<report at bugs.python.org>??:

R. David Murray added the comment:

If it is truncated, should it end with '...' or [...]?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29074>
_______________________________________

----------
nosy: +iMath

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29074>
_______________________________________

From report at bugs.python.org  Mon Dec 26 23:39:11 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 27 Dec 2016 04:39:11 +0000
Subject: [issue29078] Example in Section 8.1.5 time Objects is broken
In-Reply-To: <1482783352.26.0.821424852315.issue29078@psf.upfronthosting.co.za>
Message-ID: <20161227043907.4083.58861.E8127BA8@psf.io>


Roundup Robot added the comment:

New changeset 878a91174e74 by Xiang Zhang in branch '2.7':
Issue #29078: Add the missing import in datetime.time doc example.
https://hg.python.org/cpython/rev/878a91174e74

New changeset 172b2ac82037 by Xiang Zhang in branch '3.5':
Issue #29078: Add the missing import in datetime.time doc example.
https://hg.python.org/cpython/rev/172b2ac82037

New changeset 83b089b7ab43 by Xiang Zhang in branch '3.6':
Issue #29078: Merge 3.5.
https://hg.python.org/cpython/rev/83b089b7ab43

New changeset f35c3b0b6eda by Xiang Zhang in branch 'default':
Issue #29078: Merge 3.6.
https://hg.python.org/cpython/rev/f35c3b0b6eda

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29078>
_______________________________________

From report at bugs.python.org  Mon Dec 26 23:41:14 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 27 Dec 2016 04:41:14 +0000
Subject: [issue29078] Example in Section 8.1.5 time Objects is broken
In-Reply-To: <1482783352.26.0.821424852315.issue29078@psf.upfronthosting.co.za>
Message-ID: <1482813674.95.0.389976011368.issue29078@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

> Signed the CLA, but looks like it may take two days to reflect.

Thanks. This change is trivial so I can push it first. ;-)

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29078>
_______________________________________

From report at bugs.python.org  Mon Dec 26 23:43:18 2016
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 27 Dec 2016 04:43:18 +0000
Subject: [issue29028] Use-After-Free in PyString_FromStringAndSize() of
 stringobject.c
In-Reply-To: <1482247531.75.0.221402980867.issue29028@psf.upfronthosting.co.za>
Message-ID: <1482813798.84.0.380386136456.issue29028@psf.upfronthosting.co.za>


INADA Naoki added the comment:

LGTM

----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29028>
_______________________________________

From report at bugs.python.org  Tue Dec 27 00:05:58 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 27 Dec 2016 05:05:58 +0000
Subject: [issue29071] IDLE doesn't highlight f-strings properly
In-Reply-To: <1482714978.44.0.603392455768.issue29071@psf.upfronthosting.co.za>
Message-ID: <20161227050555.19780.10945.D789E9C3@psf.io>


Roundup Robot added the comment:

New changeset a48cc85e5706 by Terry Jan Reedy in branch '3.6':
Issue #29071: IDLE now colors f-string prefixes (but not invalid ur prefixes).
https://hg.python.org/cpython/rev/a48cc85e5706

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29071>
_______________________________________

From report at bugs.python.org  Tue Dec 27 00:08:37 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 27 Dec 2016 05:08:37 +0000
Subject: [issue29062] hashlib documentation link error
In-Reply-To: <1482571303.3.0.781602557285.issue29062@psf.upfronthosting.co.za>
Message-ID: <1482815317.29.0.48168939806.issue29062@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

This fixed the index. But the section is still messed up: https://docs.python.org/3/library/crypto.html. The three entries: Module, Examples, Credits in my mind should not appear on the index.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29062>
_______________________________________

From report at bugs.python.org  Tue Dec 27 00:20:10 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 27 Dec 2016 05:20:10 +0000
Subject: [issue29071] IDLE doesn't highlight f-strings properly
In-Reply-To: <1482714978.44.0.603392455768.issue29071@psf.upfronthosting.co.za>
Message-ID: <1482816010.86.0.0465189271765.issue29071@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

There are 10 possible f-string prefixes, including combinations with r/R.  See
https://docs.python.org/3/reference/lexical_analysis.html#string-and-bytes-literals

While adding these, I noticed that IDLE was coloring now invalid ur prefixes and deleted those.

I decided to test by modifying the existing human visual htest.

Ammar: thank you for submitting a patch.  It happens that I wrote my patch before I saw your submission.  If I had seen yours first, I might have given you a chance to finish it.  Feel free to try another IDLE issue.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29071>
_______________________________________

From report at bugs.python.org  Tue Dec 27 00:44:40 2016
From: report at bugs.python.org (Ammar Askar)
Date: Tue, 27 Dec 2016 05:44:40 +0000
Subject: [issue29071] IDLE doesn't highlight f-strings properly
In-Reply-To: <1482714978.44.0.603392455768.issue29071@psf.upfronthosting.co.za>
Message-ID: <1482817480.41.0.394366316718.issue29071@psf.upfronthosting.co.za>


Ammar Askar added the comment:

Not a problem, thank you for the encouragement.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29071>
_______________________________________

From report at bugs.python.org  Tue Dec 27 01:07:26 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 27 Dec 2016 06:07:26 +0000
Subject: [issue29062] hashlib documentation link error
In-Reply-To: <1482571303.3.0.781602557285.issue29062@psf.upfronthosting.co.za>
Message-ID: <20161227060723.106757.22041.A008DCC6@psf.io>


Roundup Robot added the comment:

New changeset c75ef013bca3 by INADA Naoki in branch 'default':
Issue #29062: doc: Fix heading level of hashlib-blake2
https://hg.python.org/cpython/rev/c75ef013bca3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29062>
_______________________________________

From report at bugs.python.org  Tue Dec 27 01:50:35 2016
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 27 Dec 2016 06:50:35 +0000
Subject: [issue29062] hashlib documentation link error
In-Reply-To: <1482571303.3.0.781602557285.issue29062@psf.upfronthosting.co.za>
Message-ID: <1482821435.35.0.279504321598.issue29062@psf.upfronthosting.co.za>


INADA Naoki added the comment:

While section level of Module, Examples, and Credits is fixed,
https://docs.python.org/3/library/crypto.html seems still weird.
It looks like there are two `hashlib` modules.

Now I think hashlib-blake2 should be merged into hashlib.

----------
resolution: fixed -> 
stage: resolved -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29062>
_______________________________________

From report at bugs.python.org  Tue Dec 27 02:03:44 2016
From: report at bugs.python.org (Florent Gallaire)
Date: Tue, 27 Dec 2016 07:03:44 +0000
Subject: [issue24665] CJK support for textwrap
In-Reply-To: <1437276510.99.0.116072917153.issue24665@psf.upfronthosting.co.za>
Message-ID: <1482822224.86.0.322949314667.issue24665@psf.upfronthosting.co.za>


Florent Gallaire added the comment:

Hello everybody,

This is a Python3 version of my lib CJKwrap:
https://github.com/fgallaire/cjkwrap3

It could be integrated as a new lib in Python 3.7.

People who are using textwrap will have no surprise, and people who wants CJK width support will be happy to use it.

Any remarks welcome.

Cheers

----------
versions: +Python 3.7 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24665>
_______________________________________

From report at bugs.python.org  Tue Dec 27 02:06:29 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 27 Dec 2016 07:06:29 +0000
Subject: [issue29062] hashlib documentation link error
In-Reply-To: <1482571303.3.0.781602557285.issue29062@psf.upfronthosting.co.za>
Message-ID: <1482822389.05.0.330262857454.issue29062@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

> Now I think hashlib-blake2 should be merged into hashlib.

+1

INADA, 3.6 branch also suffers the problems here, I didn't see you patch it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29062>
_______________________________________

From report at bugs.python.org  Tue Dec 27 02:44:29 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 27 Dec 2016 07:44:29 +0000
Subject: [issue29062] hashlib documentation link error
In-Reply-To: <1482571303.3.0.781602557285.issue29062@psf.upfronthosting.co.za>
Message-ID: <1482824669.52.0.62593065478.issue29062@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> While section level of Module, Examples, and Credits is fixed,
> https://docs.python.org/3/library/crypto.html seems still weird.
> It looks like there are two `hashlib` modules.

That is because hashlib-blake2.rst is explicitly added to the TOC list in Doc/library/crypto.rst.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29062>
_______________________________________

From report at bugs.python.org  Tue Dec 27 03:04:36 2016
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 27 Dec 2016 08:04:36 +0000
Subject: [issue29062] hashlib documentation link error
In-Reply-To: <1482571303.3.0.781602557285.issue29062@psf.upfronthosting.co.za>
Message-ID: <1482825876.65.0.689809088107.issue29062@psf.upfronthosting.co.za>


INADA Naoki added the comment:

> That is because hashlib-blake2.rst is explicitly added to the TOC list in Doc/library/crypto.rst.

Yes. All rst should be explicitly added by `toctree` or `include`.

In this case, I feel there are no reason to use `include` directive
instead of merging two files.

Another option is adding `toctree` directive in `hashlib.rst`.
But it means we should organize to use sub toctree, like Doc/library/asyncio.rst.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29062>
_______________________________________

From report at bugs.python.org  Tue Dec 27 03:16:08 2016
From: report at bugs.python.org (Gaurav Tatke)
Date: Tue, 27 Dec 2016 08:16:08 +0000
Subject: [issue9004] datetime.utctimetuple() should not set tm_isdst flag to 0
In-Reply-To: <1276659404.06.0.425467293989.issue9004@psf.upfronthosting.co.za>
Message-ID: <1482826568.4.0.771367154309.issue9004@psf.upfronthosting.co.za>


Gaurav Tatke added the comment:

Hi,
I am new to python and would like to contribute. I find this issue easy so changed the documentation of datetime module. I tested it with sphinx. Attaching a patch.

Please let me know if it is correct or needs changes.
Appreciate it!

Regards,
Gaurav

----------
keywords: +patch
nosy: +Gaurav Tatke
Added file: http://bugs.python.org/file46050/timetuple_issue9004.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9004>
_______________________________________

From report at bugs.python.org  Tue Dec 27 03:35:16 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 27 Dec 2016 08:35:16 +0000
Subject: [issue29061] secrets.randbelow(-1) hangs
In-Reply-To: <1482560683.53.0.415654381831.issue29061@psf.upfronthosting.co.za>
Message-ID: <1482827716.0.0.697826659173.issue29061@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29061>
_______________________________________

From report at bugs.python.org  Tue Dec 27 03:46:40 2016
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 27 Dec 2016 08:46:40 +0000
Subject: [issue29062] hashlib documentation link error
In-Reply-To: <1482571303.3.0.781602557285.issue29062@psf.upfronthosting.co.za>
Message-ID: <1482828400.1.0.00991828317509.issue29062@psf.upfronthosting.co.za>


INADA Naoki added the comment:

> INADA, 3.6 branch also suffers the problems here, I didn't see you patch it.

Oh, I'm sorry.
I'll update 3.6 branch in next time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29062>
_______________________________________

From report at bugs.python.org  Tue Dec 27 03:54:35 2016
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 27 Dec 2016 08:54:35 +0000
Subject: [issue29062] hashlib documentation link error
In-Reply-To: <1482571303.3.0.781602557285.issue29062@psf.upfronthosting.co.za>
Message-ID: <1482828875.14.0.636369181177.issue29062@psf.upfronthosting.co.za>


Changes by INADA Naoki <songofacandy at gmail.com>:


Added file: http://bugs.python.org/file46051/merge-hashlib-blake2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29062>
_______________________________________

From report at bugs.python.org  Tue Dec 27 03:55:50 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 27 Dec 2016 08:55:50 +0000
Subject: [issue29055] random.choice on empty sequence should hide previous
 exception [patch]
In-Reply-To: <1482508618.0.0.189699213254.issue29055@psf.upfronthosting.co.za>
Message-ID: <1482828950.87.0.24351804391.issue29055@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29055>
_______________________________________

From report at bugs.python.org  Tue Dec 27 04:07:23 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 27 Dec 2016 09:07:23 +0000
Subject: [issue29055] random.choice on empty sequence should hide previous
 exception [patch]
In-Reply-To: <1482508618.0.0.189699213254.issue29055@psf.upfronthosting.co.za>
Message-ID: <20161227090719.106931.51393.F199B2B5@psf.io>


Roundup Robot added the comment:

New changeset 0001ae913759 by Raymond Hettinger in branch '3.6':
Issue #29055: Suppress upstream exception for random.choice()
https://hg.python.org/cpython/rev/0001ae913759

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29055>
_______________________________________

From report at bugs.python.org  Tue Dec 27 04:09:33 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 27 Dec 2016 09:09:33 +0000
Subject: [issue29055] random.choice on empty sequence should hide previous
 exception [patch]
In-Reply-To: <1482508618.0.0.189699213254.issue29055@psf.upfronthosting.co.za>
Message-ID: <1482829773.84.0.653938293248.issue29055@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Thanks for the patch.

Please submit a contributor agreement for future work.  We would like to have it for all patches (though this one was so tiny it isn't strictly required).

----------
resolution:  -> fixed
status: open -> closed
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29055>
_______________________________________

From report at bugs.python.org  Tue Dec 27 04:13:30 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 27 Dec 2016 09:13:30 +0000
Subject: [issue29061] secrets.randbelow(-1) hangs
In-Reply-To: <1482560683.53.0.415654381831.issue29061@psf.upfronthosting.co.za>
Message-ID: <1482830010.55.0.605534799011.issue29061@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Brendan, would you please submit a contributor agreement.

----------
priority: high -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29061>
_______________________________________

From report at bugs.python.org  Tue Dec 27 04:36:41 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 27 Dec 2016 09:36:41 +0000
Subject: [issue23903] Generate PC/python3.def by scraping headers
In-Reply-To: <1428637761.13.0.348463350169.issue23903@psf.upfronthosting.co.za>
Message-ID: <1482831401.68.0.537890051824.issue23903@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

It is not good that the script removes existing names and adds non-existing names. It is safe to remove names that don't exist in all releases starting from 3.2.0.

1. PyCFunction_New shouldn't be removed in maintained releases. This name is exported, but is unlikely used by third-party code. It can be removed in separate issue, and only in 3.7.

2. PyCmpWrapper_Type shouldn't be added. It is not defined in 3.x.

3. _PyTrash_destroy_chain and like should not be removed for compatibility with 3.2.0-3.2.3.

4. _PyBytes_DecodeEscape shouldn't be added. It is private.

5. Exporting Py_hexdigits looks doubtful. This constant was added for internal use (like _Py_SwappedOp). Unlikely it is used in third-party code. Not attributing it as private looks an error.

6. _Py_TrueStruct shouldn't be removed. It is used in the Py_True macro.

7. *_SizeT names shouldn't be removed. They are used when PY_SSIZE_T_CLEAN is defined before including Python.h (recommended).

8. I think that rather than adding PyODict_Type to limited API, PyODict_Check and PyODict_CheckExact should be excluded from limited API (see issue29058). They never worked in limited API. Note that PyDict_Type as well as other types are not included in limited API. We can consider exposing PyODict_Check and PyODict_CheckExact as functions in limited API in 3.7, but this is other issue.

As for PyArg_VaParse and PyArg_VaParseTupleAndKeywords see issue11626. Seems they were excluded from limited API by mistake.

I suggest first fix errors in python3.def, remove non-existing names, add new names, and only after this add the ability of generating it if it doesn't break python3.def.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23903>
_______________________________________

From report at bugs.python.org  Tue Dec 27 04:53:02 2016
From: report at bugs.python.org (Joseph Shen)
Date: Tue, 27 Dec 2016 09:53:02 +0000
Subject: [issue29080] unnecessary hg required for build version 3.6 on Windows
Message-ID: <1482832382.86.0.80948215742.issue29080@psf.upfronthosting.co.za>


New submission from Joseph Shen:

the released 3.6.0 PCbuild/build.bat required hg for building. but this requirement is not necessary for build python from source. maybe it will be better for us to remove this requirement as the old versions.

----------
components: Build
messages: 284078
nosy: Joseph.Shen
priority: normal
severity: normal
status: open
title: unnecessary hg required for build version 3.6 on Windows
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29080>
_______________________________________

From report at bugs.python.org  Tue Dec 27 05:01:12 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 27 Dec 2016 10:01:12 +0000
Subject: [issue23903] Generate PC/python3.def by scraping headers
In-Reply-To: <1428637761.13.0.348463350169.issue23903@psf.upfronthosting.co.za>
Message-ID: <20161227100109.5888.54627.49A213DA@psf.io>


Roundup Robot added the comment:

New changeset 8423f86486b3 by Serhiy Storchaka in branch '3.5':
Issue #23903: Fixed errors and remove non-existing names in python3.def.
https://hg.python.org/cpython/rev/8423f86486b3

New changeset b5470d08969c by Serhiy Storchaka in branch '3.6':
Issue #23903: Fixed errors and remove non-existing names in python3.def.
https://hg.python.org/cpython/rev/b5470d08969c

New changeset 45507a5751d8 by Serhiy Storchaka in branch 'default':
Issue #23903: Fixed errors and remove non-existing names in python3.def.
https://hg.python.org/cpython/rev/45507a5751d8

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23903>
_______________________________________

From report at bugs.python.org  Tue Dec 27 05:05:12 2016
From: report at bugs.python.org (hywl51)
Date: Tue, 27 Dec 2016 10:05:12 +0000
Subject: [issue29081] time.strptime() return wrong result
Message-ID: <1482833112.13.0.0168836521105.issue29081@psf.upfronthosting.co.za>


New submission from hywl51:

In [1]:import time

In [2]: time.strptime('2016 52 0', '%Y %W %w')
Out[2]: time.struct_time(tm_year=2017, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=6, tm_yday=367, tm_isdst=-1)

When given the parameters above, the function return the struct_time object with tm_yday=367, that is wrong.

I test the codes on Python 2.7.11 and 3.5.1, the error is same.

----------
components: Library (Lib)
messages: 284080
nosy: hywl51
priority: normal
severity: normal
status: open
title: time.strptime() return wrong result
type: behavior
versions: Python 2.7, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29081>
_______________________________________

From report at bugs.python.org  Tue Dec 27 05:09:01 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Tue, 27 Dec 2016 10:09:01 +0000
Subject: [issue29082] In 2.7.13,
 _ctypes.LoadLibrary no longer accepts Unicode objects
Message-ID: <1482833341.48.0.70408057792.issue29082@psf.upfronthosting.co.za>


New submission from Chi Hsuan Yen:

In issue27330, there's one more change besides fixing possible memory leaks. In LoadLibrary function of _ctypes: [1]

-    if (!PyArg_ParseTuple(args, "O|O:LoadLibrary", &nameobj, &ignored))
+    if (!PyArg_ParseTuple(args, "S|O:LoadLibrary", &nameobj, &ignored))

Before this change, both bytes and unicode objects are accepted in _ctypes.LoadLibrary() (Unicode objects are implicitly converted to bytes), and after this change only bytes objects are valid.

There are two options:
* Revert the relevant PyArg_ParseTuple.
  It's better to have fewer surprises on 2.7 branch :)
* Document the change.

I prefer the first option as in our project ```from __future__ import unicode_literals``` is used everywhere, and in Python 3 only Unicode objects are acceptable in _ctypes.LoadLibrary().

Downstream report: https://github.com/rg3/youtube-dl/issues/11540

Added the author and the reviewer in issue27330.

[1] e04c054beb53

----------
components: ctypes
messages: 284081
nosy: Chi Hsuan Yen, martin.panter, serhiy.storchaka
priority: normal
severity: normal
status: open
title: In 2.7.13, _ctypes.LoadLibrary no longer accepts Unicode objects
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29082>
_______________________________________

From report at bugs.python.org  Tue Dec 27 05:09:49 2016
From: report at bugs.python.org (Brendan Donegan)
Date: Tue, 27 Dec 2016 10:09:49 +0000
Subject: [issue29061] secrets.randbelow(-1) hangs
In-Reply-To: <1482830010.55.0.605534799011.issue29061@psf.upfronthosting.co.za>
Message-ID: <CAESAk0iETPWzMv6FFQEdHPWLn0TfbAf_JygGfBQcqmjqV4OiQw@mail.gmail.com>


Brendan Donegan added the comment:

Hi Raymond,

I have done that when creating the patch and have confirmation in my inbox
- perhaps Ewa hasn't filed it yet?

On Tue, 27 Dec 2016 at 14:43 Raymond Hettinger <report at bugs.python.org>
wrote:

>
> Raymond Hettinger added the comment:
>
> Brendan, would you please submit a contributor agreement.
>
> ----------
> priority: high -> normal
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue29061>
> _______________________________________
>

----------
nosy: +brendand

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29061>
_______________________________________

From report at bugs.python.org  Tue Dec 27 05:18:06 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 27 Dec 2016 10:18:06 +0000
Subject: [issue23903] Generate PC/python3.def by scraping headers
In-Reply-To: <1428637761.13.0.348463350169.issue23903@psf.upfronthosting.co.za>
Message-ID: <20161227101803.107001.17271.4CF0E012@psf.io>


Roundup Robot added the comment:

New changeset d95fee442e27 by Serhiy Storchaka in branch '3.5':
Issue #23903: Added missed names to PC/python3.def.
https://hg.python.org/cpython/rev/d95fee442e27

New changeset cb864fc4b3be by Serhiy Storchaka in branch '3.6':
Issue #23903: Added missed names to PC/python3.def.
https://hg.python.org/cpython/rev/cb864fc4b3be

New changeset 513852ad0c5c by Serhiy Storchaka in branch 'default':
Issue #23903: Added missed names to PC/python3.def.
https://hg.python.org/cpython/rev/513852ad0c5c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23903>
_______________________________________

From report at bugs.python.org  Tue Dec 27 05:24:22 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 27 Dec 2016 10:24:22 +0000
Subject: [issue29011] No entry Deque in typing.py
In-Reply-To: <1482128373.3.0.983889719325.issue29011@psf.upfronthosting.co.za>
Message-ID: <1482834262.11.0.793076454802.issue29011@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


Added file: http://bugs.python.org/file46052/Deque2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29011>
_______________________________________

From report at bugs.python.org  Tue Dec 27 06:19:00 2016
From: report at bugs.python.org (Anand Reddy Pandikunta)
Date: Tue, 27 Dec 2016 11:19:00 +0000
Subject: [issue12276] 3.x ignores sys.tracebacklimit=0
In-Reply-To: <1307436501.83.0.59684150491.issue12276@psf.upfronthosting.co.za>
Message-ID: <1482837540.41.0.331007091831.issue12276@psf.upfronthosting.co.za>


Anand Reddy Pandikunta added the comment:

This patch fixes the issue. I have also added 2 test cases to make sure it works.

----------
keywords: +patch
nosy: +ChillarAnand -docs at python
Added file: http://bugs.python.org/file46053/Limit-traceback-if-sys.tracebacklimit-is-set.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12276>
_______________________________________

From report at bugs.python.org  Tue Dec 27 06:33:38 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 27 Dec 2016 11:33:38 +0000
Subject: [issue29056] logging.Formatter doesn't respect more than one
 formatException()
In-Reply-To: <1482514016.63.0.534341960628.issue29056@psf.upfronthosting.co.za>
Message-ID: <1482838418.6.0.641111676062.issue29056@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Can we close this?

----------
nosy: +rhettinger
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29056>
_______________________________________

From report at bugs.python.org  Tue Dec 27 06:36:53 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 27 Dec 2016 11:36:53 +0000
Subject: [issue29025] random.seed() relation to hash() function and its
 determinism is vague
In-Reply-To: <1482239237.17.0.976890507022.issue29025@psf.upfronthosting.co.za>
Message-ID: <1482838613.17.0.572145793085.issue29025@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

This is out of date.
See http://bugs.python.org/issue27706

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29025>
_______________________________________

From report at bugs.python.org  Tue Dec 27 07:15:19 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 27 Dec 2016 12:15:19 +0000
Subject: [issue29069] Default PyPI URL in docs is not what is really in code
In-Reply-To: <1482680312.49.0.384857389372.issue29069@psf.upfronthosting.co.za>
Message-ID: <20161227121516.79585.8333.FB9FB0B9@psf.io>


Roundup Robot added the comment:

New changeset c4cd7e00a640 by Berker Peksag in branch '3.5':
Issue #29069: Update the default URL of PyPI server
https://hg.python.org/cpython/rev/c4cd7e00a640

New changeset b1ccf713e8f8 by Berker Peksag in branch '3.6':
Issue #29069: Merge from 3.5
https://hg.python.org/cpython/rev/b1ccf713e8f8

New changeset b712e4818ff8 by Berker Peksag in branch 'default':
Issue #29069: Merge from 3.6
https://hg.python.org/cpython/rev/b712e4818ff8

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29069>
_______________________________________

From report at bugs.python.org  Tue Dec 27 07:16:11 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 27 Dec 2016 12:16:11 +0000
Subject: [issue29069] Default PyPI URL in docs is not what is really in code
In-Reply-To: <1482680312.49.0.384857389372.issue29069@psf.upfronthosting.co.za>
Message-ID: <1482840971.18.0.906080132891.issue29069@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks!

----------
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type:  -> behavior
versions: +Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29069>
_______________________________________

From report at bugs.python.org  Tue Dec 27 07:27:14 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 27 Dec 2016 12:27:14 +0000
Subject: [issue20486] msilib: can't close opened database
In-Reply-To: <1391355449.68.0.999858284587.issue20486@psf.upfronthosting.co.za>
Message-ID: <1482841634.16.0.316245819128.issue20486@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, 12345. Steve knows better, but I think the method should be named "Close" instead of "close" like _msi.View's Close method.

Also, I couldn't apply your patch:

$ hg imp http://bugs.python.org/file45971/Add_ability_to_close_MSI_database_.patch
applying http://bugs.python.org/file45971/Add_ability_to_close_MSI_database_.patch
unable to find '_msi.c' for patching
patching file _msi.c
2 out of 2 hunks FAILED -- saving rejects to file _msi.c.rej
abort: patch failed to apply

You may want to read https://docs.python.org/devguide/patch.html for details about creating a patch.

----------
nosy: +berker.peksag
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20486>
_______________________________________

From report at bugs.python.org  Tue Dec 27 07:43:58 2016
From: report at bugs.python.org (lilydjwg)
Date: Tue, 27 Dec 2016 12:43:58 +0000
Subject: [issue27650] Implement `__repr__` methods for logging.Logger and
 others
In-Reply-To: <1469822965.14.0.109412472968.issue27650@psf.upfronthosting.co.za>
Message-ID: <1482842638.6.0.558956227069.issue27650@psf.upfronthosting.co.za>


lilydjwg added the comment:

This hangs this test from celery: https://github.com/celery/celery/blob/master/t/unit/app/test_log.py#L72

It constructs a Logger with `.parent` to itself, making getEffectiveLevel loop forever. The code tries to raise an exception when such loops are detected, but its message contains the logger's repr which calls getEffectiveLevel.

----------
nosy: +lilydjwg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27650>
_______________________________________

From report at bugs.python.org  Tue Dec 27 07:52:02 2016
From: report at bugs.python.org (Felix Yan)
Date: Tue, 27 Dec 2016 12:52:02 +0000
Subject: [issue27650] Implement `__repr__` methods for logging.Logger and
 others
In-Reply-To: <1469822965.14.0.109412472968.issue27650@psf.upfronthosting.co.za>
Message-ID: <1482843122.23.0.780858002507.issue27650@psf.upfronthosting.co.za>


Changes by Felix Yan <felixonmars at archlinux.org>:


----------
nosy: +felixonmars

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27650>
_______________________________________

From report at bugs.python.org  Tue Dec 27 08:00:23 2016
From: report at bugs.python.org (Brendan Donegan)
Date: Tue, 27 Dec 2016 13:00:23 +0000
Subject: [issue29061] secrets.randbelow(-1) hangs
In-Reply-To: <1482560683.53.0.415654381831.issue29061@psf.upfronthosting.co.za>
Message-ID: <1482843623.31.0.389646882505.issue29061@psf.upfronthosting.co.za>


Brendan Donegan added the comment:

Ok, here's a second version of the patch. Normally I don't like testing multiple things in one test but I've gone with what seems to be the convention here in test_secrets.py

----------
Added file: http://bugs.python.org/file46054/issue_29061_randbelow_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29061>
_______________________________________

From report at bugs.python.org  Tue Dec 27 08:05:21 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 27 Dec 2016 13:05:21 +0000
Subject: [issue29058] Mark new limited C API
In-Reply-To: <1482538310.89.0.583492092721.issue29058@psf.upfronthosting.co.za>
Message-ID: <20161227130517.19864.51460.63C43C43@psf.io>


Roundup Robot added the comment:

New changeset f26c16aba11e by Serhiy Storchaka in branch '3.6':
Issue #29058: All stable API extensions added after Python 3.2 are now
https://hg.python.org/cpython/rev/f26c16aba11e

New changeset 77f5f31bf699 by Serhiy Storchaka in branch 'default':
Issue #29058: All stable API extensions added after Python 3.2 are now
https://hg.python.org/cpython/rev/77f5f31bf699

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29058>
_______________________________________

From report at bugs.python.org  Tue Dec 27 08:09:56 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 27 Dec 2016 13:09:56 +0000
Subject: [issue28998] Unifying Long Integers and Integers in 2.7
In-Reply-To: <1481967458.92.0.739722865425.issue28998@psf.upfronthosting.co.za>
Message-ID: <20161227130953.19637.30475.FB8762EB@psf.io>


Roundup Robot added the comment:

New changeset ffcb321ba9c0 by Serhiy Storchaka in branch '2.7':
Issue #28998: More APIs now support longs as well as ints.
https://hg.python.org/cpython/rev/ffcb321ba9c0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28998>
_______________________________________

From report at bugs.python.org  Tue Dec 27 08:10:23 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 27 Dec 2016 13:10:23 +0000
Subject: [issue28998] Unifying Long Integers and Integers in 2.7
In-Reply-To: <1481967458.92.0.739722865425.issue28998@psf.upfronthosting.co.za>
Message-ID: <1482844223.18.0.805865511471.issue28998@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28998>
_______________________________________

From report at bugs.python.org  Tue Dec 27 08:14:30 2016
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 27 Dec 2016 13:14:30 +0000
Subject: [issue29056] logging.Formatter doesn't respect more than one
 formatException()
In-Reply-To: <1482514016.63.0.534341960628.issue29056@psf.upfronthosting.co.za>
Message-ID: <1482844470.07.0.781128524883.issue29056@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29056>
_______________________________________

From report at bugs.python.org  Tue Dec 27 08:18:18 2016
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 27 Dec 2016 13:18:18 +0000
Subject: [issue27650] Implement `__repr__` methods for logging.Logger and
 others
In-Reply-To: <1469822965.14.0.109412472968.issue27650@psf.upfronthosting.co.za>
Message-ID: <1482844698.2.0.111237237704.issue27650@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

This sounds like a Celery bug, so I don't propose to change anything in this area.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27650>
_______________________________________

From report at bugs.python.org  Tue Dec 27 08:19:31 2016
From: report at bugs.python.org (Christopher Hoadley)
Date: Tue, 27 Dec 2016 13:19:31 +0000
Subject: [issue24869] shlex lineno inaccurate with certain inputs
In-Reply-To: <1439571963.46.0.603944237065.issue24869@psf.upfronthosting.co.za>
Message-ID: <1482844771.04.0.386271125093.issue24869@psf.upfronthosting.co.za>


Changes by Christopher Hoadley <chris.hoadley at gmail.com>:


----------
type:  -> behavior
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24869>
_______________________________________

From report at bugs.python.org  Tue Dec 27 08:21:17 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 27 Dec 2016 13:21:17 +0000
Subject: [issue29058] Mark new limited C API
In-Reply-To: <1482538310.89.0.583492092721.issue29058@psf.upfronthosting.co.za>
Message-ID: <1482844877.14.0.816862975851.issue29058@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Changes are not applied to 3.5. It is harder to do since many private functions in 3.5 are still available in limited API. And there is a risk to break third-party code that defines Py_LIMITED_API, but uses API with higher version than required.

----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions:  -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29058>
_______________________________________

From report at bugs.python.org  Tue Dec 27 08:21:49 2016
From: report at bugs.python.org (Christopher Hoadley)
Date: Tue, 27 Dec 2016 13:21:49 +0000
Subject: [issue16121] shlex.shlex.error_leader() reports incorrect line number
In-Reply-To: <1349295018.27.0.805550020258.issue16121@psf.upfronthosting.co.za>
Message-ID: <1482844909.01.0.850796068633.issue16121@psf.upfronthosting.co.za>


Changes by Christopher Hoadley <chris.hoadley at gmail.com>:


----------
nosy: +hoadlck
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16121>
_______________________________________

From report at bugs.python.org  Tue Dec 27 08:26:30 2016
From: report at bugs.python.org (Christopher Hoadley)
Date: Tue, 27 Dec 2016 13:26:30 +0000
Subject: [issue19120] shlex.shlex.lineno reports a different number depending
 on the previous token
In-Reply-To: <1380422113.39.0.502795028764.issue19120@psf.upfronthosting.co.za>
Message-ID: <1482845190.49.0.839278682312.issue19120@psf.upfronthosting.co.za>


Changes by Christopher Hoadley <chris.hoadley at gmail.com>:


----------
nosy: +hoadlck
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19120>
_______________________________________

From report at bugs.python.org  Tue Dec 27 08:37:26 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 27 Dec 2016 13:37:26 +0000
Subject: [issue28427] WeakValueDictionary next bug (with multithreading)
In-Reply-To: <1476354989.22.0.575160455599.issue28427@psf.upfronthosting.co.za>
Message-ID: <20161227133723.79585.40832.BB519503@psf.io>


Roundup Robot added the comment:

New changeset b8b0718d424f by Antoine Pitrou in branch '3.5':
Issue #28427: old keys should not remove new values from
https://hg.python.org/cpython/rev/b8b0718d424f

New changeset 97d6616b2d22 by Antoine Pitrou in branch '3.6':
Issue #28427: old keys should not remove new values from
https://hg.python.org/cpython/rev/97d6616b2d22

New changeset e5ce7bdf9e99 by Antoine Pitrou in branch 'default':
Issue #28427: old keys should not remove new values from
https://hg.python.org/cpython/rev/e5ce7bdf9e99

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28427>
_______________________________________

From report at bugs.python.org  Tue Dec 27 08:41:52 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 27 Dec 2016 13:41:52 +0000
Subject: [issue29083] Readd PyArg_VaParse to the stable API
Message-ID: <1482846112.52.0.144835029316.issue29083@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Seems PyArg_VaParse() and PyArg_VaParseTupleAndKeywords() were excluded from the stable API by the mistake in fixing issue11626. These functions was in the stable API before 3.3, and the documentation doesn't mention that they are not in the stable API.

I think they should be readded to the stable API.

----------
components: Interpreter Core
messages: 284097
nosy: loewis, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Readd PyArg_VaParse to the stable API
type: compile error
versions: Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29083>
_______________________________________

From report at bugs.python.org  Tue Dec 27 08:42:14 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 27 Dec 2016 13:42:14 +0000
Subject: [issue23903] Generate PC/python3.def by scraping headers
In-Reply-To: <1428637761.13.0.348463350169.issue23903@psf.upfronthosting.co.za>
Message-ID: <1482846134.34.0.851840070748.issue23903@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
dependencies: +Readd PyArg_VaParse to the stable API

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23903>
_______________________________________

From report at bugs.python.org  Tue Dec 27 08:59:17 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 27 Dec 2016 13:59:17 +0000
Subject: [issue29084] C API of OrderedDict
Message-ID: <1482847157.79.0.799208161515.issue29084@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

C API of the C implementation of OrderedDict was added in 3.5 together with the C implementation of OrderedDict. But it was never announced nor documented. Some macros contain bugs. PyODict_Check() and PyODict_CheckExact() are declared in the limited API, but don't work since use PyODict_Type not available in the limited API. PyODict_SIZE() is expanded to syntactically incorrect code and it's name is not consistent with similar macros: PyTuple_GET_SIZE, PyList_GET_SIZE and just added PyDict_GET_SIZE. Many names are just transparent wrappers around PyDict API (and they can't be different).

Since PyODict C API is not documented, partially not working and partially redundant, and the C implementation of OrderedDict is optional (other Python implementations can provide just Python implementation of OrderedDict), I think this C API should be made private if not removed.

----------
components: Interpreter Core
messages: 284098
nosy: eric.snow, rhettinger, serhiy.storchaka
priority: normal
severity: normal
status: open
title: C API of OrderedDict

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29084>
_______________________________________

From report at bugs.python.org  Tue Dec 27 09:04:35 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 27 Dec 2016 14:04:35 +0000
Subject: [issue29082] In 2.7.13,
 _ctypes.LoadLibrary no longer accepts Unicode objects
In-Reply-To: <1482833341.48.0.70408057792.issue29082@psf.upfronthosting.co.za>
Message-ID: <1482847475.53.0.295907860778.issue29082@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Good catch Chi Hsuan Yen! This is my mistake, I though PyString_Size() works only with str (as many similar *_Size() functions). Agreed, this change should be reverted. Do you want provide the patch with tests?

----------
keywords: +easy (C)
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29082>
_______________________________________

From report at bugs.python.org  Tue Dec 27 09:09:49 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 27 Dec 2016 14:09:49 +0000
Subject: [issue28427] WeakValueDictionary next bug (with multithreading)
In-Reply-To: <1476354989.22.0.575160455599.issue28427@psf.upfronthosting.co.za>
Message-ID: <20161227140946.107061.50202.31A56B5D@psf.io>


Roundup Robot added the comment:

New changeset 9acdcafd1418 by Antoine Pitrou in branch '2.7':
Issue #28427: old keys should not remove new values from
https://hg.python.org/cpython/rev/9acdcafd1418

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28427>
_______________________________________

From report at bugs.python.org  Tue Dec 27 09:11:09 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 27 Dec 2016 14:11:09 +0000
Subject: [issue28427] WeakValueDictionary next bug (with multithreading)
In-Reply-To: <1476354989.22.0.575160455599.issue28427@psf.upfronthosting.co.za>
Message-ID: <1482847869.22.0.139327533374.issue28427@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I've pushed the fixes now.  It does introduce a small amount of additional code duplication in dictobject.c, but nothing unmanageable.

Sidenote: all branches now have a different version of dict object each, which makes maintenance really painful...

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28427>
_______________________________________

From report at bugs.python.org  Tue Dec 27 09:33:49 2016
From: report at bugs.python.org (Dan Passaro)
Date: Tue, 27 Dec 2016 14:33:49 +0000
Subject: [issue29056] logging.Formatter doesn't respect more than one
 formatException()
In-Reply-To: <1482514016.63.0.534341960628.issue29056@psf.upfronthosting.co.za>
Message-ID: <1482849229.22.0.518968226106.issue29056@psf.upfronthosting.co.za>


Dan Passaro added the comment:

If there's no interest in changing the behavior I'd at least suggest that this caching is mentioned in the docs for the formatException() method specifically, with some kind of attention-grabbing note. (Right now this behavior is only explained in the format() method's docs which, as you might be able to infer, I did not think to check.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29056>
_______________________________________

From report at bugs.python.org  Tue Dec 27 09:44:37 2016
From: report at bugs.python.org (Steve Dower)
Date: Tue, 27 Dec 2016 14:44:37 +0000
Subject: [issue29058] Mark new limited C API
In-Reply-To: <1482538310.89.0.583492092721.issue29058@psf.upfronthosting.co.za>
Message-ID: <1482849877.38.0.0214975473741.issue29058@psf.upfronthosting.co.za>


Steve Dower added the comment:

Can we add a #warn to the headers then? So people know that just defining Py_LIMITED_API actually implies =0x03050000 (or whatever value is appropriate)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29058>
_______________________________________

From report at bugs.python.org  Tue Dec 27 09:47:41 2016
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 27 Dec 2016 14:47:41 +0000
Subject: [issue29056] logging.Formatter doesn't respect more than one
 formatException()
In-Reply-To: <1482514016.63.0.534341960628.issue29056@psf.upfronthosting.co.za>
Message-ID: <1482850061.53.0.759242872248.issue29056@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

Perhaps I will try to make it even clearer, but to be fair, the format() documentation is just a few paragraphs above the formatException() documentation. It's all in the section entitled "Formatter Objects", and it's IMO reasonable to expect the whole reasonably short section to be scanned before going to the trouble of raising an issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29056>
_______________________________________

From report at bugs.python.org  Tue Dec 27 09:53:45 2016
From: report at bugs.python.org (Steve Dower)
Date: Tue, 27 Dec 2016 14:53:45 +0000
Subject: [issue23903] Generate PC/python3.def by scraping headers
In-Reply-To: <1428637761.13.0.348463350169.issue23903@psf.upfronthosting.co.za>
Message-ID: <1482850425.73.0.203154567305.issue23903@psf.upfronthosting.co.za>


Steve Dower added the comment:

Unfortunately, there's no way too remove defined names from the DLL during Python 3 at all, except where the prototype was never provided. PyCFunction_New has always been a macro, and PySys_SetDefaultEncoding looks to have been removed before the API was committed.

Maintaining an export and a macro is going to be awkward, so I think we should just change them back to functions. Any half-decent optimizing compiler is going to inline it within core, and it's better than having two implementations in different places of the same function.

But yes I agree, fix the def first and then automate. But I don't want to fix it but adding things that were never usable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23903>
_______________________________________

From report at bugs.python.org  Tue Dec 27 09:54:30 2016
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 27 Dec 2016 14:54:30 +0000
Subject: [issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew
 installs fragile
In-Reply-To: <1411623045.52.0.589017779939.issue22490@psf.upfronthosting.co.za>
Message-ID: <1482850470.63.0.647416497088.issue22490@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

I'm not sure if msg230947 is still correct, and it seems neater to remove __PYVENV_LAUNCHER__ from where it's defined in the first place (the stub launcher C file) if it was just a shim needed around the time the functionality was developed (pre the 3.3 release).

It would be helpful if a Mac person could try removing it and seeing if the resulting framework builds of Python on OS X are adversely affected.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22490>
_______________________________________

From report at bugs.python.org  Tue Dec 27 10:19:40 2016
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 27 Dec 2016 15:19:40 +0000
Subject: [issue28446] pyvenv generates malformed hashbangs for scripts
In-Reply-To: <1476492788.48.0.267846160291.issue28446@psf.upfronthosting.co.za>
Message-ID: <1482851980.61.0.167133316421.issue28446@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

To reiterate Alex Regueiro's point, I don't think this is a bug, but a shortcoming of the underlying Berkeley exec(2) implementation. See this post:

https://lists.gnu.org/archive/html/bug-bash/2008-05/msg00053.html

We can leave the implementation as is, as on Windows the Python launcher should honour spaces in the interpreter path.

Spaces in shebang lines are not supported where they're not supported by the underlying POSIX implementation - which includes Linux and OS X, AFAICT.

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28446>
_______________________________________

From report at bugs.python.org  Tue Dec 27 10:21:53 2016
From: report at bugs.python.org (Ned Deily)
Date: Tue, 27 Dec 2016 15:21:53 +0000
Subject: [issue29080] unnecessary hg required for build version 3.6 on Windows
In-Reply-To: <1482832382.86.0.80948215742.issue29080@psf.upfronthosting.co.za>
Message-ID: <1482852113.25.0.533873825698.issue29080@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29080>
_______________________________________

From report at bugs.python.org  Tue Dec 27 10:55:15 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 27 Dec 2016 15:55:15 +0000
Subject: [issue23903] Generate PC/python3.def by scraping headers
In-Reply-To: <1428637761.13.0.348463350169.issue23903@psf.upfronthosting.co.za>
Message-ID: <20161227155511.20315.98641.54E75BFB@psf.io>


Roundup Robot added the comment:

New changeset 2e5ad97c9c19 by Serhiy Storchaka in branch '3.5':
Issue #23903: Added missed Windows-specific names to PC/python3.def.
https://hg.python.org/cpython/rev/2e5ad97c9c19

New changeset 86a412584c02 by Serhiy Storchaka in branch '3.6':
Issue #23903: Added missed Windows-specific names to PC/python3.def.
https://hg.python.org/cpython/rev/86a412584c02

New changeset 3a2595f82447 by Serhiy Storchaka in branch 'default':
Issue #23903: Added missed Windows-specific names to PC/python3.def.
https://hg.python.org/cpython/rev/3a2595f82447

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23903>
_______________________________________

From report at bugs.python.org  Tue Dec 27 10:59:28 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 27 Dec 2016 15:59:28 +0000
Subject: [issue28915] Modify PyObject_CallFunction() to use fast call
 internally
In-Reply-To: <1481245654.11.0.143889949597.issue28915@psf.upfronthosting.co.za>
Message-ID: <20161227155925.79722.27701.7A4759EF@psf.io>


Roundup Robot added the comment:

New changeset fa9933bf4ea0 by Serhiy Storchaka in branch 'default':
Issue #28915: Exclude _Py_VaBuildStack from the limited API.
https://hg.python.org/cpython/rev/fa9933bf4ea0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28915>
_______________________________________

From report at bugs.python.org  Tue Dec 27 11:34:47 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 27 Dec 2016 16:34:47 +0000
Subject: [issue29058] Mark new limited C API
In-Reply-To: <1482538310.89.0.583492092721.issue29058@psf.upfronthosting.co.za>
Message-ID: <1482856487.92.0.136867114437.issue29058@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Just defining Py_LIMITED_API actually implies =0x03020000.

I have no idea where a #warn can be added.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29058>
_______________________________________

From report at bugs.python.org  Tue Dec 27 11:37:50 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Tue, 27 Dec 2016 16:37:50 +0000
Subject: [issue29082] In 2.7.13,
 _ctypes.LoadLibrary no longer accepts Unicode objects
In-Reply-To: <1482833341.48.0.70408057792.issue29082@psf.upfronthosting.co.za>
Message-ID: <1482856670.99.0.567803932877.issue29082@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

Sorry, but I'm afraid of being unable to test it. I tried to setup a Windows build environment for 2.x but failed. (I've once successfully built 3.x on Windows for issue25939, but things seems different now :(

----------
keywords: +patch
Added file: http://bugs.python.org/file46055/LoadLibrary_revert_arg_parsing.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29082>
_______________________________________

From report at bugs.python.org  Tue Dec 27 11:38:11 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Tue, 27 Dec 2016 16:38:11 +0000
Subject: [issue29061] secrets.randbelow(-1) hangs
In-Reply-To: <1482560683.53.0.415654381831.issue29061@psf.upfronthosting.co.za>
Message-ID: <1482856691.42.0.869759057338.issue29061@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

SystemRandom._randbelow has this problem, perhaps it should be fixed there, not in one of many possible wrappers for it?

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29061>
_______________________________________

From report at bugs.python.org  Tue Dec 27 11:41:49 2016
From: report at bugs.python.org (Brendan Donegan)
Date: Tue, 27 Dec 2016 16:41:49 +0000
Subject: [issue29061] secrets.randbelow(-1) hangs
In-Reply-To: <1482856691.42.0.869759057338.issue29061@psf.upfronthosting.co.za>
Message-ID: <CAESAk0jX0po0-Pm2PiFm4h8FnZkwxQADeBeVLZSdckhp-22vxA@mail.gmail.com>


Brendan Donegan added the comment:

If I'm not mistaken, _randbelow is defined in Random, which SystemRandom
inherits from. Just for clarity

On Tue, 27 Dec 2016 at 22:08 Josh Rosenberg <report at bugs.python.org> wrote:

>
> Josh Rosenberg added the comment:
>
> SystemRandom._randbelow has this problem, perhaps it should be fixed
> there, not in one of many possible wrappers for it?
>
> ----------
> nosy: +josh.r
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue29061>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29061>
_______________________________________

From report at bugs.python.org  Tue Dec 27 11:53:08 2016
From: report at bugs.python.org (INADA Naoki)
Date: Tue, 27 Dec 2016 16:53:08 +0000
Subject: [issue28818] simplify lookdict functions
In-Reply-To: <1480331020.89.0.515440713784.issue28818@psf.upfronthosting.co.za>
Message-ID: <1482857588.29.0.541664635903.issue28818@psf.upfronthosting.co.za>


INADA Naoki added the comment:

http://bugs.python.org/issue28427#msg284101

> Sidenote: all branches now have a different version of dict object each, which makes maintenance really painful...

Large difference between py36 and py37 is this patch.
Can I backport this to py36 to ease maintenance?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28818>
_______________________________________

From report at bugs.python.org  Tue Dec 27 11:57:36 2016
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 27 Dec 2016 16:57:36 +0000
Subject: [issue29084] C API of OrderedDict
In-Reply-To: <1482847157.79.0.799208161515.issue29084@psf.upfronthosting.co.za>
Message-ID: <1482857856.33.0.290776966523.issue29084@psf.upfronthosting.co.za>


Brett Cannon added the comment:

If the API is broken in the limited API then I definitely think we should  consistently make it not part of the limited API. As for removing it I don't have an opinion without knowing how many people are using it.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29084>
_______________________________________

From report at bugs.python.org  Tue Dec 27 12:01:34 2016
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 27 Dec 2016 17:01:34 +0000
Subject: [issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew
 installs fragile
In-Reply-To: <1411623045.52.0.589017779939.issue22490@psf.upfronthosting.co.za>
Message-ID: <1482858094.53.0.0230615862389.issue22490@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

On Python 3.6, I made the edit. I actually used the one-liner `   os.environ.pop('__PYVENV_LAUNCHER__', None)`. I then created a venv and installed a package and successfully ran a module in that package:

$ python -m venv ~/.envs/issue22490-test
$ ~/.envs/issue22490-test/bin/python -m pip install cherrypy
Collecting cherrypy
  Downloading CherryPy-8.5.0-py2.py3-none-any.whl (463kB)
    100% |????????????????????????????????| 471kB 2.2MB/s 
Collecting six (from cherrypy)
  Using cached six-1.10.0-py2.py3-none-any.whl
Installing collected packages: six, cherrypy
Successfully installed cherrypy-8.5.0 six-1.10.0
$ ~/.envs/issue22490-test/bin/python -m cherrypy            
...
[27/Dec/2016:11:08:52] ENGINE Serving on http://127.0.0.1:8080
[27/Dec/2016:11:08:52] ENGINE Bus STARTED

So pyvenv seems to be working.

Additionally, it's corrected the undesirable behavior that Tim demonstrated:

$ rm -R ~/.envs/issue22490-test 
$ python -m virtualenv ~/.envs/issue22490-test
Using base prefix '/Library/Frameworks/Python.framework/Versions/3.6'
New python executable in /Users/jaraco/.envs/issue22490-test/bin/python3
Also creating executable in /Users/jaraco/.envs/issue22490-test/bin/python
Installing setuptools, pip, wheel...done.
$ python -c 'import subprocess; subprocess.call(["/Users/jaraco/.envs/issue22490-test/bin/python", "-c", "import sys; print(sys.executable)"])'
/Users/jaraco/.envs/issue22490-test/bin/python


I tried making a Framework build of Python with the environment variable removed entirely, but I'm not experienced enough with builds on a Mac to know what I need to do to create a proper build. I build Python from source and tried to create a venv, but it crashed with a nondescript error:

$ ./python.exe -VV
Python 3.6.0+ (3.6:86a412584c02+, Dec 27 2016, 11:24:01) 
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.42.1)]
$ ./python.exe -m venv ~/.envs/issue22490
Error: Command '['/Users/jaraco/.envs/issue22490/bin/python.exe', '-Im', 'ensurepip', '--upgrade', '--default-pip']' returned non-zero exit status 1.

Aah. The issue is probably no zlib.

$ curl https://bootstrap.pypa.io/get-pip.py -o - | ~/.envs/issue22490/bin/python
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 1558k  100 1558k    0     0  5221k      0 --:--:-- --:--:-- --:--:-- 5210k
Traceback (most recent call last):
  File "<stdin>", line 20061, in <module>
  File "<stdin>", line 194, in main
  File "<stdin>", line 82, in bootstrap
zipimport.ZipImportError: can't decompress data; zlib not available


After making sure I had zlib installed and available, by re-running xcode-select --install, I was able to build with zlib, create a venv, and install packages to it:

$ ./python.exe -m venv ~/.envs/issue22490 
$ ~/.envs/issue22490/bin/python -c "import os; os.environ['__PYVENV_LAUNCHER__']"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Users/jaraco/Dropbox/code/public/cpython/Lib/os.py", line 669, in __getitem__
    raise KeyError(key) from None
KeyError: '__PYVENV_LAUNCHER__'
$ ~/.envs/issue22490/bin/pip install cherrypy
Collecting cherrypy
  Using cached CherryPy-8.5.0-py2.py3-none-any.whl
Collecting six (from cherrypy)
  Using cached six-1.10.0-py2.py3-none-any.whl
Installing collected packages: six, cherrypy
Successfully installed cherrypy-8.5.0 six-1.10.0
$ ~/.envs/issue22490/bin/python -m cherrypy
...
[27/Dec/2016:11:58:09] ENGINE Serving on http://127.0.0.1:8080
[27/Dec/2016:11:58:09] ENGINE Bus STARTED


What else would I need to test? What might one expect to fail due to the lack of that environment variable?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22490>
_______________________________________

From report at bugs.python.org  Tue Dec 27 12:35:05 2016
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 27 Dec 2016 17:35:05 +0000
Subject: [issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew
 installs fragile
In-Reply-To: <1411623045.52.0.589017779939.issue22490@psf.upfronthosting.co.za>
Message-ID: <1482860105.49.0.0705975798818.issue22490@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

Thanks. It's worth checking what shebang was written to a script that was installed into the venv - e.g. cherryd.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22490>
_______________________________________

From report at bugs.python.org  Tue Dec 27 12:39:24 2016
From: report at bugs.python.org (Ned Batchelder)
Date: Tue, 27 Dec 2016 17:39:24 +0000
Subject: [issue29085] Python 3.6 on Windows doesn't seed Random() well enough
Message-ID: <1482860364.41.0.203895591313.issue29085@psf.upfronthosting.co.za>


New submission from Ned Batchelder:

Creating two Random() instances in quick succession produces the same sequence, but only on Windows on Python 3.6.  On 3.5 or earlier, or on Mac/Linux, the randomization is good.

Python 3.6.0 (v3.6.0:41df79263a11, Dec 23 2016, 07:18:10) [MSC v.1900 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import random; print(random.Random().randint(1, 999999), random.Random().randint(1, 999999))
903885 903885
>>> import random; print(*[random.Random().randint(1, 999999) for _ in range(2)])
996947 56476
>>> import random; print(*[random.Random().randint(1, 999999) for _ in range(2)])
793282 793282
>>> import random; print(*[random.Random().randint(1, 999999) for _ in range(2)])
519702 519702
>>> import random; print(*[random.Random().randint(1, 999999) for _ in range(2)])
230678 230678
>>> import random; print(*[random.Random().randint(1, 999999) for _ in range(3)])
474701 474701 474701
>>> import random; print(*[random.Random().randint(1, 999999) for _ in range(3)])
890942 890942 890942
>>> import random; print(*[random.Random().randint(1, 999999) for _ in range(3)])
997495 997495 997495
>>> import random; print(*[random.Random().randint(1, 999999) for _ in range(5)])
27803 27803 27803 27803 919401
>>>

I would expect each of these runs to produce unique numbers, with no duplicates.

----------
keywords: 3.6regression
messages: 284118
nosy: nedbat
priority: normal
severity: normal
status: open
title: Python 3.6 on Windows doesn't seed Random() well enough

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29085>
_______________________________________

From report at bugs.python.org  Tue Dec 27 12:40:17 2016
From: report at bugs.python.org (Ned Batchelder)
Date: Tue, 27 Dec 2016 17:40:17 +0000
Subject: [issue29085] Python 3.6 on Windows doesn't seed Random() well enough
In-Reply-To: <1482860364.41.0.203895591313.issue29085@psf.upfronthosting.co.za>
Message-ID: <1482860417.02.0.445858410875.issue29085@psf.upfronthosting.co.za>


Changes by Ned Batchelder <ned at nedbatchelder.com>:


----------
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29085>
_______________________________________

From report at bugs.python.org  Tue Dec 27 12:42:02 2016
From: report at bugs.python.org (Kyle Altendorf)
Date: Tue, 27 Dec 2016 17:42:02 +0000
Subject: [issue29085] Python 3.6 on Windows doesn't seed Random() well enough
In-Reply-To: <1482860364.41.0.203895591313.issue29085@psf.upfronthosting.co.za>
Message-ID: <1482860522.03.0.245862693291.issue29085@psf.upfronthosting.co.za>


Changes by Kyle Altendorf <sda at fstab.net>:


----------
nosy: +altendky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29085>
_______________________________________

From report at bugs.python.org  Tue Dec 27 12:44:50 2016
From: report at bugs.python.org (12345 67890)
Date: Tue, 27 Dec 2016 17:44:50 +0000
Subject: [issue20486] msilib: can't close opened database
In-Reply-To: <1391355449.68.0.999858284587.issue20486@psf.upfronthosting.co.za>
Message-ID: <1482860690.54.0.0320085384474.issue20486@psf.upfronthosting.co.za>


12345 67890 added the comment:

The method is now capitalized. Unfortunately, none of the methods are compliant with PEP formatting, but it's far too late to do anything about that.

----------
Added file: http://bugs.python.org/file46056/Add_ability_to_close_MSI_database_.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20486>
_______________________________________

From report at bugs.python.org  Tue Dec 27 12:45:02 2016
From: report at bugs.python.org (12345 67890)
Date: Tue, 27 Dec 2016 17:45:02 +0000
Subject: [issue20486] msilib: can't close opened database
In-Reply-To: <1391355449.68.0.999858284587.issue20486@psf.upfronthosting.co.za>
Message-ID: <1482860702.43.0.828333100135.issue20486@psf.upfronthosting.co.za>


Changes by 12345 67890 <xoviat at gmail.com>:


Removed file: http://bugs.python.org/file45971/Add_ability_to_close_MSI_database_.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20486>
_______________________________________

From report at bugs.python.org  Tue Dec 27 13:12:43 2016
From: report at bugs.python.org (Ned Batchelder)
Date: Tue, 27 Dec 2016 18:12:43 +0000
Subject: [issue29085] Python 3.6 on Windows doesn't seed Random() well enough
In-Reply-To: <1482860364.41.0.203895591313.issue29085@psf.upfronthosting.co.za>
Message-ID: <1482862363.5.0.606256568507.issue29085@psf.upfronthosting.co.za>


Ned Batchelder added the comment:

Adding a time.sleep(0.001) (or maybe even just 0) between the calls prevents the problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29085>
_______________________________________

From report at bugs.python.org  Tue Dec 27 13:18:00 2016
From: report at bugs.python.org (Donald Stufft)
Date: Tue, 27 Dec 2016 18:18:00 +0000
Subject: [issue29085] Python 3.6 on Windows doesn't seed Random() well enough
In-Reply-To: <1482860364.41.0.203895591313.issue29085@psf.upfronthosting.co.za>
Message-ID: <1482862680.17.0.884576529508.issue29085@psf.upfronthosting.co.za>


Donald Stufft added the comment:

It's presumably failing to read nonblocking random from CrpytGen and falling back to seeding using time and pid.

----------
nosy: +dstufft

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29085>
_______________________________________

From report at bugs.python.org  Tue Dec 27 13:20:04 2016
From: report at bugs.python.org (Ammar Askar)
Date: Tue, 27 Dec 2016 18:20:04 +0000
Subject: [issue29085] Python 3.6 on Windows doesn't seed Random() well enough
In-Reply-To: <1482860364.41.0.203895591313.issue29085@psf.upfronthosting.co.za>
Message-ID: <1482862804.33.0.960836965898.issue29085@psf.upfronthosting.co.za>


Ammar Askar added the comment:

Can recreate under

Python 3.6.0 (v3.6.0:41df79263a11, Dec 23 2016, 08:06:12) [MSC v.1900 64 bit (AMD64)] on win32

and on latest master.

----------
nosy: +ammar2
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29085>
_______________________________________

From report at bugs.python.org  Tue Dec 27 13:42:39 2016
From: report at bugs.python.org (Kyle Altendorf)
Date: Tue, 27 Dec 2016 18:42:39 +0000
Subject: [issue29085] Python 3.6 on Windows doesn't seed Random() well enough
In-Reply-To: <1482860364.41.0.203895591313.issue29085@psf.upfronthosting.co.za>
Message-ID: <1482864159.61.0.0792854589961.issue29085@psf.upfronthosting.co.za>


Kyle Altendorf added the comment:

time.sleep(0) and time.sleep(0.0) acted the same for me and both exhibited matching 'random' values in some cases.  (win10, python3.6)  I also printed time.time() with each 'random' value and it wasn't a perfect match but matching times tended to go with matching 'random' values.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29085>
_______________________________________

From report at bugs.python.org  Tue Dec 27 13:46:37 2016
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 27 Dec 2016 18:46:37 +0000
Subject: [issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew
 installs fragile
In-Reply-To: <1411623045.52.0.589017779939.issue22490@psf.upfronthosting.co.za>
Message-ID: <1482864397.85.0.632720754427.issue22490@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

That also looks good.

$ head -n1 ~/.envs/issue22490/bin/cherryd
#!/Users/jaraco/.envs/issue22490/bin/python

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22490>
_______________________________________

From report at bugs.python.org  Tue Dec 27 14:01:59 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 27 Dec 2016 19:01:59 +0000
Subject: [issue29086] Document C API that is not part of the limited API
Message-ID: <1482865319.03.0.627052322458.issue29086@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

>From the documentation:

https://docs.python.org/3/c-api/stable.html

    In the C API documentation, API elements that are not part of the limited API are marked as "Not part of the limited API."

But they don't.

Following sample patch adds the notes to Unicode Objects and Codecs C API. I'm going to add them to all C API.

What are your though about formatting the note? Should it be before the description, after the description, but before the "deprecated" directive (as in the patch), or after the first paragraph of the description? Should it be on the separate line or be appended at the end of the previous paragraph, or starts the first paragraph (if before the description)? May be introduce a special directive for it?

----------
assignee: docs at python
components: Documentation
files: unicode-not-part-of-the-limited-api.patch
keywords: patch
messages: 284125
nosy: docs at python, georg.brandl, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Document C API that is not part of the limited API
type: enhancement
versions: Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file46057/unicode-not-part-of-the-limited-api.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29086>
_______________________________________

From report at bugs.python.org  Tue Dec 27 14:13:23 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 27 Dec 2016 19:13:23 +0000
Subject: [issue29087] UCS4 support functions are not implemented
Message-ID: <1482866003.6.0.322450240953.issue29087@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

There is a special section in the documentation of Unicode Objects C API: UCS4 Support.

https://docs.python.org/3/c-api/unicode.html#ucs4-support

It documents utility functions that work on strings of Py_UCS4 characters like Py_UCS4_strlen(), Py_UCS4_strcpy(), etc. But none of these functions is implemented. May be the documentation should be just removed?

----------
assignee: docs at python
components: Documentation, Unicode
messages: 284126
nosy: benjamin.peterson, docs at python, ezio.melotti, haypo, lemburg, serhiy.storchaka
priority: normal
severity: normal
status: open
title: UCS4 support functions are not implemented
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29087>
_______________________________________

From report at bugs.python.org  Tue Dec 27 14:20:33 2016
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 27 Dec 2016 19:20:33 +0000
Subject: [issue29085] Python 3.6 on Windows doesn't seed Random() well enough
In-Reply-To: <1482860364.41.0.203895591313.issue29085@psf.upfronthosting.co.za>
Message-ID: <1482866433.94.0.342189098197.issue29085@psf.upfronthosting.co.za>


Eryk Sun added the comment:

> It's presumably failing to read nonblocking random from CrpytGen 
> and falling back to seeding using time and pid.

Yes and no. CryptGenRandom is not failing, but it is nonetheless calling random_seed_time_pid:

    >>> r = random.Random()
    Breakpoint 0 hit
    python36_d!random_seed:
    00000000`5e7277c0 4889542410      mov     qword ptr [rsp+10h],rdx
                                        ss:00000095`053ef0e8=0000000000000000
    0:000> g
    Breakpoint 1 hit
    python36_d!random_seed_time_pid:
    00000000`5e728910 48894c2408      mov     qword ptr [rsp+8],rcx
                                        ss:00000095`053ef040=000002319b6f3b88
    0:000> kc 3
    Call Site
    python36_d!random_seed_time_pid
    python36_d!random_seed
    python36_d!random_new

It looks like there's a bug in the new implementation of random_seed():

     if (arg == NULL || arg == Py_None) {
        if (random_seed_urandom(self) >= 0) {
            PyErr_Clear();

            /* Reading system entropy failed, fall back on the worst entropy:
               use the current time and process identifier. */
            random_seed_time_pid(self);
        }
        Py_RETURN_NONE;
    }

If random_seed_urandom fails, it returns -1, so this should be testing if the result is less than 0.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29085>
_______________________________________

From report at bugs.python.org  Tue Dec 27 14:22:24 2016
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 27 Dec 2016 19:22:24 +0000
Subject: [issue28446] pyvenv generates malformed hashbangs for scripts
In-Reply-To: <1476492788.48.0.267846160291.issue28446@psf.upfronthosting.co.za>
Message-ID: <1482866544.11.0.247264252023.issue28446@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

As an extra data point, note the behaviour on Windows:

C:\Users\Vinay> \python34\python -m venv "\Temp\aaa bbb"                                                       
                                                                                                               
C:\Users\Vinay> "\Temp\aaa bbb\Scripts\pip" --version                                                          
pip 6.0.8 from C:\Temp\aaa bbb\lib\site-packages (python 3.4)                                                  
                                                                                                               
C:\Users\Vinay> pyzzer -i "\Temp\aaa bbb\Scripts\pip.exe"                                                      
There is a launcher.                                                                                           
Shebang: #!"C:\Temp\aaa bbb\Scripts\python.exe"                                                                
                                                                                                               
                                                                                                               
Archive contents:                                                                                              
  __main__.py                                                                                                  
                                                                                                               
C:\Users\Vinay> "\Temp\aaa bbb\Scripts\python" -m pip install -U pip                                           
You are using pip version 6.0.8, however version 9.0.1 is available.                                           
You should consider upgrading via the 'pip install --upgrade pip' command.                                     
Collecting pip from https://pypi.python.org/packages/b6/ac/7015eb97dc749283ffdec1c3a88ddb8ae03b8fad0f0e611408f1
96358da3/pip-9.0.1-py2.py3-none-any.whl#md5=297dbd16ef53bcef0447d245815f5144                                   
  Using cached pip-9.0.1-py2.py3-none-any.whl                                                                  
Installing collected packages: pip                                                                             
  Found existing installation: pip 6.0.8                                                                       
    Uninstalling pip-6.0.8:                                                                                    
      Successfully uninstalled pip-6.0.8                                                                       
                                                                                                               
Successfully installed pip-9.0.1                                                                               
                                                                                                               
C:\Users\Vinay> "\Temp\aaa bbb\Scripts\pip" --version                                                          
pip 9.0.1 from C:\Temp\aaa bbb\lib\site-packages (python 3.4)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28446>
_______________________________________

From report at bugs.python.org  Tue Dec 27 14:23:43 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 27 Dec 2016 19:23:43 +0000
Subject: [issue29085] Python 3.6 on Windows doesn't seed Random() well enough
In-Reply-To: <1482860364.41.0.203895591313.issue29085@psf.upfronthosting.co.za>
Message-ID: <1482866623.39.0.328331608314.issue29085@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29085>
_______________________________________

From report at bugs.python.org  Tue Dec 27 14:32:07 2016
From: report at bugs.python.org (Steve Dower)
Date: Tue, 27 Dec 2016 19:32:07 +0000
Subject: [issue29058] Mark new limited C API
In-Reply-To: <1482538310.89.0.583492092721.issue29058@psf.upfronthosting.co.za>
Message-ID: <1482867127.4.0.672154119712.issue29058@psf.upfronthosting.co.za>


Steve Dower added the comment:

> Just defining Py_LIMITED_API actually implies =0x03020000.

That's the intent, but if it were actually the case then this issue wouldn't exist :)

On 3.5.3, building with Py_LIMITED_API=1 will include APIs that should only be included when Py_LIMITED_API=0x03050000. You considered fixing that too likely to break existing users (and I agree), but that doesn't mean we shouldn't make it clear that it's not doing exactly the right thing.

> I have no idea where a #warn can be added.

pyport.h or pymacro.h are probably the best places. If you null-merge into 3.6 then we shouldn't have to worry about the warning showing up in later versions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29058>
_______________________________________

From report at bugs.python.org  Tue Dec 27 14:33:51 2016
From: report at bugs.python.org (Steve Dower)
Date: Tue, 27 Dec 2016 19:33:51 +0000
Subject: [issue29080] unnecessary hg required for build version 3.6 on Windows
In-Reply-To: <1482832382.86.0.80948215742.issue29080@psf.upfronthosting.co.za>
Message-ID: <1482867231.19.0.411618732512.issue29080@psf.upfronthosting.co.za>


Steve Dower added the comment:

You're right. I moved that code from buildrelease.bat, which definitely requires hg.

PC/build.bat should not fail if hg can't be found. You'll just end up with an empty sys._mercurial/sys.version after building.

----------
assignee:  -> steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29080>
_______________________________________

From report at bugs.python.org  Tue Dec 27 14:34:09 2016
From: report at bugs.python.org (Steve Dower)
Date: Tue, 27 Dec 2016 19:34:09 +0000
Subject: [issue29080] unnecessary hg required for build version 3.6 on Windows
In-Reply-To: <1482832382.86.0.80948215742.issue29080@psf.upfronthosting.co.za>
Message-ID: <1482867249.46.0.266155569226.issue29080@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at python.org>:


----------
stage:  -> needs patch
type: behavior -> compile error
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29080>
_______________________________________

From report at bugs.python.org  Tue Dec 27 14:59:32 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 27 Dec 2016 19:59:32 +0000
Subject: [issue29058] Mark new limited C API
In-Reply-To: <1482538310.89.0.583492092721.issue29058@psf.upfronthosting.co.za>
Message-ID: <1482868772.25.0.219598746217.issue29058@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Sorry, but perhaps I don't fully understand you.

It is legitimately to just define Py_LIMITED_API without requiring specific version:

    #define Py_LIMITED_API

In that case you can use the stable API of the version 3.2, but can't use PyType_FromSpecWithBases() and PyModule_AddFunctions(), because they are correctly attributed as API of versions 3.3 and 3.5. You can also mistakenly use PyImport_ImportModuleLevelObject() added in 3.5, this is a matter of this issue. But you shouldn't.

The problem is that the warning should be emitted only for users that use incorrect API. But it shouldn't be emitted for users that use just 3.2 API (perhaps the code was written at the time of 3.2 and was not changed since).

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29058>
_______________________________________

From report at bugs.python.org  Tue Dec 27 15:13:43 2016
From: report at bugs.python.org (Steve Dower)
Date: Tue, 27 Dec 2016 20:13:43 +0000
Subject: [issue29058] Mark new limited C API
In-Reply-To: <1482538310.89.0.583492092721.issue29058@psf.upfronthosting.co.za>
Message-ID: <1482869623.1.0.423688687522.issue29058@psf.upfronthosting.co.za>


Steve Dower added the comment:

You've described it correctly.

> The problem is that the warning should be emitted only for users that use incorrect API. But it shouldn't be emitted for users that use just 3.2 API

This is why I suggested #warn and not #error. It's okay to ignore warnings if you know what you're doing, but if there's no warning then people who don't know what they're doing will get it wrong. We know that some people are subtly broken here, and ought to tell them.

Further, if we make the warning only appear for "defined(Py_LIMITED_API) && Py_LIMITED_API+0<0x03000000" then the warning can be suppressed by setting the exact version you intend to use (even though this doesn't prevent you from using the incorrect functions).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29058>
_______________________________________

From report at bugs.python.org  Tue Dec 27 15:22:35 2016
From: report at bugs.python.org (Kodiologist)
Date: Tue, 27 Dec 2016 20:22:35 +0000
Subject: [issue29088] Inconsistent use of underscore in names that start with
 "is"
Message-ID: <1482870155.37.0.889856609574.issue29088@psf.upfronthosting.co.za>


New submission from Kodiologist:

Compare ``isinstance``, ``issubclass``, and ``islower`` to ``is_integer``, ``is_fifo``, and ``is_enabled``. In Python 3.6, of all the names in the standard library starting with ``is``, I count 69 names with the underscore and 91 without. It seems better to pick one way or the other and stick with it. I would recommend using the underscore, for legibility.

----------
messages: 284133
nosy: Kodiologist
priority: normal
severity: normal
status: open
title: Inconsistent use of underscore in names that start with "is"
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29088>
_______________________________________

From report at bugs.python.org  Tue Dec 27 15:34:42 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 27 Dec 2016 20:34:42 +0000
Subject: [issue29088] Inconsistent use of underscore in names that start with
 "is"
In-Reply-To: <1482870155.37.0.889856609574.issue29088@psf.upfronthosting.co.za>
Message-ID: <1482870882.59.0.456063511368.issue29088@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yep, that would be nice.  But Python has evolved over time, and we must maintain backward compatibility.  The names are what they are.

----------
nosy: +r.david.murray
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29088>
_______________________________________

From report at bugs.python.org  Tue Dec 27 16:27:05 2016
From: report at bugs.python.org (Xezlec)
Date: Tue, 27 Dec 2016 21:27:05 +0000
Subject: [issue29089] Python 2 dictionary keys described incorrectly
Message-ID: <1482874025.47.0.911588306573.issue29089@psf.upfronthosting.co.za>


New submission from Xezlec:

In section 5.5 on the page https://docs.python.org/2/tutorial/datastructures.html#dictionaries the requirements given for dictionary keys are not correct.

Specifically, it is claimed that only immutable objects (and tuples containing only immutable objects) may be used as keys.  This is false, as user-defined mutable objects may be used as keys.  I suggest rewording along these lines:

"Only user-defined objects and immutable built-in types may be used as keys.  Although allowed, it is bad practice to use a mutable user-defined object as a key when equality is determined in any way other than identity (the default)."

----------
assignee: docs at python
components: Documentation
messages: 284135
nosy: Xezlec, docs at python
priority: normal
severity: normal
status: open
title: Python 2 dictionary keys described incorrectly
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29089>
_______________________________________

From report at bugs.python.org  Tue Dec 27 16:36:47 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 27 Dec 2016 21:36:47 +0000
Subject: [issue29089] Python 2 dictionary keys described incorrectly
In-Reply-To: <1482874025.47.0.911588306573.issue29089@psf.upfronthosting.co.za>
Message-ID: <1482874607.59.0.750948096474.issue29089@psf.upfronthosting.co.za>


R. David Murray added the comment:

It could say 'hashable object' instead of immutable object.  I don't know if hash has been introduced by that point, though.

It's the tutorial.  Probably better to just leave it alone.  Precise understanding can come later.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29089>
_______________________________________

From report at bugs.python.org  Tue Dec 27 16:38:07 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 27 Dec 2016 21:38:07 +0000
Subject: [issue29089] dictionary keys described incorrectly in tutorial
In-Reply-To: <1482874025.47.0.911588306573.issue29089@psf.upfronthosting.co.za>
Message-ID: <1482874687.08.0.544551812035.issue29089@psf.upfronthosting.co.za>


R. David Murray added the comment:

Note that this applies equally well to python3.

----------
title: Python 2 dictionary keys described incorrectly -> dictionary keys described incorrectly in tutorial
versions: +Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29089>
_______________________________________

From report at bugs.python.org  Tue Dec 27 17:13:32 2016
From: report at bugs.python.org (Arkadiusz Miskiewicz Arkadiusz Miskiewicz)
Date: Tue, 27 Dec 2016 22:13:32 +0000
Subject: [issue28700] test_dbm failure: KeyError: b'0' (intermittent in 3.5,
 reliable in 3.6)
In-Reply-To: <1479238038.8.0.290390662143.issue28700@psf.upfronthosting.co.za>
Message-ID: <1482876812.82.0.408731534263.issue28700@psf.upfronthosting.co.za>


Changes by Arkadiusz Miskiewicz				Arkadiusz Miskiewicz <arekm at maven.pl>:


----------
nosy: +arekm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28700>
_______________________________________

From report at bugs.python.org  Tue Dec 27 17:35:12 2016
From: report at bugs.python.org (Arkadiusz Miskiewicz Arkadiusz Miskiewicz)
Date: Tue, 27 Dec 2016 22:35:12 +0000
Subject: [issue28700] test_dbm failure: KeyError: b'0' (intermittent in 3.5,
 reliable in 3.6)
In-Reply-To: <1479238038.8.0.290390662143.issue28700@psf.upfronthosting.co.za>
Message-ID: <1482878112.81.0.594952857693.issue28700@psf.upfronthosting.co.za>


Arkadiusz Miskiewicz				Arkadiusz Miskiewicz added the comment:

Using configure option

--with-dbmliborder=gdbm:bdb

(so no ndbm in it) is another reason for such failure as seems that test suite has no conditional for it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28700>
_______________________________________

From report at bugs.python.org  Tue Dec 27 17:57:12 2016
From: report at bugs.python.org (Stephen J. Turnbull)
Date: Tue, 27 Dec 2016 22:57:12 +0000
Subject: [issue28080] Allow reading member names with bogus encodings in
 zipfile
In-Reply-To: <1473620375.38.0.155906896901.issue28080@psf.upfronthosting.co.za>
Message-ID: <1482879432.6.0.873539076305.issue28080@psf.upfronthosting.co.za>


Stephen J. Turnbull added the comment:

Thanks for followup!  I was just about to write you, now that 3.6 is out.  Season's Greetings!

First, how do you propose to proceed with issue28115 ("use argparse for the ZipFile module")?  If you expect to commit that first (I'm in no hurry for this patch, BTW, as long as it gets into 3.7 I'm happy), this issue should depend on it and use argparse too.

I don't see any good reason for allowing non-UTF-8 encoding to a file open for writing, and a good reason (the ZipFile standard) for not allowing it.  Certainly the CLI should not allow it, any more than it does now.  At least in my experiments InfoZip and the default zip utilities on Windows and Mac DTRT with UTF-8 zipfiles, so there is no absolute need for writing nonconforming zipfiles.  If you want to block on a convert-to-UTF-8 option I can do that (but I don't need it myself).  (Note to self: if writing to existing zipfile is extension of existing file, need to prevent mixed encodings.  Also warn about conversion.)

I thought I checked that comments were decoded.  Maybe that's only on the UTF-8 path?  Or maybe I needed more coffee.  (Hope so, that would be a messy problem if ASCII/Latin1 returns bytes and UTF-8 returns str!)  I'll think about this.  Yes, it's a backwards-compatibility issue so needs care.  Would be weird if names are decoded but other metadata (comments) not, though.  Surely someone would complain if they actually used comments?  (I'm thinking maybe a compatibility break might be OK?  With deprecation cycle?)  I expect to check all execution paths accessing metadata and have a proposed patch by 12/31.

I think I'm still short some tests, will check and write them if needed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28080>
_______________________________________

From report at bugs.python.org  Tue Dec 27 18:05:39 2016
From: report at bugs.python.org (Claudio Freire)
Date: Tue, 27 Dec 2016 23:05:39 +0000
Subject: [issue25750] tp_descr_get(self, obj,
 type) is called without owning a reference to "self"
In-Reply-To: <1448654213.28.0.807225788685.issue25750@psf.upfronthosting.co.za>
Message-ID: <1482879939.32.0.171391727334.issue25750@psf.upfronthosting.co.za>


Claudio Freire added the comment:

I cannot be 100% sure, but we have ample evidence suggesting we're experiencing this same crash in production.

We have a big system that mixes Cython and pure-python coroutines, and in one version we started seeing segfaults that strongly hint at this root cause.

Adding pure-python indirections (that keep the arguments alive, I'd wager), fixes those segfaults.

I cannot share the codebase (and in any case it's too big, and the crash is too difficult to reproduce in isolation, without real traffic), but I'd add my +1 on applying this fix.

We're currently testing to try and reproduce the segfaults on 2.7.13, after that I'll try jdemeyer's patch and report the results.

----------
nosy: +Claudio.Freire

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25750>
_______________________________________

From report at bugs.python.org  Tue Dec 27 18:18:51 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 27 Dec 2016 23:18:51 +0000
Subject: [issue29087] UCS4 support functions are not implemented
In-Reply-To: <1482866003.6.0.322450240953.issue29087@psf.upfronthosting.co.za>
Message-ID: <1482880731.85.0.101940170213.issue29087@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I recall that the very first implementation of the PEP 393 (compact strings) was heavily based on UCS4. Slowly, I optimized the code by specializing functions to each kind of string (ACSII, Latin1, UCS2, UCS4).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29087>
_______________________________________

From report at bugs.python.org  Tue Dec 27 18:45:28 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 27 Dec 2016 23:45:28 +0000
Subject: [issue29087] UCS4 support functions are not implemented
In-Reply-To: <1482866003.6.0.322450240953.issue29087@psf.upfronthosting.co.za>
Message-ID: <1482882328.12.0.824846639686.issue29087@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Py_UCS4_strlen() added by:

changeset:   72475:8beaa9a37387
user:        Martin v. L?wis <martin at v.loewis.de>
date:        Wed Sep 28 07:41:54 2011 +0200
files:       ...
description:
Implement PEP 393.


Removed by:

changeset:   73236:80a7ab9ac29f
user:        Martin v. L?wis <martin at v.loewis.de>
date:        Mon Oct 31 08:40:56 2011 +0100
files:       Include/unicodeobject.h Objects/unicodeobject.c Objects/uniops.h
description:
Drop Py_UCS4_ functions. Closes #13246.


80a7ab9ac29f came before Python 3.3.0:

haypo at selma$ hg log -r v3.3.0
changeset:   79242:bd8afb90ebf2
branch:      3.3
tag:         v3.3.0
parent:      79237:cb84dcb35114
user:        Georg Brandl <georg at python.org>
date:        Sat Sep 29 09:44:17 2012 +0200
files:       Lib/test/test_sys.py
description:
Fix test_sys.test_implementation for final releases.


Py_UCS4_strlen() was documented but was never part of any public Python release.

=> you can remove the doc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29087>
_______________________________________

From report at bugs.python.org  Tue Dec 27 20:11:31 2016
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 28 Dec 2016 01:11:31 +0000
Subject: [issue29089] dictionary keys described incorrectly in tutorial
In-Reply-To: <1482874025.47.0.911588306573.issue29089@psf.upfronthosting.co.za>
Message-ID: <1482887491.36.0.944210520969.issue29089@psf.upfronthosting.co.za>


INADA Naoki added the comment:

> It's the tutorial.  Probably better to just leave it alone.  Precise understanding can come later.

I agree.
Beginner should start using dict with builtin immutable type as key.
hashable is too complex at this point.

----------
nosy: +inada.naoki

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29089>
_______________________________________

From report at bugs.python.org  Tue Dec 27 20:45:58 2016
From: report at bugs.python.org (Xezlec)
Date: Wed, 28 Dec 2016 01:45:58 +0000
Subject: [issue29089] dictionary keys described incorrectly in tutorial
In-Reply-To: <1482874025.47.0.911588306573.issue29089@psf.upfronthosting.co.za>
Message-ID: <1482889558.28.0.0899697532357.issue29089@psf.upfronthosting.co.za>


Xezlec added the comment:

> It's the tutorial.  Probably better to just leave it alone.  Precise understanding can come later.

But the problem isn't that it's imprecise.  It's flat-out wrong.  My opinion would be that it's always a bad idea to put wrong information in the documentation, especially when it's the first Google hit.  It can lead to all sorts of confusion and frustration (as it did for me).  Users are likely to assume documentation from any official source is the final word.

If precision is the problem, could it be reworded to be more vague?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29089>
_______________________________________

From report at bugs.python.org  Tue Dec 27 21:11:48 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 28 Dec 2016 02:11:48 +0000
Subject: [issue28871] Destructor of ElementTree.Element is recursive
In-Reply-To: <1480892604.34.0.360751620771.issue28871@psf.upfronthosting.co.za>
Message-ID: <1482891108.94.0.363037885132.issue28871@psf.upfronthosting.co.za>


STINNER Victor added the comment:

bm_xml_etree.py benchmark started to crash on Python 2.7 because of the change 78bf34b6a713.

Python 2.7 @ 78bf34b6a713: bug.py does crash
Python 2.7 @ 32cc37a89b58: no crash

Full script: https://github.com/python/performance/blob/master/performance/benchmarks/bm_xml_etree.py

----------
nosy: +haypo
resolution: fixed -> 
status: closed -> open
Added file: http://bugs.python.org/file46058/bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28871>
_______________________________________

From report at bugs.python.org  Tue Dec 27 21:15:10 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 28 Dec 2016 02:15:10 +0000
Subject: [issue28871] Destructor of ElementTree.Element is recursive
In-Reply-To: <1480892604.34.0.360751620771.issue28871@psf.upfronthosting.co.za>
Message-ID: <1482891310.91.0.530576108784.issue28871@psf.upfronthosting.co.za>


STINNER Victor added the comment:

haypo at selma$ gdb -args ./python ~/bug.py 
(gdb) run
python: Objects/object.c:2453: _PyTrash_thread_deposit_object: Assertion `PyObject_IS_GC(op)' failed.

Program received signal SIGABRT, Aborted.

(gdb) py-bt
Traceback (most recent call first):
  File "/home/haypo/bug.py", line 130, in bench_parse
    root1 = etree.parse(xml_file).getroot()
  File "/home/haypo/bug.py", line 171, in bench_etree
    bench_func(etree, file_path, xml_data, xml_root)
  File "/home/haypo/bug.py", line 197, in <module>
    bench_etree(1, ET, bench_func)



(gdb) where
#0  0x00007ffff711892f in raise () from /lib64/libc.so.6
#1  0x00007ffff711a52a in abort () from /lib64/libc.so.6
#2  0x00007ffff7110e37 in __assert_fail_base () from /lib64/libc.so.6
#3  0x00007ffff7110ee2 in __assert_fail () from /lib64/libc.so.6
#4  0x0000000000463abe in _PyTrash_thread_deposit_object (op=<Element at remote 0x7fffec9152e0>) at Objects/object.c:2453
#5  0x00007fffecd29b17 in element_dealloc (self=0x7fffec9152e0) at /home/haypo/prog/python/2.7/Modules/_elementtree.c:566
#6  0x000000000046346a in _Py_Dealloc (op=<Element at remote 0x7fffec9152e0>) at Objects/object.c:2262
#7  0x00007fffecd29058 in element_dealloc_extra (self=0x7fffec915280) at /home/haypo/prog/python/2.7/Modules/_elementtree.c:301
#8  0x00007fffecd29abc in element_dealloc (self=0x7fffec915280) at /home/haypo/prog/python/2.7/Modules/_elementtree.c:561
#9  0x000000000046346a in _Py_Dealloc (op=<Element at remote 0x7fffec915280>) at Objects/object.c:2262
#10 0x00007fffecd29058 in element_dealloc_extra (self=0x7fffec915220) at /home/haypo/prog/python/2.7/Modules/_elementtree.c:301
#11 0x00007fffecd29abc in element_dealloc (self=0x7fffec915220) at /home/haypo/prog/python/2.7/Modules/_elementtree.c:561
#12 0x000000000046346a in _Py_Dealloc (op=<Element at remote 0x7fffec915220>) at Objects/object.c:2262
#13 0x00007fffecd29058 in element_dealloc_extra (self=0x7fffec9151c0) at /home/haypo/prog/python/2.7/Modules/_elementtree.c:301
#14 0x00007fffecd29abc in element_dealloc (self=0x7fffec9151c0) at /home/haypo/prog/python/2.7/Modules/_elementtree.c:561
#15 0x000000000046346a in _Py_Dealloc (op=<Element at remote 0x7fffec9151c0>) at Objects/object.c:2262
#16 0x00007fffecd29058 in element_dealloc_extra (self=0x7fffec915160) at /home/haypo/prog/python/2.7/Modules/_elementtree.c:301
#17 0x00007fffecd29abc in element_dealloc (self=0x7fffec915160) at /home/haypo/prog/python/2.7/Modules/_elementtree.c:561
#18 0x000000000046346a in _Py_Dealloc (op=<Element at remote 0x7fffec915160>) at Objects/object.c:2262
#19 0x00007fffecd29058 in element_dealloc_extra (self=0x7fffec915100) at /home/haypo/prog/python/2.7/Modules/_elementtree.c:301
#20 0x00007fffecd29abc in element_dealloc (self=0x7fffec915100) at /home/haypo/prog/python/2.7/Modules/_elementtree.c:561
#21 0x000000000046346a in _Py_Dealloc (op=<Element at remote 0x7fffec915100>) at Objects/object.c:2262
#22 0x00007fffecd29058 in element_dealloc_extra (self=0x7fffec9150a0) at /home/haypo/prog/python/2.7/Modules/_elementtree.c:301
#23 0x00007fffecd29abc in element_dealloc (self=0x7fffec9150a0) at /home/haypo/prog/python/2.7/Modules/_elementtree.c:561
#24 0x000000000046346a in _Py_Dealloc (op=<Element at remote 0x7fffec9150a0>) at Objects/object.c:2262
#25 0x00007fffecd29058 in element_dealloc_extra (self=0x7fffec915040) at /home/haypo/prog/python/2.7/Modules/_elementtree.c:301
#26 0x00007fffecd29abc in element_dealloc (self=0x7fffec915040) at /home/haypo/prog/python/2.7/Modules/_elementtree.c:561
#27 0x000000000046346a in _Py_Dealloc (op=<Element at remote 0x7fffec915040>) at Objects/object.c:2262
#28 0x00007fffecd29058 in element_dealloc_extra (self=0x7fffec90ffa0) at /home/haypo/prog/python/2.7/Modules/_elementtree.c:301
#29 0x00007fffecd29abc in element_dealloc (self=0x7fffec90ffa0) at /home/haypo/prog/python/2.7/Modules/_elementtree.c:561
#30 0x000000000046346a in _Py_Dealloc (op=<Element at remote 0x7fffec90ffa0>) at Objects/object.c:2262
#31 0x00007fffecd29058 in element_dealloc_extra (self=0x7fffec90ff40) at /home/haypo/prog/python/2.7/Modules/_elementtree.c:301
#32 0x00007fffecd29abc in element_dealloc (self=0x7fffec90ff40) at /home/haypo/prog/python/2.7/Modules/_elementtree.c:561
#33 0x000000000046346a in _Py_Dealloc (op=<Element at remote 0x7fffec90ff40>) at Objects/object.c:2262
#34 0x00007fffecd29058 in element_dealloc_extra (self=0x7fffec90fee0) at /home/haypo/prog/python/2.7/Modules/_elementtree.c:301
#35 0x00007fffecd29abc in element_dealloc (self=0x7fffec90fee0) at /home/haypo/prog/python/2.7/Modules/_elementtree.c:561
#36 0x000000000046346a in _Py_Dealloc (op=<Element at remote 0x7fffec90fee0>) at Objects/object.c:2262
#37 0x00007fffecd29058 in element_dealloc_extra (self=0x7fffec90fe80) at /home/haypo/prog/python/2.7/Modules/_elementtree.c:301
#38 0x00007fffecd29abc in element_dealloc (self=0x7fffec90fe80) at /home/haypo/prog/python/2.7/Modules/_elementtree.c:561
#39 0x000000000046346a in _Py_Dealloc (op=<Element at remote 0x7fffec90fe80>) at Objects/object.c:2262
#40 0x00007fffecd29058 in element_dealloc_extra (self=0x7fffec90fe20) at /home/haypo/prog/python/2.7/Modules/_elementtree.c:301
#41 0x00007fffecd29abc in element_dealloc (self=0x7fffec90fe20) at /home/haypo/prog/python/2.7/Modules/_elementtree.c:561
#42 0x000000000046346a in _Py_Dealloc (op=<Element at remote 0x7fffec90fe20>) at Objects/object.c:2262
#43 0x00007fffecd29058 in element_dealloc_extra (self=0x7fffec90fdc0) at /home/haypo/prog/python/2.7/Modules/_elementtree.c:301
#44 0x00007fffecd29abc in element_dealloc (self=0x7fffec90fdc0) at /home/haypo/prog/python/2.7/Modules/_elementtree.c:561
#45 0x000000000046346a in _Py_Dealloc (op=<Element at remote 0x7fffec90fdc0>) at Objects/object.c:2262
#46 0x00007fffecd29058 in element_dealloc_extra (self=0x7fffec90fd60) at /home/haypo/prog/python/2.7/Modules/_elementtree.c:301
#47 0x00007fffecd29abc in element_dealloc (self=0x7fffec90fd60) at /home/haypo/prog/python/2.7/Modules/_elementtree.c:561
#48 0x000000000046346a in _Py_Dealloc (op=<Element at remote 0x7fffec90fd60>) at Objects/object.c:2262
#49 0x00007fffecd29058 in element_dealloc_extra (self=0x7fffec90fd00) at /home/haypo/prog/python/2.7/Modules/_elementtree.c:301
(...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28871>
_______________________________________

From report at bugs.python.org  Tue Dec 27 21:27:30 2016
From: report at bugs.python.org (R. David Murray)
Date: Wed, 28 Dec 2016 02:27:30 +0000
Subject: [issue29089] dictionary keys described incorrectly in tutorial
In-Reply-To: <1482874025.47.0.911588306573.issue29089@psf.upfronthosting.co.za>
Message-ID: <1482892050.04.0.856377553634.issue29089@psf.upfronthosting.co.za>


R. David Murray added the comment:

It is not wrong.  It does not say that keys are limited to immutables, only that immutables can be keys.  Perhaps the sentence about a tuple pointing to a mutable could be tightened up, though, by saying that if a tuple points to something that can not itself be a dictionary key, then that tuple can not be a dictionary key.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29089>
_______________________________________

From report at bugs.python.org  Tue Dec 27 21:40:00 2016
From: report at bugs.python.org (Mike Hobbs)
Date: Wed, 28 Dec 2016 02:40:00 +0000
Subject: [issue29090] python34.dll crash
Message-ID: <1482892800.26.0.562397151262.issue29090@psf.upfronthosting.co.za>


New submission from Mike Hobbs:

Only info (Windows event viewer): Faulting application python_cc.exe, version 0.0.0.0, faulting module python34.dll, version 3.4.3150.1013, fault address 0x001059b7
Note: python_cc.exe is renamed python.exe to identify it in task manager.
OS is Windows XP SP3

The following script crashes the python executable every few hours (not regular, seemingly random).
The exact same script also crashes python 2.7.13. Each version has the latest pyserial module installed for the appropriate python version.
When python 2.7 crashes, the reported error is always in _ctypes.dll which is used extensively in the serialwin32.py for reading the serial port, but python 3.4 fails in the main DLL.

This same script has been running without a problem for several years on the same hardware (Quad core Shuttle with CurrentCost 128 electricity monitor on COM3, using PL2303 serial/USB chipset (probably clone)). The crashes have only occured since harddisc replacement involving new XP installation and reinstallation of application software.

Occasionally, the crash results in a blue screen but usually its just the task crash notification (which I automatically dismiss using AutoIt3 watchdog script).  Everything else on the machine id running normally so the serial port handling is the prime suspect.


import serial, sys, time, traceback, os
import xml.etree.ElementTree as ET

correction = 1.074  # 247V when CC128 is designed for 230V
path = "E:\\Apache\\htdocs\\energy\\elec_data\\"
log  = "E:\\Apache\\htdocs\\energy\\log.txt"
ser  = None
amps = [0,0,0,0]

def localtime():
    y,m,d,h,mn,s,wd,b,c = time.localtime()
    return '%4d%02d%02d %02d%02d%02d' % (y,m,d,h,mn,s)

def dbg(msg):
    msg = msg.strip()
    print(msg)
    if len(msg) <= 2: return
    global log
    # avoid huge files
    if os.path.getsize(log) > 2000000:
        y,m,d,h,mn,s,wd,b,c = time.localtime()
        old = 'log_%4d%02d%02d_%02d%02d%02d.txt' % (y,m,d,h,mn,s)
        os.rename(log, old)
    f = open(log, 'a')
    t = localtime()
    f.write('%s %s\n' % (t, msg))
    f.close()

try:
    ser = serial.Serial(port="COM3", baudrate=57600, bytesize=serial.EIGHTBITS, parity=serial.PARITY_NONE, stopbits=serial.STOPBITS_ONE, timeout=3)
    dbg("Connected to CurrentCost meter")

except serial.SerialException:
    dbg("Failed to connect to CurrentCost meter")
    sys.exit(1)

err_count = 0
while True:
    try:
        line = ser.readline().strip() # should be something every 6 seconds
        if line:
            watts = ''
            try:
                msg = ET.fromstring(line)
                watts = msg.findtext('ch1/watts')
                watts = float(watts)
                err_count = 0
            except:
                watts = ''
                err_count += 1
            finally:
                try:
                    del exc_info
                except:
                    pass

            if watts:
                # _ _      _  _
                #  _   or   __  regarded as bogus
                amps[0] = amps[1]; amps[1] = amps[2]; amps[2] = amps[3]
                amps[3] = float(watts)*.00405 # 247 volts
                bogus = False
                if amps[1]>0 and amps[1] < amps[0]/2:
                    if amps[1] < amps[2]/2: bogus = True
                    if amps[1] < amps[3]/2 and amps[2] < amps[3]/2: bogus = True
                #dbg('%s  %s  %s  %s  %s' % (amps[0],amps[1],amps[2],amps[3],bogus))
                if not bogus and amps[2]>0 and amps[3]>0:
                    y,m,d,h,mn,s,a,b,c = time.localtime()
                    try:
                        line = '%f,%f' % (float(h)+float(mn)/60+float(s)/3600, amps[1])
                        f = open('%s\\%4d%02d%02d.csv' % (path,y,m,d), 'a')
                        f.write('%s\n' % line)
                        f.close()
                    except:
                        exc_info = sys.exc_info()
                        dbg('CC EXCEPTION %s ' % traceback.format_exception(*exc_info))
                    finally:
                        try:
                            del exc_info  # force garbage collection
                        except:
                            pass
            else:
                if err_count > 100:
                    dbg("100 consecutive errors detected")
                    break

    except serial.SerialException:
        exc_info = sys.exc_info()
        dbg('CC EXCEPTION %s ' % traceback.format_exception(*exc_info))
        ser.close()
        sys.exit(1)
    except KeyboardInterrupt:
        ser.close()
        sys.exit(0)
    except:
        exc_info = sys.exc_info()
        dbg('CC EXCEPTION %s ' % traceback.format_exception(*exc_info))
    finally:
        try:
            del exc_info  # force garbage collection
        except:
            pass

ser.close()
sys.exit(1)

----------
components: Windows
messages: 284148
nosy: MikeH, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: python34.dll crash
type: crash
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29090>
_______________________________________

From report at bugs.python.org  Tue Dec 27 21:41:49 2016
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 28 Dec 2016 02:41:49 +0000
Subject: [issue29089] dictionary keys described incorrectly in tutorial
In-Reply-To: <1482874025.47.0.911588306573.issue29089@psf.upfronthosting.co.za>
Message-ID: <1482892909.52.0.93574475294.issue29089@psf.upfronthosting.co.za>


INADA Naoki added the comment:

> If precision is the problem, could it be reworded to be more vague?

"can be any immutable" seems vague enough to me.  It doesn't say "cannot be any mutable type.".

>  Users are likely to assume documentation from any official source is the final word.

But tutorial should use less words as possible.  This section is before introducing "class" statement.  Only strings, numbers, list and set are introduced before section.

I feel assuming early part of tutorial as final word bad practice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29089>
_______________________________________

From report at bugs.python.org  Tue Dec 27 21:45:48 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 28 Dec 2016 02:45:48 +0000
Subject: [issue28180] sys.getfilesystemencoding() should default to utf-8
In-Reply-To: <1474024622.65.0.838685461995.issue28180@psf.upfronthosting.co.za>
Message-ID: <1482893148.98.0.10861819916.issue28180@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I've now written this up as a PEP: https://github.com/python/peps/blob/master/pep-0538.txt

The latest attached patch implements the specific design proposed in the PEP. Relative to the last Fedora specific patch, this tweaks the warning message wording slightly, and only emits the library level warning when PYTHONALLOWCLOCALE is set:

======================
$ LANG=C ./python -c "import sys; print(sys.getfilesystemencoding())"
Python detected LC_CTYPE=C, forcing LC_ALL & LANG to C.UTF-8 (set PYTHONALLOWCLOCALE to disable this locale coercion behaviour).
utf-8


======================
$ PYTHONALLOWCLOCALE=1 LANG=C ./python -c "import sys; print(sys.getfilesystemencoding())"
Py_Initialize detected LC_CTYPE=C, which limits Unicode compatibility. Some libraries and operating system interfaces may not work correctly. Set `PYTHONALLOWCLOCALE=1 LC_CTYPE=C` to configure a similar environment when running Python directly.
ascii

----------
Added file: http://bugs.python.org/file46059/pep538_coerce_legacy_c_locale.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28180>
_______________________________________

From report at bugs.python.org  Tue Dec 27 22:48:58 2016
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 28 Dec 2016 03:48:58 +0000
Subject: [issue29057] Compiler failure on Mac OS X - sys/random.h
In-Reply-To: <1482514649.72.0.460227366509.issue29057@psf.upfronthosting.co.za>
Message-ID: <1482896938.59.0.692987363188.issue29057@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Right, my question is why does configure define HAVE_SYS_RANDOM_H if including sys/random.h causes an error?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29057>
_______________________________________

From report at bugs.python.org  Tue Dec 27 23:11:51 2016
From: report at bugs.python.org (Xezlec)
Date: Wed, 28 Dec 2016 04:11:51 +0000
Subject: [issue29089] dictionary keys described incorrectly in tutorial
In-Reply-To: <1482874025.47.0.911588306573.issue29089@psf.upfronthosting.co.za>
Message-ID: <1482898311.77.0.237408747855.issue29089@psf.upfronthosting.co.za>


Xezlec added the comment:

> Perhaps the sentence about a tuple pointing to a mutable could be tightened up, though, by saying that if a tuple points to something that can not itself be a dictionary key, then that tuple can not be a dictionary key.

That would be great.  Thank you.

> I feel assuming early part of tutorial as final word bad practice.

Alright.  If that's how both of you feel, then it can't be helped.

But if that's how it is, then maybe it would be a good idea to make the tutorial more distinct?  Right now, the only way I can tell Google has landed me on a tutorial page as opposed to a reference page is the word "tutorial" in the URL and in small print at the very top of the page.  They're styled similarly.  I never even realized they were separate things until today (let alone that one of them must be read skeptically).

Sorry to take up your time.  Thanks for listening.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29089>
_______________________________________

From report at bugs.python.org  Wed Dec 28 00:12:51 2016
From: report at bugs.python.org (Joseph Hackman)
Date: Wed, 28 Dec 2016 05:12:51 +0000
Subject: [issue29059] Windows: Python not using ANSI compatible console
In-Reply-To: <1482543191.02.0.407458515739.issue29059@psf.upfronthosting.co.za>
Message-ID: <1482901971.81.0.346244569695.issue29059@psf.upfronthosting.co.za>


Joseph Hackman added the comment:

Thanks for the tip! If you hadn't said that, I probably would have written it into the init scripts.

I'll try to write something for python-ideas / PEP tomorrow, but have attached a quick patch here so I can link to this issue for an example implementation.

----------
keywords: +patch
Added file: http://bugs.python.org/file46060/issue29059.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29059>
_______________________________________

From report at bugs.python.org  Wed Dec 28 01:03:55 2016
From: report at bugs.python.org (Tres Seaver)
Date: Wed, 28 Dec 2016 06:03:55 +0000
Subject: [issue24288] Include/opcode.h is modified during building
In-Reply-To: <1432626475.52.0.752359380395.issue24288@psf.upfronthosting.co.za>
Message-ID: <1482905035.14.0.850836601364.issue24288@psf.upfronthosting.co.za>


Tres Seaver added the comment:

ISTM that this issue should be re-opened, because it breaks out-of-tree building from a pristine / read-only source tree.  If they are "public" headers, files like 'opcode.h' should be generated and checked in as part of the release process, rather than modified during a normal build.

----------
nosy: +tseaver

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24288>
_______________________________________

From report at bugs.python.org  Wed Dec 28 01:08:03 2016
From: report at bugs.python.org (Tres Seaver)
Date: Wed, 28 Dec 2016 06:08:03 +0000
Subject: [issue24288] permissions
In-Reply-To: <1432626475.52.0.752359380395.issue24288@psf.upfronthosting.co.za>
Message-ID: <1482905283.35.0.526622725841.issue24288@psf.upfronthosting.co.za>


Changes by Tres Seaver <tseaver at agendaless.com>:


----------
title: Include/opcode.h is modified during building -> permissions

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24288>
_______________________________________

From report at bugs.python.org  Wed Dec 28 01:09:18 2016
From: report at bugs.python.org (Tres Seaver)
Date: Wed, 28 Dec 2016 06:09:18 +0000
Subject: [issue24288] Include/opcode.h is modified during building
In-Reply-To: <1432626475.52.0.752359380395.issue24288@psf.upfronthosting.co.za>
Message-ID: <1482905358.09.0.023168055443.issue24288@psf.upfronthosting.co.za>


Changes by Tres Seaver <tseaver at agendaless.com>:


----------
title: permissions -> Include/opcode.h is modified during building

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24288>
_______________________________________

From report at bugs.python.org  Wed Dec 28 02:13:14 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 28 Dec 2016 07:13:14 +0000
Subject: [issue28871] Destructor of ElementTree.Element is recursive
In-Reply-To: <1480892604.34.0.360751620771.issue28871@psf.upfronthosting.co.za>
Message-ID: <1482909194.16.0.445585773319.issue28871@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Ah, I tested only with non-debug build in which asserts were ignored! In 2.7 Element doesn't support garbage collection, and the trashcan mechanism Py_TRASHCAN_SAFE_BEGIN/Py_TRASHCAN_SAFE_END can't be applied.

I see three alternatives:

1. Just revert the changes. Let deep ElementTree crashing.

2. Add the support of garbage collection. This will increase the size of empty Element by 1.5 times. This looks less appropriate that the first option since this harms working code.

3. Try to implement different mechanism. By using external list object as a stack or using other field for creating a linked list.

I'll revert the patch (except tests fix) and will try to implement different mechanism.

----------
stage: resolved -> needs patch
versions:  -Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28871>
_______________________________________

From report at bugs.python.org  Wed Dec 28 02:20:17 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 28 Dec 2016 07:20:17 +0000
Subject: [issue29087] UCS4 support functions are not implemented
In-Reply-To: <1482866003.6.0.322450240953.issue29087@psf.upfronthosting.co.za>
Message-ID: <20161228072014.4558.18844.B851ECE2@psf.io>


Roundup Robot added the comment:

New changeset 29d46d29e169 by Serhiy Storchaka in branch '3.5':
Issue #29087: Removed the documentation of non-existing UCS4 support functions.
https://hg.python.org/cpython/rev/29d46d29e169

New changeset e44b6b01c8cf by Serhiy Storchaka in branch '3.6':
Issue #29087: Removed the documentation of non-existing UCS4 support functions.
https://hg.python.org/cpython/rev/e44b6b01c8cf

New changeset 0ec4befef7e0 by Serhiy Storchaka in branch 'default':
Issue #29087: Removed the documentation of non-existing UCS4 support functions.
https://hg.python.org/cpython/rev/0ec4befef7e0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29087>
_______________________________________

From report at bugs.python.org  Wed Dec 28 02:20:58 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 28 Dec 2016 07:20:58 +0000
Subject: [issue29087] UCS4 support functions are not implemented
In-Reply-To: <1482866003.6.0.322450240953.issue29087@psf.upfronthosting.co.za>
Message-ID: <1482909658.07.0.73751268781.issue29087@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thanks Victor.

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29087>
_______________________________________

From report at bugs.python.org  Wed Dec 28 02:23:21 2016
From: report at bugs.python.org (Seth Michael Larson)
Date: Wed, 28 Dec 2016 07:23:21 +0000
Subject: [issue29091] Python 3.5+ socket.socketpair fallback incorrectly
 implemented
Message-ID: <1482909801.54.0.391034460781.issue29091@psf.upfronthosting.co.za>


New submission from Seth Michael Larson:

The socket.socketpair() fallback for Python 3.5+ is incorrectly implemented from the original source. The fallback doesn't provide a backlog argument to the lsock.listen() function call.

When running the function it gives the following error:
`TypeError: listen() takes exactly one argument (0 given)`

Issue can be seen here on line 514: 
https://hg.python.org/cpython/file/3.6/Lib/socket.py

Should add 1 as the argument to listen() to bring the implementation in line with the source implementation at: https://gist.github.com/geertj/4325783

----------
components: Library (Lib)
messages: 284158
nosy: SethMichaelLarson
priority: normal
severity: normal
status: open
title: Python 3.5+ socket.socketpair fallback incorrectly implemented
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29091>
_______________________________________

From report at bugs.python.org  Wed Dec 28 02:41:08 2016
From: report at bugs.python.org (=?utf-8?q?R=C3=BCdiger_Jungbeck?=)
Date: Wed, 28 Dec 2016 07:41:08 +0000
Subject: [issue29037] Python 2.7.13 prints version header and exits
 immediately on Windows 10 x64
In-Reply-To: <1482346835.39.0.82709495756.issue29037@psf.upfronthosting.co.za>
Message-ID: <1482910868.68.0.781963260495.issue29037@psf.upfronthosting.co.za>


R?diger Jungbeck added the comment:

I have the same problem (on 2 different systems) with the win32 version in Windows 10.

The problem seems to go away when I start python -S so it has something to do with site.py

----------
nosy: +ruediger.jungbeck at rsj.de

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29037>
_______________________________________

From report at bugs.python.org  Wed Dec 28 02:47:17 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 28 Dec 2016 07:47:17 +0000
Subject: [issue29073] bytearray.__mod__() truncates on first \x00
In-Reply-To: <1482745964.51.0.352448624616.issue29073@psf.upfronthosting.co.za>
Message-ID: <1482911237.55.0.94504561889.issue29073@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29073>
_______________________________________

From report at bugs.python.org  Wed Dec 28 02:57:29 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 28 Dec 2016 07:57:29 +0000
Subject: [issue29073] bytearray.__mod__() truncates on first \x00
In-Reply-To: <1482745964.51.0.352448624616.issue29073@psf.upfronthosting.co.za>
Message-ID: <20161228075725.18214.13251.F11EC159@psf.io>


Roundup Robot added the comment:

New changeset 277b36596a54 by Serhiy Storchaka in branch '3.5':
Issue #29073: bytearray formatting no longer truncates on first null byte.
https://hg.python.org/cpython/rev/277b36596a54

New changeset 9b77e3a586b0 by Serhiy Storchaka in branch '3.6':
Issue #29073: Added a test for bytearray formatting with null byte.
https://hg.python.org/cpython/rev/9b77e3a586b0

New changeset 82bfdf599e24 by Serhiy Storchaka in branch 'default':
Issue #29073: Added a test for bytearray formatting with null byte.
https://hg.python.org/cpython/rev/82bfdf599e24

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29073>
_______________________________________

From report at bugs.python.org  Wed Dec 28 02:59:58 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 28 Dec 2016 07:59:58 +0000
Subject: [issue29073] bytearray.__mod__() truncates on first \x00
In-Reply-To: <1482745964.51.0.352448624616.issue29073@psf.upfronthosting.co.za>
Message-ID: <1482911998.1.0.132948270843.issue29073@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29073>
_______________________________________

From report at bugs.python.org  Wed Dec 28 03:07:50 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 28 Dec 2016 08:07:50 +0000
Subject: [issue9770] curses.ascii.isblank() function is broken. It confuses
 backspace (BS 0x08) with tab (0x09)
In-Reply-To: <1283558509.74.0.494754089018.issue9770@psf.upfronthosting.co.za>
Message-ID: <20161228080747.20377.98600.81241CD9@psf.io>


Roundup Robot added the comment:

New changeset cba619a7bf6a by Serhiy Storchaka in branch '3.5':
Issue #9770: curses.ascii predicates now work correctly with negative integers.
https://hg.python.org/cpython/rev/cba619a7bf6a

New changeset 84ca252ac346 by Serhiy Storchaka in branch '2.7':
Issue #9770: curses.ascii predicates now work correctly with negative integers.
https://hg.python.org/cpython/rev/84ca252ac346

New changeset eb81f2d2a42b by Serhiy Storchaka in branch '3.6':
Issue #9770: curses.ascii predicates now work correctly with negative integers.
https://hg.python.org/cpython/rev/eb81f2d2a42b

New changeset 1c0b72996e60 by Serhiy Storchaka in branch 'default':
Issue #9770: curses.ascii predicates now work correctly with negative integers.
https://hg.python.org/cpython/rev/1c0b72996e60

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9770>
_______________________________________

From report at bugs.python.org  Wed Dec 28 03:08:42 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 28 Dec 2016 08:08:42 +0000
Subject: [issue9770] curses.ascii.isblank() function is broken. It confuses
 backspace (BS 0x08) with tab (0x09)
In-Reply-To: <1283558509.74.0.494754089018.issue9770@psf.upfronthosting.co.za>
Message-ID: <1482912522.9.0.306069410927.issue9770@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9770>
_______________________________________

From report at bugs.python.org  Wed Dec 28 03:10:08 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 28 Dec 2016 08:10:08 +0000
Subject: [issue13051] Infinite recursion in curses.textpad.Textbox
In-Reply-To: <1317170831.29.0.145546521568.issue13051@psf.upfronthosting.co.za>
Message-ID: <1482912608.85.0.733561221131.issue13051@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13051>
_______________________________________

From report at bugs.python.org  Wed Dec 28 03:15:07 2016
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 28 Dec 2016 08:15:07 +0000
Subject: [issue29037] Python 2.7.13 prints version header and exits
 immediately on Windows 10 x64
In-Reply-To: <1482346835.39.0.82709495756.issue29037@psf.upfronthosting.co.za>
Message-ID: <1482912907.17.0.813318345992.issue29037@psf.upfronthosting.co.za>


Eryk Sun added the comment:

In the cmd shell, run `where python` to confirm that "python" runs 2.7 python.exe, and not a python.bat or python.lnk file. Also, check whether stdin is an interactive terminal by running `python -c "import sys; print sys.stdin.isatty()"`.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29037>
_______________________________________

From report at bugs.python.org  Wed Dec 28 03:23:42 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 28 Dec 2016 08:23:42 +0000
Subject: [issue13051] Infinite recursion in curses.textpad.Textbox
In-Reply-To: <1317170831.29.0.145546521568.issue13051@psf.upfronthosting.co.za>
Message-ID: <20161228082339.79403.61585.0EF9A4B5@psf.io>


Roundup Robot added the comment:

New changeset b446a4aab9cf by Serhiy Storchaka in branch '3.5':
Issue #13051: Fixed recursion errors in large or resized curses.textpad.Textbox.
https://hg.python.org/cpython/rev/b446a4aab9cf

New changeset d87771d1c1e6 by Serhiy Storchaka in branch '2.7':
Issue #13051: Fixed recursion errors in large or resized curses.textpad.Textbox.
https://hg.python.org/cpython/rev/d87771d1c1e6

New changeset ea87e00a3e89 by Serhiy Storchaka in branch '3.6':
Issue #13051: Fixed recursion errors in large or resized curses.textpad.Textbox.
https://hg.python.org/cpython/rev/ea87e00a3e89

New changeset ea7f22cf9c8c by Serhiy Storchaka in branch 'default':
Issue #13051: Fixed recursion errors in large or resized curses.textpad.Textbox.
https://hg.python.org/cpython/rev/ea7f22cf9c8c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13051>
_______________________________________

From report at bugs.python.org  Wed Dec 28 03:24:41 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 28 Dec 2016 08:24:41 +0000
Subject: [issue13051] Infinite recursion in curses.textpad.Textbox
In-Reply-To: <1317170831.29.0.145546521568.issue13051@psf.upfronthosting.co.za>
Message-ID: <1482913481.27.0.0755786566639.issue13051@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your contribution Tycho.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13051>
_______________________________________

From report at bugs.python.org  Wed Dec 28 03:27:07 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 28 Dec 2016 08:27:07 +0000
Subject: [issue24288] Include/opcode.h is modified during building
In-Reply-To: <1432626475.52.0.752359380395.issue24288@psf.upfronthosting.co.za>
Message-ID: <1482913627.32.0.224721295347.issue24288@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Please open new issue Tres. If it is not opened.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24288>
_______________________________________

From report at bugs.python.org  Wed Dec 28 03:30:44 2016
From: report at bugs.python.org (A.B., Khalid)
Date: Wed, 28 Dec 2016 08:30:44 +0000
Subject: [issue29037] Python 2.7.13 prints version header and exits
 immediately on Windows 10 x64
In-Reply-To: <1482346835.39.0.82709495756.issue29037@psf.upfronthosting.co.za>
Message-ID: <1482913844.79.0.787550553137.issue29037@psf.upfronthosting.co.za>


A.B., Khalid added the comment:

Running "where python" shows that the updated python (the one with the bug mentioned above) is the one being run.

Running python -c "import sys; print sys.stdin.isatty()" prints out "True".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29037>
_______________________________________

From report at bugs.python.org  Wed Dec 28 03:42:26 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 28 Dec 2016 08:42:26 +0000
Subject: [issue29092] Sync os.stat's doc and doc string
Message-ID: <1482914545.99.0.849195642081.issue29092@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

The accepted types of parameter *path* are different between os.stat's doc and doc string.

In doc, it mentions Pathlike, string and file descriptor. In doc string, it mentions string, bytes and file descriptor. (3.5 only lack bytes in doc).

----------
assignee: docs at python
components: Documentation
files: doc-os-stat.patch
keywords: patch
messages: 284167
nosy: docs at python, xiang.zhang
priority: normal
severity: normal
stage: patch review
status: open
title: Sync os.stat's doc and doc string
versions: Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file46061/doc-os-stat.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29092>
_______________________________________

From report at bugs.python.org  Wed Dec 28 04:15:30 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 28 Dec 2016 09:15:30 +0000
Subject: [issue28969] lru_cache is not threadsafe
In-Reply-To: <1481712564.52.0.530922236321.issue28969@psf.upfronthosting.co.za>
Message-ID: <1482916530.29.0.320154407567.issue28969@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

What solution do you prefer Raymond?

----------
assignee: serhiy.storchaka -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28969>
_______________________________________

From report at bugs.python.org  Wed Dec 28 04:31:40 2016
From: report at bugs.python.org (Petri Lehtinen)
Date: Wed, 28 Dec 2016 09:31:40 +0000
Subject: [issue16121] shlex.shlex.error_leader() reports incorrect line number
In-Reply-To: <1349295018.27.0.805550020258.issue16121@psf.upfronthosting.co.za>
Message-ID: <1482917500.61.0.213562473348.issue16121@psf.upfronthosting.co.za>


Changes by Petri Lehtinen <petri at digip.org>:


----------
nosy:  -petri.lehtinen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16121>
_______________________________________

From report at bugs.python.org  Wed Dec 28 05:36:02 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 28 Dec 2016 10:36:02 +0000
Subject: [issue28969] lru_cache is not threadsafe
In-Reply-To: <1481712564.52.0.530922236321.issue28969@psf.upfronthosting.co.za>
Message-ID: <1482921362.15.0.312689346677.issue28969@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Antoine noticed that the first patch doesn't need special sentinel object. Thus it can be simplified.

----------
Added file: http://bugs.python.org/file46062/lru_cache-dict-pop-3.5-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28969>
_______________________________________

From report at bugs.python.org  Wed Dec 28 07:23:31 2016
From: report at bugs.python.org (Jan Niklas Hasse)
Date: Wed, 28 Dec 2016 12:23:31 +0000
Subject: [issue28180] sys.getfilesystemencoding() should default to utf-8
In-Reply-To: <1474024622.65.0.838685461995.issue28180@psf.upfronthosting.co.za>
Message-ID: <1482927811.23.0.955345779468.issue28180@psf.upfronthosting.co.za>


Jan Niklas Hasse added the comment:

Only important case for me: What when LANG is unset?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28180>
_______________________________________

From report at bugs.python.org  Wed Dec 28 07:48:18 2016
From: report at bugs.python.org (Evan)
Date: Wed, 28 Dec 2016 12:48:18 +0000
Subject: [issue29093] Windows launcher breaks history in Git Bash
Message-ID: <1482929297.98.0.0622229530904.issue29093@psf.upfronthosting.co.za>


New submission from Evan:

When I launch *any* version of Python using py.exe from Git Bash, the up and down arrows clear the line buffer instead of navigating history.

The following things all work as intended:

* py.exe in cmd.exe
* py.exe in Git Bash using winpty
* Python 2.7, 3.5, 3.6 when run directly

The only thing that appears to trigger this bug is using the launcher in Git Bash without winpty.

Tested with the following versions of Git Bash:

* GNU bash, version 4.3.42(2)-release (x86_64-pc-msys)
* GNU bash, version 4.3.46(2)-release (x86_64-pc-msys)

Unfortunately I can't point to exactly which version of the launcher introduced this bug. Initially I was certain this only happened when I upgraded from 3.5.2 to 3.6.0, but now I've checked another machine with 3.5.2 and 3.4.4, and the bug appears there too.

----------
components: Windows
messages: 284171
nosy: evan_, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows launcher breaks history in Git Bash
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29093>
_______________________________________

From report at bugs.python.org  Wed Dec 28 08:26:31 2016
From: report at bugs.python.org (Peter Ebden)
Date: Wed, 28 Dec 2016 13:26:31 +0000
Subject: [issue29094] Regression in zipfile writing in 2.7.13
Message-ID: <1482931591.96.0.8795611166.issue29094@psf.upfronthosting.co.za>


New submission from Peter Ebden:

In Python 2.7.13, using zipfile.ZipFile to write into a file with some initial preamble produces a zip file that cannot be read again by some zip implementations.
Our use case is using pex (https://github.com/pantsbuild/pex) which writes a zip that begins with a shebang, and later attempting to manipulate that using Go's standard archive/zip package. In 2.7.12 that works OK, but in 2.7.13 the .pex file is rejected on reading. Linux's command-line unzip tool will read the archive, but issues a warning ("4 extra bytes at beginning or within zipfile") which wasn't present previously. 
zipfile.ZipFile does read the files OK.

I assume this is related to https://bugs.python.org/issue26293 since that's the most obvious zipfile change in 2.7.13. It's pretty easy to reproduce using the example in that issue:

from zipfile import ZipFile
with open('a.zip', 'wb') as base:
    base.write(b'old\n')
    with ZipFile(base, 'a') as myzip:
        myzip.write('eggs.txt')

unzip -t a.zip
Archive:  a.zip
warning [a.zip]:  4 extra bytes at beginning or within zipfile
  (attempting to process anyway)
...

----------
components: Library (Lib)
messages: 284172
nosy: Peter Ebden
priority: normal
severity: normal
status: open
title: Regression in zipfile writing in 2.7.13
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29094>
_______________________________________

From report at bugs.python.org  Wed Dec 28 08:26:35 2016
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 28 Dec 2016 13:26:35 +0000
Subject: [issue26382] List object memory allocator
In-Reply-To: <1455805611.43.0.0364707113583.issue26382@psf.upfronthosting.co.za>
Message-ID: <1482931595.5.0.869132876662.issue26382@psf.upfronthosting.co.za>


INADA Naoki added the comment:

Update patch for Python 2.7

----------
nosy: +inada.naoki
versions: +Python 3.7 -Python 3.6
Added file: http://bugs.python.org/file46063/listobject_CPython2-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26382>
_______________________________________

From report at bugs.python.org  Wed Dec 28 09:33:52 2016
From: report at bugs.python.org (R. David Murray)
Date: Wed, 28 Dec 2016 14:33:52 +0000
Subject: [issue29089] dictionary keys described incorrectly in tutorial
In-Reply-To: <1482874025.47.0.911588306573.issue29089@psf.upfronthosting.co.za>
Message-ID: <1482935632.36.0.164150156081.issue29089@psf.upfronthosting.co.za>


R. David Murray added the comment:

You know, it might actually not be a bad idea to use a slightly different color scheme for the tutorial.  We'll see if that idea generates any interest :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29089>
_______________________________________

From report at bugs.python.org  Wed Dec 28 09:37:39 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 28 Dec 2016 14:37:39 +0000
Subject: [issue29084] C API of OrderedDict
In-Reply-To: <1482847157.79.0.799208161515.issue29084@psf.upfronthosting.co.za>
Message-ID: <1482935859.8.0.860062301675.issue29084@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

+1 for privatizing

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29084>
_______________________________________

From report at bugs.python.org  Wed Dec 28 10:29:21 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 28 Dec 2016 15:29:21 +0000
Subject: [issue28180] sys.getfilesystemencoding() should default to utf-8
In-Reply-To: <1474024622.65.0.838685461995.issue28180@psf.upfronthosting.co.za>
Message-ID: <1482938961.37.0.469592098194.issue28180@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

If nothing is configured (i.e. none of LC_ALL, LC_CTYPE or LANG are set in the environment), then C reports the locale as "C". It's probably worthwhile for me to add a Background section to the PEP that explains the behaviour of ``setlocale`` at the C level, as that's the source of the majority of the problems, as well as the key mechanism used to implement the locale coercion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28180>
_______________________________________

From report at bugs.python.org  Wed Dec 28 10:49:03 2016
From: report at bugs.python.org (Steve Dower)
Date: Wed, 28 Dec 2016 15:49:03 +0000
Subject: [issue29037] Python 2.7.13 prints version header and exits
 immediately on Windows 10 x64
In-Reply-To: <1482346835.39.0.82709495756.issue29037@psf.upfronthosting.co.za>
Message-ID: <1482940143.42.0.0758782491639.issue29037@psf.upfronthosting.co.za>


Steve Dower added the comment:

Running "python -v" might show what the last thing it tried to do before exiting was.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29037>
_______________________________________

From report at bugs.python.org  Wed Dec 28 10:51:24 2016
From: report at bugs.python.org (Steve Dower)
Date: Wed, 28 Dec 2016 15:51:24 +0000
Subject: [issue29059] Windows: Python not using ANSI compatible console
In-Reply-To: <1482543191.02.0.407458515739.issue29059@psf.upfronthosting.co.za>
Message-ID: <1482940284.51.0.363759510932.issue29059@psf.upfronthosting.co.za>


Steve Dower added the comment:

Sounds good. Don't focus on ease of implementation, BTW. The post and eventual PEP need to cover the benefits, risks and alternatives more than anything else.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29059>
_______________________________________

From report at bugs.python.org  Wed Dec 28 10:54:18 2016
From: report at bugs.python.org (Steve Dower)
Date: Wed, 28 Dec 2016 15:54:18 +0000
Subject: [issue29093] Windows launcher breaks history in Git Bash
In-Reply-To: <1482929297.98.0.0622229530904.issue29093@psf.upfronthosting.co.za>
Message-ID: <1482940458.7.0.992351257038.issue29093@psf.upfronthosting.co.za>


Steve Dower added the comment:

You mean the history within Python? That's extremely strange.

Have you reported this to the git bash folks? We'll probably need someone who understands what their shell is actually doing to make any progress here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29093>
_______________________________________

From report at bugs.python.org  Wed Dec 28 11:13:50 2016
From: report at bugs.python.org (A.B., Khalid)
Date: Wed, 28 Dec 2016 16:13:50 +0000
Subject: [issue29037] Python 2.7.13 prints version header and exits
 immediately on Windows 10 x64
In-Reply-To: <1482346835.39.0.82709495756.issue29037@psf.upfronthosting.co.za>
Message-ID: <1482941630.56.0.926509677957.issue29037@psf.upfronthosting.co.za>


A.B., Khalid added the comment:

I enclose the output of "python -v". Where Python exits is of course indicated by the end of the file. However, there is no obvious error that is printed out.

Also it might be worthwhile to note that I cleared all compiled files left over from the previous Python (2.7.12) so as to make sure none of them was the cause of the problem. That unfortunately did not affect the buggy behavior.

----------
Added file: http://bugs.python.org/file46064/python-v.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29037>
_______________________________________

From report at bugs.python.org  Wed Dec 28 11:23:03 2016
From: report at bugs.python.org (Matthew Barnett)
Date: Wed, 28 Dec 2016 16:23:03 +0000
Subject: [issue29074] repr doesn't give full result for this re math result
In-Reply-To: <1482756115.08.0.598245159081.issue29074@psf.upfronthosting.co.za>
Message-ID: <1482942183.24.0.501723443719.issue29074@psf.upfronthosting.co.za>


Matthew Barnett added the comment:

Probably "...", although we also have to consider that the matched portion could in fact not be truncated but just happen to end with "...", although that would be a rare occurrence.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29074>
_______________________________________

From report at bugs.python.org  Wed Dec 28 11:48:43 2016
From: report at bugs.python.org (Tim Golden)
Date: Wed, 28 Dec 2016 16:48:43 +0000
Subject: [issue29037] Python 2.7.13 prints version header and exits
 immediately on Windows 10 x64
In-Reply-To: <1482941630.56.0.926509677957.issue29037@psf.upfronthosting.co.za>
Message-ID: <38d131e8-5804-9bef-df1e-a739449050d5@timgolden.me.uk>


Tim Golden added the comment:

Do you have any Python environment variables set?

If you're not sure, try at a command prompt:

SET PY

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29037>
_______________________________________

From report at bugs.python.org  Wed Dec 28 11:59:21 2016
From: report at bugs.python.org (A.B., Khalid)
Date: Wed, 28 Dec 2016 16:59:21 +0000
Subject: [issue29037] Python 2.7.13 prints version header and exits
 immediately on Windows 10 x64
In-Reply-To: <1482346835.39.0.82709495756.issue29037@psf.upfronthosting.co.za>
Message-ID: <1482944361.84.0.775321915915.issue29037@psf.upfronthosting.co.za>


A.B., Khalid added the comment:

Output of SET PY is as follows:

E:\>SET PY
PYSDL2_DLL_PATH=E:\Python27\Lib\site-packages
PYTHON3_HOME=E:\Python35
PYTHON_HOME=E:\Python27

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29037>
_______________________________________

From report at bugs.python.org  Wed Dec 28 12:05:09 2016
From: report at bugs.python.org (Evan)
Date: Wed, 28 Dec 2016 17:05:09 +0000
Subject: [issue29093] Windows launcher breaks history in Git Bash
In-Reply-To: <1482929297.98.0.0622229530904.issue29093@psf.upfronthosting.co.za>
Message-ID: <1482944709.57.0.306036834468.issue29093@psf.upfronthosting.co.za>


Evan added the comment:

Yes, the history within the current Python session. It's worth noting that the history usually behaves like in cmd.exe, not bash. (I don't have a py.exe without the bug at the moment to confirm that is the same.)

Testing now, it seems all the history shortcuts (F1-F9) function correctly when running Python directly, but when run with the launcher all behave as though the history buffer were empty. Somehow the combination of the shell and the launcher are stopping it from keeping history.

I'll open an issue on their bug tracker and report back.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29093>
_______________________________________

From report at bugs.python.org  Wed Dec 28 12:06:16 2016
From: report at bugs.python.org (Steve Dower)
Date: Wed, 28 Dec 2016 17:06:16 +0000
Subject: [issue29037] Python 2.7.13 prints version header and exits
 immediately on Windows 10 x64
In-Reply-To: <1482346835.39.0.82709495756.issue29037@psf.upfronthosting.co.za>
Message-ID: <1482944776.48.0.0576964457767.issue29037@psf.upfronthosting.co.za>


Steve Dower added the comment:

pyreadline is probably the problem. Try uninstalling or updating it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29037>
_______________________________________

From report at bugs.python.org  Wed Dec 28 12:08:09 2016
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 28 Dec 2016 17:08:09 +0000
Subject: [issue29037] Python 2.7.13 prints version header and exits
 immediately on Windows 10 x64
In-Reply-To: <1482346835.39.0.82709495756.issue29037@psf.upfronthosting.co.za>
Message-ID: <1482944889.04.0.0101838074361.issue29037@psf.upfronthosting.co.za>


Eryk Sun added the comment:

You have pyreadline installed, a 3rd party module that takes over reading from the console. Try disabling it temporarily by deleting "E:\Python27\lib\site-packages\readline.pyc" and renaming "E:\Python27\lib\site-packages\readline.py" to "readline.py.bak".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29037>
_______________________________________

From report at bugs.python.org  Wed Dec 28 12:10:09 2016
From: report at bugs.python.org (=?utf-8?q?R=C3=BCdiger_Jungbeck?=)
Date: Wed, 28 Dec 2016 17:10:09 +0000
Subject: [issue29037] Python 2.7.13 prints version header and exits
 immediately on Windows 10 x64
In-Reply-To: <1482346835.39.0.82709495756.issue29037@psf.upfronthosting.co.za>
Message-ID: <1482945009.33.0.885005827971.issue29037@psf.upfronthosting.co.za>


R?diger Jungbeck added the comment:

Replacing pyreadline 2.0 with pyreadline 2.1 solved my problems

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29037>
_______________________________________

From report at bugs.python.org  Wed Dec 28 12:11:11 2016
From: report at bugs.python.org (A.B., Khalid)
Date: Wed, 28 Dec 2016 17:11:11 +0000
Subject: [issue29037] Python 2.7.13 prints version header and exits
 immediately on Windows 10 x64
In-Reply-To: <1482346835.39.0.82709495756.issue29037@psf.upfronthosting.co.za>
Message-ID: <1482945071.36.0.861302052895.issue29037@psf.upfronthosting.co.za>


A.B., Khalid added the comment:

OK. I updated pyreadline to version 2.1 from version 2.0 and now the buggy behavior is gone.

"""
E:\>python
Python 2.7.13 (v2.7.13:a06454b1afa1, Dec 17 2016, 20:53:40) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>>
"""

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29037>
_______________________________________

From report at bugs.python.org  Wed Dec 28 12:14:26 2016
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 28 Dec 2016 17:14:26 +0000
Subject: [issue29090] python34.dll crash
In-Reply-To: <1482892800.26.0.562397151262.issue29090@psf.upfronthosting.co.za>
Message-ID: <1482945266.94.0.174872915211.issue29090@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Unfortunately, this is unlikely to be fixed.  Python 3.4 is in security-fix only mode, so this will only be fixed in 3.4 if it can be shown to be a security issue.  Even so, a binary installer will not be produced for the next 3.4 release, so you'd have to build it yourself.  Also, it's not clear that this is a bug in Python itself, we'd need a reproducer that doesn't require PySerial.

Are you certain that you're using the same versions of Python and PySerial that were previously working?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29090>
_______________________________________

From report at bugs.python.org  Wed Dec 28 12:15:50 2016
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 28 Dec 2016 17:15:50 +0000
Subject: [issue29037] Python 2.7.13 prints version header and exits
 immediately on Windows 10 x64
In-Reply-To: <1482346835.39.0.82709495756.issue29037@psf.upfronthosting.co.za>
Message-ID: <1482945350.93.0.706598755996.issue29037@psf.upfronthosting.co.za>


Changes by Eryk Sun <eryksun at gmail.com>:


----------
Removed message: http://bugs.python.org/msg284186

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29037>
_______________________________________

From report at bugs.python.org  Wed Dec 28 12:59:20 2016
From: report at bugs.python.org (Steve Dower)
Date: Wed, 28 Dec 2016 17:59:20 +0000
Subject: [issue29033] Windows Python installer rolls back when run under
 SYSTEM account (SCCM)
In-Reply-To: <1482311785.5.0.564825395885.issue29033@psf.upfronthosting.co.za>
Message-ID: <1482947960.85.0.799163093763.issue29033@psf.upfronthosting.co.za>


Steve Dower added the comment:

Thanks. I finally got a chance to look at these logs - apologies for taking some time.

It looks like some of the installs succeeded and others were then trying to modify the existing installation (I *think* this is why the unattend.xml file had no effect).

This has hit a particular known problem where a quiet per-machine install when one already exists will uninstall packages, rather than quickly exiting because it's already up to date. I haven't been able to figure out the cause before, but your logs have given me some more information to work with, so thank you :)

I don't see any problem here with the first installation, so provided you do not try to run it a second time, I think it should be fine. Perhaps you can add your own pre-check to the batch file or SCCM to skip it? Meanwhile, I'll try and figure out a good solution to the underlying issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29033>
_______________________________________

From report at bugs.python.org  Wed Dec 28 13:41:07 2016
From: report at bugs.python.org (Mike Place)
Date: Wed, 28 Dec 2016 18:41:07 +0000
Subject: [issue16396] Importing ctypes.wintypes on Linux gives a traceback
In-Reply-To: <1351956172.0.0.64927799046.issue16396@psf.upfronthosting.co.za>
Message-ID: <1482950467.87.0.195884345904.issue16396@psf.upfronthosting.co.za>


Mike Place added the comment:

+1 to getting this patch in. The fact that this raises a ValueError and not an ImportError is really annoying and we definitely see it as a bug.

----------
nosy: +Mike Place

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16396>
_______________________________________

From report at bugs.python.org  Wed Dec 28 14:42:16 2016
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 28 Dec 2016 19:42:16 +0000
Subject: [issue29085] Python 3.6 on Windows doesn't seed Random() well enough
In-Reply-To: <1482860364.41.0.203895591313.issue29085@psf.upfronthosting.co.za>
Message-ID: <1482954136.21.0.731700377678.issue29085@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Does this affect the secrets module at all?

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29085>
_______________________________________

From report at bugs.python.org  Wed Dec 28 14:42:38 2016
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 28 Dec 2016 19:42:38 +0000
Subject: [issue29085] Python 3.6 on Windows doesn't seed Random() well enough
In-Reply-To: <1482860364.41.0.203895591313.issue29085@psf.upfronthosting.co.za>
Message-ID: <1482954158.16.0.677689823488.issue29085@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29085>
_______________________________________

From report at bugs.python.org  Wed Dec 28 15:02:42 2016
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Wed, 28 Dec 2016 20:02:42 +0000
Subject: [issue29095] Compiling Python 3.6 from source on MacOS X Sierra
Message-ID: <1482955362.45.0.530145158959.issue29095@psf.upfronthosting.co.za>


New submission from Walter D?rwald:

I'm trying to compile Python 3.6 from source on MacOS X Sierra. However it seems that the _ssl module doesn't get built. Attached is the complete output.

Note that I have openssl installed via homebrew:

~/ ? brew list openssl
/usr/local/Cellar/openssl/1.0.2j/bin/c_rehash
/usr/local/Cellar/openssl/1.0.2j/bin/openssl
/usr/local/Cellar/openssl/1.0.2j/include/openssl/ (75 files)
/usr/local/Cellar/openssl/1.0.2j/lib/libcrypto.1.0.0.dylib
/usr/local/Cellar/openssl/1.0.2j/lib/libssl.1.0.0.dylib
/usr/local/Cellar/openssl/1.0.2j/lib/engines/ (12 files)
/usr/local/Cellar/openssl/1.0.2j/lib/pkgconfig/ (3 files)
/usr/local/Cellar/openssl/1.0.2j/lib/ (4 other files)
/usr/local/Cellar/openssl/1.0.2j/share/man/ (1592 files)

but if I understood Mac/BuildScript/resources/ReadMe.rtf correctly, this should be irrelevant.

Anyway the resulting pip seems to be unusable:

~/ ? python -mpip install cx_Oracle
pip is configured with locations that require TLS/SSL, however the ssl module in Python is not available.
Collecting cx_Oracle
  Could not fetch URL https://pypi.python.org/simple/cx-oracle/: There was a problem confirming the ssl certificate: Can't connect to HTTPS URL because the SSL module is not available. - skipping

----------
components: Build
files: Python3.6-build.log
messages: 284193
nosy: doerwalter
priority: normal
severity: normal
status: open
title: Compiling Python 3.6 from source on MacOS X Sierra
versions: Python 3.6
Added file: http://bugs.python.org/file46065/Python3.6-build.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29095>
_______________________________________

From report at bugs.python.org  Wed Dec 28 15:05:46 2016
From: report at bugs.python.org (INADA Naoki)
Date: Wed, 28 Dec 2016 20:05:46 +0000
Subject: [issue26382] List object memory allocator
In-Reply-To: <1455805611.43.0.0364707113583.issue26382@psf.upfronthosting.co.za>
Message-ID: <1482955546.42.0.266124845748.issue26382@psf.upfronthosting.co.za>


Changes by INADA Naoki <songofacandy at gmail.com>:


Added file: http://bugs.python.org/file46066/listobject_CPython3-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26382>
_______________________________________

From report at bugs.python.org  Wed Dec 28 15:08:13 2016
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 28 Dec 2016 20:08:13 +0000
Subject: [issue29085] Python 3.6 on Windows doesn't seed Random() well enough
In-Reply-To: <1482860364.41.0.203895591313.issue29085@psf.upfronthosting.co.za>
Message-ID: <1482955693.76.0.836975619546.issue29085@psf.upfronthosting.co.za>


Eryk Sun added the comment:

The secrets module uses SystemRandom, which overrides random() and getrandbits() to use os.urandom, so it's not affected.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29085>
_______________________________________

From report at bugs.python.org  Wed Dec 28 15:20:46 2016
From: report at bugs.python.org (Paul Moore)
Date: Wed, 28 Dec 2016 20:20:46 +0000
Subject: [issue29093] Windows launcher breaks history in Git Bash
In-Reply-To: <1482929297.98.0.0622229530904.issue29093@psf.upfronthosting.co.za>
Message-ID: <1482956446.63.0.584106877604.issue29093@psf.upfronthosting.co.za>


Paul Moore added the comment:

Does the git bash shell leave a readline DLL on the user's PATH? If so, Python's readline support will kick in, and as a result Python will behave differently.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29093>
_______________________________________

From report at bugs.python.org  Wed Dec 28 15:38:35 2016
From: report at bugs.python.org (Ted Meyer)
Date: Wed, 28 Dec 2016 20:38:35 +0000
Subject: [issue29096] Signal Handlers reliably cause UnboundLocalErrors
Message-ID: <1482957515.7.0.441178310139.issue29096@psf.upfronthosting.co.za>


New submission from Ted Meyer:

Using this simple snippit of code:
import signal



import signal

def sig_hdlr(signum, frame):
    raise ValueError()

def faulty():
    local_var = ""
    signal.signal(signal.SIGALRM, sig_hdlr)
    signal.alarm(1)
    try:
        while True:
            local_var += "!"
    except ValueError:
        print (local_val)

faulty()



I can reliably get a crash:
tmathmeyer at tmathmeyer-linuxstation:~$ python --version
Python 2.7.6
tmathmeyer at tmathmeyer-linuxstation:~$ python pybug.py 
Traceback (most recent call last):
  File "pybug.py", line 16, in <module>
    faulty()
  File "pybug.py", line 14, in faulty
    print local_val
NameError: global name 'local_val' is not defined

tmathmeyer at tmathmeyer-linuxstation:~$ python3.4 pybug.py 
Traceback (most recent call last):
  File "pybug.py", line 12, in faulty
    local_var += "!"
  File "pybug.py", line 4, in sig_hdlr
    raise ValueError()
ValueError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "pybug.py", line 16, in <module>
    faulty()
  File "pybug.py", line 14, in faulty
    print (local_val)
NameError: name 'local_val' is not defined


I can repro this on 2.7.6 and 3.4, but do not have other versions to test on.

----------
messages: 284196
nosy: Ted Meyer
priority: normal
severity: normal
status: open
title: Signal Handlers reliably cause UnboundLocalErrors
versions: Python 2.7, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29096>
_______________________________________

From report at bugs.python.org  Wed Dec 28 15:41:59 2016
From: report at bugs.python.org (Ted Meyer)
Date: Wed, 28 Dec 2016 20:41:59 +0000
Subject: [issue29096] Signal Handlers reliably cause UnboundLocalErrors
In-Reply-To: <1482957515.7.0.441178310139.issue29096@psf.upfronthosting.co.za>
Message-ID: <1482957719.98.0.129222131649.issue29096@psf.upfronthosting.co.za>


Changes by Ted Meyer <tmathmeyer at google.com>:


----------
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29096>
_______________________________________

From report at bugs.python.org  Wed Dec 28 15:46:49 2016
From: report at bugs.python.org (Ted Meyer)
Date: Wed, 28 Dec 2016 20:46:49 +0000
Subject: [issue29096] Signal Handlers reliably cause UnboundLocalErrors
In-Reply-To: <1482957515.7.0.441178310139.issue29096@psf.upfronthosting.co.za>
Message-ID: <1482958009.29.0.946561577027.issue29096@psf.upfronthosting.co.za>


Ted Meyer added the comment:

Sorry everyone, it appears I made a mistake pasting the code in here.
There was a type where I was trying to print local_val instead of local_var. the code should be this:

import signal

def sig_hdlr(signum, frame):
    raise ValueError()

def faulty():
    local_var = ""
    signal.signal(signal.SIGALRM, sig_hdlr)
    signal.alarm(1)
    try:
        while True:
            local_var += "!"
    except ValueError:
        print (local_var)

faulty()


and the crash should be this:
Traceback (most recent call last):
  File "pybug.py", line 12, in faulty
    local_var += "!"
  File "pybug.py", line 4, in sig_hdlr
    raise ValueError()
ValueError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "pybug.py", line 16, in <module>
    faulty()
  File "pybug.py", line 14, in faulty
    print (local_var)
UnboundLocalError: local variable 'local_var' referenced before assignment

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29096>
_______________________________________

From report at bugs.python.org  Wed Dec 28 15:49:00 2016
From: report at bugs.python.org (Joe Jevnik)
Date: Wed, 28 Dec 2016 20:49:00 +0000
Subject: [issue29096] Signal Handlers reliably cause UnboundLocalErrors
In-Reply-To: <1482957515.7.0.441178310139.issue29096@psf.upfronthosting.co.za>
Message-ID: <1482958140.15.0.985244111084.issue29096@psf.upfronthosting.co.za>


Joe Jevnik added the comment:

The issue appears to be in ceval.c:unicode_concatenate (or the py2 equivalent)

The code sets the local variable on the lhs to NULL before doing a potentially inplace append to the string. This means that if a signal is raised during the concat, we never hit the STORE_FAST instruction following the INPLACE_ADD so the local or cell still holds NULL, triggering an error.

I am not really sure what can be done to prevent the failure while still allowing the optimization.

----------
components: +Interpreter Core
nosy: +llllllllll
type: crash -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29096>
_______________________________________

From report at bugs.python.org  Wed Dec 28 15:49:20 2016
From: report at bugs.python.org (=?utf-8?q?Pekka_Kl=C3=A4rck?=)
Date: Wed, 28 Dec 2016 20:49:20 +0000
Subject: [issue29097] datetime.fromtimestamp(t) when 0 <= t <= 86399 fails on
 Python 3.6
Message-ID: <1482958160.11.0.32337159902.issue29097@psf.upfronthosting.co.za>


New submission from Pekka Kl?rck:

For example:

E:\>py -3.6 -c "import datetime; datetime.datetime.fromtimestamp(42)"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
OSError: [Errno 22] Invalid argument

Works fine at least with Python 2.6-2.7 and 3.3-3.5. Only tested on Windows (missing deadsnakes for easy Linux testing).

I was also surprised to get OSError in general, but apparently fromtimestamp uses that instead of ValueError nowadays in some error situations.

----------
messages: 284199
nosy: pekka.klarck
priority: normal
severity: normal
status: open
title: datetime.fromtimestamp(t) when 0 <= t <= 86399 fails on Python 3.6
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29097>
_______________________________________

From report at bugs.python.org  Wed Dec 28 16:47:21 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 28 Dec 2016 21:47:21 +0000
Subject: [issue26382] List object memory allocator
In-Reply-To: <1482955546.47.0.615180195635.issue26382@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwY_tuD3mPSBgvjYBFhmtD4xnAdxC1WBu=z5Sx8ZvaV4tQ@mail.gmail.com>


STINNER Victor added the comment:

Il don't understand your change: in Python 3.6, PyMem now uses exactly the
same allocator than PyObject.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26382>
_______________________________________

From report at bugs.python.org  Wed Dec 28 16:49:58 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 28 Dec 2016 21:49:58 +0000
Subject: [issue26382] List object memory allocator
In-Reply-To: <CAMpsgwY_tuD3mPSBgvjYBFhmtD4xnAdxC1WBu=z5Sx8ZvaV4tQ@mail.gmail.com>
Message-ID: <CAMpsgwZohiqGRakgoxEyzERb_EbQtEMKXmXgCXcan8_zW3Fx8Q@mail.gmail.com>


STINNER Victor added the comment:

See https://bugs.python.org/issue26249

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26382>
_______________________________________

From report at bugs.python.org  Wed Dec 28 17:08:50 2016
From: report at bugs.python.org (Carl George)
Date: Wed, 28 Dec 2016 22:08:50 +0000
Subject: [issue29098] document minimum sqlite version
Message-ID: <1482962930.74.0.760741820297.issue29098@psf.upfronthosting.co.za>


New submission from Carl George:

While attempting to build a Python 3.6 RPM for RHEL/CentOS 6, I noticed the following warning.

*** WARNING: renaming "_sqlite3" since importing it failed: build/lib.linux-i686-3.6-pydebug/_sqlite3.cpython-36dm-i386-linux-gnu.so: undefined symbol: sqlite3_stmt_readonly

I was able to locate changeset 284676cf2ac8 (#10740) which introduced the usage of the sqlite3_stmt_readonly interface.  That interface wasn't added to sqlite until 3.7.4 (http://www.sqlite.org/releaselog/3_7_4.html).  My RPM build failed because RHEL/CentOS 6 only has sqlite 3.6.20.  I understand that Python can't support old libraries forever, but can this minimum sqlite version be noted somewhere in the documentation?

----------
assignee: docs at python
components: Documentation
messages: 284202
nosy: carlwgeorge, docs at python
priority: normal
severity: normal
status: open
title: document minimum sqlite version
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29098>
_______________________________________

From report at bugs.python.org  Wed Dec 28 17:12:13 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 28 Dec 2016 22:12:13 +0000
Subject: [issue28871] Destructor of ElementTree.Element is recursive
In-Reply-To: <1482909194.16.0.445585773319.issue28871@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwayDm5uE-VsmvFYTM5uPk8S7VE6XRiKLRVDdokD2nPZ7Q@mail.gmail.com>


STINNER Victor added the comment:

This issue seems theorical to me, whereas the breakage of benchmarks is
very concrete for me. So I suggest to revert the change in Python 2.7.

(2) looks like the right design and it was implemented in Python 3 (no?).

I don't think that it's worth it to backport the change to Python 2. You
are the first one to report the issue and the backport is risky.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28871>
_______________________________________

From report at bugs.python.org  Wed Dec 28 17:39:23 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 28 Dec 2016 22:39:23 +0000
Subject: [issue29080] unnecessary hg required for build version 3.6 on Windows
In-Reply-To: <1482832382.86.0.80948215742.issue29080@psf.upfronthosting.co.za>
Message-ID: <20161228223919.3544.77721.B1D6D19F@psf.io>


Roundup Robot added the comment:

New changeset bc71c144e6f0 by Steve Dower in branch '3.5':
Issue #29080: Removes hard dependency on hg.exe from PC/build.bat
https://hg.python.org/cpython/rev/bc71c144e6f0

New changeset f98d8c9f3cde by Steve Dower in branch '3.6':
Issue #29080: Removes hard dependency on hg.exe from PC/build.bat
https://hg.python.org/cpython/rev/f98d8c9f3cde

New changeset 57c2fc60c989 by Steve Dower in branch 'default':
Issue #29080: Removes hard dependency on hg.exe from PC/build.bat
https://hg.python.org/cpython/rev/57c2fc60c989

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29080>
_______________________________________

From report at bugs.python.org  Wed Dec 28 17:39:33 2016
From: report at bugs.python.org (Steve Dower)
Date: Wed, 28 Dec 2016 22:39:33 +0000
Subject: [issue29080] unnecessary hg required for build version 3.6 on Windows
In-Reply-To: <1482832382.86.0.80948215742.issue29080@psf.upfronthosting.co.za>
Message-ID: <1482964773.81.0.572903447227.issue29080@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29080>
_______________________________________

From report at bugs.python.org  Wed Dec 28 18:04:29 2016
From: report at bugs.python.org (Bozo Kopic)
Date: Wed, 28 Dec 2016 23:04:29 +0000
Subject: [issue29099] sqlite3 timestamp converter ValueError
Message-ID: <1482966269.67.0.620298847284.issue29099@psf.upfronthosting.co.za>


New submission from Bozo Kopic:

Current convert_timestamp function raises exception when parsing timestamps that contain timezone information and have microsecond set to zero.

Patch for this behavior is included.

Example script that demonstrates this problem:

import sys
import datetime
import sqlite3
import traceback
import contextlib


def main():
    db = sqlite3.connect('test.db', detect_types=sqlite3.PARSE_DECLTYPES)
    db.executescript("""
        CREATE TABLE IF NOT EXISTS test (
            timestamp TIMESTAMP)
        """)

    t = datetime.datetime.now(tz=datetime.timezone.utc)
    t = t.replace(microsecond=0)
    db.executemany("INSERT INTO test VALUES (:timestamp)", [{'timestamp': t}])
    db.commit()

    with contextlib.closing(db.cursor()) as c:
        try:
            c.execute('SELECT * FROM test')
            c.fetchall()
            print('original implementation success')
        except Exception as e:
            print('original implementation failed')
            traceback.print_exc()
        c.close()

    sqlite3.register_converter("timestamp", _sqlite_convert_timestamp)

    with contextlib.closing(db.cursor()) as c:
        try:
            c.execute('SELECT * FROM test')
            c.fetchall()
            print('patched implementation success')
        except Exception as e:
            print('patched implementation failed')
            traceback.print_exc()
        c.close()


def _sqlite_convert_timestamp(val):
    datepart, timepart = val.split(b" ")

    # this is the patch
    timepart = timepart.split(b'+', 1)[0].split(b'-', 1)[0]

    year, month, day = map(int, datepart.split(b"-"))
    timepart_full = timepart.split(b".")
    hours, minutes, seconds = map(int, timepart_full[0].split(b":"))
    if len(timepart_full) == 2:
        microseconds = int('{:0<6.6}'.format(timepart_full[1].decode()))
    else:
        microseconds = 0
    val = datetime.datetime(year, month, day, hours, minutes, seconds,
                            microseconds)
    return val


if __name__ == '__main__':
    sys.exit(main())

----------
components: Library (Lib)
files: sqlite3.patch
keywords: patch
messages: 284205
nosy: bozo.kopic
priority: normal
severity: normal
status: open
title: sqlite3 timestamp converter ValueError
type: crash
versions: Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file46067/sqlite3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29099>
_______________________________________

From report at bugs.python.org  Wed Dec 28 18:19:12 2016
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Wed, 28 Dec 2016 23:19:12 +0000
Subject: [issue28710] Sphinx incompatible markup in the standard library
In-Reply-To: <1479257982.94.0.253343336813.issue28710@psf.upfronthosting.co.za>
Message-ID: <1482967152.34.0.80446781801.issue28710@psf.upfronthosting.co.za>


?ukasz Langa added the comment:

Marking as a stdlib-wide issue since it's not configparser-specific.

FYI, as you probably noticed, the `term' syntax predates Sphinx and is used in lots of places. While I think it would be nice to fix it, it's a big diff.

----------
title: Sphinx incompatible markup in configparser.ConfigParser. -> Sphinx incompatible markup in the standard library

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28710>
_______________________________________

From report at bugs.python.org  Wed Dec 28 18:21:32 2016
From: report at bugs.python.org (Steve Dower)
Date: Wed, 28 Dec 2016 23:21:32 +0000
Subject: [issue29033] Windows Python installer rolls back when run under
 SYSTEM account (SCCM)
In-Reply-To: <1482311785.5.0.564825395885.issue29033@psf.upfronthosting.co.za>
Message-ID: <1482967292.86.0.999684575933.issue29033@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at python.org>:


----------
assignee:  -> steve.dower

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29033>
_______________________________________

From report at bugs.python.org  Wed Dec 28 18:22:00 2016
From: report at bugs.python.org (Steve Dower)
Date: Wed, 28 Dec 2016 23:22:00 +0000
Subject: [issue25778] winreg.EnumValue does not truncate strings correctly
In-Reply-To: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za>
Message-ID: <1482967320.65.0.86640852366.issue25778@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed
versions:  -Python 2.7, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25778>
_______________________________________

From report at bugs.python.org  Wed Dec 28 18:22:22 2016
From: report at bugs.python.org (Steve Dower)
Date: Wed, 28 Dec 2016 23:22:22 +0000
Subject: [issue28747] Expose SSL_CTX_set_cert_verify_callback
In-Reply-To: <1479591372.9.0.198427018061.issue28747@psf.upfronthosting.co.za>
Message-ID: <1482967342.19.0.480701713171.issue28747@psf.upfronthosting.co.za>


Steve Dower added the comment:

Any comment from the SSL experts?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28747>
_______________________________________

From report at bugs.python.org  Wed Dec 28 18:22:46 2016
From: report at bugs.python.org (Steve Dower)
Date: Wed, 28 Dec 2016 23:22:46 +0000
Subject: [issue29060] Changing the installation location still adds AppData
 filepaths that do not exist to the path variable on Windows 10
In-Reply-To: <1482549233.73.0.705523991357.issue29060@psf.upfronthosting.co.za>
Message-ID: <1482967366.36.0.63343936296.issue29060@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29060>
_______________________________________

From report at bugs.python.org  Wed Dec 28 18:26:44 2016
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Wed, 28 Dec 2016 23:26:44 +0000
Subject: [issue28909] Adding LTTng-UST tracing support
In-Reply-To: <1481227474.94.0.337411886613.issue28909@psf.upfronthosting.co.za>
Message-ID: <1482967604.48.0.764810398754.issue28909@psf.upfronthosting.co.za>


?ukasz Langa added the comment:

This looks promising but I don't know how to test it. Tests would be welcome, as well as some explanation what OS and kernel I need to use to test it out.

Why does your patch rename the DTrace provider from "python" to "cpython"? At this point, with release of Python 3.6, it's an incompatible change we can't really accept easily.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28909>
_______________________________________

From report at bugs.python.org  Wed Dec 28 18:26:49 2016
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Wed, 28 Dec 2016 23:26:49 +0000
Subject: [issue28909] Adding LTTng-UST tracing support
In-Reply-To: <1481227474.94.0.337411886613.issue28909@psf.upfronthosting.co.za>
Message-ID: <1482967609.68.0.804964184898.issue28909@psf.upfronthosting.co.za>


Changes by ?ukasz Langa <lukasz at langa.pl>:


----------
assignee:  -> lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28909>
_______________________________________

From report at bugs.python.org  Wed Dec 28 18:30:03 2016
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Wed, 28 Dec 2016 23:30:03 +0000
Subject: [issue29077] build failure when enabling dtrace on FreeBSD
In-Reply-To: <1482779942.39.0.346100216113.issue29077@psf.upfronthosting.co.za>
Message-ID: <1482967803.4.0.547339591543.issue29077@psf.upfronthosting.co.za>


?ukasz Langa added the comment:

I cannot repro as I don't have a FreeBSD environment handy. I will gladly accept a patch that makes it work with FreeBSD 11.0!

I admit I tested my implementation with OS X 10.11 and Linux (SystemTap with Ubuntu).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29077>
_______________________________________

From report at bugs.python.org  Wed Dec 28 18:38:56 2016
From: report at bugs.python.org (Steve Dower)
Date: Wed, 28 Dec 2016 23:38:56 +0000
Subject: [issue28675] about PEP 528 / PEP 529
In-Reply-To: <1478977503.51.0.187349952636.issue28675@psf.upfronthosting.co.za>
Message-ID: <1482968336.84.0.681661262942.issue28675@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28675>
_______________________________________

From report at bugs.python.org  Wed Dec 28 18:42:04 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 28 Dec 2016 23:42:04 +0000
Subject: [issue28768] Warning: implicit declaration of function '_setmode'
In-Reply-To: <1479758430.88.0.97682867264.issue28768@psf.upfronthosting.co.za>
Message-ID: <20161228234201.3669.99798.20448951@psf.io>


Roundup Robot added the comment:

New changeset 5027780d456b by Steve Dower in branch '3.6':
Issue #28768: Fix implicit declaration of function _setmode. Patch by Masayuki Yamamoto
https://hg.python.org/cpython/rev/5027780d456b

New changeset 276d1bae92be by Steve Dower in branch 'default':
Issue #28768: Fix implicit declaration of function _setmode. Patch by Masayuki Yamamoto
https://hg.python.org/cpython/rev/276d1bae92be

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28768>
_______________________________________

From report at bugs.python.org  Wed Dec 28 18:42:29 2016
From: report at bugs.python.org (Steve Dower)
Date: Wed, 28 Dec 2016 23:42:29 +0000
Subject: [issue28768] Warning: implicit declaration of function '_setmode'
In-Reply-To: <1479758430.88.0.97682867264.issue28768@psf.upfronthosting.co.za>
Message-ID: <1482968549.16.0.153805804134.issue28768@psf.upfronthosting.co.za>


Steve Dower added the comment:

I applied to 3.6 and default. If anyone is motivated enough to apply to 2.7, feel free.

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28768>
_______________________________________

From report at bugs.python.org  Wed Dec 28 18:43:56 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 28 Dec 2016 23:43:56 +0000
Subject: [issue29080] unnecessary hg required for build version 3.6 on Windows
In-Reply-To: <1482832382.86.0.80948215742.issue29080@psf.upfronthosting.co.za>
Message-ID: <20161228234354.20560.2185.8F773F21@psf.io>


Roundup Robot added the comment:

New changeset 84beb5cba826 by Steve Dower in branch '3.5':
Issue #29080: Fixes Misc/NEWS entry
https://hg.python.org/cpython/rev/84beb5cba826

New changeset 048d1942b325 by Steve Dower in branch '3.6':
Issue #29080: Fixes Misc/NEWS entry
https://hg.python.org/cpython/rev/048d1942b325

New changeset 38e44a23ea66 by Steve Dower in branch 'default':
Issue #29080: Fixes Misc/NEWS entry
https://hg.python.org/cpython/rev/38e44a23ea66

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29080>
_______________________________________

From report at bugs.python.org  Wed Dec 28 18:45:38 2016
From: report at bugs.python.org (Steve Dower)
Date: Wed, 28 Dec 2016 23:45:38 +0000
Subject: [issue28983] Python 3.5.2 won't install on my computer
In-Reply-To: <1481840742.78.0.554470867064.issue28983@psf.upfronthosting.co.za>
Message-ID: <1482968738.31.0.747579374412.issue28983@psf.upfronthosting.co.za>


Steve Dower added the comment:

Apologies for the delayed response - I haven't been going through bugs recently.

If you're still having trouble, please try uninstalling and then running the commands above. After that, try reinstalling. (Those are uninstall commands that should fix the problem of it not-quite-uninstalling. If you run them after installing, you will definitely corrupt your installation.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28983>
_______________________________________

From report at bugs.python.org  Wed Dec 28 18:46:18 2016
From: report at bugs.python.org (Steve Dower)
Date: Wed, 28 Dec 2016 23:46:18 +0000
Subject: [issue29037] Python 2.7.13 prints version header and exits
 immediately on Windows 10 x64
In-Reply-To: <1482346835.39.0.82709495756.issue29037@psf.upfronthosting.co.za>
Message-ID: <1482968778.69.0.191361053776.issue29037@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29037>
_______________________________________

From report at bugs.python.org  Wed Dec 28 18:47:13 2016
From: report at bugs.python.org (Steve Dower)
Date: Wed, 28 Dec 2016 23:47:13 +0000
Subject: [issue28902] 3.6.0rc1 installer fails to install / uninstall.
In-Reply-To: <1481178281.99.0.0821886789548.issue28902@psf.upfronthosting.co.za>
Message-ID: <1482968833.26.0.419691863669.issue28902@psf.upfronthosting.co.za>


Steve Dower added the comment:

I believe this is out of date now, but if you have similar issues with the final release, feel free to respond to this thread again.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28902>
_______________________________________

From report at bugs.python.org  Wed Dec 28 18:52:58 2016
From: report at bugs.python.org (Steve Dower)
Date: Wed, 28 Dec 2016 23:52:58 +0000
Subject: [issue26631] Unable to install Python 3.5.1 on Windows 10 - Error
 0x80070643: Failed to install MSI package.
In-Reply-To: <1458771798.71.0.333968276616.issue26631@psf.upfronthosting.co.za>
Message-ID: <1482969178.31.0.881368272409.issue26631@psf.upfronthosting.co.za>


Steve Dower added the comment:

oselljr - are you still having this trouble with 3.5.2?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26631>
_______________________________________

From report at bugs.python.org  Wed Dec 28 18:54:33 2016
From: report at bugs.python.org (Steve Dower)
Date: Wed, 28 Dec 2016 23:54:33 +0000
Subject: [issue28989] .dll files missing
In-Reply-To: <1481902695.92.0.0511959734428.issue28989@psf.upfronthosting.co.za>
Message-ID: <1482969273.14.0.890247885383.issue28989@psf.upfronthosting.co.za>


Steve Dower added the comment:

Gabriel - did that solution work for you? If not, can you install and provide all the Python logs from %TEMP%?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28989>
_______________________________________

From report at bugs.python.org  Wed Dec 28 19:03:58 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 29 Dec 2016 00:03:58 +0000
Subject: [issue29079] pathlib.resolve() causes infinite loop on Windows
In-Reply-To: <1482785174.29.0.0980303906914.issue29079@psf.upfronthosting.co.za>
Message-ID: <20161229000354.80070.25798.F0DCE9A9@psf.io>


Roundup Robot added the comment:

New changeset af8c8551ea45 by Steve Dower in branch '3.6':
Issue #29079: Prevent infinite loop in pathlib.resolve() on Windows
https://hg.python.org/cpython/rev/af8c8551ea45

New changeset 9de7bf6c60d2 by Steve Dower in branch 'default':
Issue #29079: Prevent infinite loop in pathlib.resolve() on Windows
https://hg.python.org/cpython/rev/9de7bf6c60d2

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29079>
_______________________________________

From report at bugs.python.org  Wed Dec 28 19:04:11 2016
From: report at bugs.python.org (Steve Dower)
Date: Thu, 29 Dec 2016 00:04:11 +0000
Subject: [issue29079] pathlib.resolve() causes infinite loop on Windows
In-Reply-To: <1482785174.29.0.0980303906914.issue29079@psf.upfronthosting.co.za>
Message-ID: <1482969851.28.0.301069755287.issue29079@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at python.org>:


----------
assignee:  -> steve.dower
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29079>
_______________________________________

From report at bugs.python.org  Wed Dec 28 19:50:47 2016
From: report at bugs.python.org (Jordon Phillips)
Date: Thu, 29 Dec 2016 00:50:47 +0000
Subject: [issue29100] Core dump / OverflowError for datetime.fromtimestamp
 with overly large timestamp in Ubuntu 12.04
Message-ID: <1482972647.78.0.524140289263.issue29100@psf.upfronthosting.co.za>


New submission from Jordon Phillips:

In Python 3.6.0 if you give datetime.fromtimestamp a very bad value you either get a core dump or an OverflowError. The core dump occurs when no tzinfo is provided, the OverflowError occurs when a tzinfo is provided (such as tzlocal from dateutil). Attached is a minimal script to reproduce the error. Note that this behavior only occurs on certain systems. It does not happen on OSX 10.11.6, but it does happen on Ubuntu 12.04. I imagine it happens on other systems as well, but I haven't tested beyond those two.

Here are the specific errors I get on Ubuntu 12.04. When no tzinfo is provided:

python: /tmp/python-build.20161228223921.28011/Python-3.6.0/Modules/_datetimemodule.c:251: days_before_year: Assertion `year >= 1' failed.
Aborted (core dumped)

When a tzinfo is provided:

Traceback (most recent call last):
  File "test1.py", line 11, in <module>
    datetime.fromtimestamp(bad_st_mtime, local_time_zone)
  File "~/.pyenv/versions/venv36d/lib/python3.6/site-packages/dateutil/tz/_common.py", line 210, in fromutc
    dt_wall = self._fromutc(dt)
  File "~/.pyenv/versions/venv36d/lib/python3.6/site-packages/dateutil/tz/_common.py", line 195, in _fromutc
    return dt + dtdst
OverflowError: date value out of range


I imagine this is related to the fold changes.

----------
components: Library (Lib)
files: test.py
messages: 284218
nosy: Jordon Phillips
priority: normal
severity: normal
status: open
title: Core dump / OverflowError for datetime.fromtimestamp with overly large timestamp in Ubuntu 12.04
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file46068/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29100>
_______________________________________

From report at bugs.python.org  Wed Dec 28 19:52:25 2016
From: report at bugs.python.org (Donald Stufft)
Date: Thu, 29 Dec 2016 00:52:25 +0000
Subject: [issue29100] Core dump / OverflowError for datetime.fromtimestamp
 with overly large timestamp in Ubuntu 12.04
In-Reply-To: <1482972647.78.0.524140289263.issue29100@psf.upfronthosting.co.za>
Message-ID: <1482972745.55.0.224199957443.issue29100@psf.upfronthosting.co.za>


Changes by Donald Stufft <donald at stufft.io>:


----------
nosy: +dstufft

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29100>
_______________________________________

From report at bugs.python.org  Wed Dec 28 20:00:48 2016
From: report at bugs.python.org (Evan)
Date: Thu, 29 Dec 2016 01:00:48 +0000
Subject: [issue29093] Windows launcher breaks history in Git Bash
In-Reply-To: <1482929297.98.0.0622229530904.issue29093@psf.upfronthosting.co.za>
Message-ID: <1482973248.57.0.259103999639.issue29093@psf.upfronthosting.co.za>


Evan added the comment:

No, it doesn't provide a version of readline that works with Windows binaries. Trying to import readline fails no matter how I start Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29093>
_______________________________________

From report at bugs.python.org  Wed Dec 28 20:11:01 2016
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 29 Dec 2016 01:11:01 +0000
Subject: [issue29059] Windows: Python not using ANSI compatible console
In-Reply-To: <1482543191.02.0.407458515739.issue29059@psf.upfronthosting.co.za>
Message-ID: <1482973861.27.0.418142888006.issue29059@psf.upfronthosting.co.za>


Eryk Sun added the comment:

> As there is no good interface in core Python to the kernel32 console
> operations (and there probably shouldn't be, it would be better to be 
> consistent), I suggest just flipping the bit at startup on Windows.

I don't follow your statement about consistency. Python could adopt a built-in wincon module to partially support the console API, just like winreg partially supports the registry API. 

When _WindowsConsoleIO was being developed, I mentioned the idea of enabling VT mode a couple of times, but there was no interest that I could see. I don't think Windows devs really care much about this feature, especially since it's only available in Windows 10. colorama has been the popular way to get cross-platform support for supporting text color in terminals and the Windows console. There's also pyreadline, which supports VT escapes and much more. Enabling the console's VT mode won't simplify the implementation of colorama or pyreadline so long as Windows 7 and 8 are supported, which will be for several more years. 

One problem with enabling VT mode at startup is that it could cause compatibility problems with child processes. cmd faced this problem and has since resolved it [1] by reverting to the original console mode before executing a program. If Python enables VT mode at startup, there should be a sys variable (based on a C global) that has the original mode value. Applications would be able to restore the original mode to either opt out entirely or before executing a child process. Py_FinalizeEx would also have to be modified to restore the original mode before shutting down the interpreter.

[1]: http://preview.tinyurl.com/jgtcgfs

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29059>
_______________________________________

From report at bugs.python.org  Wed Dec 28 20:37:48 2016
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 29 Dec 2016 01:37:48 +0000
Subject: [issue26382] List object memory allocator
In-Reply-To: <1455805611.43.0.0364707113583.issue26382@psf.upfronthosting.co.za>
Message-ID: <1482975468.67.0.0459783073919.issue26382@psf.upfronthosting.co.za>


INADA Naoki added the comment:

I know PyMem and PyObject allocator is same by default. But it's configurable.
How should I choose right allocator?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26382>
_______________________________________

From report at bugs.python.org  Wed Dec 28 20:40:38 2016
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 29 Dec 2016 01:40:38 +0000
Subject: [issue26382] List object memory allocator
In-Reply-To: <1455805611.43.0.0364707113583.issue26382@psf.upfronthosting.co.za>
Message-ID: <1482975638.59.0.650144493738.issue26382@psf.upfronthosting.co.za>


INADA Naoki added the comment:

Maybe, PyObject_MALLOC remains only for backward compatibility?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26382>
_______________________________________

From report at bugs.python.org  Wed Dec 28 22:44:59 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Thu, 29 Dec 2016 03:44:59 +0000
Subject: [issue29095] Compiling Python 3.6 from source on MacOS X Sierra
In-Reply-To: <1482955362.45.0.530145158959.issue29095@psf.upfronthosting.co.za>
Message-ID: <1482983099.4.0.41220586234.issue29095@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

Did you set CFLAGS and LDFLAGS?

----------
nosy: +Chi Hsuan Yen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29095>
_______________________________________

From report at bugs.python.org  Wed Dec 28 22:58:24 2016
From: report at bugs.python.org (Victor Liu)
Date: Thu, 29 Dec 2016 03:58:24 +0000
Subject: [issue29101] Nested lambdas in setattr() lose context in Python 2.7
Message-ID: <1482983904.15.0.0148999643172.issue29101@psf.upfronthosting.co.za>


New submission from Victor Liu:

I would expect bug.py to output:
foo
bar
baz

but instead we observe:
baz
baz
baz

Replicated on Windows 10 Home Edition, Python 2.7.13 (v2.7.13:a06454b1afa1, Dec 17 2016, 20:42:59) [MSC v.1500 32 bit (Intel)]

----------
files: bug.py
messages: 284224
nosy: Victor Liu
priority: normal
severity: normal
status: open
title: Nested lambdas in setattr() lose context in Python 2.7
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file46069/bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29101>
_______________________________________

From report at bugs.python.org  Wed Dec 28 23:03:32 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 29 Dec 2016 04:03:32 +0000
Subject: [issue29085] Python 3.6 on Windows doesn't seed Random() well enough
In-Reply-To: <1482860364.41.0.203895591313.issue29085@psf.upfronthosting.co.za>
Message-ID: <20161229040328.3455.885.B203AF58@psf.io>


Roundup Robot added the comment:

New changeset 0a55e039d25f by Benjamin Peterson in branch '3.6':
fix error check, so that Random.seed actually uses OS randomness (closes #29085)
https://hg.python.org/cpython/rev/0a55e039d25f

New changeset fc3eab44765f by Benjamin Peterson in branch 'default':
merge 3.6 (#29085)
https://hg.python.org/cpython/rev/fc3eab44765f

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29085>
_______________________________________

From report at bugs.python.org  Wed Dec 28 23:09:08 2016
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 29 Dec 2016 04:09:08 +0000
Subject: [issue29094] Regression in zipfile writing in 2.7.13
In-Reply-To: <1482931591.96.0.8795611166.issue29094@psf.upfronthosting.co.za>
Message-ID: <1482984548.58.0.893830261343.issue29094@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> serhiy.storchaka
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29094>
_______________________________________

From report at bugs.python.org  Wed Dec 28 23:21:15 2016
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 29 Dec 2016 04:21:15 +0000
Subject: [issue29091] Python 3.5+ socket.socketpair fallback incorrectly
 implemented
In-Reply-To: <1482909801.54.0.391034460781.issue29091@psf.upfronthosting.co.za>
Message-ID: <1482985275.45.0.559578286554.issue29091@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Are you using that implementation on Python 2? Python 3's socket.listen has one optional backlog argument.

----------
nosy: +benjamin.peterson
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29091>
_______________________________________

From report at bugs.python.org  Wed Dec 28 23:23:32 2016
From: report at bugs.python.org (Seth Michael Larson)
Date: Thu, 29 Dec 2016 04:23:32 +0000
Subject: [issue29091] Python 3.5+ socket.socketpair fallback incorrectly
 implemented
In-Reply-To: <1482909801.54.0.391034460781.issue29091@psf.upfronthosting.co.za>
Message-ID: <1482985412.04.0.855196663674.issue29091@psf.upfronthosting.co.za>


Seth Michael Larson added the comment:

Sorry for making noise, yes I was using the implementation in Python 2.x. I will do better investigation in the future.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29091>
_______________________________________

From report at bugs.python.org  Wed Dec 28 23:25:25 2016
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 29 Dec 2016 04:25:25 +0000
Subject: [issue29101] Nested lambdas in setattr() lose context in Python 2.7
In-Reply-To: <1482983904.15.0.0148999643172.issue29101@psf.upfronthosting.co.za>
Message-ID: <1482985525.6.0.544073303317.issue29101@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

https://docs.python.org/2/faq/programming.html#why-do-lambdas-defined-in-a-loop-with-different-values-all-return-the-same-result

----------
nosy: +benjamin.peterson
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29101>
_______________________________________

From report at bugs.python.org  Wed Dec 28 23:31:10 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 29 Dec 2016 04:31:10 +0000
Subject: [issue29100] Core dump / OverflowError for datetime.fromtimestamp
 with overly large timestamp in Ubuntu 12.04
In-Reply-To: <1482972647.78.0.524140289263.issue29100@psf.upfronthosting.co.za>
Message-ID: <1482985870.52.0.321064937699.issue29100@psf.upfronthosting.co.za>


Changes by Xiang Zhang <angwerzx at 126.com>:


----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29100>
_______________________________________

From report at bugs.python.org  Thu Dec 29 01:53:42 2016
From: report at bugs.python.org (Eric Snow)
Date: Thu, 29 Dec 2016 06:53:42 +0000
Subject: [issue29102] Add an id field to PyInterpreterState.
Message-ID: <1482994422.5.0.64533163171.issue29102@psf.upfronthosting.co.za>


New submission from Eric Snow:

Currently there isn't any way to uniquely identify an interpreter.  This patch adds a new "id" field to the PyInterpreterState struct.  The ID for every new interpreter is set to the value of an increasing global counter.  That means that the ID is unique within the process.

IIRC, the availability of unique ID would help tools that make use of subinterpreters, like mod_wsgi.  It is also necessary for any effort to expose interpreters in Python-level code (which is the subject of other ongoing work).

The patch also adds:

unsigned long PyInterpreterState_GetID(PyInterpreterState *interp)

Note that, without a Python-level interpreters module, testing this change is limited to extending the existing test code in test_capi.

----------
assignee: eric.snow
components: Interpreter Core
files: interpreter-id.diff
keywords: patch
messages: 284229
nosy: brett.cannon, eric.snow, grahamd, ncoghlan, steve.dower
priority: normal
severity: normal
stage: patch review
status: open
title: Add an id field to PyInterpreterState.
type: enhancement
versions: Python 3.7
Added file: http://bugs.python.org/file46070/interpreter-id.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29102>
_______________________________________

From report at bugs.python.org  Thu Dec 29 02:01:49 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 Dec 2016 07:01:49 +0000
Subject: [issue29102] Add an id field to PyInterpreterState.
In-Reply-To: <1482994422.5.0.64533163171.issue29102@psf.upfronthosting.co.za>
Message-ID: <1482994909.95.0.760732100508.issue29102@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Why not use just the pointer to PyInterpreterState itself?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29102>
_______________________________________

From report at bugs.python.org  Thu Dec 29 02:07:00 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 29 Dec 2016 07:07:00 +0000
Subject: [issue29099] sqlite3 timestamp converter cannot handle timezone
In-Reply-To: <1482966269.67.0.620298847284.issue29099@psf.upfronthosting.co.za>
Message-ID: <1482995220.74.0.13533791812.issue29099@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Thanks for your report Bozo.

I think this is due to timestamp converter doesn't handle timezone now. Besides this ValueError, if I understand correctly, even if you pass a datetime object with tzinfo, with microsecond set, the returned datetime object is a wrong one since the tzinfo is discarded.

----------
nosy: +xiang.zhang
title: sqlite3 timestamp converter ValueError -> sqlite3 timestamp converter cannot handle timezone
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29099>
_______________________________________

From report at bugs.python.org  Thu Dec 29 02:13:43 2016
From: report at bugs.python.org (Eric Snow)
Date: Thu, 29 Dec 2016 07:13:43 +0000
Subject: [issue29102] Add an id field to PyInterpreterState.
In-Reply-To: <1482994422.5.0.64533163171.issue29102@psf.upfronthosting.co.za>
Message-ID: <1482995623.2.0.993941433871.issue29102@psf.upfronthosting.co.za>


Eric Snow added the comment:

Pointers can get re-used, so they aren't temporally unique.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29102>
_______________________________________

From report at bugs.python.org  Thu Dec 29 02:25:43 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 Dec 2016 07:25:43 +0000
Subject: [issue29102] Add an id field to PyInterpreterState.
In-Reply-To: <1482994422.5.0.64533163171.issue29102@psf.upfronthosting.co.za>
Message-ID: <1482996343.83.0.168840910669.issue29102@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

What is the use case of keeping the uniqueness after deleting an interpreter?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29102>
_______________________________________

From report at bugs.python.org  Thu Dec 29 02:37:30 2016
From: report at bugs.python.org (Jean-Sebastien Bevilacqua)
Date: Thu, 29 Dec 2016 07:37:30 +0000
Subject: [issue29103] Make enum.py pep8 compliant
Message-ID: <1482997050.71.0.505456771635.issue29103@psf.upfronthosting.co.za>


New submission from Jean-Sebastien Bevilacqua:

Hello,
This is my first patch on CPython, so please tell me if I do something wrong.

When executing flake8 on Lib/enum.py, there are lot of warning. This patch remove all these warnings.

----------
components: Library (Lib)
files: enum_format.patch
keywords: patch
messages: 284234
nosy: barry, eli.bendersky, ethan.furman, realitix
priority: normal
severity: normal
status: open
title: Make enum.py pep8 compliant
type: enhancement
versions: Python 3.7
Added file: http://bugs.python.org/file46071/enum_format.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29103>
_______________________________________

From report at bugs.python.org  Thu Dec 29 02:43:56 2016
From: report at bugs.python.org (Evan)
Date: Thu, 29 Dec 2016 07:43:56 +0000
Subject: [issue29093] Windows launcher breaks history in Git Bash
In-Reply-To: <1482929297.98.0.0622229530904.issue29093@psf.upfronthosting.co.za>
Message-ID: <1482997436.77.0.958807829597.issue29093@psf.upfronthosting.co.za>


Evan added the comment:

I tried compiling the version of the launcher from https://github.com/python/cpython/tree/3.3, and the bug is still present there.

Previously when I was testing older versions with the launcher I had to uninstall pyreadline from several of them to confirm the bug was present. In retrospect it's obvious that this means the bug would have been hidden from me until now; I just happened to notice it after installing 3.6 because I hadn't installed pyreadline.

I now believe this affects *all* versions of the launcher, and that this has nothing to do with 3.6.0 in particular.

Associated issue: https://github.com/git-for-windows/git/issues/1013

----------
versions: +Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29093>
_______________________________________

From report at bugs.python.org  Thu Dec 29 03:38:11 2016
From: report at bugs.python.org (Mr B Jones)
Date: Thu, 29 Dec 2016 08:38:11 +0000
Subject: [issue29033] Windows Python installer rolls back when run under
 SYSTEM account (SCCM)
In-Reply-To: <1482311785.5.0.564825395885.issue29033@psf.upfronthosting.co.za>
Message-ID: <1483000691.86.0.0496200688253.issue29033@psf.upfronthosting.co.za>


Mr B Jones added the comment:

All those logs came from one machine. SCCM is usually really good at detecting the existence of an install by checking the package GUID in the windows installed database, but getting the right GUID when dealing with a non-msi install is sometimes hit and miss (with a pure MSI install, it just pulls everything out of the MSI automagically). It can also check for the existence of files/folders, and files with particular version numbers embedded in them (though windows seems to display these version number differently than SCCM sees them sometimes).

In this case I guess I got the wrong GUID, so it went on re-trying the install, and all bets were then off. Usually the easiest way to get this right if it isn't automatic from the MSI is install the package then look in the registry for an uninstall or modify string which looks like "msiexec /x {GUID HERE}", but if I remember correctly (and it has been a couple of weeks so I could be thinking of the wrong package), the python installer doesn't do that.

When I'm back in work (from 9th), I can try it again SCCM.

Thanks for all your assistance.
Bryn

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29033>
_______________________________________

From report at bugs.python.org  Thu Dec 29 03:40:27 2016
From: report at bugs.python.org (Mr B Jones)
Date: Thu, 29 Dec 2016 08:40:27 +0000
Subject: [issue29033] Windows Python installer rolls back when run under
 SYSTEM account (SCCM)
In-Reply-To: <1482311785.5.0.564825395885.issue29033@psf.upfronthosting.co.za>
Message-ID: <1483000827.31.0.947457952379.issue29033@psf.upfronthosting.co.za>


Mr B Jones added the comment:

Windows Installer database even (autocorrect got me on the work iPhone).
Thanks again,
Bryn

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29033>
_______________________________________

From report at bugs.python.org  Thu Dec 29 04:39:33 2016
From: report at bugs.python.org (Edward K. Ream)
Date: Thu, 29 Dec 2016 09:39:33 +0000
Subject: [issue25778] winreg.EnumValue does not truncate strings correctly
In-Reply-To: <1449064525.57.0.047427517368.issue25778@psf.upfronthosting.co.za>
Message-ID: <1483004373.8.0.0214354446992.issue25778@psf.upfronthosting.co.za>


Edward K. Ream added the comment:

Thank you, Steve, et. al. for resolving this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25778>
_______________________________________

From report at bugs.python.org  Thu Dec 29 04:41:53 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 29 Dec 2016 09:41:53 +0000
Subject: [issue26382] List object memory allocator
In-Reply-To: <1482975468.67.0.0459783073919.issue26382@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbOboJQqbTdjhSXJUb_EOYOQWT3Jk1M-+1i+qm+jDvJKA@mail.gmail.com>


STINNER Victor added the comment:

I know PyMem and PyObject allocator is same by default. But it's
configurable.
How should I choose right allocator?

The two functions always use the same allocator:
https://docs.python.org/dev/using/cmdline.html#envvar-PYTHONMALLOC

Sorry but which issue are you trying to fix here? Can you please elaborate
your use case?

As I wrote before, only Python 2 should be modified now (if you consider
that it's worth it, the speedup is small).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26382>
_______________________________________

From report at bugs.python.org  Thu Dec 29 04:56:03 2016
From: report at bugs.python.org (Bozo Kopic)
Date: Thu, 29 Dec 2016 09:56:03 +0000
Subject: [issue29099] sqlite3 timestamp converter cannot handle timezone
In-Reply-To: <1482966269.67.0.620298847284.issue29099@psf.upfronthosting.co.za>
Message-ID: <1483005363.68.0.421014648079.issue29099@psf.upfronthosting.co.za>


Bozo Kopic added the comment:

Yes, that is correct. Timezone information is discarded. Submitted patch only resolves occurrence of ValueError.

Is additional patch that enables parsing of timezone required?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29099>
_______________________________________

From report at bugs.python.org  Thu Dec 29 05:06:56 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 29 Dec 2016 10:06:56 +0000
Subject: [issue29099] sqlite3 timestamp converter cannot handle timezone
In-Reply-To: <1482966269.67.0.620298847284.issue29099@psf.upfronthosting.co.za>
Message-ID: <1483006016.08.0.274744804219.issue29099@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

I would prefer add the support for timezone since the current behaviour seems not correct to me. If you'd like to work on it, don't forget to add a test case and sign the CLA.

But I am not sure this should be treated as a bug or new feature.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29099>
_______________________________________

From report at bugs.python.org  Thu Dec 29 05:10:39 2016
From: report at bugs.python.org (INADA Naoki)
Date: Thu, 29 Dec 2016 10:10:39 +0000
Subject: [issue26382] List object memory allocator
In-Reply-To: <1455805611.43.0.0364707113583.issue26382@psf.upfronthosting.co.za>
Message-ID: <1483006239.59.0.9184752446.issue26382@psf.upfronthosting.co.za>


INADA Naoki added the comment:

OK. I didn't know PyMem and PyObject allocators are always same.
No reason to change Python 3.
How about Python 2?

Off topic: I want to know which of PyMem and PyObject allocator is preferred
when writing new code.

----------
versions:  -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26382>
_______________________________________

From report at bugs.python.org  Thu Dec 29 05:21:03 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 Dec 2016 10:21:03 +0000
Subject: [issue29099] sqlite3 timestamp converter cannot handle timezone
In-Reply-To: <1482966269.67.0.620298847284.issue29099@psf.upfronthosting.co.za>
Message-ID: <1483006863.26.0.77724172318.issue29099@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could you provide a unittest?

----------
nosy: +belopolsky, ghaering, lemburg
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29099>
_______________________________________

From report at bugs.python.org  Thu Dec 29 05:38:14 2016
From: report at bugs.python.org (Gaurav Tatke)
Date: Thu, 29 Dec 2016 10:38:14 +0000
Subject: [issue28612] str.translate needs a mapping example
In-Reply-To: <1478278954.92.0.793705359912.issue28612@psf.upfronthosting.co.za>
Message-ID: <1483007894.97.0.287353520561.issue28612@psf.upfronthosting.co.za>


Gaurav Tatke added the comment:

Hi,

I am new to Python and want to contribute. I am attaching a patch having required example of using defaultdict with translate. Please let me know if anything needs to be changed. I have tested the example and also the html doc in my local.

Regards,
Gaurav

----------
keywords: +patch
nosy: +Gaurav Tatke
Added file: http://bugs.python.org/file46072/translateexample_issue28612.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28612>
_______________________________________

From report at bugs.python.org  Thu Dec 29 05:38:36 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 29 Dec 2016 10:38:36 +0000
Subject: [issue29099] sqlite3 timestamp converter cannot handle timezone
In-Reply-To: <1482966269.67.0.620298847284.issue29099@psf.upfronthosting.co.za>
Message-ID: <1483007916.71.0.439305981704.issue29099@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

import sqlite3, datetime
c = sqlite3.connect(':memory:', detect_types=sqlite3.PARSE_DECLTYPES|sqlite3.PARSE_COLNAMES)
cur = c.cursor()
cur.execute('create table test(t timestamp)')
t = datetime.datetime.now(tz=datetime.timezone.utc)
cur.execute("insert into test(t) values (?)", (t,))
cur.execute('select t from test')
l = cur.fetchone()[0]
t == l   # the result not equal to the original one

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29099>
_______________________________________

From report at bugs.python.org  Thu Dec 29 05:44:56 2016
From: report at bugs.python.org (Jiajun Huang)
Date: Thu, 29 Dec 2016 10:44:56 +0000
Subject: [issue28961] unittest.mock._Call ignores `name` parameter
In-Reply-To: <1481636868.17.0.0411235027553.issue28961@psf.upfronthosting.co.za>
Message-ID: <1483008296.79.0.336058376633.issue28961@psf.upfronthosting.co.za>


Jiajun Huang added the comment:

hi, do this need more test case or something else to be merged? please let me know :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28961>
_______________________________________

From report at bugs.python.org  Thu Dec 29 06:33:15 2016
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Thu, 29 Dec 2016 11:33:15 +0000
Subject: [issue29095] Compiling Python 3.6 from source on MacOS X Sierra
In-Reply-To: <1482955362.45.0.530145158959.issue29095@psf.upfronthosting.co.za>
Message-ID: <1483011195.03.0.0325730795704.issue29095@psf.upfronthosting.co.za>


Walter D?rwald added the comment:

No, neither CFLAGS nor LDFLAGS are set, the only "FLAGS" environment variable I have set is ARCHFLAGS='-arch x86_64' (I can't remember why). However unsetting this variable doesn't change the result.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29095>
_______________________________________

From report at bugs.python.org  Thu Dec 29 06:39:13 2016
From: report at bugs.python.org (Jan Gosmann)
Date: Thu, 29 Dec 2016 11:39:13 +0000
Subject: =?utf-8?q?=5Bissue24875=5D_pyvenv_doesn=C2=B4t_install_PIP_inside_a_new_v?=
 =?utf-8?q?env_with_--system-site-package?=
In-Reply-To: <1439699040.07.0.199956094974.issue24875@psf.upfronthosting.co.za>
Message-ID: <1483011553.14.0.159495927247.issue24875@psf.upfronthosting.co.za>


Changes by Jan Gosmann <jan+pythontracker at hyper-world.de>:


----------
nosy: +jgosmann

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24875>
_______________________________________

From report at bugs.python.org  Thu Dec 29 06:42:06 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Thu, 29 Dec 2016 11:42:06 +0000
Subject: [issue29095] Compiling Python 3.6 from source on MacOS X Sierra
In-Reply-To: <1482955362.45.0.530145158959.issue29095@psf.upfronthosting.co.za>
Message-ID: <1483011726.26.0.326346518503.issue29095@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

Ah, things are quite the opposite :)

You have to set CFLAGS and LDFLAGS so that setup.py can find openssl headers and libraries from Homebrew. For example:

export CFLAGS="-I/usr/local/opt/openssl/include"
export LDFLAGS="-L/usr/local/opt/openssl/lib"

The reason for that is that Apple once shipped their forked OpenSSL in older Mac OS X versions, so Homebrew can't install OpenSSL headers and libraries to public paths (/usr/local/include & /usr/local/lib). On the other hand, CPython should not use paths in /usr/local/opt/ as it's internal details of Homebrew.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29095>
_______________________________________

From report at bugs.python.org  Thu Dec 29 06:56:25 2016
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Thu, 29 Dec 2016 11:56:25 +0000
Subject: [issue29104] Left bracket remains in format string result when '\'
 preceeds it
Message-ID: <1483012585.51.0.342717701316.issue29104@psf.upfronthosting.co.za>


New submission from Jim Fasarakis-Hilliard:

In short:

    >>> f"\{10}"

yields:

    "\\{10"

This is reproducible only when `\` precedes the opening bracket, that is:

    >>> f"\ {10}"

results in: "\\ 10"

----------
components: Interpreter Core
messages: 284249
nosy: Jim Fasarakis-Hilliard
priority: normal
severity: normal
status: open
title: Left bracket remains in format string result when '\' preceeds it
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29104>
_______________________________________

From report at bugs.python.org  Thu Dec 29 07:05:18 2016
From: report at bugs.python.org (SilentGhost)
Date: Thu, 29 Dec 2016 12:05:18 +0000
Subject: [issue29104] Left bracket remains in format string result when '\'
 preceeds it
In-Reply-To: <1483012585.51.0.342717701316.issue29104@psf.upfronthosting.co.za>
Message-ID: <1483013118.53.0.938528478665.issue29104@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +eric.smith
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29104>
_______________________________________

From report at bugs.python.org  Thu Dec 29 07:08:25 2016
From: report at bugs.python.org (SilentGhost)
Date: Thu, 29 Dec 2016 12:08:25 +0000
Subject: [issue29097] datetime.fromtimestamp(t) when 0 <= t <= 86399 fails on
 Python 3.6
In-Reply-To: <1482958160.11.0.32337159902.issue29097@psf.upfronthosting.co.za>
Message-ID: <1483013305.88.0.365040602495.issue29097@psf.upfronthosting.co.za>


SilentGhost added the comment:

This doesn't seem likely that it's anything to do with datetime, could you try reproducing it in repl?

----------
nosy: +SilentGhost

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29097>
_______________________________________

From report at bugs.python.org  Thu Dec 29 07:20:47 2016
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Thu, 29 Dec 2016 12:20:47 +0000
Subject: [issue29095] Compiling Python 3.6 from source on MacOS X Sierra
In-Reply-To: <1482955362.45.0.530145158959.issue29095@psf.upfronthosting.co.za>
Message-ID: <1483014047.04.0.694660575156.issue29095@psf.upfronthosting.co.za>


Walter D?rwald added the comment:

OK, I've set CFLAGS and LDFLAGS as you suggested. However the ssl module still doesn't get built. Attached is the new build log (Python3.6-build2.log)

----------
Added file: http://bugs.python.org/file46073/Python3.6-build2.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29095>
_______________________________________

From report at bugs.python.org  Thu Dec 29 07:31:59 2016
From: report at bugs.python.org (Bozo Kopic)
Date: Thu, 29 Dec 2016 12:31:59 +0000
Subject: [issue29099] sqlite3 timestamp converter cannot handle timezone
In-Reply-To: <1482966269.67.0.620298847284.issue29099@psf.upfronthosting.co.za>
Message-ID: <1483014719.46.0.0808984654986.issue29099@psf.upfronthosting.co.za>


Bozo Kopic added the comment:

I'm providing new patch that adds support for parsing timezone information.

Tests are included.

----------
Added file: http://bugs.python.org/file46074/sqlite3-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29099>
_______________________________________

From report at bugs.python.org  Thu Dec 29 07:34:52 2016
From: report at bugs.python.org (Bozo Kopic)
Date: Thu, 29 Dec 2016 12:34:52 +0000
Subject: [issue29099] sqlite3 timestamp converter cannot handle timezone
In-Reply-To: <1482966269.67.0.620298847284.issue29099@psf.upfronthosting.co.za>
Message-ID: <1483014892.54.0.129391212672.issue29099@psf.upfronthosting.co.za>


Changes by Bozo Kopic <bozo.kopic at gmail.com>:


Removed file: http://bugs.python.org/file46074/sqlite3-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29099>
_______________________________________

From report at bugs.python.org  Thu Dec 29 07:36:00 2016
From: report at bugs.python.org (Bozo Kopic)
Date: Thu, 29 Dec 2016 12:36:00 +0000
Subject: [issue29099] sqlite3 timestamp converter cannot handle timezone
In-Reply-To: <1482966269.67.0.620298847284.issue29099@psf.upfronthosting.co.za>
Message-ID: <1483014960.37.0.512305194114.issue29099@psf.upfronthosting.co.za>


Changes by Bozo Kopic <bozo.kopic at gmail.com>:


Added file: http://bugs.python.org/file46075/sqlite3-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29099>
_______________________________________

From report at bugs.python.org  Thu Dec 29 07:41:02 2016
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Thu, 29 Dec 2016 12:41:02 +0000
Subject: [issue28978] a redundant right parentheses in the EBNF rules of
 parameter_list
In-Reply-To: <1481803174.61.0.122563860327.issue28978@psf.upfronthosting.co.za>
Message-ID: <1483015261.99.0.0166657720211.issue28978@psf.upfronthosting.co.za>


Jim Fasarakis-Hilliard added the comment:

Attached patche for Python 3.3 (change `defparameter` to use `+`).

----------
keywords: +patch
Added file: http://bugs.python.org/file46076/3.3_func_def.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28978>
_______________________________________

From report at bugs.python.org  Thu Dec 29 07:41:48 2016
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Thu, 29 Dec 2016 12:41:48 +0000
Subject: [issue28978] a redundant right parentheses in the EBNF rules of
 parameter_list
In-Reply-To: <1481803174.61.0.122563860327.issue28978@psf.upfronthosting.co.za>
Message-ID: <1483015308.98.0.297576202444.issue28978@psf.upfronthosting.co.za>


Jim Fasarakis-Hilliard added the comment:

Further patch for `3.4` and `3.5`:

Change `|` to `(` and fix `defparameter` to use `+`

----------
Added file: http://bugs.python.org/file46077/3.4_3.5_func_def.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28978>
_______________________________________

From report at bugs.python.org  Thu Dec 29 07:42:44 2016
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Thu, 29 Dec 2016 12:42:44 +0000
Subject: [issue28978] a redundant right parentheses in the EBNF rules of
 parameter_list
In-Reply-To: <1481803174.61.0.122563860327.issue28978@psf.upfronthosting.co.za>
Message-ID: <1483015364.06.0.397732184918.issue28978@psf.upfronthosting.co.za>


Jim Fasarakis-Hilliard added the comment:

Further patch for 3.6 and 3.7 to address `defparameter` change here too.

----------
Added file: http://bugs.python.org/file46078/3.6_3.7_func_def.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28978>
_______________________________________

From report at bugs.python.org  Thu Dec 29 07:45:48 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 29 Dec 2016 12:45:48 +0000
Subject: [issue29104] Left bracket remains in format string result when '\'
 preceeds it
In-Reply-To: <1483012585.51.0.342717701316.issue29104@psf.upfronthosting.co.za>
Message-ID: <1483015548.13.0.596902268376.issue29104@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

I'm not sure this counts as an error. The backslash means to treat the next character literally, which this does. And since \{ is not a valid escape sequence, it keeps both characters, exactly like:

>>> '\c'
'\\c'

Furthermore, since unknown escape sequences are deprecated, this usage is going to be an error in the future. You can see this now with -Werror:

$ python.exe  -Werror
Python 3.6.0b1+ (3.6:87de1f12c41c+, Sep 16 2016, 07:05:57) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> f'\{10}'
DeprecationWarning: invalid escape sequence '\{'
>>> '\c'
DeprecationWarning: invalid escape sequence '\c'
>>>

Since this works as I expect it to now, and since it will become an error in the future, I don't think any change is warranted.

----------
assignee:  -> eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29104>
_______________________________________

From report at bugs.python.org  Thu Dec 29 07:48:19 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 29 Dec 2016 12:48:19 +0000
Subject: [issue29104] Left bracket remains in format string result when '\'
 preceeds it
In-Reply-To: <1483012585.51.0.342717701316.issue29104@psf.upfronthosting.co.za>
Message-ID: <1483015699.36.0.0162494020061.issue29104@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

But I admit that dropping the trailing } seems odd. I think this particular usage should be an error: no bare } allowed, similar to:

>>> f'10}'
  File "<stdin>", line 1
SyntaxError: f-string: single '}' is not allowed

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29104>
_______________________________________

From report at bugs.python.org  Thu Dec 29 07:57:38 2016
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Thu, 29 Dec 2016 12:57:38 +0000
Subject: [issue29104] Left bracket remains in format string result when '\'
 preceeds it
In-Reply-To: <1483012585.51.0.342717701316.issue29104@psf.upfronthosting.co.za>
Message-ID: <1483016258.07.0.171888870402.issue29104@psf.upfronthosting.co.za>


Jim Fasarakis-Hilliard added the comment:

I see, the original "complaint" about this behavior on stack overflow was made due to the discrepancy between the f-string the the format "equivalent": '\{}'.format(10)'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29104>
_______________________________________

From report at bugs.python.org  Thu Dec 29 08:02:54 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 29 Dec 2016 13:02:54 +0000
Subject: [issue29104] Left bracket remains in format string result when '\'
 preceeds it
In-Reply-To: <1483012585.51.0.342717701316.issue29104@psf.upfronthosting.co.za>
Message-ID: <1483016574.01.0.315705424868.issue29104@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Do you have a link to the SO question?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29104>
_______________________________________

From report at bugs.python.org  Thu Dec 29 08:07:25 2016
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Thu, 29 Dec 2016 13:07:25 +0000
Subject: [issue29104] Left bracket remains in format string result when '\'
 preceeds it
In-Reply-To: <1483012585.51.0.342717701316.issue29104@psf.upfronthosting.co.za>
Message-ID: <1483016845.55.0.373668197455.issue29104@psf.upfronthosting.co.za>


Jim Fasarakis-Hilliard added the comment:

Yes, should've attached in my previous message. See http://stackoverflow.com/questions/41330097/why-does-the-symbol-remain-when-f-10-is-evaluated-in-python-3-6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29104>
_______________________________________

From report at bugs.python.org  Thu Dec 29 08:37:39 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 Dec 2016 13:37:39 +0000
Subject: [issue29104] Left bracket remains in format string result when '\'
 preceeds it
In-Reply-To: <1483012585.51.0.342717701316.issue29104@psf.upfronthosting.co.za>
Message-ID: <1483018659.17.0.606415332328.issue29104@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The problem is not that the trailing } is dropped, but that the starting { starts an f-string expression.

>>> f'\{2*5}'
'\\{10'

I expected either '\\10' as in '\{}'.format(2*5), or at least '\\{2*5}'.

There is other f-string parsing error:

>>> f'\\N{2*5}'
'\\N{2*5}'

I expected '\\N10'. '\\N' doesn't start a unicode name escape. This is a legitimate expression.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29104>
_______________________________________

From report at bugs.python.org  Thu Dec 29 08:40:33 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 29 Dec 2016 13:40:33 +0000
Subject: [issue29104] Left bracket remains in format string result when '\'
 preceeds it
In-Reply-To: <1483012585.51.0.342717701316.issue29104@psf.upfronthosting.co.za>
Message-ID: <1483018833.56.0.807359780655.issue29104@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Yes:

>>> f'\{2*5}'
'\\{10'

I agree '\\10' would make sense.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29104>
_______________________________________

From report at bugs.python.org  Thu Dec 29 08:47:09 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Thu, 29 Dec 2016 13:47:09 +0000
Subject: [issue29095] Compiling Python 3.6 from source on MacOS X Sierra
In-Reply-To: <1482955362.45.0.530145158959.issue29095@psf.upfronthosting.co.za>
Message-ID: <1483019229.29.0.726824317419.issue29095@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

Change this line:

export CFLAGS="-I/usr/local/Cellar/openssl/1.0.2j/include/openssl"

into:

export CFLAGS="-I/usr/local/Cellar/openssl/1.0.2j/include"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29095>
_______________________________________

From report at bugs.python.org  Thu Dec 29 09:15:05 2016
From: report at bugs.python.org (Ammar Askar)
Date: Thu, 29 Dec 2016 14:15:05 +0000
Subject: [issue29097] datetime.fromtimestamp(t) when 0 <= t <= 86399 fails on
 Python 3.6
In-Reply-To: <1482958160.11.0.32337159902.issue29097@psf.upfronthosting.co.za>
Message-ID: <1483020905.84.0.518337021652.issue29097@psf.upfronthosting.co.za>


Ammar Askar added the comment:

Can recreate successfully on windows, but not on linux:

> C:\Python36\python.exe -c "import datetime; datetime.datetime.fromtimestamp(42)"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
OSError: [Errno 22] Invalid argument

> C:\Python36\python.exe
Python 3.6.0 (v3.6.0:41df79263a11, Dec 23 2016, 08:06:12) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime; datetime.datetime.fromtimestamp(42)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 22] Invalid argument

----------
nosy: +ammar2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29097>
_______________________________________

From report at bugs.python.org  Thu Dec 29 09:34:03 2016
From: report at bugs.python.org (SilentGhost)
Date: Thu, 29 Dec 2016 14:34:03 +0000
Subject: [issue29097] datetime.fromtimestamp(t) when 0 <= t <= 86399 fails on
 Python 3.6
In-Reply-To: <1482958160.11.0.32337159902.issue29097@psf.upfronthosting.co.za>
Message-ID: <1483022043.95.0.481834291208.issue29097@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
components: +Windows
nosy: +belopolsky, paul.moore, steve.dower, tim.golden, zach.ware
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29097>
_______________________________________

From report at bugs.python.org  Thu Dec 29 09:35:22 2016
From: report at bugs.python.org (SilentGhost)
Date: Thu, 29 Dec 2016 14:35:22 +0000
Subject: [issue29097] datetime.fromtimestamp(t) when 0 <= t <= 86399 fails on
 Python 3.6
In-Reply-To: <1482958160.11.0.32337159902.issue29097@psf.upfronthosting.co.za>
Message-ID: <1483022122.92.0.876904303084.issue29097@psf.upfronthosting.co.za>


SilentGhost added the comment:

Cannot reproduce this with the tip on linux

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29097>
_______________________________________

From report at bugs.python.org  Thu Dec 29 09:42:55 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Thu, 29 Dec 2016 14:42:55 +0000
Subject: [issue29104] Left bracket remains in format string result when '\'
 preceeds it
In-Reply-To: <1483012585.51.0.342717701316.issue29104@psf.upfronthosting.co.za>
Message-ID: <1483022575.58.0.285159424121.issue29104@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

This problem was no doubt introduced after 3.6a1 when I changed the parsing to disallow backslashes inside {}.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29104>
_______________________________________

From report at bugs.python.org  Thu Dec 29 09:45:13 2016
From: report at bugs.python.org (R. David Murray)
Date: Thu, 29 Dec 2016 14:45:13 +0000
Subject: [issue29103] Make enum.py pep8 compliant
In-Reply-To: <1482997050.71.0.505456771635.issue29103@psf.upfronthosting.co.za>
Message-ID: <1483022713.55.0.458882029421.issue29103@psf.upfronthosting.co.za>


R. David Murray added the comment:

In general we do not accept PEP8 patches; it is code churn with insufficient benefit since many modules in the stdlib predate either PEP8 itself or the current version of PEP8.  However, enum is a new enough module that I suppose this might get accepted.  In any case, thank you for wanting to contribute!

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29103>
_______________________________________

From report at bugs.python.org  Thu Dec 29 09:49:22 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Thu, 29 Dec 2016 14:49:22 +0000
Subject: [issue28518] execute("begin immediate") throwing OperationalError
In-Reply-To: <1477307118.31.0.70785963389.issue28518@psf.upfronthosting.co.za>
Message-ID: <1483022962.05.0.311122549723.issue28518@psf.upfronthosting.co.za>


Aviv Palivoda added the comment:

Issue #29003 seems to be related to this one. I think that they can be solved the same way as done in Serhiy patch but I would like to suggest a different approach.
I suggest changing the check for DDL statement with a check for DML statement. We actually should start a transaction only for DML statements (https://docs.python.org/3/library/sqlite3.html#controlling-transactions) so all other statements (DDL, DCL and TCL) should not start a transaction.
The attached patch solve both this issue and issue #29003.

----------
Added file: http://bugs.python.org/file46079/sqlite-ddl-dml.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28518>
_______________________________________

From report at bugs.python.org  Thu Dec 29 09:52:39 2016
From: report at bugs.python.org (R. David Murray)
Date: Thu, 29 Dec 2016 14:52:39 +0000
Subject: [issue29097] datetime.fromtimestamp(t) when 0 <= t <= 86399 fails on
 Python 3.6
In-Reply-To: <1482958160.11.0.32337159902.issue29097@psf.upfronthosting.co.za>
Message-ID: <1483023159.33.0.425342448419.issue29097@psf.upfronthosting.co.za>


R. David Murray added the comment:

Sounds like it really is an OSError (that is, that the Windows OS is the source of the error).  Whether or not we can or should do something about that is a separate question, though.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29097>
_______________________________________

From report at bugs.python.org  Thu Dec 29 10:07:18 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 29 Dec 2016 15:07:18 +0000
Subject: [issue29003] sqlite3: can't run VACUUM on Python 3.6
In-Reply-To: <1482031172.61.0.238447305866.issue29003@psf.upfronthosting.co.za>
Message-ID: <1483024038.01.0.881413957534.issue29003@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for trying pre-release versions of Python 3.6, Ma Lin. This has already been reported in issue 28518 so I'm closing this as a duplicate.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> execute("begin immediate") throwing OperationalError

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29003>
_______________________________________

From report at bugs.python.org  Thu Dec 29 10:10:20 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 Dec 2016 15:10:20 +0000
Subject: [issue29104] Left bracket remains in format string result when '\'
 preceeds it
In-Reply-To: <1483012585.51.0.342717701316.issue29104@psf.upfronthosting.co.za>
Message-ID: <1483024220.33.0.959302678118.issue29104@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Proposed patch fixes parsing backslashes in f-strings.

P.S. Definitely we should find other name for this term. I hate misleading "f-string".

----------
keywords: +patch
Added file: http://bugs.python.org/file46080/fstring_backslash.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29104>
_______________________________________

From report at bugs.python.org  Thu Dec 29 10:28:04 2016
From: report at bugs.python.org (Ammar Askar)
Date: Thu, 29 Dec 2016 15:28:04 +0000
Subject: [issue29097] datetime.fromtimestamp(t) when 0 <= t <= 86399 fails on
 Python 3.6
In-Reply-To: <1482958160.11.0.32337159902.issue29097@psf.upfronthosting.co.za>
Message-ID: <1483025284.87.0.282211545943.issue29097@psf.upfronthosting.co.za>


Ammar Askar added the comment:

The 86,399 upperbound comes from this line (max_fold_seconds=86400):

https://github.com/python/cpython/blob/master/Modules/_datetimemodule.c#L4277-L4278

The bug is introduced as part of the fold detection in this commit: https://github.com/python/cpython/commit/56376cacd2a0f6af834fe4d2a20b1a1095afb26f

Window's locatime_s function gives an EINVAL error when time is less than 0. Which is where the OSError comes from.

https://msdn.microsoft.com/en-us/library/a442x3ye.aspx

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29097>
_______________________________________

From report at bugs.python.org  Thu Dec 29 10:37:18 2016
From: report at bugs.python.org (Steve Dower)
Date: Thu, 29 Dec 2016 15:37:18 +0000
Subject: [issue29102] Add an id field to PyInterpreterState.
In-Reply-To: <1482994422.5.0.64533163171.issue29102@psf.upfronthosting.co.za>
Message-ID: <1483025838.67.0.797436016771.issue29102@psf.upfronthosting.co.za>


Steve Dower added the comment:

Tracking purposes mainly, so someone outside the interpreter state can tell when it's no longer there. Making interpreter states weak-referencable would have a similar effect, and could very well use this id if we didn't need the callback.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29102>
_______________________________________

From report at bugs.python.org  Thu Dec 29 10:51:15 2016
From: report at bugs.python.org (Ned Deily)
Date: Thu, 29 Dec 2016 15:51:15 +0000
Subject: [issue29095] Compiling Python 3.6 from source on MacOS X Sierra
In-Reply-To: <1482955362.45.0.530145158959.issue29095@psf.upfronthosting.co.za>
Message-ID: <1483026675.75.0.737298331157.issue29095@psf.upfronthosting.co.za>


Ned Deily added the comment:

See the Developers Guide for more information on build dependencies and recommended ways to satisfy OpenSSL dependencies:

http://cpython-devguide.readthedocs.io/en/latest/setup.html#build-dependencies

----------
nosy: +ned.deily
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29095>
_______________________________________

From report at bugs.python.org  Thu Dec 29 11:03:29 2016
From: report at bugs.python.org (=?utf-8?b?0JDQvdC00YDQtdC5INCR0L7QtNGA0L7Qsg==?=)
Date: Thu, 29 Dec 2016 16:03:29 +0000
Subject: [issue5215] change value of local variable in debug
In-Reply-To: <1234338182.69.0.0258607971835.issue5215@psf.upfronthosting.co.za>
Message-ID: <1483027409.78.0.650617977055.issue5215@psf.upfronthosting.co.za>


?????? ?????? added the comment:

I still can reproduce this bug, is that intended behavior?
  1  	def func():
  2  	  import pdb; pdb.set_trace()
  3  	  x = 0
  4    	  y = 0
  5  	  z = 0
  6  	
  7  	if __name__ == "__main__":
  8  	  func()

> /test.py(3)func()
-> x = 0
(Pdb) n
> /test.py(4)func()
-> y = 0
(Pdb) x = 5
(Pdb) y = 3
(Pdb) j 5
> /test.py(5)func()
-> z = 0
(Pdb) x
0
(Pdb) y
*** NameError: name 'y' is not defined

----------
nosy: +?????? ??????
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5215>
_______________________________________

From report at bugs.python.org  Thu Dec 29 11:19:47 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 Dec 2016 16:19:47 +0000
Subject: [issue29102] Add an id field to PyInterpreterState.
In-Reply-To: <1482994422.5.0.64533163171.issue29102@psf.upfronthosting.co.za>
Message-ID: <1483028387.89.0.525988383117.issue29102@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

If add an API for getting an unique ID of the interpreter state, is it needed to add an API for getting the interpreter state by ID?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29102>
_______________________________________

From report at bugs.python.org  Thu Dec 29 11:29:54 2016
From: report at bugs.python.org (iMath)
Date: Thu, 29 Dec 2016 16:29:54 +0000
Subject: [issue29105] code or doc improvement for
 logging.handlers.RotatingFileHandler
Message-ID: <1483028994.58.0.687650973528.issue29105@psf.upfronthosting.co.za>


New submission from iMath:

For 
class logging.handlers.RotatingFileHandler(filename, mode='a', maxBytes=0, backupCount=0, encoding=None, delay=0) 

if backupCount is zero and maxBytes is non-zero, the log file size could exceed maxBytes, i.e. we are not able to restrict the log file size using RotatingFileHandler at this case .
I suggest add the above description to the doc 
https://docs.python.org/3.6/library/logging.handlers.html#logging.handlers.RotatingFileHandler
If possible , set backupCount=1 by default to avoid this pitfall as much as possible.

The doc right now just says "if either of maxBytes or backupCount is zero, rollover never occurs.", it is too difficult to understand the meaning of 'Rollover' to aviod the pitfall .

----------
assignee: docs at python
components: Documentation
messages: 284277
nosy: docs at python, redstone-cold
priority: normal
severity: normal
status: open
title: code or doc improvement for logging.handlers.RotatingFileHandler
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29105>
_______________________________________

From report at bugs.python.org  Thu Dec 29 11:51:52 2016
From: report at bugs.python.org (Eric Snow)
Date: Thu, 29 Dec 2016 16:51:52 +0000
Subject: [issue29102] Add an id field to PyInterpreterState.
In-Reply-To: <1482994422.5.0.64533163171.issue29102@psf.upfronthosting.co.za>
Message-ID: <1483030312.37.0.836957428631.issue29102@psf.upfronthosting.co.za>


Eric Snow added the comment:

Three reasons come to mind:

1. threads are identified by small integers
2. long, random-looking IDs are not human-friendly, and subinterpreter IDs will be used like thread IDs are
3. related to what Steve said, temporally unique IDs allow us to be confident about whether or not an interpreter has been destroyed (and how many interpreters there have been)

Since PyInterpreterState is not a PyObject, using weakrefs to address the third point won't work, right?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29102>
_______________________________________

From report at bugs.python.org  Thu Dec 29 11:52:42 2016
From: report at bugs.python.org (Szabolcs Dombi)
Date: Thu, 29 Dec 2016 16:52:42 +0000
Subject: [issue29106] get-pip.py fails with Python 3.6 embed Windows
Message-ID: <1483030362.55.0.53701112975.issue29106@psf.upfronthosting.co.za>


New submission from Szabolcs Dombi:

Downloaded python 3.6 embedable zip file (windows 32 bit)

Downloaded get-pip.py from the following URL:
https://pip.pypa.io/en/stable/installing/

This is the traceback:

Traceback (most recent call last):
  File "get-pip.py", line 20061, in <module>
    main()
  File "get-pip.py", line 194, in main
    bootstrap(tmpdir=tmpdir)
  File "get-pip.py", line 82, in bootstrap
    import pip
  File "<frozen importlib._bootstrap>", line 961, in _find_and_load
  File "<frozen importlib._bootstrap>", line 950, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 646, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 616, in _load_backward_compatible
  File "C:\Users\User\AppData\Local\Temp\tmpinoq60hn\pip.zip\pip\__init__.py", line 26, in <module>
  File "<frozen importlib._bootstrap>", line 961, in _find_and_load
  File "<frozen importlib._bootstrap>", line 950, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 646, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 616, in _load_backward_compatible
  File "C:\Users\User\AppData\Local\Temp\tmpinoq60hn\pip.zip\pip\utils\__init__.py", line 23, in <module>
  File "<frozen importlib._bootstrap>", line 961, in _find_and_load
  File "<frozen importlib._bootstrap>", line 950, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 646, in _load_unlocked
  File "<frozen importlib._bootstrap>", line 616, in _load_backward_compatible
  File "C:\Users\User\AppData\Local\Temp\tmpinoq60hn\pip.zip\pip\locations.py", line 88, in <module>
  File "ntpath.py", line 75, in join
TypeError: expected str, bytes or os.PathLike object, not NoneType

----------
messages: 284279
nosy: Szabolcs Dombi
priority: normal
severity: normal
status: open
title: get-pip.py fails with Python 3.6 embed Windows
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29106>
_______________________________________

From report at bugs.python.org  Thu Dec 29 11:57:50 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 Dec 2016 16:57:50 +0000
Subject: [issue29102] Add an id field to PyInterpreterState.
In-Reply-To: <1482994422.5.0.64533163171.issue29102@psf.upfronthosting.co.za>
Message-ID: <1483030670.4.0.209857906524.issue29102@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There is an issue with integer identifiers of threads. See issue25658 and https://mail.python.org/pipermail/python-ideas/2016-December/043983.html.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29102>
_______________________________________

From report at bugs.python.org  Thu Dec 29 12:00:53 2016
From: report at bugs.python.org (Ammar Askar)
Date: Thu, 29 Dec 2016 17:00:53 +0000
Subject: [issue29097] datetime.fromtimestamp(t) when 0 <= t <= 86399 fails on
 Python 3.6
In-Reply-To: <1482958160.11.0.32337159902.issue29097@psf.upfronthosting.co.za>
Message-ID: <1483030853.52.0.650594411695.issue29097@psf.upfronthosting.co.za>


Ammar Askar added the comment:

I just ran the following script to check if there are any folds from timestamps [0, 86399] in any timezone.

  import datetime
  import pytz

  for tz in pytz.all_timezones:
      tz = pytz.timezone(tz)
      for i in range(86400):
          if datetime.datetime.fromtimestamp(i, tz).fold == 1:
              print(str(tz)) 

and it turns out there aren't any. I highly doubt any timezone is going to retroactively enable/disable DST during the epoch, so a potentially hacky fix is to just have a windows specific check for this value range.

I'm adding the people involved in PEP 495 to the nosy list so they can give their input.

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29097>
_______________________________________

From report at bugs.python.org  Thu Dec 29 12:06:25 2016
From: report at bugs.python.org (Ammar Askar)
Date: Thu, 29 Dec 2016 17:06:25 +0000
Subject: [issue29106] get-pip.py fails with Python 3.6 embed Windows
In-Reply-To: <1483030362.55.0.53701112975.issue29106@psf.upfronthosting.co.za>
Message-ID: <1483031185.86.0.574174924737.issue29106@psf.upfronthosting.co.za>


Ammar Askar added the comment:

Please post this issue on pypa's get-pip issue tracker https://github.com/pypa/get-pip

----------
nosy: +ammar2
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29106>
_______________________________________

From report at bugs.python.org  Thu Dec 29 12:47:54 2016
From: report at bugs.python.org (Steve Dower)
Date: Thu, 29 Dec 2016 17:47:54 +0000
Subject: [issue29102] Add an id field to PyInterpreterState.
In-Reply-To: <1482994422.5.0.64533163171.issue29102@psf.upfronthosting.co.za>
Message-ID: <1483033674.56.0.658040381148.issue29102@psf.upfronthosting.co.za>


Steve Dower added the comment:

That's an issue with TLS initialisation, not thread IDs. It's easily solved by defining an "uninitialized" value (e.g. 0) and an "invalid" value (e.g. -1).

Interpreter states are in a linked list, so you can traverse the list to find one by ID.

WRT weakrefs, we can't use them directly, but I suspect the higher-level API will need it. Possibly adding a callback on finalisation would fill both needs, but I like having a reliable ID - otherwise we'll probably end up with multiple different IDs managed indirectly via callbacks. (Perhaps a single callback for when any interpreter is finalized that passes the ID through? That should work well, since the ID is designed to outlive the interpreter itself, so it can be an asynchronous notification.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29102>
_______________________________________

From report at bugs.python.org  Thu Dec 29 12:48:41 2016
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Thu, 29 Dec 2016 17:48:41 +0000
Subject: [issue29095] Compiling Python 3.6 from source on MacOS X Sierra
In-Reply-To: <1482955362.45.0.530145158959.issue29095@psf.upfronthosting.co.za>
Message-ID: <1483033721.85.0.590574405864.issue29095@psf.upfronthosting.co.za>


Walter D?rwald added the comment:

OK, with the fixed CFLAGS definition I do indeed get a working ssl module.

I wonder whether the link Ned posted should be put into the README file.

Anyway I think the issue can be closed. Thanks for the help!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29095>
_______________________________________

From report at bugs.python.org  Thu Dec 29 12:49:05 2016
From: report at bugs.python.org (Bozo Kopic)
Date: Thu, 29 Dec 2016 17:49:05 +0000
Subject: [issue29099] sqlite3 timestamp converter cannot handle timezone
In-Reply-To: <1482966269.67.0.620298847284.issue29099@psf.upfronthosting.co.za>
Message-ID: <1483033745.86.0.218968895712.issue29099@psf.upfronthosting.co.za>


Changes by Bozo Kopic <bozo.kopic at gmail.com>:


Removed file: http://bugs.python.org/file46075/sqlite3-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29099>
_______________________________________

From report at bugs.python.org  Thu Dec 29 12:49:15 2016
From: report at bugs.python.org (Bozo Kopic)
Date: Thu, 29 Dec 2016 17:49:15 +0000
Subject: [issue29099] sqlite3 timestamp converter cannot handle timezone
In-Reply-To: <1482966269.67.0.620298847284.issue29099@psf.upfronthosting.co.za>
Message-ID: <1483033755.11.0.587438932563.issue29099@psf.upfronthosting.co.za>


Changes by Bozo Kopic <bozo.kopic at gmail.com>:


Added file: http://bugs.python.org/file46081/sqlite3-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29099>
_______________________________________

From report at bugs.python.org  Thu Dec 29 12:53:36 2016
From: report at bugs.python.org (Steve Dower)
Date: Thu, 29 Dec 2016 17:53:36 +0000
Subject: [issue29033] Windows Python installer rolls back when run under
 SYSTEM account (SCCM)
In-Reply-To: <1482311785.5.0.564825395885.issue29033@psf.upfronthosting.co.za>
Message-ID: <1483034016.13.0.541644861358.issue29033@psf.upfronthosting.co.za>


Steve Dower added the comment:

Does SCCM support dependency provider keys? If so, Python 3.6.0 and 3.5.3 and later will set one of these (see issue28846), which should make it easier to detect the whole bundle. Previous versions of 3.5 used a random GUID here.

I managed to reproduce the issue on a test machine by running a per-user install as admin, then the per-machine install. I tried a few ideas to treat the per-user and per-machine installs more distinctly, but nothing seems to work well. Most likely, I'll just have to add a more serious block when there's an existing install and prevent the second bad installation, though I haven't yet figured out how to do that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29033>
_______________________________________

From report at bugs.python.org  Thu Dec 29 13:11:00 2016
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 29 Dec 2016 18:11:00 +0000
Subject: [issue29097] datetime.fromtimestamp(t) when 0 <= t <= 86399 fails on
 Python 3.6
In-Reply-To: <1482958160.11.0.32337159902.issue29097@psf.upfronthosting.co.za>
Message-ID: <1483035060.73.0.53674377097.issue29097@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

I think we should just clip the negative lower probe value to 0 on Windows before passing it to local().  Also, if we still care about platforms with 32-bit time_t, we should check for over/under flow *before* calling local().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29097>
_______________________________________

From report at bugs.python.org  Thu Dec 29 13:21:21 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 Dec 2016 18:21:21 +0000
Subject: [issue29099] sqlite3 timestamp converter cannot handle timezone
In-Reply-To: <1482966269.67.0.620298847284.issue29099@psf.upfronthosting.co.za>
Message-ID: <1483035681.35.0.0271943002365.issue29099@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
stage: test needed -> patch review
Added file: http://bugs.python.org/file46082/sqlite3-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29099>
_______________________________________

From report at bugs.python.org  Thu Dec 29 13:23:48 2016
From: report at bugs.python.org (Naftali Harris)
Date: Thu, 29 Dec 2016 18:23:48 +0000
Subject: [issue29107] traceback module incorrectly formats args-less syntax
 errors
Message-ID: <1483035828.75.0.241561980745.issue29107@psf.upfronthosting.co.za>


New submission from Naftali Harris:

The traceback documentation states that it "exactly mimics the behavior of the Python interpreter when it prints a stack trace." Here's a small case where it doesn't, on 2.7.13:

~/repos/Python-2.7.13$ cat example.py
def f(x):
    global x
~/repos/Python-2.7.13$ ./python.exe
Python 2.7.13 (default, Dec 29 2016, 09:54:42)
[GCC 4.2.1 Compatible Apple LLVM 7.3.0 (clang-703.0.31)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import traceback
>>> import example
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "example.py", line 1
    def f(x):
SyntaxError: name 'x' is local and global
>>> try:
... 	import example
... except:
... 	traceback.print_exc()
...
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
SyntaxError: name 'x' is local and global (example.py, line 1)
>>>

I believe Kurt fixed this for Python 3000 with https://mail.python.org/pipermail/python-3000-checkins/2007-July/001259.html

----------
components: Library (Lib)
messages: 284287
nosy: Naftali.Harris, benjamin.peterson, kbk
priority: normal
severity: normal
status: open
title: traceback module incorrectly formats args-less syntax errors
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29107>
_______________________________________

From report at bugs.python.org  Thu Dec 29 13:40:36 2016
From: report at bugs.python.org (Skye)
Date: Thu, 29 Dec 2016 18:40:36 +0000
Subject: [issue26631] Unable to install Python 3.5.1 on Windows 10 - Error
 0x80070643: Failed to install MSI package.
In-Reply-To: <1458771798.71.0.333968276616.issue26631@psf.upfronthosting.co.za>
Message-ID: <1483036836.87.0.746057671323.issue26631@psf.upfronthosting.co.za>


Skye added the comment:

The problem is gone. Thank you, for all your work!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26631>
_______________________________________

From report at bugs.python.org  Thu Dec 29 13:45:06 2016
From: report at bugs.python.org (Ammar Askar)
Date: Thu, 29 Dec 2016 18:45:06 +0000
Subject: [issue29028] Use-After-Free in PyString_FromStringAndSize() of
 stringobject.c
In-Reply-To: <1482247531.75.0.221402980867.issue29028@psf.upfronthosting.co.za>
Message-ID: <1483037106.4.0.188082411324.issue29028@psf.upfronthosting.co.za>


Ammar Askar added the comment:

Updated patch based on Rietveld review

----------
Added file: http://bugs.python.org/file46083/buffer-use-after-free-fix.patch2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29028>
_______________________________________

From report at bugs.python.org  Thu Dec 29 14:01:37 2016
From: report at bugs.python.org (Eric Snow)
Date: Thu, 29 Dec 2016 19:01:37 +0000
Subject: [issue29102] Add an id field to PyInterpreterState.
In-Reply-To: <CALFfu7DJu2jOpdkVZkUwv1reELXqsFaiFu5wBARrjnrUpWrnoA@mail.gmail.com>
Message-ID: <CALFfu7BrWH+XSq31HPoVTVASEuDFmLsMQLSdeUDuzqrPHvhOxA@mail.gmail.com>


Eric Snow added the comment:

Interpreter states are in a linked list, so you

can traverse the list to find one by ID.

Exactly.  At first I had added a PyInterpreterState_FindByID() or something
like that.  However, as you noted, I realized it wasn't necessary. :)

WRT weakrefs, we can't use them directly, but I suspect the higher-level
API will need it...

Everything you said about weakrefs sounds good.  We can discuss more when
we get to that high-level API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29102>
_______________________________________

From report at bugs.python.org  Thu Dec 29 14:04:43 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 Dec 2016 19:04:43 +0000
Subject: [issue29099] sqlite3 timestamp converter cannot handle timezone
In-Reply-To: <1482966269.67.0.620298847284.issue29099@psf.upfronthosting.co.za>
Message-ID: <1483038283.28.0.499481899774.issue29099@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

In general the patch LGTM. Added comments on Rietveld.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29099>
_______________________________________

From report at bugs.python.org  Thu Dec 29 14:52:36 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 Dec 2016 19:52:36 +0000
Subject: [issue29028] Use-After-Free in PyString_FromStringAndSize() of
 stringobject.c
In-Reply-To: <1482247531.75.0.221402980867.issue29028@psf.upfronthosting.co.za>
Message-ID: <1483041156.12.0.791223589905.issue29028@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29028>
_______________________________________

From report at bugs.python.org  Thu Dec 29 15:07:21 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 Dec 2016 20:07:21 +0000
Subject: [issue29028] Use-After-Free in PyString_FromStringAndSize() of
 stringobject.c
In-Reply-To: <1482247531.75.0.221402980867.issue29028@psf.upfronthosting.co.za>
Message-ID: <1483042041.58.0.148221475124.issue29028@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There a problem with PySlice_GetIndicesEx() (see issue27867). Buffer length shouldn't be evaluated before PySlice_GetIndicesEx() since it can call user code that can change buffer length. This issue can't be solved without first solving issue27867.

get_buf() is called twice. First for getting the size, and later in buffer_item() or after PySlice_GetIndicesEx() for getting a pointer. I think it can be called once.

Ammar, please write a unittest for this issue. It should also cover bugs in the first two versions of the patch.

----------
dependencies: +various issues due to misuse of PySlice_GetIndicesEx

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29028>
_______________________________________

From report at bugs.python.org  Thu Dec 29 15:08:03 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 Dec 2016 20:08:03 +0000
Subject: [issue29028] Use-After-Free in PyString_FromStringAndSize() of
 stringobject.c
In-Reply-To: <1482247531.75.0.221402980867.issue29028@psf.upfronthosting.co.za>
Message-ID: <1483042083.98.0.660659365981.issue29028@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29028>
_______________________________________

From report at bugs.python.org  Thu Dec 29 15:08:28 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 Dec 2016 20:08:28 +0000
Subject: [issue27867] various issues due to misuse of PySlice_GetIndicesEx
In-Reply-To: <1472226685.15.0.242668202848.issue27867@psf.upfronthosting.co.za>
Message-ID: <1483042108.85.0.580184998634.issue27867@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
assignee:  -> serhiy.storchaka
versions: +Python 2.7, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27867>
_______________________________________

From report at bugs.python.org  Thu Dec 29 15:49:40 2016
From: report at bugs.python.org (bpoaugust)
Date: Thu, 29 Dec 2016 20:49:40 +0000
Subject: [issue29053] Implement >From_ decoding on input from mbox
In-Reply-To: <1482502608.45.0.127449678115.issue29053@psf.upfronthosting.co.za>
Message-ID: <1483044580.57.0.735175242875.issue29053@psf.upfronthosting.co.za>


Changes by bpoaugust <sebbaz+bpo at gmail.com>:


----------
versions: +Python 3.5 -Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29053>
_______________________________________

From report at bugs.python.org  Thu Dec 29 15:59:47 2016
From: report at bugs.python.org (bpoaugust)
Date: Thu, 29 Dec 2016 20:59:47 +0000
Subject: [issue29020] collapse_rfc2231_value has inconsistent unquoting
In-Reply-To: <1482193812.46.0.729778317823.issue29020@psf.upfronthosting.co.za>
Message-ID: <1483045187.04.0.777957334246.issue29020@psf.upfronthosting.co.za>


bpoaugust added the comment:

I have just checked and AFAICT collapse_rfc2231_value is only called by get_filename and get_boundary in message.py.

Both of these call get_param and default to unquote=True.

So in all cases the parameter value passed to collapse_rfc2231_value will already have been unquoted. Calling unquote again is a bug.

The obvious fix is to remove the calls to unquote from collapse_rfc2231_value.

This will also fix issue28945.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29020>
_______________________________________

From report at bugs.python.org  Thu Dec 29 16:00:53 2016
From: report at bugs.python.org (bpoaugust)
Date: Thu, 29 Dec 2016 21:00:53 +0000
Subject: [issue28945] get_boundary (and get_filename) invokes unquote twice
In-Reply-To: <1481547297.88.0.91240101349.issue28945@psf.upfronthosting.co.za>
Message-ID: <1483045253.48.0.381457658749.issue28945@psf.upfronthosting.co.za>


bpoaugust added the comment:

This is actually a bug in collapse_rfc2231_value: issue29020

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28945>
_______________________________________

From report at bugs.python.org  Thu Dec 29 16:57:31 2016
From: report at bugs.python.org (Jose Miguel Colella)
Date: Thu, 29 Dec 2016 21:57:31 +0000
Subject: [issue29108] Python 3.6.0 multiprocessing map_async callback
Message-ID: <1483048651.39.0.165070292977.issue29108@psf.upfronthosting.co.za>


New submission from Jose Miguel Colella:

Hello I am trying to use the callback for the map_async method for Pool, but have found a bug. In the below code, only the print statement is carried out, the return is completely ignored. Is this working as designed or is this a bug?

from multiprocessing import Pool


def f(x):
    return x * x


def s(x):
    print(f'Here: {x}')
    return type(x)


if __name__ == '__main__':
    with Pool(5) as p:
        result = p.map_async(f, [1, 2, 3], callback=s)
        q = result.get()
        print(q)

----------
components: Library (Lib)
files: main2.py
messages: 284295
nosy: Jose Miguel Colella
priority: normal
severity: normal
status: open
title: Python 3.6.0 multiprocessing map_async callback
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file46084/main2.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29108>
_______________________________________

From report at bugs.python.org  Thu Dec 29 16:59:26 2016
From: report at bugs.python.org (Jose Miguel Colella)
Date: Thu, 29 Dec 2016 21:59:26 +0000
Subject: [issue29108] Python 3.6.0 multiprocessing map_async callback
In-Reply-To: <1483048651.39.0.165070292977.issue29108@psf.upfronthosting.co.za>
Message-ID: <1483048766.75.0.832538025322.issue29108@psf.upfronthosting.co.za>


Jose Miguel Colella added the comment:

The result is:
Here: [1, 4, 9]
[1, 4, 9]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29108>
_______________________________________

From report at bugs.python.org  Thu Dec 29 17:03:02 2016
From: report at bugs.python.org (Ned Deily)
Date: Thu, 29 Dec 2016 22:03:02 +0000
Subject: [issue29108] Python 3.6.0 multiprocessing map_async callback
In-Reply-To: <1483048651.39.0.165070292977.issue29108@psf.upfronthosting.co.za>
Message-ID: <1483048982.78.0.506123945891.issue29108@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
nosy: +davin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29108>
_______________________________________

From report at bugs.python.org  Thu Dec 29 17:37:55 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 29 Dec 2016 22:37:55 +0000
Subject: [issue27867] various issues due to misuse of PySlice_GetIndicesEx
In-Reply-To: <1472226685.15.0.242668202848.issue27867@psf.upfronthosting.co.za>
Message-ID: <1483051075.54.0.597146205466.issue27867@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Renamed _PySlice_EvalIndices() to _PySlice_AdjustIndices() and changed its signature. Updated the documentation and python3.def. Fixed yet one bug: implementation-defined behavior with division by negative step.

Note that since new functions are used in public macro, they become a part of the stable API. Shouldn't starting underscores be removed from names?

An attempt of discussing names and signatures on Python-Dev: https://mail.python.org/pipermail/python-dev/2016-December/147048.html.

----------
Added file: http://bugs.python.org/file46085/slice_get_indices_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27867>
_______________________________________

From report at bugs.python.org  Thu Dec 29 18:39:06 2016
From: report at bugs.python.org (Loic Pefferkorn)
Date: Thu, 29 Dec 2016 23:39:06 +0000
Subject: [issue29109] Small doc improvements for tracemalloc
Message-ID: <1483054746.95.0.549035293258.issue29109@psf.upfronthosting.co.za>


New submission from Loic Pefferkorn:

Hello,

I believe that some improvements can be made to the Python 3.4 documentation of the tracemalloc module:

* Wrong parameter name, 'group_by' instead of 'key_type' (checked in tracemalloc.py)
* Don't round up numbers when explaining the examples. If they exactly match what can be read in the script output, it is to easier to understand (4.8 MiB vs 4855 KiB)
* Fix incorrect method link that was pointing to another module

I will wait for some feedback before checking the 3.5, 3.6 versions, hopefully I did not forget something :)

Cheers,
Loic

----------
assignee: docs at python
components: Documentation
files: doc_3.4_tracemalloc.diff
keywords: patch
messages: 284298
nosy: docs at python, haypo, loicp
priority: normal
severity: normal
status: open
title: Small doc improvements for tracemalloc
type: enhancement
versions: Python 3.4
Added file: http://bugs.python.org/file46086/doc_3.4_tracemalloc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29109>
_______________________________________

From report at bugs.python.org  Thu Dec 29 19:55:17 2016
From: report at bugs.python.org (Anthony Zhang)
Date: Fri, 30 Dec 2016 00:55:17 +0000
Subject: [issue29110] [patch] Fix file object leak in `aifc.open` when given
 invalid AIFF file.
Message-ID: <1483059317.41.0.849254662988.issue29110@psf.upfronthosting.co.za>


New submission from Anthony Zhang:

Summary
-------

This shows up as two closely-related issues:

* ``aifc.open`` leaks file object when invalid AIFF file encountered. This is probably a bug.
* ``aifc.close`` closes file object even when it didn't open the file object to begin with. While this is technically documented behaviour [1], it's inconsistent with how similar modules like ``wave`` work [2].

I have confirmed the issue is present in all the selected Python versions.

Steps to reproduce
------------------

For the first issue, run this code:

    #!/usr/bin/env python3

    # to simplify this example, use this script itself as a random non-AIFF file (though any non-AIFF file will work fine)
    FILE = __file__

    # print warnings on stderr
    import warnings
    warnings.resetwarnings()

    # try to open the non-AIFF file as an AIFF file, which should fail, but shouldn't give any ResourceWarnings
    import aifc
    try: aifc.open(FILE, "rb")
    except: pass

For the second issue, run this code:

    #!/usr/bin/env python3

    from os import path
    FILE = path.expanduser("~/cpython/Lib/test/audiodata/pluck-pcm8.aiff")

    # open the file as a file-like object, then open it again with ``aifc.open``
    import aifc
    with open(FILE, "rb") as f:
        assert not f.closed, "Before opening with AIFC"
        with aifc.open(f, "rb"):
            pass
        assert not f.closed, "After opening with AIFC"

Expected result
---------------

For the first code sample, code should give no output - ``aifc.open`` should throw an exception due to the passed filename being an invalid AIFF file, but that exception should be caught and suppressed. by the ``try``/``except`` statements.

For the second code sample, all assertions should pass - the file should be opened with ``open``, "opened" again with ``aifc.open``, and should not be closed when the inner context manager exits.

Actual result
-------------

For the first code sample:

    $ python3 test.py
    /home/anthony/Desktop/test.py:13: ResourceWarning: unclosed file <_io.BufferedReader name='/home/anthony/Desktop/test.py'>
      except: pass

In other words, code executes as described in "Expected result", but also prints a warning to stderr about the file object not being closed.

For the second code sample:

    $ python3 "/home/anthony/Desktop/test.py"
    Traceback (most recent call last):
      File "/home/anthony/Desktop/test.py", line 11, in <module>
        assert not f.closed, "After opening with AIFC"
    AssertionError: After opening with AIFC

In other words, code runs normally until the inner context manager exits, and the file object gets closed, even though the file object wasn't opened by ``aifc``.

Solution
--------

Attached are patches that fix each issue separately - the first patch fixes the first mentioned issue, while the second patch fixes both at once.

Backwards compatibility:

* The first patch, "fix_aifc_leak.patch", makes no functionality changes, so there shouldn't be any backwards compatibility concerns.
* The second patch, "fix_aifc_leak_and_file_object_close.patch", slightly changes the behaviour of `aifc_instance.close()` so that it closes in only a subset of cases it would originally. While it is possible for this to lead to leaks in certain cases (example below), the impact shoul be low, as existing codebases seem to use context managers and similar constructs that clean everything up properly.

    #!/usr/bin/env python3

    from os import path
    FILE = path.expanduser("~/cpython/Lib/test/audiodata/pluck-pcm8.aiff")
    import aifc
    f = open(FILE, "rb")
    with aifc.open(f, "rb"):
        pass
    # with the patch applied, `f` is not closed at this point anymore

[1]: https://docs.python.org/3/library/aifc.html#aifc.aifc.close
[2]: https://docs.python.org/3/library/wave.html#wave.Wave_read.close

----------
components: Library (Lib)
files: fix_aifc_leak.patch
keywords: patch
messages: 284299
nosy: azhang
priority: normal
severity: normal
status: open
title: [patch] Fix file object leak in `aifc.open` when given invalid AIFF file.
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file46087/fix_aifc_leak.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29110>
_______________________________________

From report at bugs.python.org  Thu Dec 29 19:56:05 2016
From: report at bugs.python.org (Anthony Zhang)
Date: Fri, 30 Dec 2016 00:56:05 +0000
Subject: [issue29110] [patch] Fix file object leak in `aifc.open` when given
 invalid AIFF file.
In-Reply-To: <1483059317.41.0.849254662988.issue29110@psf.upfronthosting.co.za>
Message-ID: <1483059365.33.0.0584287850568.issue29110@psf.upfronthosting.co.za>


Changes by Anthony Zhang <azhang9 at gmail.com>:


Added file: http://bugs.python.org/file46088/fix_aifc_leak_and_file_object_close.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29110>
_______________________________________

From report at bugs.python.org  Thu Dec 29 20:15:53 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 30 Dec 2016 01:15:53 +0000
Subject: [issue29109] Small doc improvements for tracemalloc
In-Reply-To: <1483054746.95.0.549035293258.issue29109@psf.upfronthosting.co.za>
Message-ID: <20161230011543.3396.54435.9B5B8C76@psf.io>


Roundup Robot added the comment:

New changeset 192e0ae17236 by Victor Stinner in branch '3.5':
Issue #29109: Enhance tracemalloc documentation
https://hg.python.org/cpython/rev/192e0ae17236

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29109>
_______________________________________

From report at bugs.python.org  Thu Dec 29 20:17:24 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 30 Dec 2016 01:17:24 +0000
Subject: [issue29109] Small doc improvements for tracemalloc
In-Reply-To: <1483054746.95.0.549035293258.issue29109@psf.upfronthosting.co.za>
Message-ID: <1483060644.85.0.0337744722708.issue29109@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Thank you for your contribution! I applied your patch to Python 3.5, 3.6 and default (future 3.7).

You should consider signing the PSF Contributor Agreement:
https://www.python.org/psf/contrib/contrib-form/

"While you retain the copyright, giving the PSF the ability to license your code means it can be put under the PSF license so it can be legally distributed with Python."

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29109>
_______________________________________

From report at bugs.python.org  Thu Dec 29 20:24:58 2016
From: report at bugs.python.org (Eric Lafontaine)
Date: Fri, 30 Dec 2016 01:24:58 +0000
Subject: [issue29020] collapse_rfc2231_value has inconsistent unquoting
In-Reply-To: <1482193812.46.0.729778317823.issue29020@psf.upfronthosting.co.za>
Message-ID: <1483061098.42.0.908588493619.issue29020@psf.upfronthosting.co.za>


Changes by Eric Lafontaine <eric.lafontaine1 at gmail.com>:


----------
nosy: +Eric Lafontaine

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29020>
_______________________________________

From report at bugs.python.org  Thu Dec 29 20:59:53 2016
From: report at bugs.python.org (Antony Lee)
Date: Fri, 30 Dec 2016 01:59:53 +0000
Subject: [issue29111] Strange signature for memoryview constructor
Message-ID: <1483063193.08.0.841678787602.issue29111@psf.upfronthosting.co.za>


New submission from Antony Lee:

The return value of `inspect.signature(memoryview)` is rather strange:

Python 3.5.2 (default, Nov  7 2016, 11:31:36) 
[GCC 6.2.1 20160830] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import inspect; inspect.signature(memoryview)
<Signature (module, /, object)>

----------
components: Library (Lib)
messages: 284302
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: Strange signature for memoryview constructor
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29111>
_______________________________________

From report at bugs.python.org  Thu Dec 29 21:04:27 2016
From: report at bugs.python.org (Jesse Hall)
Date: Fri, 30 Dec 2016 02:04:27 +0000
Subject: [issue29112] questionable wording in sequences documentation
Message-ID: <1483063467.95.0.432250545704.issue29112@psf.upfronthosting.co.za>


New submission from Jesse Hall:

In note 3 of 4.6.1, the word "string" should be replaced with "sequence", because the note is describing a general example where this concept is not specifically used with a string type sequence, it is discussing the general use of negative indexes which can be used on any type of sequence.

----------
assignee: docs at python
components: Documentation
messages: 284303
nosy: Jesse Hall, docs at python
priority: normal
severity: normal
status: open
title: questionable wording in sequences documentation
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29112>
_______________________________________

From report at bugs.python.org  Thu Dec 29 21:16:05 2016
From: report at bugs.python.org (Adam Williamson)
Date: Fri, 30 Dec 2016 02:16:05 +0000
Subject: [issue29113] modulefinder no longer finds all required modules for
 Python itself, due to use of __import__ in sysconfig
Message-ID: <1483064165.82.0.932079190988.issue29113@psf.upfronthosting.co.za>


New submission from Adam Williamson:

I'm not sure if this is really considered a bug or just an unavoidable limitation, but as it involves part of the stdlib operating on Python itself, I figured it was at least worth reporting.

In Fedora we have a fairly simple little script called python-deps:

https://github.com/rhinstaller/anaconda/blob/master/dracut/python-deps

which is used to figure out the dependencies of a couple of Python scripts used in the installer's initramfs environment, so the necessary bits of Python (but not the rest of it) can be included in the installer's initramfs.

Unfortunately, with Python 3.6, this seems to be broken for the core of Python itself, because of this change:

https://github.com/python/cpython/commit/a6431f2c8cf4783c2fd522b2f6ee04c3c204237f

which changed sysconfig.py from doing "from _sysconfigdata import build_time_vars" to using __import__ . I *think* that modulefinder can't cope with this use of __import__ and so misses that sysconfig requires "_sysconfigdata_m_linux_x86_64-linux-gnu" (or whatever the actual name is on your particular platform and arch).

This results in us not including the platform-specific module in the installer initramfs, so Python blows up on startup when the 'site' module tries to import the 'sysconfig' module.

We could work around this one way or another in the python-deps script, but I figured the issue was at least worth an upstream report to see if it's considered a significant issue or not.

You can reproduce the problem quite trivially by writing a test script which just does, e.g., "import site", and then running the example code from the ModuleFinder docs on it:

from modulefinder import ModuleFinder

finder = ModuleFinder()
finder.run_script('test.py')

print('Loaded modules:')
for name, mod in finder.modules.items():
    print('%s: ' % name, end='')
    print(','.join(list(mod.globalnames.keys())[:3]))

if you examine the output, you'll see that the 'sysconfig' module is included, but the site-specific module is not.

----------
components: Library (Lib)
messages: 284304
nosy: adamwill
priority: normal
severity: normal
status: open
title: modulefinder no longer finds all required modules for Python itself, due to use of __import__ in sysconfig
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29113>
_______________________________________

From report at bugs.python.org  Thu Dec 29 22:20:42 2016
From: report at bugs.python.org (Davin Potts)
Date: Fri, 30 Dec 2016 03:20:42 +0000
Subject: [issue29108] Python 3.6.0 multiprocessing map_async callback
In-Reply-To: <1483048651.39.0.165070292977.issue29108@psf.upfronthosting.co.za>
Message-ID: <1483068042.35.0.0994027399552.issue29108@psf.upfronthosting.co.za>


Davin Potts added the comment:

This appears to be working as designed.  The purpose of the callback is to receive a single argument (nominally, the ready result from the map operation) and perform its task (whatever it may be) very quickly so as not to further delay the handing back of results from the map operation.

Attempting to read into your comments, it sounds like you were perhaps expecting the return from the callback to appear somewhere?  If that was your expectation then no, that is not the purpose of a callback here.  Any transformation of input data to the final output data is performed by the function being applied by the map.  While there are many potential uses for a callback, its stated requirement is that it be as quick an operation as possible as opposed to something that further transforms the results or anything like a "reduce" operation which is not necessarily quick.

If you think this needs clarification in the documentation, please suggest something?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29108>
_______________________________________

From report at bugs.python.org  Thu Dec 29 22:38:29 2016
From: report at bugs.python.org (Ned Deily)
Date: Fri, 30 Dec 2016 03:38:29 +0000
Subject: [issue29113] modulefinder no longer finds all required modules for
 Python itself, due to use of __import__ in sysconfig
In-Reply-To: <1483064165.82.0.932079190988.issue29113@psf.upfronthosting.co.za>
Message-ID: <1483069109.61.0.103156053563.issue29113@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
nosy: +doko
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29113>
_______________________________________

From report at bugs.python.org  Thu Dec 29 23:01:49 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 30 Dec 2016 04:01:49 +0000
Subject: [issue29112] questionable wording in sequences documentation
In-Reply-To: <1483063467.95.0.432250545704.issue29112@psf.upfronthosting.co.za>
Message-ID: <20161230040146.80213.91471.231C69BA@psf.io>


Roundup Robot added the comment:

New changeset 0d20da97a6a0 by Xiang Zhang in branch '2.7':
Issue #29112: Fix a questionable wording in sequence doc.
https://hg.python.org/cpython/rev/0d20da97a6a0

New changeset f4b747f59804 by Xiang Zhang in branch '3.5':
Issue #29112: Fix a questionable wording in sequence doc.
https://hg.python.org/cpython/rev/f4b747f59804

New changeset b09d0a2587da by Xiang Zhang in branch '3.6':
Issue #29112: Merge 3.5.
https://hg.python.org/cpython/rev/b09d0a2587da

New changeset 4432cba89398 by Xiang Zhang in branch 'default':
Issue #29112: Merge 3.6.
https://hg.python.org/cpython/rev/4432cba89398

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29112>
_______________________________________

From report at bugs.python.org  Thu Dec 29 23:03:44 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 30 Dec 2016 04:03:44 +0000
Subject: [issue29112] questionable wording in sequences documentation
In-Reply-To: <1483063467.95.0.432250545704.issue29112@psf.upfronthosting.co.za>
Message-ID: <1483070624.36.0.894207062384.issue29112@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Thanks for your report Jesse. Now fixed.

----------
nosy: +xiang.zhang
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 2.7, Python 3.5, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29112>
_______________________________________

From report at bugs.python.org  Fri Dec 30 00:19:15 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 30 Dec 2016 05:19:15 +0000
Subject: [issue29103] Make enum.py pep8 compliant
In-Reply-To: <1482997050.71.0.505456771635.issue29103@psf.upfronthosting.co.za>
Message-ID: <1483075155.7.0.578406312951.issue29103@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I really don't like how this patch is done or even the spirit of it.  To my eyes, some of the code looks worse (especially the addition of trailing backslashes and some odd line-wraps that aren't sensitive to readability or context).

I'm going to close this.   If Ethan wants to make minor tweaks to his whitespace or line-wrapping, I believe he can do a better job with his own code.

Jean-Sebastien, thank you for trying to contribute, but PEP-8ing other people's code generally isn't helpful.  I recommend that you find a tracker item that needs a patch for a substantive change and work on that.  I think you will find it more satisfying and will have a much greater chance of acceptance.

----------
nosy: +rhettinger
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29103>
_______________________________________

From report at bugs.python.org  Fri Dec 30 00:23:24 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 30 Dec 2016 05:23:24 +0000
Subject: [issue28612] str.translate needs a mapping example
In-Reply-To: <1478278954.92.0.793705359912.issue28612@psf.upfronthosting.co.za>
Message-ID: <1483075404.51.0.928511000404.issue28612@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I like the idea of adding a mapping example but don't want to encourage use of defaultdict in contexts like this one.  A defaultdict usefully specifies a default but has the unpleasant side-effect of altering the dictionary (adding new keys) during the look-up phase.  This has bitten a lot of people (including famous ones like Peter Norvig).

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28612>
_______________________________________

From report at bugs.python.org  Fri Dec 30 00:32:30 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 30 Dec 2016 05:32:30 +0000
Subject: [issue29089] dictionary keys described incorrectly in tutorial
In-Reply-To: <1482874025.47.0.911588306573.issue29089@psf.upfronthosting.co.za>
Message-ID: <1483075950.07.0.237139587953.issue29089@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I'm going to concur with the other respondents on this.  As a Python teacher, this is how I teach what should be used as a dictionary key.

While immutability and hashability aren't equivalent, it is a good first approximation.  Also, even though it is true that you could make a hashable object that is mutable, it is generally a bad practice that leads to regrets.

I'm going to close this.  If someone wants to change the styling of the tutorial, that can reasonably be discussed in another patch.

Thank you for your ideas, but we're going to pass on this one.  The tutorial is a place where it can be counter-productive to 1) make discussions too long, 2) go into atypical practices, 3) add too many caveats in a effort to be overly precise, etc.   Also, this part of the tutorial has been around for many years and has done a reasonably good job at educating its readers.

----------
nosy: +rhettinger
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29089>
_______________________________________

From report at bugs.python.org  Fri Dec 30 00:33:57 2016
From: report at bugs.python.org (Eric Lafontaine)
Date: Fri, 30 Dec 2016 05:33:57 +0000
Subject: [issue29020] collapse_rfc2231_value has inconsistent unquoting
In-Reply-To: <1482193812.46.0.729778317823.issue29020@psf.upfronthosting.co.za>
Message-ID: <1483076037.84.0.136631314087.issue29020@psf.upfronthosting.co.za>


Eric Lafontaine added the comment:

Hi all,

The fix is already provided in issue28945 .  Please review it and I would like to flag it as needing more test on more version of python...

The patch would just require more Test Case that would check for the 
filename for preventing re-occurence in the future on the file-name.

Thanks for the analysis bpoaugust :).  I'm hoping no client relied on this function for the unquote though...

Regards,
Eric Lafontaine

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29020>
_______________________________________

From report at bugs.python.org  Fri Dec 30 00:42:21 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 30 Dec 2016 05:42:21 +0000
Subject: [issue29061] secrets.randbelow(-1) hangs
In-Reply-To: <1482560683.53.0.415654381831.issue29061@psf.upfronthosting.co.za>
Message-ID: <1483076541.08.0.575545587454.issue29061@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

_randbelow is a private api and it is not broken, it is just being misused by the secrets module.   All of the other calls to it are already range checked and it would be inefficient and unnecessary to repeat this the check.

Brendan, thank you for the updated patch.  It looks correct.  I will apply shortly.

Please do follow-up with Ewa so we can get the asterisk to appear by your name :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29061>
_______________________________________

From report at bugs.python.org  Fri Dec 30 00:43:10 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 30 Dec 2016 05:43:10 +0000
Subject: [issue29111] Strange signature for memoryview constructor
In-Reply-To: <1483063193.08.0.841678787602.issue29111@psf.upfronthosting.co.za>
Message-ID: <1483076590.21.0.0727923024852.issue29111@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
components: +Interpreter Core -Library (Lib)
nosy: +larry, skrah, yselivanov
type:  -> behavior
versions: +Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29111>
_______________________________________

From report at bugs.python.org  Fri Dec 30 00:53:38 2016
From: report at bugs.python.org (lanf0n)
Date: Fri, 30 Dec 2016 05:53:38 +0000
Subject: [issue29114] __class__ not exists in the method which bounded by
 types.MethodType.
Message-ID: <1483077218.4.0.672977492114.issue29114@psf.upfronthosting.co.za>


New submission from lanf0n:

test code below:

```python

>>> from types import MethodType
>>> class A:
...   def f(self):
...     print(__class__)
...
>>> a = A()
>>> a.fn = MethodType(lambda s: print(__class__), a)
>>>
>>> a.f()
<class '__main__.A'>
>>> a.fn()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 1, in <lambda>
NameError: name '__class__' is not defined
```

this behavior affect `super()` not work in patched function scope, 
of course we can use old super as super(self.__class__, self) to make it work as expected, but I think it should work as original method if we already bounded the function to instance(class).

----------
components: Library (Lib)
messages: 284313
nosy: lanfon72
priority: normal
severity: normal
status: open
title: __class__ not exists in the method which bounded by types.MethodType.
type: behavior
versions: Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29114>
_______________________________________

From report at bugs.python.org  Fri Dec 30 00:55:15 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 30 Dec 2016 05:55:15 +0000
Subject: [issue29061] secrets.randbelow(-1) hangs
In-Reply-To: <1482560683.53.0.415654381831.issue29061@psf.upfronthosting.co.za>
Message-ID: <20161230055512.79468.4175.ECE786CC@psf.io>


Roundup Robot added the comment:

New changeset 0509844f38df by Raymond Hettinger in branch '3.6':
Issue #29061:  secrets.randbelow() would hang with a negative input
https://hg.python.org/cpython/rev/0509844f38df

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29061>
_______________________________________

From report at bugs.python.org  Fri Dec 30 00:55:46 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 30 Dec 2016 05:55:46 +0000
Subject: [issue29061] secrets.randbelow(-1) hangs
In-Reply-To: <1482560683.53.0.415654381831.issue29061@psf.upfronthosting.co.za>
Message-ID: <1483077346.47.0.184002888374.issue29061@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Thanks for the bug report and for the patch.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29061>
_______________________________________

From report at bugs.python.org  Fri Dec 30 00:57:49 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 30 Dec 2016 05:57:49 +0000
Subject: [issue28612] str.translate needs a mapping example
In-Reply-To: <1478278954.92.0.793705359912.issue28612@psf.upfronthosting.co.za>
Message-ID: <1483077469.37.0.75078631136.issue28612@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

If the side effect of defaultdict is unpleasant, the correct way is combining the translation mapping with the custom mapping by ChainMap. But this example is too complex for the documentation of str.translate(). On other side, it is trivial for more experience users and don't need special mentioning.

I think other resources (ActiveState Code Reciepes [1] or books) are better places for this example.

[1] http://code.activestate.com/recipes/popular/

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28612>
_______________________________________

From report at bugs.python.org  Fri Dec 30 01:00:20 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 30 Dec 2016 06:00:20 +0000
Subject: [issue29110] [patch] Fix file object leak in `aifc.open` when given
 invalid AIFF file.
In-Reply-To: <1483059317.41.0.849254662988.issue29110@psf.upfronthosting.co.za>
Message-ID: <1483077620.38.0.839730372001.issue29110@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
assignee:  -> serhiy.storchaka
nosy: +serhiy.storchaka
stage:  -> patch review
versions:  -Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29110>
_______________________________________

From report at bugs.python.org  Fri Dec 30 01:23:27 2016
From: report at bugs.python.org (Jean-Sebastien Bevilacqua)
Date: Fri, 30 Dec 2016 06:23:27 +0000
Subject: [issue29103] Make enum.py pep8 compliant
In-Reply-To: <1482997050.71.0.505456771635.issue29103@psf.upfronthosting.co.za>
Message-ID: <1483079007.13.0.949025690337.issue29103@psf.upfronthosting.co.za>


Jean-Sebastien Bevilacqua added the comment:

Hello Raymond Hettinger,
Thanks for your advice and your comment.

I agree with you that pep8 compliant isn't useful. If you look at my patch, the first change is a unused import, not just a text formatting.

Maybe this first change can be useful ? (not importing unused module)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29103>
_______________________________________

From report at bugs.python.org  Fri Dec 30 01:37:21 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 30 Dec 2016 06:37:21 +0000
Subject: [issue29099] sqlite3 timestamp converter cannot handle timezone
In-Reply-To: <1482966269.67.0.620298847284.issue29099@psf.upfronthosting.co.za>
Message-ID: <1483079841.86.0.518996088677.issue29099@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

LGTM generally. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29099>
_______________________________________

From report at bugs.python.org  Fri Dec 30 01:57:41 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 30 Dec 2016 06:57:41 +0000
Subject: [issue29103] Make enum.py pep8 compliant
In-Reply-To: <1482997050.71.0.505456771635.issue29103@psf.upfronthosting.co.za>
Message-ID: <20161230065738.79468.52763.BA4BB63D@psf.io>


Roundup Robot added the comment:

New changeset bf6987b93358 by Raymond Hettinger in branch '3.6':
Issue #29103: Remove unused import.  Noticed by Jean-Sebastien Bevilacqua.
https://hg.python.org/cpython/rev/bf6987b93358

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29103>
_______________________________________

From report at bugs.python.org  Fri Dec 30 02:04:15 2016
From: report at bugs.python.org (Jose Miguel Colella)
Date: Fri, 30 Dec 2016 07:04:15 +0000
Subject: [issue29108] Python 3.6.0 multiprocessing map_async callback
In-Reply-To: <1483048651.39.0.165070292977.issue29108@psf.upfronthosting.co.za>
Message-ID: <1483081455.82.0.161862189891.issue29108@psf.upfronthosting.co.za>


Jose Miguel Colella added the comment:

Hello David,
Thanks for your response. Improvements to the documentation could clear this misunderstanding. I had initially believed that after transforming with the function passed to the map, it would use the callback on each of the result arguments. 
Just to understand the use case of the callback. So basically it should not return anything and be a simple print?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29108>
_______________________________________

From report at bugs.python.org  Fri Dec 30 02:12:01 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 30 Dec 2016 07:12:01 +0000
Subject: [issue29114] __class__ not exists in the method which bounded by
 types.MethodType.
In-Reply-To: <1483077218.4.0.672977492114.issue29114@psf.upfronthosting.co.za>
Message-ID: <1483081921.07.0.944738815038.issue29114@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

You can't do it like this. The document explicitly states it only works inside a class definition:

"Also note that, aside from the zero argument form, super() is not limited to use inside methods. The two argument form specifies the arguments exactly and makes the appropriate references. The zero argument form only works inside a class definition, as the compiler fills in the necessary details to correctly retrieve the class being defined, as well as accessing the current instance for ordinary methods."

So if treat it as an enhancement, is it reasonable Nick?

----------
nosy: +ncoghlan, xiang.zhang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29114>
_______________________________________

From report at bugs.python.org  Fri Dec 30 03:00:15 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Fri, 30 Dec 2016 08:00:15 +0000
Subject: [issue29061] secrets.randbelow(-1) hangs
In-Reply-To: <1483076541.08.0.575545587454.issue29061@psf.upfronthosting.co.za>
Message-ID: <20161230080008.GB3887@ando.pearwood.info>


Steven D'Aprano added the comment:

> _randbelow is a private api and it is not broken, it is just being 
> misused by the secrets module.

"Misused" seems a bit strong. Should I understand that you dislike the 
wrapper around _randbelow? The implementation was given in the PEP, and 
I don't remember any objections to it, but if you have an alternative 
implementation I'm not wedded to the idea of wrapping _randbelow.

https://www.python.org/dev/peps/pep-0506/#id81

Thanks for the patch Brendan, and thanks Raymond for applying it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29061>
_______________________________________

From report at bugs.python.org  Fri Dec 30 03:37:44 2016
From: report at bugs.python.org (Decorater)
Date: Fri, 30 Dec 2016 08:37:44 +0000
Subject: [issue29115] distutils.core.setup does not let people set
 'bugtrack_url'.
Message-ID: <1483087064.15.0.921977916672.issue29115@psf.upfronthosting.co.za>


New submission from Decorater:

So, I could have an example setup.py which sets a bugtrack url however using sdist and bdist_wheel on them produces this warning:

H:\Python\Python360\lib\distutils\dist.py:261: UserWarning: Unknown distribution option: 'bugtrack_url'
  warnings.warn(msg)

The issue with this is wanting to set or change the bug track url's for the particular packages using setup.py to generate a PKG-INFO file which explicitly sets the value.

Currently there is no way to modify the fields online anymore since probably like 3~4 months ago I before was able to do it for a little while without having to upload a PKG-INFO file.

Example setup.py that does this:

from setuptools import setup
import re

requirements = []
try:
    with open('requirements.txt') as f:
        requirements = f.read().splitlines()
except Exception as ex:
    with open('sasync.egg-info\requires.txt') as f:
        requirements = f.read().splitlines()

version = '0.0.1'

if not version:
    raise RuntimeError('version is not set')

with open('README') as f:
    readme = f.read()

setup(name='examplepackage',
      author='Decorater',
      author_email='seandhunt_7 at yahoo.com',
      url='https://github.com/AraHaan/examplepackage',
      bugtrack_url='https://github.com/AraHaan/examplepackage/issues',
      version=version,
      packages=['sasync'],
      license='MIT',
      description=('example package package demonstrating that bugtrack_url is not recognized by distutils.'),
      long_description=readme,
      maintainer_email='seandhunt_7 at yahoo.com',
      download_url='https://github.com/AraHaan/examplepackage',
      include_package_data=True,
      install_requires=requirements,
      platforms='Any',
      classifiers=[
        'Development Status :: 4 - Beta',
        'Environment :: Console',
        'Intended Audience :: Developers',
        'Intended Audience :: Other Audience',
        'Intended Audience :: Science/Research',
        'License :: OSI Approved :: MIT License',
        'Natural Language :: English',
        'Operating System :: OS Independent',
        'Programming Language :: Python :: 3.4',
        'Programming Language :: Python :: 3.5',
        'Programming Language :: Python :: 3.6',
        'Topic :: Software Development :: Libraries :: Python Modules',
      ]
)

----------
components: Distutils, Library (Lib)
messages: 284323
nosy: Decorater, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: distutils.core.setup does not let people set 'bugtrack_url'.
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29115>
_______________________________________

From report at bugs.python.org  Fri Dec 30 04:16:15 2016
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 30 Dec 2016 09:16:15 +0000
Subject: [issue29111] Strange signature for memoryview constructor
In-Reply-To: <1483063193.08.0.841678787602.issue29111@psf.upfronthosting.co.za>
Message-ID: <1483089375.71.0.94729989853.issue29111@psf.upfronthosting.co.za>


Stefan Krah added the comment:

The patch seems to fix it. $module was a thing at some point, I don't know whether the semantics changed or if it was wrong in the first place.

----------
keywords: +patch
Added file: http://bugs.python.org/file46089/issue29111.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29111>
_______________________________________

From report at bugs.python.org  Fri Dec 30 04:43:41 2016
From: report at bugs.python.org (Decorater)
Date: Fri, 30 Dec 2016 09:43:41 +0000
Subject: [issue28816] Document if zipimport can respect import hooks to load
 custom files from zip.
In-Reply-To: <1480326340.52.0.39566018579.issue28816@psf.upfronthosting.co.za>
Message-ID: <1483091021.3.0.232501504354.issue28816@psf.upfronthosting.co.za>


Decorater added the comment:

OK, Well I just tested and it sadly don't support import hooks that adds support for importing custom file types or file types python does know about with a uncommon extension inside of zip files which is somewhat sad. However if someone was to do something similar to py2exe's import hook allowing memory loading pyd and so files they could allow it to work for their import hook's needs.

----------
keywords: +patch
Added file: http://bugs.python.org/file46090/zipimport.rst.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28816>
_______________________________________

From report at bugs.python.org  Fri Dec 30 06:08:44 2016
From: report at bugs.python.org (Ammar Askar)
Date: Fri, 30 Dec 2016 11:08:44 +0000
Subject: [issue29097] datetime.fromtimestamp(t) when 0 <= t <= 86399 fails on
 Python 3.6
In-Reply-To: <1482958160.11.0.32337159902.issue29097@psf.upfronthosting.co.za>
Message-ID: <1483096124.1.0.546168865749.issue29097@psf.upfronthosting.co.za>


Ammar Askar added the comment:

I've attached two patches that fix this behavior, one by simply foregoing the fold detection for this time range on windows (the patch that I'd argue is simpler and more readable)

And one that truncates the passed values to local to not be negative. This one would have been simple but unfortunately there's the complication that there are two local calls and additionally, the second one cannot be truncated to exactly 0 because then we incorrectly detect a fold for the timestamp 0.

----------
keywords: +patch
Added file: http://bugs.python.org/file46091/forego_fold_detection.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29097>
_______________________________________

From report at bugs.python.org  Fri Dec 30 06:08:56 2016
From: report at bugs.python.org (Ammar Askar)
Date: Fri, 30 Dec 2016 11:08:56 +0000
Subject: [issue29097] datetime.fromtimestamp(t) when 0 <= t <= 86399 fails on
 Python 3.6
In-Reply-To: <1482958160.11.0.32337159902.issue29097@psf.upfronthosting.co.za>
Message-ID: <1483096136.25.0.998770980608.issue29097@psf.upfronthosting.co.za>


Changes by Ammar Askar <ammar at ammaraskar.com>:


Added file: http://bugs.python.org/file46092/truncate_negatives.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29097>
_______________________________________

From report at bugs.python.org  Fri Dec 30 06:26:34 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 30 Dec 2016 11:26:34 +0000
Subject: [issue29111] Strange signature for memoryview constructor
In-Reply-To: <1483063193.08.0.841678787602.issue29111@psf.upfronthosting.co.za>
Message-ID: <20161230112631.6426.80410.17A4216A@psf.io>


Roundup Robot added the comment:

New changeset 1e1e24629218 by Stefan Krah in branch '3.5':
Issue #29111: Fix memoryview signature.
https://hg.python.org/cpython/rev/1e1e24629218

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29111>
_______________________________________

From report at bugs.python.org  Fri Dec 30 06:31:28 2016
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 30 Dec 2016 11:31:28 +0000
Subject: [issue29111] Strange signature for memoryview constructor
In-Reply-To: <1483063193.08.0.841678787602.issue29111@psf.upfronthosting.co.za>
Message-ID: <1483097488.22.0.0693488664831.issue29111@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan at bytereef.org>:


----------
assignee:  -> skrah
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29111>
_______________________________________

From report at bugs.python.org  Fri Dec 30 08:33:46 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 30 Dec 2016 13:33:46 +0000
Subject: [issue29102] Add an id field to PyInterpreterState.
In-Reply-To: <1482994422.5.0.64533163171.issue29102@psf.upfronthosting.co.za>
Message-ID: <1483104826.87.0.574356250248.issue29102@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

+1 from me for the general idea.

One subtlety with the draft implementation is that an Initialize/Finalize cycle doesn't reset the counter, which:

1. Increases the chance of counter overflow (while admittedly still leaving it incredibly low)
2. Means you still can't readily check whether the current interpreter is the main interpreter (i.e. the one created automatically in Py_Initialize)

What do you think about resetting the counter back to 1 in Py_Initialize?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29102>
_______________________________________

From report at bugs.python.org  Fri Dec 30 08:42:38 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 30 Dec 2016 13:42:38 +0000
Subject: [issue29102] Add an id field to PyInterpreterState.
In-Reply-To: <1482994422.5.0.64533163171.issue29102@psf.upfronthosting.co.za>
Message-ID: <1483105358.64.0.287555611903.issue29102@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> What do you think about resetting the counter back to 1 in Py_Initialize?

Wouldn't this break the main property of IDs, the uniqueness?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29102>
_______________________________________

From report at bugs.python.org  Fri Dec 30 09:01:34 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 30 Dec 2016 14:01:34 +0000
Subject: [issue29114] __class__ not exists in the method which bounded by
 types.MethodType.
In-Reply-To: <1483077218.4.0.672977492114.issue29114@psf.upfronthosting.co.za>
Message-ID: <1483106494.87.0.511547459455.issue29114@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Right, this isn't actually a bug, it just requires a bit more creativity to bind and resolve `__class__` correctly when defining the replacement method.

Here's what happens normally with zero-argument super():

>>> class A:
...     def f(self):
...         print(__class__)
... 
>>> A().f()
<class '__main__.A'>
>>> A.f.__closure__
(<cell at 0x7f0ea25f1f48: type object at 0x55ea30974318>,)
>>> inspect.getclosurevars(A.f)
ClosureVars(nonlocals={'__class__': <class '__main__.A'>}, globals={}, builtins={'print': <built-in function print>}, unbound=set())

And here's one way of emulating the __class__ resolution part:

>>> def make_method():
...     __class__ = A
...     def fn(self):
...         print(__class__)
...     return fn
... 
>>> A.fn = make_method()
>>> A().fn()
<class '__main__.A'>

And applying that to get zero-argument super() working in a substitute method gives:

>>> class B(A):
...     def f(self):
...         super().f()
... 
>>> B().f() # Normal super()
<class '__main__.A'>
>>> def make_B_method():
...     __class__ = B
...     def fn(self):
...         return super().fn()
...     return fn
... 
>>> B.fn = make_B_method()
>>> B().fn()  # Emulated super()
<class '__main__.A'>

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29114>
_______________________________________

From report at bugs.python.org  Fri Dec 30 09:07:09 2016
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 30 Dec 2016 14:07:09 +0000
Subject: [issue29115] distutils.core.setup does not let people set
 'bugtrack_url'.
In-Reply-To: <1483087064.15.0.921977916672.issue29115@psf.upfronthosting.co.za>
Message-ID: <1483106829.47.0.878232699942.issue29115@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

I believe you need to report this problem to the setuptools maintainers. The stdlib distutils itself never defined a setup() argument 'bugtrack_url', so raises a warning when seeing this argument.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29115>
_______________________________________

From report at bugs.python.org  Fri Dec 30 09:20:52 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 30 Dec 2016 14:20:52 +0000
Subject: [issue29102] Add an id field to PyInterpreterState.
In-Reply-To: <1482994422.5.0.64533163171.issue29102@psf.upfronthosting.co.za>
Message-ID: <1483107652.7.0.366584152343.issue29102@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

It depends on the scope of uniqueness we're after. `threading._counter()` (which is the small-integer-ID debugging counter for threading.Thread names) is a module global in the threading module, so an Initialize/Finalize cycle will reset it.

If we wanted to track "Which Initialize/Finalize cycle is this?" *as well*, it would make more sense to me to have that as a separate "runtime" counter, such that the full coordinates of the current point of execution were:

- runtime counter (How many times has Py_Initialize been called?)
- interpreter counter (Which interpreter is currently active?)
- thread name (Which thread is currently active?)

I'll also note that in the threading module, the main thread is implicitly thread 0 (but named as MainThread) - Thread-1 is the first thread created via threading.Thread. So it may make sense to use a signed numeric ID, with 0 being the main interpreter, 1 being the first subinterpreter, and negative IDs being errors.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29102>
_______________________________________

From report at bugs.python.org  Fri Dec 30 10:51:25 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 30 Dec 2016 15:51:25 +0000
Subject: [issue29115] distutils.core.setup does not let people set
 'bugtrack_url'.
In-Reply-To: <1483087064.15.0.921977916672.issue29115@psf.upfronthosting.co.za>
Message-ID: <1483113085.92.0.469977911077.issue29115@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Marc-Andre is correct. bugtrack_url is a distribute/setuptools specific option. Please report your problem to them.

----------
nosy: +berker.peksag
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29115>
_______________________________________

From report at bugs.python.org  Fri Dec 30 11:15:17 2016
From: report at bugs.python.org (lanf0n)
Date: Fri, 30 Dec 2016 16:15:17 +0000
Subject: [issue29114] __class__ not exists in the method which bounded by
 types.MethodType.
In-Reply-To: <1483077218.4.0.672977492114.issue29114@psf.upfronthosting.co.za>
Message-ID: <1483114517.76.0.877423132406.issue29114@psf.upfronthosting.co.za>


lanf0n added the comment:

thanks xiang, Nick,

I might misunderstood MethodType to bound method will work as class definition.

It might not good to enhance MethodType to work as class definition, same problem on patching method to a class as Nick explained.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29114>
_______________________________________

From report at bugs.python.org  Fri Dec 30 11:30:15 2016
From: report at bugs.python.org (Steve Dower)
Date: Fri, 30 Dec 2016 16:30:15 +0000
Subject: [issue29102] Add an id field to PyInterpreterState.
In-Reply-To: <1482994422.5.0.64533163171.issue29102@psf.upfronthosting.co.za>
Message-ID: <1483115415.89.0.460197359329.issue29102@psf.upfronthosting.co.za>


Steve Dower added the comment:

> Wouldn't this break the main property of IDs, the uniqueness?

If we bump it up to a 64-bit ID then it'll be no worse than how we track all dict mutations.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29102>
_______________________________________

From report at bugs.python.org  Fri Dec 30 11:38:21 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 30 Dec 2016 16:38:21 +0000
Subject: [issue29114] __class__ not exists in the method which bounded by
 types.MethodType.
In-Reply-To: <1483077218.4.0.672977492114.issue29114@psf.upfronthosting.co.za>
Message-ID: <1483115901.84.0.58573560206.issue29114@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Sorry, I wasn't at all clear about that part - the above techniques should work with explicitly created types.MethodType instances as well.

That is, this should work the same as in my earlier examples (although I don't have that interpreter session around to test it any more):

    >>> b = B()
    >>> b.fn = types.MethodType(make_B_method(), b)
    >>> b.fn()  # Emulated super()
    <class '__main__.A'>

If you were to build on top of what I wrote above (i.e. setting "B.fn = make_B_method()"), that explicit bound method creation would be akin to doing:

    >>> b = B()
    >>> b.fn = b.fn # Cache the bound method on the instance

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29114>
_______________________________________

From report at bugs.python.org  Fri Dec 30 13:22:40 2016
From: report at bugs.python.org (Ethan Furman)
Date: Fri, 30 Dec 2016 18:22:40 +0000
Subject: [issue29103] Make enum.py pep8 compliant
In-Reply-To: <1482997050.71.0.505456771635.issue29103@psf.upfronthosting.co.za>
Message-ID: <1483122160.61.0.593928738674.issue29103@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Thanks Raymond and Jean-Sebastien.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29103>
_______________________________________

From report at bugs.python.org  Fri Dec 30 13:28:40 2016
From: report at bugs.python.org (Steve Dower)
Date: Fri, 30 Dec 2016 18:28:40 +0000
Subject: [issue24932] Migrate _testembed to a C unit testing library
In-Reply-To: <1440481888.38.0.825081560944.issue24932@psf.upfronthosting.co.za>
Message-ID: <1483122520.19.0.837463719307.issue24932@psf.upfronthosting.co.za>


Steve Dower added the comment:

The only real advantage of adding a native unit testing framework here is to avoid having to start/destroy _testembed[.exe] multiple times during the test run. But given the nature of these tests is highly environmental, I don't think we can reasonably avoid it. I'm also highly doubtful that any framework is going to actually reduce the work we'd need to do to mock out initialization steps.

I've attached a patch that takes the first step towards making _testembed more usable, by changing main() to look up a test from a list and execute it, then return the exit code. The support in test_capi.EmbeddingTests is neat, so adding more tests here will be?fairly straightforward.

----------
keywords: +patch
nosy: +steve.dower
versions: +Python 3.7
Added file: http://bugs.python.org/file46093/24932_1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24932>
_______________________________________

From report at bugs.python.org  Fri Dec 30 13:30:44 2016
From: report at bugs.python.org (Naftali Harris)
Date: Fri, 30 Dec 2016 18:30:44 +0000
Subject: [issue29107] traceback module incorrectly formats args-less syntax
 errors
In-Reply-To: <1483035828.75.0.241561980745.issue29107@psf.upfronthosting.co.za>
Message-ID: <1483122644.23.0.688174559708.issue29107@psf.upfronthosting.co.za>


Naftali Harris added the comment:

Two other minor discrepancies between the way traceback and the interpreter format SyntaxError's, in 2.7.13:

1.

>>> e = SyntaxError("some message", ("myfile.py", None, None, None))
>>> raise e
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SyntaxError: some message (myfile.py)
>>> try:
... 	raise e
... except:
... 	traceback.print_exc()
...
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
Traceback (most recent call last):
  File "<stdin>", line 4, in <module>
  File "/Users/naftali/repos/Python-2.7.13/Lib/traceback.py", line 233, in print_exc
    print_exception(etype, value, tb, limit, file)
  File "/Users/naftali/repos/Python-2.7.13/Lib/traceback.py", line 126, in print_exception
    lines = format_exception_only(etype, value)
  File "/Users/naftali/repos/Python-2.7.13/Lib/traceback.py", line 188, in format_exception_only
    lines.append('  File "%s", line %d\n' % (filename, lineno))
TypeError: %d format: a number is required, not NoneType


2.

>>> e = SyntaxError("some message", ("myfile.py", 3, 10, "hello"))
>>> raise e
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "myfile.py", line 3
    hello
             ^
SyntaxError: some message
>>> try:
... 	raise e
... except:
... 	traceback.print_exc()
...
Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
  File "myfile.py", line 3
    hello
        ^
SyntaxError: some message

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29107>
_______________________________________

From report at bugs.python.org  Fri Dec 30 13:56:51 2016
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Fri, 30 Dec 2016 18:56:51 +0000
Subject: [issue29116] Make str and bytes error messages on concatenation
 conform with other sequences
Message-ID: <1483124211.75.0.715869443236.issue29116@psf.upfronthosting.co.za>


New submission from Jim Fasarakis-Hilliard:

Specifically, bytes (always, from what I could find) had this error message:

    >>> b'' + ''
    TypeError: can't concat bytes to str

while str, after a change in issue26057, was made to:

    >>> '' + b''
    TypeError: must be str, not bytes

from the previous form of "TypeError: Can't convert 'bytes' object to str implicitly".

I think these could be changed to conform with what the other sequences generate and fall in line with the error messages produced for other operations.

Specifically changing them to:

    >>> b'' + ''
    TypeError: can only concatenate bytes (not 'str') to bytes

and similarly for str.

If this idea makes sense, I can attach a patch that addresses it.

----------
components: Interpreter Core
messages: 284340
nosy: Jim Fasarakis-Hilliard
priority: normal
severity: normal
status: open
title: Make str and bytes error messages on concatenation conform with other sequences
type: behavior
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29116>
_______________________________________

From report at bugs.python.org  Fri Dec 30 15:12:01 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 30 Dec 2016 20:12:01 +0000
Subject: [issue29116] Make str and bytes error messages on concatenation
 conform with other sequences
In-Reply-To: <1483124211.75.0.715869443236.issue29116@psf.upfronthosting.co.za>
Message-ID: <1483128721.89.0.201246647343.issue29116@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Old error message is misleading. It implied that there are objects that can be converted to str implicitly. This was true in Python 2, but is false in Python 3.

New error message conforms with TypeError messages produced by PyArg_Parse*(). It is the same in a number of str methods. It doesn't conform with the error messages for other produced by concatenating other types. But different messages are generated for different types:

>>> b'' + 1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can't concat bytes to int
>>> a = bytearray(); a += 1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can't concat int to bytearray
>>> [] + 1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can only concatenate list (not "int") to list
>>> a = []; a += 1
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'int' object is not iterable
>>> import array; array.array('b') + []
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can only append array (not "list") to array
>>> import array; a = array.array('b'); a += []
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can only extend array with array (not "list")
>>> import operator; operator.concat(1, '')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'int' object can't be concatenated

I think it would be better to unify them all.

I'm not sure that this change can be considered as a bug fix rather than an enhancement. Leave this on 3.6 release manager.

----------
assignee:  -> ned.deily
nosy: +ned.deily, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29116>
_______________________________________

From report at bugs.python.org  Fri Dec 30 15:15:33 2016
From: report at bugs.python.org (Gaurav Tatke)
Date: Fri, 30 Dec 2016 20:15:33 +0000
Subject: [issue28612] str.translate needs a mapping example
In-Reply-To: <1478278954.92.0.793705359912.issue28612@psf.upfronthosting.co.za>
Message-ID: <1483128933.67.0.601009793562.issue28612@psf.upfronthosting.co.za>


Gaurav Tatke added the comment:

Hi,

Pardon my ignorance, I am new to this but have below queries/thoughts -

1. Why would we say that adding new keys during lookup phase is an unpleasant side-effect? From what I understood by docs, one of the main reasons to use defaultdicts is to be able to insert a missing key and give a default value to it. 'defaultdict' doc itself suggest that doing this is cleaner and faster than using dict.setdefault().

2. I believe defaultdict perfectly fits in this context of creating translation table for str.translate(). Even if we have very large string containing all characters from 4-5 languages, our defaultdict will still be comparatively small. It is easier to create a translation table using defaultdict when we have to strip most characters out of a string as in the example requested in the issue. Creating a translation table using str.maketrans() or by user defined function is tricky in this use case.

3. If argument for using defaultdict in this context is not convincing, shall I just give a patch, giving example of str.translate() using str.maketranse()?

Regards,

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28612>
_______________________________________

From report at bugs.python.org  Fri Dec 30 15:17:59 2016
From: report at bugs.python.org (Gaurav Tatke)
Date: Fri, 30 Dec 2016 20:17:59 +0000
Subject: [issue28612] str.translate needs a mapping example
In-Reply-To: <1478278954.92.0.793705359912.issue28612@psf.upfronthosting.co.za>
Message-ID: <1483129079.93.0.769410977765.issue28612@psf.upfronthosting.co.za>


Gaurav Tatke added the comment:

Should a user be suggested to use str.translate() for the use case where user only wants to keep certain characters and strip off everything else?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28612>
_______________________________________

From report at bugs.python.org  Fri Dec 30 15:19:43 2016
From: report at bugs.python.org (Decorater)
Date: Fri, 30 Dec 2016 20:19:43 +0000
Subject: [issue29115] distutils.core.setup does not let people set
 'bugtrack_url'.
In-Reply-To: <1483087064.15.0.921977916672.issue29115@psf.upfronthosting.co.za>
Message-ID: <1483129183.36.0.410461991896.issue29115@psf.upfronthosting.co.za>


Decorater added the comment:

The problem with setuptools on that is that they export their setup like so which uses the distutils setup by doing:

setup = distutils.core.setup. That is how they are doing it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29115>
_______________________________________

From report at bugs.python.org  Fri Dec 30 15:41:31 2016
From: report at bugs.python.org (Decorater)
Date: Fri, 30 Dec 2016 20:41:31 +0000
Subject: [issue29115] distutils.core.setup does not let people set
 'bugtrack_url'.
In-Reply-To: <1483087064.15.0.921977916672.issue29115@psf.upfronthosting.co.za>
Message-ID: <1483130491.69.0.414016302675.issue29115@psf.upfronthosting.co.za>


Decorater added the comment:

So basically what from setuptools import setup is really doing is the same as doing from distutils.core import setup

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29115>
_______________________________________

From report at bugs.python.org  Fri Dec 30 15:58:42 2016
From: report at bugs.python.org (R. David Murray)
Date: Fri, 30 Dec 2016 20:58:42 +0000
Subject: [issue29115] distutils.core.setup does not let people set
 'bugtrack_url'.
In-Reply-To: <1483087064.15.0.921977916672.issue29115@psf.upfronthosting.co.za>
Message-ID: <1483131522.83.0.992474992181.issue29115@psf.upfronthosting.co.za>


R. David Murray added the comment:

Except that setuptools monkey patches distutiles all over the place.  So no, it isn't the same at all.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29115>
_______________________________________

From report at bugs.python.org  Fri Dec 30 16:51:10 2016
From: report at bugs.python.org (Antony Lee)
Date: Fri, 30 Dec 2016 21:51:10 +0000
Subject: [issue29117] dir(<bound method>) should include dunder attributes of
 the unbound method
Message-ID: <1483134670.11.0.964598948516.issue29117@psf.upfronthosting.co.za>


New submission from Antony Lee:

```
Python 3.5.2 (default, Nov  7 2016, 11:31:36) 
[GCC 6.2.1 20160830] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> class C:
...     def f(self): pass
... 
>>> C.f.attr = 42
>>> print(dir(C.f))
['__annotations__', '__call__', '__class__', '__closure__', '__code__', '__defaults__', '__delattr__', '__dict__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__get__', '__getattribute__', '__globals__', '__gt__', '__hash__', '__init__', '__kwdefaults__', '__le__', '__lt__', '__module__', '__name__', '__ne__', '__new__', '__qualname__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', 'attr']
>>> print(dir(C().f))
['__call__', '__class__', '__delattr__', '__dir__', '__doc__', '__eq__', '__format__', '__func__', '__ge__', '__get__', '__getattribute__', '__gt__', '__hash__', '__init__', '__le__', '__lt__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__self__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', 'attr']
>>> 
```

Note that `dir(C().f)` does include the custom `attr` attribute, but is missing some of the dunder attributes (e.g. `__annotations__`), which are actually accessible directly from the boun method.

----------
components: Interpreter Core
messages: 284347
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: dir(<bound method>) should include dunder attributes of the unbound method
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29117>
_______________________________________

From report at bugs.python.org  Fri Dec 30 16:53:37 2016
From: report at bugs.python.org (Jim Fasarakis-Hilliard)
Date: Fri, 30 Dec 2016 21:53:37 +0000
Subject: [issue29116] Make str and bytes error messages on concatenation
 conform with other sequences
In-Reply-To: <1483124211.75.0.715869443236.issue29116@psf.upfronthosting.co.za>
Message-ID: <1483134817.73.0.63128157666.issue29116@psf.upfronthosting.co.za>


Jim Fasarakis-Hilliard added the comment:

Should that message be the one predominantly used for sequences, i.e:

   TypeError: can only concatenate class1 (not "class2") to class1

or should another one be used like "Unsupported operand type(s) for op: 'class1' and 'class2'?

The first is problematic with cases like `+=` where an iterable is accepted, the second seems better to me at least.

As for `operator.concat`, any reason why the check is made beforehand to see if the first argument has a `__getitem__` method? Couldn't that just be removed allowing the exception from `concat(1, '')` to just propagate to the caller?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29116>
_______________________________________

From report at bugs.python.org  Fri Dec 30 16:57:26 2016
From: report at bugs.python.org (Decorater)
Date: Fri, 30 Dec 2016 21:57:26 +0000
Subject: [issue29115] distutils.core.setup does not let people set
 'bugtrack_url'.
In-Reply-To: <1483087064.15.0.921977916672.issue29115@psf.upfronthosting.co.za>
Message-ID: <1483135046.41.0.028739651732.issue29115@psf.upfronthosting.co.za>


Decorater added the comment:

Except for the setup function, yeah. https://github.com/pypa/setuptools/blob/master/setuptools/__init__.py#L112

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29115>
_______________________________________

From report at bugs.python.org  Fri Dec 30 17:43:16 2016
From: report at bugs.python.org (Eric Snow)
Date: Fri, 30 Dec 2016 22:43:16 +0000
Subject: [issue29102] Add an id field to PyInterpreterState.
In-Reply-To: <1482994422.5.0.64533163171.issue29102@psf.upfronthosting.co.za>
Message-ID: <1483137796.7.0.758994986653.issue29102@psf.upfronthosting.co.za>


Eric Snow added the comment:

> What do you think about resetting the counter back to 1 in Py_Initialize?

Sounds good to me.  When I was working on the patch I had the idea in the back of my mind that not resetting the counter would better support interpreter separation efforts in the future.  However, after giving it some thought I don't think that's the case.  So resetting it in Py_Initialize() is fine with me.

> I'll also note that in the threading module, the main thread is
> implicitly thread 0 (but named as MainThread) - Thread-1 is the first
> thread created via threading.Thread. So it may make sense to use a
> signed numeric ID, with 0 being the main interpreter, 1 being the first
> subinterpreter, and negative IDs being errors.

I had considered that and went with an unsigned long.  0 is used for errors, and starting at 1, which effectively means the main interpreter is always 1.  If we later run into overflow issues then we can sort that out at that point (e.g. by moving to a 64-bit int or even a Python int).

I'll add comments to the patch regarding these points.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29102>
_______________________________________

From report at bugs.python.org  Fri Dec 30 17:50:23 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 30 Dec 2016 22:50:23 +0000
Subject: [issue29115] distutils.core.setup does not let people set
 'bugtrack_url'.
In-Reply-To: <1483087064.15.0.921977916672.issue29115@psf.upfronthosting.co.za>
Message-ID: <1483138223.38.0.88155285856.issue29115@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Again, this is not a distutils bug and it has already been reported to the setuptools maintainers: https://github.com/pypa/setuptools/issues/29

Quoting from the original report:

> Currently setuptools.dist.Distribution passes the unfiltered collection
> of keyword arguments up to distutils.core.Distribution. This results in
> lots of scary looking "UserWarning" messages when you actually use the
> setuptools-only options

and see also:

> It also makes it look like you're calling distutils rather than setuptools,
> since the stack trace (showing that this is a call up into setuptools)
> isn't visible.

The setuptools maintainer replied (which he also maintains distutils):

> Indeed, setuptools just passes the attributes through directly through to Distribution. [...]

And by the way, I saw your own report while doing a research on this. Quoting from https://github.com/pypa/setuptools/issues/906

> [...] So that way setuptools can fix this bug as the standard library devs
> that manage distutils are too lazy to fix it themselves.

Next time I suggest you to do a better research before starting to blame the core developers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29115>
_______________________________________

From report at bugs.python.org  Fri Dec 30 18:06:33 2016
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 30 Dec 2016 23:06:33 +0000
Subject: [issue29115] distutils.core.setup does not let people set
 'bugtrack_url'.
In-Reply-To: <1483087064.15.0.921977916672.issue29115@psf.upfronthosting.co.za>
Message-ID: <1483139193.7.0.705591598858.issue29115@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

I did some more research: setuptools didn't have this keyword either.

It was added to PyPI at some point and then probably got picked up by some package authors as new "optional" keyword argument for setup():

http://stackoverflow.com/questions/14459828/how-to-set-bug-tracker-url-in-setup-py-script

There isn't anything we can do about this in the Python stdlib and neither can setuptools (except write a filter for it).

It's probably best to let the package authors still using the keyword know that they have to remove the keyword settings from their setup.py.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29115>
_______________________________________

From report at bugs.python.org  Fri Dec 30 18:25:23 2016
From: report at bugs.python.org (Eric Snow)
Date: Fri, 30 Dec 2016 23:25:23 +0000
Subject: [issue29102] Add an id field to PyInterpreterState.
In-Reply-To: <1482994422.5.0.64533163171.issue29102@psf.upfronthosting.co.za>
Message-ID: <1483140323.85.0.483780632593.issue29102@psf.upfronthosting.co.za>


Eric Snow added the comment:

Here's the updated patch.

----------
Added file: http://bugs.python.org/file46094/interpreter-id-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29102>
_______________________________________

From report at bugs.python.org  Fri Dec 30 18:40:16 2016
From: report at bugs.python.org (Christopher Barker)
Date: Fri, 30 Dec 2016 23:40:16 +0000
Subject: [issue28612] str.translate needs a mapping example
In-Reply-To: <1483129079.93.0.769410977765.issue28612@psf.upfronthosting.co.za>
Message-ID: <CALGmxE+8mFWMFKOsHaCf_ok7K-uqR-Z8L0F-jqcC1XMepoPd7w@mail.gmail.com>


Christopher Barker added the comment:

This all came out of a thread on python-ideas, starting here:

https://mail.python.org/pipermail/python-ideas/2016-October/043284.html

the thread kind of petered out, but it seems there was a kinda-sorta
consensus that we didn't need any new string methods, but rather same notes
in the docs on how to to use .translate() to remove "all but these" was in
order.

And the defaultdict method was proposed as the easiest / most pythonic.

As it happens, I did't live the fact hat defaultdict will build up a
big(ish) dict of Nones for no reason, and thus suggested a NoneDict option:

class NoneDict(dict):
    """
    Dictionary implementation that always returns None when a key is not in
the dict,
    rather than raising a KeyError
    """
    def __getitem__(self, key):
        try:
            val = dict.__getitem__(self, key)
        except KeyError:
            val = None
        return val

Though maybe that's a bit much for the docs.

However, in short:

either the defaultdict approach is siple and pythonic enough to be in teh
docs, or we SHOULD add something new to the string object.

(or maybe someone has another nifty pythonic way to do this with the stdlib
that's better than defaultdict?)

-CHB

On Fri, Dec 30, 2016 at 12:18 PM, Gaurav Tatke <report at bugs.python.org>
wrote:

>
> Gaurav Tatke added the comment:
>
> Should a user be suggested to use str.translate() for the use case where
> user only wants to keep certain characters and strip off everything else?
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue28612>
> _______________________________________
>

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov

----------
nosy: +Chris.Barker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28612>
_______________________________________

From report at bugs.python.org  Fri Dec 30 18:46:03 2016
From: report at bugs.python.org (Naftali Harris)
Date: Fri, 30 Dec 2016 23:46:03 +0000
Subject: [issue29107] traceback module incorrectly formats args-less syntax
 errors
In-Reply-To: <1483035828.75.0.241561980745.issue29107@psf.upfronthosting.co.za>
Message-ID: <1483141563.07.0.580997338155.issue29107@psf.upfronthosting.co.za>


Naftali Harris added the comment:

For your convenience, here is a possible patch fixing these issues. It modifies the format_exception_only function in the traceback module to follow the behavior of the interpreter a little more closely for SyntaxError's. Feel free to use, in whole, in part, or not at all, as you wish. Happy new year! :-)

----------
keywords: +patch
Added file: http://bugs.python.org/file46095/traceback_fixes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29107>
_______________________________________

From report at bugs.python.org  Fri Dec 30 18:56:45 2016
From: report at bugs.python.org (Naftali Harris)
Date: Fri, 30 Dec 2016 23:56:45 +0000
Subject: [issue29107] traceback module incorrectly formats args-less syntax
 errors
In-Reply-To: <1483035828.75.0.241561980745.issue29107@psf.upfronthosting.co.za>
Message-ID: <1483142205.93.0.558147969139.issue29107@psf.upfronthosting.co.za>


Naftali Harris added the comment:

Adding Georg, who is listed as an expert for the traceback module (https://docs.python.org/devguide/experts.html).

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29107>
_______________________________________

From report at bugs.python.org  Fri Dec 30 20:03:30 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 31 Dec 2016 01:03:30 +0000
Subject: [issue29098] document minimum sqlite version
In-Reply-To: <1482962930.74.0.760741820297.issue29098@psf.upfronthosting.co.za>
Message-ID: <1483146210.39.0.0295381981111.issue29098@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29098>
_______________________________________

From report at bugs.python.org  Fri Dec 30 20:16:35 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 31 Dec 2016 01:16:35 +0000
Subject: [issue29105] code or doc improvement for
 logging.handlers.RotatingFileHandler
In-Reply-To: <1483028994.58.0.687650973528.issue29105@psf.upfronthosting.co.za>
Message-ID: <1483146995.38.0.0237169459704.issue29105@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29105>
_______________________________________

From report at bugs.python.org  Fri Dec 30 21:55:23 2016
From: report at bugs.python.org (Decorater)
Date: Sat, 31 Dec 2016 02:55:23 +0000
Subject: [issue29115] distutils.core.setup does not let people set
 'bugtrack_url'.
In-Reply-To: <1483087064.15.0.921977916672.issue29115@psf.upfronthosting.co.za>
Message-ID: <1483152923.02.0.0558194239459.issue29115@psf.upfronthosting.co.za>


Decorater added the comment:

In that case why does pypi.python.org not let me change that bug track url option or set it anymore?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29115>
_______________________________________

From report at bugs.python.org  Fri Dec 30 22:45:01 2016
From: report at bugs.python.org (Spacemage 33)
Date: Sat, 31 Dec 2016 03:45:01 +0000
Subject: [issue29118] Randit
Message-ID: <1483155901.64.0.660907130999.issue29118@psf.upfronthosting.co.za>


New submission from Spacemage 33:

I have a book with i can learn phyton but in the first Little game there is "from random import randit" and the book is for Phyton3 now it do not work im realy said about this please fix that

----------
assignee: terry.reedy
components: IDLE
files: Screenshot_4.png
messages: 284358
nosy: Spacemage 33, terry.reedy
priority: normal
severity: normal
status: open
title: Randit
versions: Python 3.6
Added file: http://bugs.python.org/file46096/Screenshot_4.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29118>
_______________________________________

From report at bugs.python.org  Fri Dec 30 22:58:51 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 31 Dec 2016 03:58:51 +0000
Subject: [issue29102] Add an id field to PyInterpreterState.
In-Reply-To: <1482994422.5.0.64533163171.issue29102@psf.upfronthosting.co.za>
Message-ID: <1483156731.95.0.768445516495.issue29102@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

The concern I have with using an unsigned value as the interpreter ID is that it's applying the "NULL means an error" idiom or the "false means an error" idiom to a non-pointer and non-boolean return type, whereas the common conventions for integer return values are:

* 0 = success in CLI return codes
* non-negative = success in int-based C APIs

If we were to use int_fast32_t for IDs instead, then any negative value can indicate an error, and the main interpreter could be given ID 0 to better align with the threading.Thread naming scheme.

Whether we hit runtime error at 2 billion subinterpreters or 4 billion subinterpreters in a single process isn't likely to make much difference to anyone, but choosing an idiosyncratic error indicator will impact everyone that attempts to interact with the API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29102>
_______________________________________

From report at bugs.python.org  Fri Dec 30 23:01:03 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 31 Dec 2016 04:01:03 +0000
Subject: [issue24932] Use proper command line parsing in _testembed
In-Reply-To: <1440481888.38.0.825081560944.issue24932@psf.upfronthosting.co.za>
Message-ID: <1483156863.97.0.707939431261.issue24932@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
title: Migrate _testembed to a C unit testing library -> Use proper command line parsing in _testembed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24932>
_______________________________________

From report at bugs.python.org  Fri Dec 30 23:08:21 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 31 Dec 2016 04:08:21 +0000
Subject: [issue24932] Use proper command line parsing in _testembed
In-Reply-To: <1440481888.38.0.825081560944.issue24932@psf.upfronthosting.co.za>
Message-ID: <1483157301.65.0.948269395674.issue24932@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Steve's patch LGTM, and I now agree our needs are simple enough that we can rely on subprocess+unittest for the result reporting.

I'd just missed Steve's simple solution of using the return code to indicate success or failure, as well as Eric's approach in issue 29102 of teaching the related Python test case to read the text output from the _testembed test case.

If we eventually want to go beyond the single "run this test case" argument, then adding getopt() support to _testembed should be sufficient.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24932>
_______________________________________

From report at bugs.python.org  Fri Dec 30 23:42:39 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 31 Dec 2016 04:42:39 +0000
Subject: [issue29118] Randit
In-Reply-To: <1483155901.64.0.660907130999.issue29118@psf.upfronthosting.co.za>
Message-ID: <1483159359.92.0.751907144442.issue29118@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

This issue has nothing to do with IDLE.  There is also no bug here.  Python's random module has a randint function that works fine.  Either you or the book have misspelled 'randint' as 'randit' or the book is using its own random module and not the stdlib version.  Please post on python-list if you think you have found a bug.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29118>
_______________________________________

From report at bugs.python.org  Fri Dec 30 23:43:51 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 31 Dec 2016 04:43:51 +0000
Subject: [issue29118] Randit
In-Reply-To: <1483155901.64.0.660907130999.issue29118@psf.upfronthosting.co.za>
Message-ID: <1483159431.97.0.685901905084.issue29118@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Also, wherever you post, copy and paste the traceback instead of adding a link to an image.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29118>
_______________________________________

From report at bugs.python.org  Fri Dec 30 23:57:26 2016
From: report at bugs.python.org (Glenn Linderman)
Date: Sat, 31 Dec 2016 04:57:26 +0000
Subject: [issue29059] Windows: Python not using ANSI compatible console
In-Reply-To: <1482543191.02.0.407458515739.issue29059@psf.upfronthosting.co.za>
Message-ID: <1483160246.12.0.384522999031.issue29059@psf.upfronthosting.co.za>


Glenn Linderman added the comment:

Nice idea, but not by default. An easy way to switch back and forth, and to be sure the original mode is restored on process exit would be a win.

Most windows users want a real GUI, not curses, but compatibility with VT escape codes for cross-platform semi-GUI stuff could be useful... and could enable the stdlib curses to be included in Python for windows also? I'm not sure why it isn't, and "ANSI" a.k.a. VT escape codes have been available in Windows for a long time... but until Python 3.6.0 (thanks again Steve, and others), Windows console handling in Python has been extremely limited.

Also note that UniCurses and Pygcurse exist and provide similar capabilities.

----------
nosy: +v+python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29059>
_______________________________________

From report at bugs.python.org  Sat Dec 31 00:16:28 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 31 Dec 2016 05:16:28 +0000
Subject: [issue29075] Remove Windows Vista support
In-Reply-To: <1482775241.44.0.333291277311.issue29075@psf.upfronthosting.co.za>
Message-ID: <1483161388.98.0.604777462871.issue29075@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

How certain are you that Vista support will actually end?

Other things: assuming reasonable certainty, could the 3.6 installer say "This is the last version that will run on Vista!"?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29075>
_______________________________________

From report at bugs.python.org  Sat Dec 31 00:17:43 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 31 Dec 2016 05:17:43 +0000
Subject: [issue29076] Py 3.6 Mac installer doesn't update "python3" shell
 command
In-Reply-To: <1482778000.76.0.584407589583.issue29076@psf.upfronthosting.co.za>
Message-ID: <1483161463.46.0.816864883982.issue29076@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
title: Python 3.6 installer doesn't update "python3" shell command -> Py 3.6 Mac installer doesn't update "python3" shell command

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29076>
_______________________________________

From report at bugs.python.org  Sat Dec 31 00:21:10 2016
From: report at bugs.python.org (Steve Dower)
Date: Sat, 31 Dec 2016 05:21:10 +0000
Subject: [issue29059] Windows: Python not using ANSI compatible console
In-Reply-To: <1482543191.02.0.407458515739.issue29059@psf.upfronthosting.co.za>
Message-ID: <1483161670.55.0.939678162521.issue29059@psf.upfronthosting.co.za>


Steve Dower added the comment:

I suspect curses could be updated to fully support Windows, even without the VT100 mode (all the functionality has existed for years, just through a different interface). It really just needs someone to take on the project, and there are already better options out there (I forget the name, but the IPython team are very happy with whatever library they're using these days), so possibly it's more of an awareness problem that doesn't need to be solved in the core distro.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29059>
_______________________________________

From report at bugs.python.org  Sat Dec 31 00:27:25 2016
From: report at bugs.python.org (Steve Dower)
Date: Sat, 31 Dec 2016 05:27:25 +0000
Subject: [issue29102] Add an id field to PyInterpreterState.
In-Reply-To: <1482994422.5.0.64533163171.issue29102@psf.upfronthosting.co.za>
Message-ID: <1483162045.3.0.169105155693.issue29102@psf.upfronthosting.co.za>


Steve Dower added the comment:

I fully expect subinterpreters to have a serious role in long running applications like web servers or other agents (e.g. cluster nodes), so I'd rather just bite the bullet and take 64-bits now so that we can completely neglect reuse issues. Otherwise we'll find ourselves adding infrastructure to hide the fact that you may see the same id twice.

Another four bytes is a cheap way to avoid an entire abstraction layer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29102>
_______________________________________

From report at bugs.python.org  Sat Dec 31 01:11:43 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 31 Dec 2016 06:11:43 +0000
Subject: [issue29119] Unintentional hard reference assignment in Python
 version of OrderedDict.move_to_end
Message-ID: <1483164703.14.0.0947290095452.issue29119@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

The root.prev and first.prev assignments should use weak references rather than hard references.  Spotted by Andra Bogildea.

----------
components: Library (Lib)
files: od_proxy.diff
keywords: patch
messages: 284367
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Unintentional hard reference assignment in Python version of OrderedDict.move_to_end
type: resource usage
versions: Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file46097/od_proxy.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29119>
_______________________________________

From report at bugs.python.org  Sat Dec 31 01:15:15 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 31 Dec 2016 06:15:15 +0000
Subject: [issue29119] Unintentional hard reference assignment in Python
 version of OrderedDict.move_to_end
In-Reply-To: <1483164703.14.0.0947290095452.issue29119@psf.upfronthosting.co.za>
Message-ID: <1483164915.9.0.0299235168708.issue29119@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
priority: normal -> low
Added file: http://bugs.python.org/file46098/od_proxy2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29119>
_______________________________________

From report at bugs.python.org  Sat Dec 31 01:33:37 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 31 Dec 2016 06:33:37 +0000
Subject: [issue29119] Unintentional hard reference assignment in Python
 version of OrderedDict.move_to_end
In-Reply-To: <1483164703.14.0.0947290095452.issue29119@psf.upfronthosting.co.za>
Message-ID: <1483166017.29.0.376619299862.issue29119@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Makes sense. Any chance to create tests?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29119>
_______________________________________

From report at bugs.python.org  Sat Dec 31 01:49:59 2016
From: report at bugs.python.org (Glenn Linderman)
Date: Sat, 31 Dec 2016 06:49:59 +0000
Subject: [issue29059] Windows: Python not using ANSI compatible console
In-Reply-To: <1482543191.02.0.407458515739.issue29059@psf.upfronthosting.co.za>
Message-ID: <1483166999.73.0.0491340171329.issue29059@psf.upfronthosting.co.za>


Glenn Linderman added the comment:

Re: curses... maybe that becomes a DOCS issue, to mention the available packages. But it would be easier, no doubt to port curses to a known existing escape sequence control set, than to use a bunch arcane, foreign-to-the-Unix-porter-that-wants-curses obscure and seldom discussed Windows APIs.

IIRC, ANSI is somewhat incompatible with sending random binary gibberish to the screen, as people accidentally do with TYPE sometimes :) But the random binary gibberish may contain ANSI control sequences... That's why I'm negative on making it a default.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29059>
_______________________________________

From report at bugs.python.org  Sat Dec 31 01:54:11 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 31 Dec 2016 06:54:11 +0000
Subject: [issue29116] Make str and bytes error messages on concatenation
 conform with other sequences
In-Reply-To: <1483124211.75.0.715869443236.issue29116@psf.upfronthosting.co.za>
Message-ID: <1483167251.58.0.877408325538.issue29116@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Different cases accept different types. Not always we can say that only one specific type is accepted.

"list +" accepts only lists, "list +=" is a syntax sugar for list.extend and accepts any iterables. "bytes +" and "bytearray +=" accept any objects that support the buffer protocol. "array +" and "array +=" accept only arrays.

Changing semantic is out of the scope of this issue. I think there are reasons for current behavior.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29116>
_______________________________________

From report at bugs.python.org  Sat Dec 31 02:12:13 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 31 Dec 2016 07:12:13 +0000
Subject: [issue29110] [patch] Fix file object leak in `aifc.open` when given
 invalid AIFF file.
In-Reply-To: <1483059317.41.0.849254662988.issue29110@psf.upfronthosting.co.za>
Message-ID: <1483168333.56.0.417159540939.issue29110@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your patches Anthony. Could you please create a unittest for the first issue?

The second issue is well known. Since the behavior is documented, I think it can be changed only in Python 3.7. The patch needs the "versionchanged" directives in the documentation and documenting the change in What's New (in the section "Porting to Python 3.7" or like). This change can cause reference leaks in existing code.

This is not the only inconsistency between aifc and similar modules.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29110>
_______________________________________

From report at bugs.python.org  Sat Dec 31 02:15:34 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 31 Dec 2016 07:15:34 +0000
Subject: [issue29116] Make str and bytes error messages on concatenation
 conform with other sequences
In-Reply-To: <1483124211.75.0.715869443236.issue29116@psf.upfronthosting.co.za>
Message-ID: <1483168534.38.0.537773711574.issue29116@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Originally this issue was raised on StackOverflow:

http://stackoverflow.com/questions/41388606/python-3-6-vs-3-5-typeerror-message-on-string-concatenation

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29116>
_______________________________________

From report at bugs.python.org  Sat Dec 31 02:18:48 2016
From: report at bugs.python.org (Ma Lin)
Date: Sat, 31 Dec 2016 07:18:48 +0000
Subject: [issue28518] execute("begin immediate") throwing OperationalError
In-Reply-To: <1477307118.31.0.70785963389.issue28518@psf.upfronthosting.co.za>
Message-ID: <1483168728.41.0.424818234487.issue28518@psf.upfronthosting.co.za>


Ma Lin added the comment:

I have no idea about how to fix it, but I would like to suggest that add back this test which was removed in commit 284676cf2ac8 :

file: /Lib/sqlite3/test/transactions.py
def CheckVacuum(self):
    self.cur.execute("create table test(i)")
    self.cur.execute("insert into test(i) values (5)")
    self.cur.execute("vacuum")

Thank you for your efforts! regards.

----------
nosy: +Ma Lin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28518>
_______________________________________

From report at bugs.python.org  Sat Dec 31 02:25:08 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 31 Dec 2016 07:25:08 +0000
Subject: [issue29119] Unintentional hard reference assignment in Python
 version of OrderedDict.move_to_end
In-Reply-To: <1483164703.14.0.0947290095452.issue29119@psf.upfronthosting.co.za>
Message-ID: <1483169108.52.0.932806042766.issue29119@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


Added file: http://bugs.python.org/file46099/od_proxy2a.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29119>
_______________________________________

From report at bugs.python.org  Sat Dec 31 02:31:29 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 31 Dec 2016 07:31:29 +0000
Subject: [issue29102] Add an id field to PyInterpreterState.
In-Reply-To: <1482994422.5.0.64533163171.issue29102@psf.upfronthosting.co.za>
Message-ID: <1483169489.5.0.254646709236.issue29102@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Yeah, I'm also fine with using int_fast64_t for the subinterpreter count.

The only thing I'm really advocating for strongly on that front is that I think it makes sense to sacrifice the sign bit in the ID field as an error indicator that provides a more idiomatic C API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29102>
_______________________________________

From report at bugs.python.org  Sat Dec 31 02:33:17 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 31 Dec 2016 07:33:17 +0000
Subject: [issue29119] Unintentional hard reference assignment in Python
 version of OrderedDict.move_to_end
In-Reply-To: <1483164703.14.0.0947290095452.issue29119@psf.upfronthosting.co.za>
Message-ID: <1483169597.45.0.109575472644.issue29119@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I'm leaving this for Andra Bogildea to work through and comment on.  

Testing is likely to be awkward at best.  It would involve white box implementation specific steps like accessing the name managed variables and rotating through the doubly linked list to verify that all the prev-links have the type, <class 'weakproxy'>.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29119>
_______________________________________

From report at bugs.python.org  Sat Dec 31 02:58:21 2016
From: report at bugs.python.org (INADA Naoki)
Date: Sat, 31 Dec 2016 07:58:21 +0000
Subject: [issue29062] hashlib documentation link error
In-Reply-To: <1482571303.3.0.781602557285.issue29062@psf.upfronthosting.co.za>
Message-ID: <1483171101.65.0.377037384955.issue29062@psf.upfronthosting.co.za>


INADA Naoki added the comment:

May I commit merge-hashlib-blake2.patch to 3.6 branch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29062>
_______________________________________

From report at bugs.python.org  Sat Dec 31 03:00:04 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 31 Dec 2016 08:00:04 +0000
Subject: [issue29119] Unintentional hard reference assignment in Python
 version of OrderedDict.move_to_end
In-Reply-To: <1483164703.14.0.0947290095452.issue29119@psf.upfronthosting.co.za>
Message-ID: <1483171204.53.0.549229732199.issue29119@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

od_proxy2a.diff LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29119>
_______________________________________

From report at bugs.python.org  Sat Dec 31 03:02:24 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 31 Dec 2016 08:02:24 +0000
Subject: [issue29062] hashlib documentation link error
In-Reply-To: <1482571303.3.0.781602557285.issue29062@psf.upfronthosting.co.za>
Message-ID: <1483171344.38.0.354645384734.issue29062@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +martin.panter, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29062>
_______________________________________

From report at bugs.python.org  Sat Dec 31 03:11:55 2016
From: report at bugs.python.org (Eric Snow)
Date: Sat, 31 Dec 2016 08:11:55 +0000
Subject: [issue29102] Add an id field to PyInterpreterState.
In-Reply-To: <1482994422.5.0.64533163171.issue29102@psf.upfronthosting.co.za>
Message-ID: <1483171915.46.0.923601751307.issue29102@psf.upfronthosting.co.za>


Eric Snow added the comment:

int_fast64_t it is then. :)  I vacillated between the options and went with the bigger space.  However, you're right that following convention is worth it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29102>
_______________________________________

From report at bugs.python.org  Sat Dec 31 03:32:59 2016
From: report at bugs.python.org (patrila)
Date: Sat, 31 Dec 2016 08:32:59 +0000
Subject: [issue28815] test_socket fails if /proc/modules is existent but not
 readable
In-Reply-To: <1480263378.99.0.648069549511.issue28815@psf.upfronthosting.co.za>
Message-ID: <1483173179.49.0.771872823257.issue28815@psf.upfronthosting.co.za>


patrila added the comment:

@Martin Panter: Thanks for your support and merging.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28815>
_______________________________________

From report at bugs.python.org  Sat Dec 31 04:45:23 2016
From: report at bugs.python.org (Eric Snow)
Date: Sat, 31 Dec 2016 09:45:23 +0000
Subject: [issue29102] Add an id field to PyInterpreterState.
In-Reply-To: <1482994422.5.0.64533163171.issue29102@psf.upfronthosting.co.za>
Message-ID: <1483177523.65.0.247773045098.issue29102@psf.upfronthosting.co.za>


Eric Snow added the comment:

I've updated the patch to address Nick's review.  Thanks!

----------
Added file: http://bugs.python.org/file46100/interpreter-id-3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29102>
_______________________________________

From report at bugs.python.org  Sat Dec 31 06:06:12 2016
From: report at bugs.python.org (Evan)
Date: Sat, 31 Dec 2016 11:06:12 +0000
Subject: [issue29093] Windows launcher breaks history in Git Bash
In-Reply-To: <1482929297.98.0.0622229530904.issue29093@psf.upfronthosting.co.za>
Message-ID: <1483182372.05.0.341416917348.issue29093@psf.upfronthosting.co.za>


Evan added the comment:

This appears to be a bug with Git Bash, not Python or the launcher. Closing.

----------
resolution:  -> third party
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29093>
_______________________________________

From report at bugs.python.org  Sat Dec 31 06:07:48 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 31 Dec 2016 11:07:48 +0000
Subject: [issue29105] code or doc improvement for
 logging.handlers.RotatingFileHandler
In-Reply-To: <1483028994.58.0.687650973528.issue29105@psf.upfronthosting.co.za>
Message-ID: <20161231110743.25791.8083.F66F9A17@psf.io>


Roundup Robot added the comment:

New changeset 4255c7aae85b by Vinay Sajip in branch '3.6':
Closes #29105: Updated RotatingFileHandler documentation.
https://hg.python.org/cpython/rev/4255c7aae85b

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29105>
_______________________________________

From report at bugs.python.org  Sat Dec 31 06:36:34 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 31 Dec 2016 11:36:34 +0000
Subject: [issue29120] Rename Python/random.c to Python/bootstrap_hash.c
Message-ID: <1483184194.47.0.551318865872.issue29120@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

This is the last major structural refactoring proposal to come out of the prep work on the PEP 432 modular bootstrapping feature development branch: 

* rename Python/random.c -> Python/hash_randomization.c
* rename _PyRandom_Init -> __Py_HashRandomization_Init
* rename _PyRandom_Fini -> __Py_HashRandomization_Fini

The current naming is confusing when working on the interpreter startup sequence as the file and API naming looks like it relates to initialising the random module, when it has nothing to do with that.

----------
assignee: ncoghlan
messages: 284383
nosy: brett.cannon, christian.heimes, eric.snow, ncoghlan, steve.dower
priority: normal
severity: normal
stage: needs patch
status: open
title: Rename Python/random.c to Python/bootstrap_hash.c
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29120>
_______________________________________

From report at bugs.python.org  Sat Dec 31 06:40:21 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 31 Dec 2016 11:40:21 +0000
Subject: [issue28524] Set default argument of logging.disable() to
 logging.CRITICAL
In-Reply-To: <1477345510.5.0.68336976066.issue28524@psf.upfronthosting.co.za>
Message-ID: <20161231114017.124199.55927.2FDCEFA2@psf.io>


Roundup Robot added the comment:

New changeset 459500606560 by Vinay Sajip in branch 'default':
Closes #28524: added default level for logging.disable().
https://hg.python.org/cpython/rev/459500606560

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28524>
_______________________________________

From report at bugs.python.org  Sat Dec 31 06:46:34 2016
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 31 Dec 2016 11:46:34 +0000
Subject: [issue22490] Using realpath for __PYVENV_LAUNCHER__ makes Homebrew
 installs fragile
In-Reply-To: <1411623045.52.0.589017779939.issue22490@psf.upfronthosting.co.za>
Message-ID: <1483184794.09.0.687902624874.issue22490@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

> I tried making a Framework build of Python with the environment variable removed entirely, but I'm not experienced enough with builds on a Mac to know what I need to do to create a proper build.

Given Jason's comment above, it's probably best for one of the Mac-expert committers to remove the environment variable altogether from Mac/Tools/pythonw.c:main(), and confirm everything still builds and runs OK, and then for Tim to confirm that Homebrew isn't adversely impacted by the change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22490>
_______________________________________

From report at bugs.python.org  Sat Dec 31 06:48:59 2016
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 31 Dec 2016 11:48:59 +0000
Subject: [issue28443] Logger methods never use kwargs
In-Reply-To: <1476457754.13.0.399529764318.issue28443@psf.upfronthosting.co.za>
Message-ID: <1483184939.85.0.329544089767.issue28443@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

I'll close this - as indicated in my comment, there's no need for this enhancement, as the already available "extra" parameter performs the same function.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28443>
_______________________________________

From report at bugs.python.org  Sat Dec 31 06:50:30 2016
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 31 Dec 2016 11:50:30 +0000
Subject: [issue15452] Improve the security model for logging listener()
In-Reply-To: <1343264495.49.0.0195201203683.issue15452@psf.upfronthosting.co.za>
Message-ID: <1483185030.72.0.859396173302.issue15452@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15452>
_______________________________________

From report at bugs.python.org  Sat Dec 31 07:02:49 2016
From: report at bugs.python.org (Paul Moore)
Date: Sat, 31 Dec 2016 12:02:49 +0000
Subject: [issue29093] Windows launcher breaks history in Git Bash
In-Reply-To: <1482929297.98.0.0622229530904.issue29093@psf.upfronthosting.co.za>
Message-ID: <1483185769.06.0.397838864955.issue29093@psf.upfronthosting.co.za>


Paul Moore added the comment:

Thanks for letting us know

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29093>
_______________________________________

From report at bugs.python.org  Sat Dec 31 07:11:21 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 31 Dec 2016 12:11:21 +0000
Subject: [issue29120] Rename Python/random.c to Python/bootstrap_hash.c
In-Reply-To: <1483184194.47.0.551318865872.issue29120@psf.upfronthosting.co.za>
Message-ID: <1483186281.32.0.227627952288.issue29120@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is not just about the hash randomization. The file also contains implementations of _PyOS_URandom() and _PyOS_URandomNonblock().

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29120>
_______________________________________

From report at bugs.python.org  Sat Dec 31 07:20:26 2016
From: report at bugs.python.org (Andra Bogildea)
Date: Sat, 31 Dec 2016 12:20:26 +0000
Subject: [issue29119] Unintentional hard reference assignment in Python
 version of OrderedDict.move_to_end
In-Reply-To: <1483164703.14.0.0947290095452.issue29119@psf.upfronthosting.co.za>
Message-ID: <1483186826.62.0.140011263324.issue29119@psf.upfronthosting.co.za>


Andra Bogildea added the comment:

od_proxy.diff and od_proxy2a.diff are the same. Did you meant soft_link = proxy(link) in od_proxy2a.diff?

I believe Technique 1 (od_proxy.diff) is preferable, because it reuses the proxy object.

Regarding automated tests, I agree with what?s been said. The usage of weak references is an internal detail (and name mangling makes it even more inconvenient).

----------
nosy: +andrabogildea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29119>
_______________________________________

From report at bugs.python.org  Sat Dec 31 07:32:45 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 31 Dec 2016 12:32:45 +0000
Subject: [issue29120] Move hash randomisation initialisation out of
 Python/random.c
In-Reply-To: <1483184194.47.0.551318865872.issue29120@psf.upfronthosting.co.za>
Message-ID: <1483187565.05.0.473945430762.issue29120@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

You're right, I forgot about that part (I was mainly looking at the diffs today).

Spelling out the *problem*, rather than just jumping to a specific proposed solution, the confusing code layout we currently have is:

* Modules/_randommodule.c provides _random.Random
* Include/pylifecycle.c declares (amongst other things):
  * _PyRandom_Init
  * _PyRandom_Fini
  * _PyOS_URandom
  * _PyOS_URandomNonBlock
* Python/random.c implements all four of those APIs

I don't believe the latter two APIs existed back when I started the PEP 432 feature branch, which is why I had forgotten about them in this context.

Having the OS independent _PyOS_URandom APIs in a file called "Python/random.c" is reasonable, and there's even a legitimate connection to the random module there by way of random.SystemRandom.

So the only confusing aspect is also having the hash randomisation initialisation functions in there, rather than in their own file, with more appropriate API names.

----------
title: Rename Python/random.c to Python/bootstrap_hash.c -> Move hash randomisation initialisation out of Python/random.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29120>
_______________________________________

From report at bugs.python.org  Sat Dec 31 08:09:25 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 31 Dec 2016 13:09:25 +0000
Subject: [issue29120] Move hash randomisation initialisation out of
 Python/random.c
In-Reply-To: <1483184194.47.0.551318865872.issue29120@psf.upfronthosting.co.za>
Message-ID: <1483189765.9.0.152422739536.issue29120@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Actually _PyRandom_Fini() has a relation to _PyOS_URandom APIs. It releases resources acquired by _PyOS_URandom APIs. It shouldn't be renamed to _Py_HashRandomization_Fini.

_PyRandom_Init() just initializes _Py_HashSecret. But it can't be implemented via _PyOS_URandom APIs. It uses a static function from this file. If move it to other place, we should add new _PyOS_URandom API function. I don't think this would make the code cleaner.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29120>
_______________________________________

From report at bugs.python.org  Sat Dec 31 08:17:52 2016
From: report at bugs.python.org (Marcus)
Date: Sat, 31 Dec 2016 13:17:52 +0000
Subject: [issue28518] execute("begin immediate") throwing OperationalError
In-Reply-To: <1477307118.31.0.70785963389.issue28518@psf.upfronthosting.co.za>
Message-ID: <1483190272.42.0.178746764046.issue28518@psf.upfronthosting.co.za>


Changes by Marcus <marcus at callidomus.com>:


----------
nosy: +callidomus

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28518>
_______________________________________

From report at bugs.python.org  Sat Dec 31 09:29:36 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 31 Dec 2016 14:29:36 +0000
Subject: [issue28518] execute("begin immediate") throwing OperationalError
In-Reply-To: <1477307118.31.0.70785963389.issue28518@psf.upfronthosting.co.za>
Message-ID: <1483194576.09.0.367839305691.issue28518@psf.upfronthosting.co.za>


Berker Peksag added the comment:

I only did a quick review, but Aviv's latest patch looks reasonable to me. Thanks!

And yes, we can add CheckVacuum back if it's not already tested.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28518>
_______________________________________

From report at bugs.python.org  Sat Dec 31 09:43:26 2016
From: report at bugs.python.org (Evan)
Date: Sat, 31 Dec 2016 14:43:26 +0000
Subject: [issue29093] Windows launcher breaks history in Git Bash
In-Reply-To: <1482929297.98.0.0622229530904.issue29093@psf.upfronthosting.co.za>
Message-ID: <1483195406.09.0.837781505655.issue29093@psf.upfronthosting.co.za>


Evan added the comment:

No problem, thanks for your time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29093>
_______________________________________

From report at bugs.python.org  Sat Dec 31 09:51:04 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 31 Dec 2016 14:51:04 +0000
Subject: [issue29120] Move hash randomisation initialisation out of
 Python/random.c
In-Reply-To: <1483184194.47.0.551318865872.issue29120@psf.upfronthosting.co.za>
Message-ID: <1483195864.95.0.229614567712.issue29120@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29120>
_______________________________________

From report at bugs.python.org  Sat Dec 31 09:52:10 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 31 Dec 2016 14:52:10 +0000
Subject: [issue29120] Move hash randomisation initialisation out of
 Python/random.c
In-Reply-To: <1483184194.47.0.551318865872.issue29120@psf.upfronthosting.co.za>
Message-ID: <1483195930.46.0.14107706553.issue29120@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Nick: As Serhiy explained, IMHO you misunderstood _PyRandom_Init() and _PyRandom_Fini(), I suggest to close the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29120>
_______________________________________

From report at bugs.python.org  Sat Dec 31 10:09:58 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 31 Dec 2016 15:09:58 +0000
Subject: [issue29102] Add an id field to PyInterpreterState.
In-Reply-To: <1482994422.5.0.64533163171.issue29102@psf.upfronthosting.co.za>
Message-ID: <1483196998.93.0.79489010482.issue29102@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I would prefer to not use "fast" C types because they are not well supported. For example, ctypes has ctypes.c_int64 but no ctypes.c_int_fast64.

Previous work adding an unique identifier: PEP 509
https://www.python.org/dev/peps/pep-0509/#integer-overflow

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29102>
_______________________________________

From report at bugs.python.org  Sat Dec 31 11:04:55 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Sat, 31 Dec 2016 16:04:55 +0000
Subject: [issue29121] sqlite3 Controlling Transactions documentation not
 updated
Message-ID: <1483200295.1.0.801871810477.issue29121@psf.upfronthosting.co.za>


New submission from Aviv Palivoda:

commit 284676cf2ac8 changed the sqlite3 module so it will no longer implicitly commit an open transaction before DDL statements. The docs have been updated but there is still an incorrect paragraph that has not been removed. 
Attached is a patch that remove the old paragraph.

----------
files: sqlite-transaction-doc.patch
keywords: patch
messages: 284396
nosy: berker.peksag, ghaering, palaviv, serhiy.storchaka
priority: normal
severity: normal
status: open
title: sqlite3 Controlling Transactions documentation not updated
versions: Python 3.6, Python 3.7
Added file: http://bugs.python.org/file46101/sqlite-transaction-doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29121>
_______________________________________

From report at bugs.python.org  Sat Dec 31 11:08:18 2016
From: report at bugs.python.org (Aviv Palivoda)
Date: Sat, 31 Dec 2016 16:08:18 +0000
Subject: [issue28518] execute("begin immediate") throwing OperationalError
In-Reply-To: <1477307118.31.0.70785963389.issue28518@psf.upfronthosting.co.za>
Message-ID: <1483200498.48.0.959402604091.issue28518@psf.upfronthosting.co.za>


Aviv Palivoda added the comment:

Adding the vacuum test can't actually happen because the change in commit 284676cf2ac8 changed the API and we don't commit before non DML statements. I opened a issue that will clarify the docs (#29121).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28518>
_______________________________________

From report at bugs.python.org  Sat Dec 31 11:31:49 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Sat, 31 Dec 2016 16:31:49 +0000
Subject: [issue29082] In 2.7.13,
 _ctypes.LoadLibrary no longer accepts Unicode objects
In-Reply-To: <1482833341.48.0.70408057792.issue29082@psf.upfronthosting.co.za>
Message-ID: <1483201909.76.0.309030108185.issue29082@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

I finally get Windows builds working. Here's the patch.

----------
Added file: http://bugs.python.org/file46102/issue29082.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29082>
_______________________________________

From report at bugs.python.org  Sat Dec 31 11:32:09 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Sat, 31 Dec 2016 16:32:09 +0000
Subject: [issue29082] In 2.7.13,
 _ctypes.LoadLibrary no longer accepts Unicode objects
In-Reply-To: <1482833341.48.0.70408057792.issue29082@psf.upfronthosting.co.za>
Message-ID: <1483201929.19.0.53948270283.issue29082@psf.upfronthosting.co.za>


Changes by Chi Hsuan Yen <yan12125 at gmail.com>:


Removed file: http://bugs.python.org/file46055/LoadLibrary_revert_arg_parsing.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29082>
_______________________________________

From report at bugs.python.org  Sat Dec 31 11:35:28 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Sat, 31 Dec 2016 16:35:28 +0000
Subject: [issue29082] In 2.7.13,
 _ctypes.LoadLibrary no longer accepts Unicode objects
In-Reply-To: <1482833341.48.0.70408057792.issue29082@psf.upfronthosting.co.za>
Message-ID: <1483202128.3.0.171656369944.issue29082@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

Oops, Parser/asdl_c.py shouldn't be included. Here's the correct patch

----------
Added file: http://bugs.python.org/file46103/issue29082.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29082>
_______________________________________

From report at bugs.python.org  Sat Dec 31 12:06:59 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 31 Dec 2016 17:06:59 +0000
Subject: [issue26267] UUID docs should say how to get "standard form"
In-Reply-To: <1454438589.41.0.991764109365.issue26267@psf.upfronthosting.co.za>
Message-ID: <20161231170655.123564.75350.27A834C8@psf.io>


Roundup Robot added the comment:

New changeset 1a25c639f81e by Berker Peksag in branch '3.5':
Issue #26267: Improve uuid.UUID documentation
https://hg.python.org/cpython/rev/1a25c639f81e

New changeset c9e944cc6301 by Berker Peksag in branch '3.6':
Issue #26267: Merge from 3.5
https://hg.python.org/cpython/rev/c9e944cc6301

New changeset 8b19c2a1b197 by Berker Peksag in branch 'default':
Issue #26267: Merge from 3.6
https://hg.python.org/cpython/rev/8b19c2a1b197

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26267>
_______________________________________

From report at bugs.python.org  Sat Dec 31 12:07:33 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 31 Dec 2016 17:07:33 +0000
Subject: [issue26267] UUID docs should say how to get "standard form"
In-Reply-To: <1454438589.41.0.991764109365.issue26267@psf.upfronthosting.co.za>
Message-ID: <1483204053.61.0.0351452678717.issue26267@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks, Ammar.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26267>
_______________________________________

From report at bugs.python.org  Sat Dec 31 12:33:48 2016
From: report at bugs.python.org (styg)
Date: Sat, 31 Dec 2016 17:33:48 +0000
Subject: [issue29122] set() bug
Message-ID: <1483205628.15.0.98024774147.issue29122@psf.upfronthosting.co.za>


New submission from styg:

set() method leads to this error:
a=[1,2,3,3]
b=set(a)
print b
>> set([1,2,3]) # should be [1,2,3]

----------
messages: 284402
nosy: styg
priority: normal
severity: normal
status: open
title: set() bug
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29122>
_______________________________________

From report at bugs.python.org  Sat Dec 31 12:41:10 2016
From: report at bugs.python.org (Ammar Askar)
Date: Sat, 31 Dec 2016 17:41:10 +0000
Subject: [issue29122] set() bug
In-Reply-To: <1483205628.15.0.98024774147.issue29122@psf.upfronthosting.co.za>
Message-ID: <1483206070.8.0.237400397297.issue29122@psf.upfronthosting.co.za>


Ammar Askar added the comment:

Why would the expected output be [1, 2, 3]? That is the list notation for having a list that contains the elements 1, 2 and 3.

----------
nosy: +ammar2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29122>
_______________________________________

From report at bugs.python.org  Sat Dec 31 12:41:47 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 31 Dec 2016 17:41:47 +0000
Subject: [issue29123] CheckSqlTimestamp is fragile
Message-ID: <1483206107.71.0.541035804461.issue29123@psf.upfronthosting.co.za>


New submission from Berker Peksag:

======================================================================
FAIL: CheckSqlTimestamp (sqlite3.test.types.DateTimeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/root/buildarea/3.6.angelico-debian-amd64/build/Lib/sqlite3/test/types.py", line 391, in CheckSqlTimestamp
    self.assertEqual(ts.year, now.year)
AssertionError: 2016 != 2017

----------------------------------------------------------------------

See http://buildbot.python.org/all/builders/AMD64%20Debian%20root%203.6/builds/93/steps/test/logs/stdio for details.

In Lib/sqlite3/test/types.py, there is a comment saying

    # SQLite's current_timestamp uses UTC time, while datetime.datetime.now() uses local time.

Unless I'm missing something, there is no reason not to use datetime.utcnow(). That would make the test more robust.

----------
components: Tests
messages: 284404
nosy: berker.peksag
priority: normal
severity: normal
stage: needs patch
status: open
title: CheckSqlTimestamp is fragile
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29123>
_______________________________________

From report at bugs.python.org  Sat Dec 31 12:51:05 2016
From: report at bugs.python.org (Liran Ringel)
Date: Sat, 31 Dec 2016 17:51:05 +0000
Subject: [issue29124] Freeze fails to compile on windows
Message-ID: <1483206665.88.0.0421614971405.issue29124@psf.upfronthosting.co.za>


New submission from Liran Ringel:

The patch fixes 3 bugs:
1. Include Python.h in frozen_dllmain.c - needed for Py_ARRAY_LENGTH symbol
2. DL_IMPORT is used in checkextensions_win32.py, but it's deprecated and not defined anymore. Replaced it with __declspec(dllimport)
3. Fix python lib path in winmakemakefile.py

There is one more thing left to do to make it work, but it already has an open issue:
http://bugs.python.org/issue28068

----------
components: Demos and Tools, Windows
files: fix-freeze-on-windows.patch
keywords: patch
messages: 284405
nosy: Liran Ringel, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Freeze fails to compile on windows
type: compile error
versions: Python 3.5, Python 3.6, Python 3.7
Added file: http://bugs.python.org/file46104/fix-freeze-on-windows.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29124>
_______________________________________

From report at bugs.python.org  Sat Dec 31 13:34:56 2016
From: report at bugs.python.org (Eric Snow)
Date: Sat, 31 Dec 2016 18:34:56 +0000
Subject: [issue29102] Add an id field to PyInterpreterState.
In-Reply-To: <1482994422.5.0.64533163171.issue29102@psf.upfronthosting.co.za>
Message-ID: <1483209296.61.0.020791833935.issue29102@psf.upfronthosting.co.za>


Eric Snow added the comment:

Thanks for pointing that out, Victor.  Given the precedent I switched to using int64_t.  The patch actually uses PY_INT64_T, but I didn't see a reason to use int64_t directly.  FWIW, there *are* a few places that use int_fast64_t, but they are rather specialized and I didn't want this patch to be a place where I had to deal with setting a more general precedent. :)

----------
Added file: http://bugs.python.org/file46105/interpreter-id-4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29102>
_______________________________________

From report at bugs.python.org  Sat Dec 31 13:48:09 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 31 Dec 2016 18:48:09 +0000
Subject: [issue29122] set() bug
In-Reply-To: <1483205628.15.0.98024774147.issue29122@psf.upfronthosting.co.za>
Message-ID: <1483210089.73.0.641965318226.issue29122@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Sorry Styg, but this is the expected behavior.

To achieve what you wanted, write this is instead:

   print list(set(a))

----------
nosy: +rhettinger
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29122>
_______________________________________

From report at bugs.python.org  Sat Dec 31 14:00:30 2016
From: report at bugs.python.org (symphorien)
Date: Sat, 31 Dec 2016 19:00:30 +0000
Subject: [issue29125] Shell injection via TIX_LIBRARY when using tkinter.tix
Message-ID: <1483210830.52.0.920210756798.issue29125@psf.upfronthosting.co.za>


New submission from symphorien:

The tkinter.tix module looks for a Tix installation in the directory specified by the TIX_LIBRARY environment variable, but blindly trusts that it is a path in the filesystem. This enables a shell injection :

TIX_LIBRARY='/dev/null}; exec gsimplecal;' python2 -c "from Tix import Tk; Tk()"

or 

TIX_LIBRARY='/dev/null}; exec gsimplecal;' python3 -c "from tkinter.tix import Tk; Tk()"

Python execs gsimplecal, waits on its completion and then raises a tkinter.TclError.

The offending code is here : https://github.com/python/cpython/blob/master/Lib/tkinter/tix.py#L204-L208

----------
components: Tkinter
messages: 284408
nosy: symphorien
priority: normal
severity: normal
status: open
title: Shell injection via TIX_LIBRARY when using tkinter.tix
type: security
versions: Python 2.7, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29125>
_______________________________________

From report at bugs.python.org  Sat Dec 31 14:00:46 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 31 Dec 2016 19:00:46 +0000
Subject: [issue29120] Move hash randomisation initialisation out of
 Python/random.c
In-Reply-To: <1483184194.47.0.551318865872.issue29120@psf.upfronthosting.co.za>
Message-ID: <1483210846.06.0.877139547499.issue29120@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

FWIW, I concur with Nick's initial observation that the current "API naming looks like it relates to initialising the random module, when it has nothing to do with that."

It would be nice if Python/random.c were renamed to something else that indicated its relation to urandom and to hash secrets.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29120>
_______________________________________

From report at bugs.python.org  Sat Dec 31 14:03:28 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 31 Dec 2016 19:03:28 +0000
Subject: [issue29119] Unintentional hard reference assignment in Python
 version of OrderedDict.move_to_end
In-Reply-To: <1483164703.14.0.0947290095452.issue29119@psf.upfronthosting.co.za>
Message-ID: <20161231190325.124199.19147.15E2D98F@psf.io>


Roundup Robot added the comment:

New changeset 19376765d7c3 by Raymond Hettinger in branch '3.5':
Issue #29119: Fix weakref in OrderedDict.move_to_end(). Work by Andra Bogildea.
https://hg.python.org/cpython/rev/19376765d7c3

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29119>
_______________________________________

From report at bugs.python.org  Sat Dec 31 14:08:30 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 31 Dec 2016 19:08:30 +0000
Subject: [issue29119] Unintentional hard reference assignment in Python
 version of OrderedDict.move_to_end
In-Reply-To: <1483164703.14.0.0947290095452.issue29119@psf.upfronthosting.co.za>
Message-ID: <20161231190828.124023.60535.705AB115@psf.io>


Roundup Robot added the comment:

New changeset cd811b867393 by Raymond Hettinger in branch '3.6':
Issue #29119:  Merge in ACK from 3.5 branch
https://hg.python.org/cpython/rev/cd811b867393

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29119>
_______________________________________

From report at bugs.python.org  Sat Dec 31 14:09:38 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 31 Dec 2016 19:09:38 +0000
Subject: [issue29119] Unintentional hard reference assignment in Python
 version of OrderedDict.move_to_end
In-Reply-To: <1483164703.14.0.0947290095452.issue29119@psf.upfronthosting.co.za>
Message-ID: <1483211378.42.0.94428667251.issue29119@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Nice work Andra.  Thank you.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29119>
_______________________________________

From report at bugs.python.org  Sat Dec 31 14:47:39 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 31 Dec 2016 19:47:39 +0000
Subject: [issue29123] CheckSqlTimestamp is fragile
In-Reply-To: <1483206107.71.0.541035804461.issue29123@psf.upfronthosting.co.za>
Message-ID: <20161231194736.21314.5661.C2990C44@psf.io>


Roundup Robot added the comment:

New changeset bb64ae455490 by Berker Peksag in branch '3.5':
Issue #29123: Make CheckSqlTimestamp more robust
https://hg.python.org/cpython/rev/bb64ae455490

New changeset 0331420d6cba by Berker Peksag in branch '3.6':
Issue #29123: Merge from 3.5
https://hg.python.org/cpython/rev/0331420d6cba

New changeset ad06f9acff92 by Berker Peksag in branch 'default':
Issue #29123: Merge from 3.6
https://hg.python.org/cpython/rev/ad06f9acff92

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29123>
_______________________________________

From report at bugs.python.org  Sat Dec 31 14:48:10 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 31 Dec 2016 19:48:10 +0000
Subject: [issue29123] CheckSqlTimestamp is fragile
In-Reply-To: <1483206107.71.0.541035804461.issue29123@psf.upfronthosting.co.za>
Message-ID: <1483213690.13.0.975776708497.issue29123@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29123>
_______________________________________

From report at bugs.python.org  Sat Dec 31 16:20:41 2016
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 31 Dec 2016 21:20:41 +0000
Subject: [issue29093] Windows launcher breaks history in Git Bash
In-Reply-To: <1482929297.98.0.0622229530904.issue29093@psf.upfronthosting.co.za>
Message-ID: <1483219241.44.0.708936598715.issue29093@psf.upfronthosting.co.za>


Eryk Sun added the comment:

git-bash.exe runs bash.exe via cmd.exe, which means the console (conhost.exe) ends up with 5 attached processes:

    cmd.exe
        bash.exe
            bash.exe
                py.exe
                    python.exe

The default console configuration uses 4 history buffers, so by the time python.exe runs, they've all been used up. You can change this in the Alt+Space control menu's "Properties" dialog. This should modify the settings associated with cmd.exe, which are stored at "HKCU\Console\%SystemRoot%_system32_cmd.exe". In the upper right section increase the number of buffers to 32. You can also increase the size. I increase it to 500 commands. Start a new console via "Git Bash Here" to confirm that the new settings are remembered.  

Also modify the default configuration used for new programs, which is stored at "HKCU\Console". Back on the Alt+Space control menu, choose "Defaults" and similarly modify the size and number of buffers. 

Note that if you run a console program using a shortcut, such as the default "Command Prompt" shortcut, the console configuration is stored in the .LNK shortcut file instead of the registry.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29093>
_______________________________________

From report at bugs.python.org  Sat Dec 31 18:25:17 2016
From: report at bugs.python.org (Jim Nasby)
Date: Sat, 31 Dec 2016 23:25:17 +0000
Subject: [issue29126] Fix comments about _PyThreadState_Current
Message-ID: <1483226717.62.0.229510209962.issue29126@psf.upfronthosting.co.za>


New submission from Jim Nasby:

Attached patch fixes two comments in dictobject.c referring to no longer exposed _PyThreadState_Current variable. I also tweaked the grammar for that issue in NEWS, since it came up in my search. Apologies if that's considered gratuitous noise.

----------
components: Interpreter Core
files: _PyThreadState_Current_comments.diff
keywords: patch
messages: 284415
nosy: Jim Nasby
priority: normal
severity: normal
status: open
title: Fix comments about _PyThreadState_Current
type: enhancement
versions: Python 3.7
Added file: http://bugs.python.org/file46106/_PyThreadState_Current_comments.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29126>
_______________________________________

From report at bugs.python.org  Sat Dec 31 18:49:26 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 31 Dec 2016 23:49:26 +0000
Subject: [issue29123] CheckSqlTimestamp is fragile
In-Reply-To: <1483206107.71.0.541035804461.issue29123@psf.upfronthosting.co.za>
Message-ID: <20161231234923.28562.90754.6391902F@psf.io>


Roundup Robot added the comment:

New changeset 1d5b4426fe87 by Berker Peksag in branch '2.7':
Issue #29123: Make CheckSqlTimestamp more robust
https://hg.python.org/cpython/rev/1d5b4426fe87

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29123>
_______________________________________

From report at bugs.python.org  Sat Dec 31 19:00:51 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 01 Jan 2017 00:00:51 +0000
Subject: [issue29126] Fix comments about _PyThreadState_Current
In-Reply-To: <1483226717.62.0.229510209962.issue29126@psf.upfronthosting.co.za>
Message-ID: <1483228851.82.0.731884620848.issue29126@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29126>
_______________________________________

From report at bugs.python.org  Sat Dec 31 19:12:32 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 01 Jan 2017 00:12:32 +0000
Subject: [issue29120] Move hash randomisation initialisation out of
 Python/random.c
In-Reply-To: <1483210846.06.0.877139547499.issue29120@psf.upfronthosting.co.za>
Message-ID: <CADiSq7fhF5Cv6P0QO5NKCr1zOU3FWNKrM-k3FQhWwibpAOmxpw@mail.gmail.com>


Nick Coghlan added the comment:

On 1 Jan 2017 05:00, "Raymond Hettinger" <report at bugs.python.org> wrote:

It would be nice if Python/random.c were renamed to something else that
indicated its relation to urandom and to hash secrets.

Right, based on Victor & Serhiy's feedback, the split I would now propose
 is:

- Include/pyurandom.h and Python/pyurandom.c for the OS urandom APIs (with
related init/fini functions)
- Python/hash_randomization.c for the hash seeding functions  (while this
process *uses* pyurandom, it isn't part of *providing* that interface)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29120>
_______________________________________

From report at bugs.python.org  Sat Dec 31 21:44:14 2016
From: report at bugs.python.org (Eric Ahn)
Date: Sun, 01 Jan 2017 02:44:14 +0000
Subject: [issue29127] Incorrect reference names in asyncio.subprocess
 documentation
Message-ID: <1483238654.05.0.408550900872.issue29127@psf.upfronthosting.co.za>


New submission from Eric Ahn:

On this page of the documentation https://docs.python.org/3/library/asyncio-subprocess.html it seems that some of the reference names are incorrect.

Namely, asyncio.subprocess.PIPE is referred to as asyncio.asyncio.subprocess.PIPE (along with STDOUT and DEVNULL), plus asyncio.subprocess.Process is referred to as asyncio.asyncio.subprocess.Process.

This is reflected in the permalinks as well as when one tries to reference these via intersphinx (which is how I discovered it; I was trying to link to this page and was failing).

----------
assignee: docs at python
components: Documentation
messages: 284418
nosy: Eric Ahn, docs at python
priority: normal
severity: normal
status: open
title: Incorrect reference names in asyncio.subprocess documentation
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue29127>
_______________________________________

From report at bugs.python.org  Sat Dec 31 22:19:52 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 01 Jan 2017 03:19:52 +0000
Subject: [issue28911] Clarify the behaviour of assert_called_once_with
In-Reply-To: <1481233700.68.0.637550951007.issue28911@psf.upfronthosting.co.za>
Message-ID: <1483240792.44.0.987980243212.issue28911@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag, michael.foord -153957
stage:  -> patch review
type: enhancement -> behavior
versions:  -Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28911>
_______________________________________

From report at bugs.python.org  Sat Dec 31 22:28:55 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 01 Jan 2017 03:28:55 +0000
Subject: [issue28964] AST literal_eval exceptions provide no information about
 line number
In-Reply-To: <1481665664.26.0.256194535172.issue28964@psf.upfronthosting.co.za>
Message-ID: <1483241335.84.0.00758082091614.issue28964@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, Steve!.

This looks like a reasonable request to me, but 1) we can only make this change in 3.7 2) we need a test case for the new message 3) you can use f-strings instead of str.format()

----------
nosy: +berker.peksag
stage:  -> patch review
type: behavior -> enhancement
versions: +Python 3.7 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue28964>
_______________________________________