From report at bugs.python.org  Sun May  1 00:32:17 2016
From: report at bugs.python.org (Yclept Nemo)
Date: Sun, 01 May 2016 04:32:17 +0000
Subject: [New-bugs-announce] [issue26897] Clarify Popen stdin, stdout, stderr
Message-ID: <1462077137.11.0.0338937138998.issue26897@psf.upfronthosting.co.za>


New submission from Yclept Nemo:

From: https://docs.python.org/dev/library/subprocess.html#popen-constructor

"..., an existing file descriptor (a positive integer), an existing file object, and None."

It should be made clear that the file object must be backed by an operating system file, i.e. must have a valid file descriptor.

As it stands, the documentation suggests implicit concurrency: that any file object can be used, and on read/write from the subprocess/OS arbitrary python code will be executed, i.e. the python interpreter is pre-empted or python spawns a hidden I/O thread.

Anyway, I'm pretty sure subprocess.Popen() just redirects the forked process' stdout/stdin/stderr to the file descriptors from the provided file object.

----------
assignee: docs at python
components: Documentation
messages: 264579
nosy: Yclept.Nemo, docs at python
priority: normal
severity: normal
status: open
title: Clarify Popen stdin, stdout, stderr
versions: Python 3.6

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

From report at bugs.python.org  Sun May  1 04:06:17 2016
From: report at bugs.python.org (Marco Buttu)
Date: Sun, 01 May 2016 08:06:17 +0000
Subject: [New-bugs-announce] [issue26898] Error in the
Message-ID: <1462089977.93.0.233622268862.issue26898@psf.upfronthosting.co.za>


New submission from Marco Buttu:

The math.isclose() documentation reports is_close() as function name, instead of isclose(): 

  >>> import math
  >>> math.isclose.__doc__[:45]
  'is_close(a, b, *, rel_tol=1e-09, abs_tol=0.0)'

----------
assignee: docs at python
components: Documentation
files: isclose.patch
keywords: patch
messages: 264585
nosy: docs at python, marco.buttu
priority: normal
severity: normal
status: open
title: Error in the
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42669/isclose.patch

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

From report at bugs.python.org  Sun May  1 06:09:35 2016
From: report at bugs.python.org (Paul Sokolovsky)
Date: Sun, 01 May 2016 10:09:35 +0000
Subject: [New-bugs-announce] [issue26899] struct.pack_into(),
 struct.unpack_from() don't document support for negative offsets
Message-ID: <1462097375.63.0.546095370218.issue26899@psf.upfronthosting.co.za>


New submission from Paul Sokolovsky:

See
https://docs.python.org/3/library/struct.html#struct.pack_into
https://docs.python.org/3/library/struct.html#struct.unpack_from

Actual source contains code like:

    if (offset < 0)
        offset += vbuf.len;

to allow specify offsets from the end of a buffer.

----------
assignee: docs at python
components: Documentation
messages: 264590
nosy: docs at python, pfalcon
priority: normal
severity: normal
status: open
title: struct.pack_into(), struct.unpack_from() don't document support for negative offsets
versions: Python 3.6

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

From report at bugs.python.org  Sun May  1 06:17:53 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 May 2016 10:17:53 +0000
Subject: [New-bugs-announce] [issue26900] Exclude the private API from the
 stable API
Message-ID: <1462097873.28.0.0706601779139.issue26900@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch excludes the private API from the stable API. This includes:

_Py_Identifier-related API (other _Py_Identifier-related functions are already excluded):

struct _Py_Identifier;
#define _Py_static_string_init(value)
#define _Py_static_string(varname, value)
#define _Py_IDENTIFIER(varname)
PyAPI_FUNC(PyObject*) _PyUnicode_FromId(_Py_Identifier*);
PyAPI_FUNC(PyObject *) _PyObject_GetAttrId(PyObject *, struct _Py_Identifier *);
PyAPI_FUNC(int) _PyObject_SetAttrId(PyObject *, struct _Py_Identifier *, PyObject *);
PyAPI_FUNC(int) _PyObject_HasAttrId(PyObject *, struct _Py_Identifier *);
PyAPI_FUNC(PyObject *) _PyObject_CallMethodId(PyObject *o, _Py_Identifier *method, const char *format, ...);
PyAPI_FUNC(PyObject *) _PyObject_CallMethodId_SizeT(PyObject *o, _Py_Identifier *name, const char *format, ...);
PyAPI_FUNC(PyObject *) _PyObject_CallMethodIdObjArgs(PyObject *o, struct _Py_Identifier *method, ...);
PyAPI_FUNC(PyObject *) _PyDict_GetItemIdWithError(PyObject *dp, struct _Py_Identifier *key);
PyAPI_FUNC(PyObject *) _PyDict_GetItemId(PyObject *dp, struct _Py_Identifier *key);
PyAPI_FUNC(int) _PyDict_SetItemId(PyObject *dp, struct _Py_Identifier *key, PyObject *item);
PyAPI_FUNC(PyObject *) _PySys_GetObjectId(_Py_Identifier *key);

File helpers that hides OS-specific details and handle EINTR:

PyAPI_FUNC(PyObject *) _Py_device_encoding(int);
PyAPI_FUNC(FILE *) _Py_wfopen(const wchar_t *path, const wchar_t *mode);
PyAPI_FUNC(FILE*) _Py_fopen(const char *pathname, const char *mode);
PyAPI_FUNC(FILE*) _Py_fopen_obj(PyObject *path, const char *mode);
PyAPI_FUNC(Py_ssize_t) _Py_read(int fd, void *buf, size_t count);
PyAPI_FUNC(Py_ssize_t) _Py_write(int fd, const void *buf, size_t count);
PyAPI_FUNC(Py_ssize_t) _Py_write_noraise(int fd, const void *buf, size_t count);
PyAPI_FUNC(int) _Py_wreadlink(const wchar_t *path, wchar_t *buf, size_t bufsiz);
PyAPI_FUNC(wchar_t*) _Py_wrealpath(const wchar_t *path, wchar_t *resolved_path, size_t resolved_path_size);
PyAPI_FUNC(wchar_t*) _Py_wgetcwd(wchar_t *buf, size_t size);

Other OS functions:

PyAPI_FUNC(int) _PyOS_IsMainThread(void);
PyAPI_FUNC(void*) _PyOS_SigintEvent(void);
PyAPI_FUNC(int) _PyOS_GetOpt(int argc, wchar_t **argv, wchar_t *optstring);
PyAPI_FUNC(int) _PyOS_URandom(void *buffer, Py_ssize_t size);

Old helpers kept for binary compatibility of extensions built before 3.2.4:

PyAPI_FUNC(void) _PyTrash_deposit_object(PyObject*);
PyAPI_FUNC(void) _PyTrash_destroy_chain(void);
PyAPI_DATA(int) _PyTrash_delete_nesting;
PyAPI_DATA(PyObject *) _PyTrash_delete_later;

And other functions and data:

PyAPI_DATA(PyTypeObject) _PyNone_Type;
PyAPI_DATA(PyTypeObject) _PyNotImplemented_Type;
PyAPI_DATA(PyTypeObject) _PyMethodWrapper_Type;
PyAPI_DATA(int) _Py_SwappedOp[];

PyAPI_FUNC(Py_ssize_t) _Py_GetAllocatedBlocks(void);
PyAPI_FUNC(PyObject *) _PyObject_GC_Malloc(size_t size);
PyAPI_FUNC(PyObject *) _PyObject_GC_Calloc(size_t size);
PyAPI_FUNC(int) _PyObject_IsAbstract(PyObject *);

PyAPI_FUNC(PyObject*) _Py_strhex(const char* argbuf, const Py_ssize_t arglen);
PyAPI_FUNC(PyObject*) _Py_strhex_bytes(const char* argbuf, const Py_ssize_t arglen);

PyAPI_FUNC(void) _Py_add_one_to_index_F(int nd, Py_ssize_t *index, const Py_ssize_t *shape);
PyAPI_FUNC(void) _Py_add_one_to_index_C(int nd, Py_ssize_t *index, const Py_ssize_t *shape);

PyAPI_DATA(PyTypeObject) _PyNamespace_Type;
PyAPI_FUNC(PyObject *) _PyNamespace_New(PyObject *kwds);

PyAPI_FUNC(int) _PyOS_IsMainThread(void);
PyAPI_FUNC(void*) _PyOS_SigintEvent(void);
PyAPI_FUNC(int) _PyOS_GetOpt(int argc, wchar_t **argv, wchar_t *optstring);
PyAPI_FUNC(int) _PyOS_URandom(void *buffer, Py_ssize_t size);

PyAPI_FUNC(int) _PyState_AddModule(PyObject*, struct PyModuleDef*);
PyAPI_FUNC(PyThreadState *) _PyThreadState_Prealloc(PyInterpreterState *);
PyAPI_FUNC(void) _PyThreadState_Init(PyThreadState *);
PyAPI_FUNC(void) _PyThreadState_DeleteExcept(PyThreadState *tstate);
PyAPI_FUNC(void) _PyGILState_Reinit(void);
PyAPI_FUNC(PyThreadState *) _PyThreadState_UncheckedGet(void);

PyAPI_FUNC(void) _PyUnicode_ClearStaticStrings(void);
PyAPI_FUNC(int) _PyUnicode_EQ(PyObject *, PyObject *);

PyAPI_FUNC(void) _Py_DumpTraceback(int fd, PyThreadState *tstate);
PyAPI_FUNC(const char*) _Py_DumpTracebackThreads(int fd, PyInterpreterState *interp, PyThreadState *current_tstate);

PyAPI_FUNC(void) _PyImportZip_Init(void);

PyAPI_FUNC(PyObject *) _PyLong_GCD(PyObject *, PyObject *);

All these names are not documented (except _PyObject_GC_Calloc accidentally mentioned in What's New in 3.5) and are not used implicitly in macros (except _PyObject_CallMethodId_SizeT used in _PyObject_CallMethodId).

Many of these functions were added after implementing PEP 384 and changed its signature during its lifetime. They are not explicitly exclude from the stable API only by accident.

----------
components: Interpreter Core
files: private_limited_api.diff
keywords: patch
messages: 264591
nosy: haypo, loewis, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Exclude the private API from the stable API
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42670/private_limited_api.diff

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

From report at bugs.python.org  Sun May  1 09:20:07 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 May 2016 13:20:07 +0000
Subject: [New-bugs-announce] [issue26901] Argument Clinic test is broken
Message-ID: <1462108807.42.0.528462387786.issue26901@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

$ ./python Tools/clinic/clinic_test.py
Error:
Destination does not exist: 'file'

It works in 3.4.

----------
components: Argument Clinic, Tests
messages: 264595
nosy: larry, serhiy.storchaka
priority: high
severity: normal
status: open
title: Argument Clinic test is broken
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun May  1 14:45:28 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 May 2016 18:45:28 +0000
Subject: [New-bugs-announce] [issue26902] Argument Clinic incorrectly work
 with custom converter and renamed parameter
Message-ID: <1462128328.67.0.613776590116.issue26902@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Argument Clinic uses original name of Python parameter in generated code for custom (format code "O&") converter even if the parameter was renamed.

Example:

/*[clinic input]
test
    filename as path: object(converter="PyUnicode_FSConverter")
    /
[clinic start generated code]*/

Generated code:

static PyObject *
test(PyModuleDef *module, PyObject *arg)
{
    PyObject *return_value = NULL;
    PyObject *path;

    if (!PyUnicode_FSConverter(arg, &filename))
        goto exit;
    return_value = test_impl(module, path);

exit:
    return return_value;
}

----------
components: Argument Clinic
messages: 264606
nosy: larry, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Argument Clinic incorrectly work with custom converter and renamed parameter
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun May  1 16:45:38 2016
From: report at bugs.python.org (Diogo Pereira)
Date: Sun, 01 May 2016 20:45:38 +0000
Subject: [New-bugs-announce] [issue26903]
 ProcessPoolExecutor(max_workers=64) crashes on Windows
Message-ID: <1462135538.41.0.857077084248.issue26903@psf.upfronthosting.co.za>


New submission from Diogo Pereira:

I'm using Python 3.5.1 x86-64 on Windows Server 2008 R2. Trying to run the ProcessPoolExecutor example [1] generates this exception:

Exception in thread Thread-1:
Traceback (most recent call last):
  File "C:\Program Files\Python35\lib\threading.py", line 914, in _bootstrap_inner
    self.run()
  File "C:\Program Files\Python35\lib\threading.py", line 862, in run
    self._target(*self._args, **self._kwargs)
  File "C:\Program Files\Python35\lib\concurrent\futures\process.py", line 270, in _queue_management_worker
    ready = wait([reader] + sentinels)
  File "C:\Program Files\Python35\lib\multiprocessing\connection.py", line 859, in wait
    ready_handles = _exhaustive_wait(waithandle_to_obj.keys(), timeout)
  File "C:\Program Files\Python35\lib\multiprocessing\connection.py", line 791, in _exhaustive_wait
    res = _winapi.WaitForMultipleObjects(L, False, timeout)
ValueError: need at most 63 handles, got a sequence of length 64


The problem seems to be related to the value of the Windows constant MAXIMUM_WAIT_OBJECTS (see [2]), which is 64. This machine has 64 logical cores, so ProcessPoolExecutor defaults to 64 workers.

Lowering max_workers to 63 or 62 still results in the same exception, but max_workers=61 works fine.


[1] https://docs.python.org/3.5/library/concurrent.futures.html#processpoolexecutor-example
[2] https://hg.python.org/cpython/file/80d1faa9735d/Modules/_winapi.c#l1339

----------
components: Windows
messages: 264608
nosy: diogocp, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: ProcessPoolExecutor(max_workers=64) crashes on Windows
versions: Python 3.5

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

From report at bugs.python.org  Mon May  2 00:29:13 2016
From: report at bugs.python.org (Michael Cuthbert)
Date: Mon, 02 May 2016 04:29:13 +0000
Subject: [New-bugs-announce] [issue26904] Difflib quick_ratio() could use
 Counter()
Message-ID: <1462163353.47.0.300392305122.issue26904@psf.upfronthosting.co.za>


New submission from Michael Cuthbert:

The implementation used in difflib.SequenceMatcher().quick_ratio() counts how often each member of the sequence (character, list entry, etc.) appears in order to calculate its lower bound.

Counting how often an entry appears in an iterable has been sped up in cPython w/ the _count_elements() c function in _collections.

This patch uses the collections uses collections.Counter() as a way of getting this speedup (and any future speedups in cPython or other implementations); code is somewhat simplified also.

Performance:
There is a slight overhead to creating two collections.Counter() objects rather than simple dicts.  On two Mac systems (Python 3.5 on stock Macbook Air, and Py 3.6a0 latest on recent Mac Pro) the new implementation passes the speed of the previous when the length of the iterable is around 60 items.  As the number of items increases, the performance gains increase significantly. By 400 items, the new implementation's speed is about 3x the old, and seems to approach 3.6x asymptotically.

Below 60 items, the older implementation is faster; reaching a max of 8x the speed of the new when comparing a string of one element against a string of one element.  (The degenerate case of comparing one or two empty iterables is checked for in this implementation and is thus faster than the old implementation). I believe that users using quick_ratio() are more likely to be looking for speed improvements on larger 

Like the previous implementation, the count of the items in seq2 (self.b) is cached; if run again, it is about 41% faster (compared to 47% faster before).

This is my first patch submission, so any suggestions would be appreciated.

----------
components: Library (Lib)
files: difflib_quick_ratio.patch
keywords: patch
messages: 264618
nosy: Michael Cuthbert
priority: normal
severity: normal
status: open
title: Difflib quick_ratio() could use Counter()
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file42676/difflib_quick_ratio.patch

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

From report at bugs.python.org  Mon May  2 05:48:14 2016
From: report at bugs.python.org (yangming)
Date: Mon, 02 May 2016 09:48:14 +0000
Subject: [New-bugs-announce] [issue26905] from multiprocessing.pool import
 Pool bug on linux
Message-ID: <1462182494.66.0.452090779121.issue26905@psf.upfronthosting.co.za>


New submission from yangming:

When my code run on windows,it's right,but on linux,id(q) print same RAM address.

----------
components: Argument Clinic
files: pool.py
messages: 264637
nosy: 859911096, larry
priority: normal
severity: normal
status: open
title: from multiprocessing.pool import Pool bug on linux
versions: Python 2.7
Added file: http://bugs.python.org/file42680/pool.py

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

From report at bugs.python.org  Mon May  2 09:03:48 2016
From: report at bugs.python.org (Antti Haapala)
Date: Mon, 02 May 2016 13:03:48 +0000
Subject: [New-bugs-announce] [issue26906] __reduce__ format
Message-ID: <1462194228.9.0.692226837642.issue26906@psf.upfronthosting.co.za>


Changes by Antti Haapala <antti at haapala.name>:


----------
nosy: ztane
priority: normal
severity: normal
status: open
title: __reduce__ format
versions: Python 2.7

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

From report at bugs.python.org  Mon May  2 10:29:23 2016
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 02 May 2016 14:29:23 +0000
Subject: [New-bugs-announce] [issue26907] Add missing getsockopt constants
Message-ID: <1462199363.91.0.625327027717.issue26907@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The socket doesn't expose some constants for getsockopt() and setsockopt():

Get domain and protocol from socket fd
SO_DOMAIN
SO_PROTOCOL

enable/disable passing of credentials
SO_PASSCRED

get security context (SELinux context)
SO_PEERSEC

enable/disable passing of security context
SO_PASSSEC

----------
assignee: christian.heimes
messages: 264649
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: Add missing getsockopt constants
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Mon May  2 12:59:43 2016
From: report at bugs.python.org (Vladimir Rutsky)
Date: Mon, 02 May 2016 16:59:43 +0000
Subject: [New-bugs-announce] [issue26908] "1and 0" evaluated a zero,
 instead of SyntaxError
Message-ID: <1462208383.05.0.60534121789.issue26908@psf.upfronthosting.co.za>


New submission from Vladimir Rutsky:

Looks like there is no need to place space separators after numbers:

$ python3.5 -c "print(1and 0)"
0
$ python3.5 -c "print([1for i in range(1)])"
[1]

Not sure is this a bug or a feature, but I would expect that this should be SyntaxError, same as here:

$ python3.5 -c "1 and0"
  File "<string>", line 1
    1 and0
         ^
SyntaxError: invalid syntax

If this is a feature, can anyone give reasoning for it?

----------
messages: 264654
nosy: rutsky
priority: normal
severity: normal
status: open
title: "1and 0" evaluated a zero, instead of SyntaxError
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Mon May  2 13:06:33 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Mon, 02 May 2016 17:06:33 +0000
Subject: [New-bugs-announce] [issue26909] Serious performance loss (10
 times) when NOT using .drain()
Message-ID: <1462208793.52.0.483694752489.issue26909@psf.upfronthosting.co.za>


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

https://github.com/python/asyncio/issues/338

(example of program shows bug resides on github)

----------
components: asyncio
messages: 264655
nosy: gvanrossum, haypo, mmarkk, yselivanov
priority: normal
severity: normal
status: open
title: Serious performance loss (10 times) when NOT using .drain()
type: performance
versions: Python 3.5

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

From report at bugs.python.org  Mon May  2 13:50:17 2016
From: report at bugs.python.org (Luigi Semenzato)
Date: Mon, 02 May 2016 17:50:17 +0000
Subject: [New-bugs-announce] [issue26910] dictionary literal should not
 allow duplicate keys
Message-ID: <1462211417.21.0.537077061483.issue26910@psf.upfronthosting.co.za>


New submission from Luigi Semenzato:

This was already discussed and rejected at https://bugs.python.org/issue16385.  I am reopening because I am not convinced that the discussion presented all arguments properly.

The original problem description:

lives_in = { 'lion': ['Africa', 'America],
             'parrot': ['Europe'],
             #... 100+ more rows here
             'lion': ['Europe'],
             #... 100+ more rows here
           }

The above constructor overwrites the 'lion' entry silently, often causing unexpected behavior.

These are the arguments presented in favor of the rejection, followed by my rebuttals.

1. "An error is out of the question for compatibility reasons".  No real rebuttal here, except I wonder if exceptions are ever made and under what circumstances.  I should point out that a warning may also create incompatibilities.

2. "There are ways to rewrite this as a loop on a list".  Yes of course, but the entire point of the dictionary literal is to offer a concise and convenient notation for entering a dictionary as program text.

3. "Being able to re-write keys is fundamental to Python dicts and why they can be used for Python's mutable namespaces".  This is fine but it applies to the data structure, not the literal constructor.

4. "A code generator could depend on being able to write duplicate keys without having to go back and erase previous output".  Yes, but it seems wrong to facilitate automated code generation at the expense of human code writing.  For hand-written code, I claim that in most (all?) cases it would be preferable to have the compiler detect key duplications.  It is easier for an automated code generator to check for duplications than it is for a human.

5. "There is already pylint".  True, but it forces an additional step, and seems like a cop-out for not wanting to do the "right thing" in the language.

For context, someone ran into this problem in my team at Google.  We fixed it using pylint, but I really don't see the point of having these constructor semantics.  From the discussions I have seen, it seems just an oversight in the implementation/specification of dictionary literals (search keywords: dict constructor, dict literal).  I'd be happy to hear stronger reasoning in favor of the status quo.

----------
components: Interpreter Core
messages: 264657
nosy: Luigi Semenzato
priority: normal
severity: normal
status: open
title: dictionary literal should not allow duplicate keys
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon May  2 15:45:26 2016
From: report at bugs.python.org (Ivan Zakhryaschev)
Date: Mon, 02 May 2016 19:45:26 +0000
Subject: [New-bugs-announce] [issue26911]
 lib2to3/tests/pytree_idempotency.py has a broken import
Message-ID: <1462218326.23.0.838867840781.issue26911@psf.upfronthosting.co.za>


New submission from Ivan Zakhryaschev:

Line 21 of lib2to3/tests/pytree_idempotency.py:

import pgen2

This seems to be broken, because it should be:

import lib2to3.pgen2

(This makes the auto-requirements generator in ALT Sisyphus to generate a broken/unsatisfiable dependency on pgen2 when packaging this into an RPM.)

All other uses of pgen2 in Python 3.5.1 sources use other forms of import: either relative or the absolute one as I suggest:

$ git grep -F pgen2
lib2to3/btm_matcher.py:        # from .pgen2 import token // token.__dict__.items():
lib2to3/btm_utils.py:from .pgen2 import grammar, token
lib2to3/fixer_util.py:from .pgen2 import token
lib2to3/fixes/fix_apply.py:from ..pgen2 import token
lib2to3/fixes/fix_dict.py:from ..pgen2 import token
lib2to3/fixes/fix_except.py:from ..pgen2 import token
lib2to3/fixes/fix_filter.py:from ..pgen2 import token
lib2to3/fixes/fix_has_key.py:from ..pgen2 import token
lib2to3/fixes/fix_map.py:from ..pgen2 import token
lib2to3/fixes/fix_ne.py:from ..pgen2 import token
lib2to3/fixes/fix_next.py:from ..pgen2 import token
lib2to3/fixes/fix_numliterals.py:from ..pgen2 import token
lib2to3/fixes/fix_print.py:from ..pgen2 import token
lib2to3/fixes/fix_raise.py:from ..pgen2 import token
lib2to3/fixes/fix_throw.py:from ..pgen2 import token
lib2to3/fixes/fix_tuple_params.py:from ..pgen2 import token
lib2to3/fixes/fix_types.py:from ..pgen2 import token
lib2to3/fixes/fix_unicode.py:from ..pgen2 import token
lib2to3/fixes/fix_ws_comma.py:from ..pgen2 import token
lib2to3/patcomp.py:from .pgen2 import driver, literals, token, tokenize, parse, grammar
lib2to3/pgen2/__init__.py:"""The pgen2 package."""
lib2to3/pgen2/conv.py:from pgen2 import grammar, token
lib2to3/pgen2/token.py:#   originally monkeypatched in by pgen2.tokenize
lib2to3/pgen2/tokenize.py:from lib2to3.pgen2.token import *
lib2to3/pygram.py:from .pgen2 import token
lib2to3/pygram.py:from .pgen2 import driver
lib2to3/pytree.py:        # from .pgen2 import token // token.__dict__.items():
lib2to3/refactor.py:from .pgen2 import driver, tokenize, token
lib2to3/tests/pytree_idempotency.py:import pgen2
lib2to3/tests/pytree_idempotency.py:from pgen2 import driver
lib2to3/tests/pytree_idempotency.py:            except pgen2.parse.ParseError as err:
lib2to3/tests/support.py:from lib2to3.pgen2 import driver
lib2to3/tests/test_parser.py:from lib2to3.pgen2 import tokenize
lib2to3/tests/test_parser.py:from ..pgen2.parse import ParseError
lib2to3/tests/test_refactor.py:from lib2to3.pgen2 import token
lib2to3/tests/test_util.py:from lib2to3.pgen2 import token

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 264663
nosy: imz
priority: normal
severity: normal
status: open
title: lib2to3/tests/pytree_idempotency.py has a broken import
type: compile error
versions: Python 3.5

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

From report at bugs.python.org  Mon May  2 16:44:13 2016
From: report at bugs.python.org (Ivan Zakharyaschev)
Date: Mon, 02 May 2016 20:44:13 +0000
Subject: [New-bugs-announce] [issue26912] test/test_email/torture_test.py
 (and test_asian_codecs.py) has a broken import
Message-ID: <1462221853.95.0.795708912177.issue26912@psf.upfronthosting.co.za>


New submission from Ivan Zakharyaschev:

(An issue similar to http://bugs.python.org/issue26911 , but with a different source file from the tests)

Lib/test/test_email/torture_test.py:15:from email.test.test_email import TestEmailBase

should be:

from test.test_email import TestEmailBase

because the first variant has a non-existing path.

(This makes the auto-requirements generator in ALT Sisyphus to generate a broken/unsatisfiable dependency on email.test.test_email when building the package from http://git.altlinux.org/people/imz/packages/python3.git .)

Similarly,

Lib/test/test_email/test_asian_codecs.py:8:from test.test_email.test_email import TestEmailBase

should better not have an extra "test_email" component in the path.

All other imports of test_email in Python 3.5.1 sources are of the form I'm suggesting:

$ git --no-pager grep -Fn .test_email
Lib/test/test_email/__init__.py:9:from test.test_email import __file__ as landmark
Lib/test/test_email/__main__.py:1:from test.test_email import load_tests
Lib/test/test_email/test__encoded_words.py:4:from test.test_email import TestEmailBase
Lib/test/test_email/test__header_value_parser.py:6:from test.test_email import TestEmailBase, parameterize
Lib/test/test_email/test_asian_codecs.py:8:from test.test_email.test_email import TestEmailBase
Lib/test/test_email/test_contentmanager.py:2:from test.test_email import TestEmailBase, parameterize
Lib/test/test_email/test_defect_handling.py:6:from test.test_email import TestEmailBase
Lib/test/test_email/test_email.py:42:from test.test_email import openfile, TestEmailBase
Lib/test/test_email/test_generator.py:8:from test.test_email import TestEmailBase, parameterize
Lib/test/test_email/test_headerregistry.py:8:from test.test_email import TestEmailBase, parameterize
Lib/test/test_email/test_inversion.py:11:from test.test_email import TestEmailBase, parameterize
Lib/test/test_email/test_message.py:5:from test.test_email import TestEmailBase, parameterize
Lib/test/test_email/test_parser.py:5:from test.test_email import TestEmailBase
Lib/test/test_email/test_pickleable.py:9:from test.test_email import TestEmailBase, parameterize
Lib/test/test_email/torture_test.py:15:from email.test.test_email import TestEmailBase
Misc/HISTORY:1733:- Issue #8315: (partial fix) python -m unittest test.test_email now works.

BTW, I'm not sure these two files are used anywhere, because grep gives no results for their names.

----------
components: Tests
messages: 264667
nosy: imz
priority: normal
severity: normal
status: open
title: test/test_email/torture_test.py (and test_asian_codecs.py) has a broken import
type: compile error
versions: Python 3.5

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

From report at bugs.python.org  Mon May  2 16:59:11 2016
From: report at bugs.python.org (Peter Norvig)
Date: Mon, 02 May 2016 20:59:11 +0000
Subject: [New-bugs-announce] [issue26913] statistics.mean of bools
Message-ID: <1462222751.06.0.733276334894.issue26913@psf.upfronthosting.co.za>


New submission from Peter Norvig:

mean([True, True, True, False]) should be 0.75, but it returns 0.25.

The fix is to change _sum so that when the type is bool, the result should be coerced to int, not bool.

Why it is important for statistics.mean to work with bools:
It is natural to say something like
    mean(x > threshold for x in data)
and expect to get the percentage of items in data that are above threshold.

----------
components: Library (Lib)
messages: 264670
nosy: Peter.Norvig
priority: normal
severity: normal
status: open
title: statistics.mean of bools
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon May  2 18:57:24 2016
From: report at bugs.python.org (Ned Batchelder)
Date: Mon, 02 May 2016 22:57:24 +0000
Subject: [New-bugs-announce] [issue26914] Fix formatting of lists in PEP 420
Message-ID: <1462229844.3.0.0802177041097.issue26914@psf.upfronthosting.co.za>


New submission from Ned Batchelder:

The numbered and bulletted lists are indented from the body text, which looks good in the .rst, but causes the lists themselves to be blockquotes.  This leads to confusing formatting on python.org: https://www.python.org/dev/peps/pep-0420/

BTW: this formatting error is rampant among the PEPs... :(

----------
assignee: docs at python
components: Documentation
files: pep-0420.patch
keywords: patch
messages: 264677
nosy: docs at python, nedbat
priority: normal
severity: normal
status: open
title: Fix formatting of lists in PEP 420
Added file: http://bugs.python.org/file42686/pep-0420.patch

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

From report at bugs.python.org  Tue May  3 02:19:16 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 03 May 2016 06:19:16 +0000
Subject: [New-bugs-announce] [issue26915] Test identity first in membership
 operation of ItemsView, ValuesView and Sequence in collections.abc
Message-ID: <1462256356.96.0.954300432794.issue26915@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

__contains__ operation in ItemsView, ValuesView and Sequence in collections.abc simply test equality with ==. This introduces inconsistent behaviour with built-in containers when encountering objects like NaN, which does not equal to itself. I asked something about this on core-mentorship, see https://mail.python.org/mailman/private/core-mentorship/2016-April/003543.html.

----------
components: Library (Lib)
messages: 264688
nosy: xiang.zhang
priority: normal
severity: normal
status: open
title: Test identity first in membership operation of ItemsView, ValuesView and Sequence in collections.abc
versions: Python 3.6

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

From report at bugs.python.org  Tue May  3 04:36:45 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 May 2016 08:36:45 +0000
Subject: [New-bugs-announce] [issue26916] Word duplications in PEPs
Message-ID: <1462264605.88.0.73387048167.issue26916@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch fixes typos in PEPs that cause words duplications.

----------
assignee: docs at python
components: Documentation
files: pep_duplicates.patch
keywords: patch
messages: 264695
nosy: docs at python, martin.panter, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Word duplications in PEPs
Added file: http://bugs.python.org/file42689/pep_duplicates.patch

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

From report at bugs.python.org  Tue May  3 04:48:27 2016
From: report at bugs.python.org (Armin Rigo)
Date: Tue, 03 May 2016 08:48:27 +0000
Subject: [New-bugs-announce] [issue26917] Inconsistency in
 unicodedata.normalize()?
Message-ID: <1462265307.72.0.382714967199.issue26917@psf.upfronthosting.co.za>


New submission from Armin Rigo:

There is an apparent inconsistency in unicodedata.normalize("NFC"), introduced with the switch from the Unicode DB 5.1.0 to 5.2.0 (in Python 2.7).  First, please note that my knowledge of unicode is limited, so I may be wrong and the following behavior might be perfectly correct.

>>> from unicodedata import normalize
>>> print(normalize("NFC", "---\uafb8\u11a7---").encode('utf-8'))
b'---\xea\xbe\xb8\xe1\x86\xa7---'    # i.e., the same as the input

>>> print(normalize("NFC", "---\uafb8\u11a7---\U0002f8a1").encode('utf-8'))
b'---\xea\xbe\xb8---\xe3\xa4\xba'

Note how in the second example the initial two-character part is replaced with a single character (actually the first of them).  This does not occur in the first example.  In Python 2.6, both inputs would be normalized to the single-character output.

The new behavior introduced in Python 2.7 is to first do a quick-check on the string, and if this `is_normalized()` function returns 1, we know that the string should already be normalized and we return it unmodified.  However, the example "\uafb8\u11a7" shows a contradictory behavior: it causes both is_normalized() to return 1, but actual normalization to change it.  We can see in the second example above that if, for an unrelated reason, we force is_normalized() to return 0 (by adding some non-normalized character elsewhere in the string), then the "\uafb8\u11a7" is changed.

This is a bit unexpected, but I don't know if it is officially correct behavior or if the problem is a bug in `is_normalized()`.

----------
components: Unicode
messages: 264697
nosy: arigo, ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: Inconsistency in unicodedata.normalize()?
type: behavior
versions: Python 2.7, Python 3.6

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

From report at bugs.python.org  Tue May  3 05:13:44 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 03 May 2016 09:13:44 +0000
Subject: [New-bugs-announce] [issue26918] android: test_pipes fails
Message-ID: <1462266824.98.0.209704046857.issue26918@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

test_pipes fails on an android emulator running an x86 system image at API level 21.


root at generic_x86:/data/local/tmp # python -m test -v test_pipes
== CPython 3.6.0a0 (default:f4c6dab59cd8+, May 3 2016, 10:42:45) [GCC 4.9 20140827 (prerelease)]
==   Linux-3.4.67+-i686-with-libc little-endian
==   hash algorithm: fnv 32bit
==   /data/local/tmp/test_python_1927
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_randomiza
tion=1, isolated=0)
Run tests sequentially
0:00:00 [1/1] test_pipes
testBadAppendOptions (test.test_pipes.SimplePipeTests) ... ok
testBadOpenMode (test.test_pipes.SimplePipeTests) ... ok
testBadPrependOptions (test.test_pipes.SimplePipeTests) ... ok
testClone (test.test_pipes.SimplePipeTests) ... ok
testEmptyPipeline1 (test.test_pipes.SimplePipeTests) ... ok
testEmptyPipeline2 (test.test_pipes.SimplePipeTests) ... ok
testEmptyPipeline3 (test.test_pipes.SimplePipeTests) ... ok
testReadOpenSink (test.test_pipes.SimplePipeTests) ... ok
testRepr (test.test_pipes.SimplePipeTests) ... ok
testSetDebug (test.test_pipes.SimplePipeTests) ... ok
testSimplePipe1 (test.test_pipes.SimplePipeTests) ... /system/bin/sh: tr: not found
FAIL
testSimplePipe2 (test.test_pipes.SimplePipeTests) ... sh: tr: not found
FAIL
testSimplePipe3 (test.test_pipes.SimplePipeTests) ... /system/bin/sh: tr: not found
FAIL
testWriteOpenSource (test.test_pipes.SimplePipeTests) ... ok

======================================================================
FAIL: testSimplePipe1 (test.test_pipes.SimplePipeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/test_pipes.py", line 27, in testSimplePipe1
    self.assertEqual(f.read(), 'HELLO WORLD #1')
AssertionError: '' != 'HELLO WORLD #1'
+ HELLO WORLD #1

======================================================================
FAIL: testSimplePipe2 (test.test_pipes.SimplePipeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/test_pipes.py", line 36, in testSimplePipe2
    self.assertEqual(f.read(), 'HELLO WORLD #2')
AssertionError: '' != 'HELLO WORLD #2'
+ HELLO WORLD #2

======================================================================
FAIL: testSimplePipe3 (test.test_pipes.SimplePipeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/test_pipes.py", line 45, in testSimplePipe3
    self.assertEqual(f.read(), 'HELLO WORLD #2')
AssertionError: '' != 'HELLO WORLD #2'
+ HELLO WORLD #2

----------------------------------------------------------------------
Ran 14 tests in 0.039s

FAILED (failures=3)
test test_pipes failed
1 test failed:
    test_pipes
Total duration: 0:00:01

----------
components: Cross-Build, Library (Lib)
messages: 264702
nosy: Alex.Willmer, xdegaye
priority: normal
severity: normal
status: open
title: android: test_pipes fails
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Tue May  3 05:18:35 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 03 May 2016 09:18:35 +0000
Subject: [New-bugs-announce] [issue26919] android: test_cmd_line fails
Message-ID: <1462267115.39.0.594600458307.issue26919@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

test_cmd_line fails on an android emulator running an x86 system image at API level 21.


======================================================================
FAIL: test_non_ascii (test.test_cmd_line.CmdLineTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/test_cmd_line.py", line 141, in test_non_ascii
    assert_python_ok('-c', command)
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/support/script_helper.py", line 135, in assert_python_ok
    return _assert_python(True, *args, **env_vars)
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/support/script_helper.py", line 121, in _assert_python
    err))
AssertionError: Process return code is 1
command line: ['/data/local/tmp/python/bin/python', '-X', 'faulthandler', '-I', '-c', "assert(ord('\xe6') == 230)"]

stdout:
---

---

stderr:
---
Unable to decode the command from the command line:
UnicodeEncodeError: 'utf-8' codec can't encode characters in position 12-13: surrogates not allowed
---

----------------------------------------------------------------------
Ran 33 tests in 1.943s

FAILED (failures=1, skipped=1)
test test_cmd_line failed
1 test failed:
    test_cmd_line
Total duration: 0:00:03

----------
components: Cross-Build, Library (Lib)
messages: 264703
nosy: Alex.Willmer, xdegaye
priority: normal
severity: normal
status: open
title: android: test_cmd_line fails
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Tue May  3 05:26:22 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 03 May 2016 09:26:22 +0000
Subject: [New-bugs-announce] [issue26920] android: test_sys fails
Message-ID: <1462267582.58.0.744255750518.issue26920@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

test_sys fails on an android emulator running an x86 system image at API level 21.

...
test_implementation (test.test_sys.SysModuleTest) ... ok
test_intern (test.test_sys.SysModuleTest) ... ok
test_ioencoding (test.test_sys.SysModuleTest) ... ok
test_ioencoding_nonascii (test.test_sys.SysModuleTest) ... Traceback (most recent call last):
  File "<string>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode character '\xe6' in position 0: ordinal not in range(
128)
FAIL
test_is_finalizing (test.test_sys.SysModuleTest) ... ok
test_lost_displayhook (test.test_sys.SysModuleTest) ... ok
...
======================================================================
FAIL: test_c_locale_surrogateescape (test.test_sys.SysModuleTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/test_sys.py", line 709, in test_c_locale_surr
ogateescape
    'stdin: surrogateescape\n'
AssertionError: 'stdin: strict\nstdout: strict\nstderr: backslashreplace\n' != 'stdin: surrogateesca
pe\nstdout: surrogateescape\nstderr: backslashreplace\n'
- stdin: strict
- stdout: strict
+ stdin: surrogateescape
+ stdout: surrogateescape
  stderr: backslashreplace


======================================================================
FAIL: test_ioencoding_nonascii (test.test_sys.SysModuleTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/test_sys.py", line 638, in test_ioencoding_no
nascii
    self.assertEqual(out, os.fsencode(test.support.FS_NONASCII))
AssertionError: b'' != b'\xc3\xa6'

----------------------------------------------------------------------
Ran 43 tests in 0.913s

FAILED (failures=2, skipped=2)
test test_sys failed
1 test failed:
    test_sys
Total duration: 0:00:01

----------
components: Cross-Build, Extension Modules
messages: 264705
nosy: Alex.Willmer, lemburg, loewis, xdegaye
priority: normal
severity: normal
status: open
title: android: test_sys fails
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Tue May  3 06:22:18 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 May 2016 10:22:18 +0000
Subject: [New-bugs-announce] [issue26921] Incorrect usage of a/an articles
 in PEPs
Message-ID: <1462270938.38.0.294058819503.issue26921@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch fixes the usage of a/an articles in PEPs.

----------
assignee: docs at python
components: Documentation
files: pep_articles.patch
keywords: patch
messages: 264710
nosy: docs at python, georg.brandl, martin.panter, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Incorrect usage of a/an articles in PEPs
Added file: http://bugs.python.org/file42693/pep_articles.patch

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

From report at bugs.python.org  Tue May  3 08:20:34 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 May 2016 12:20:34 +0000
Subject: [New-bugs-announce] [issue26922] build from fresh checkout fails
Message-ID: <1462278034.88.0.00181655793676.issue26922@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Building from a fresh checkout with "./configure" followed by "make -j4" fails here:

$ make -j4
[... snip ...]
./python -E -S -m sysconfig --generate-posix-vars ;\
if test $? -ne 0 ; then \
	echo "generate-posix-vars failed" ; \
	rm -f ./pybuilddir.txt ; \
	exit 1 ; \
fi
Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Fatal Python error: Py_Initialize: Unable to get the locale encoding
ImportError: No module named 'encodings'

Current thread 0x00007fa1b6f48700 (most recent call first):
Aborted
generate-posix-vars failed
Makefile:598: recipe for target 'pybuilddir.txt' failed
make: *** [pybuilddir.txt] Error 1

----------
components: Build
messages: 264717
nosy: pitrou
priority: normal
severity: normal
status: open
title: build from fresh checkout fails
type: compile error
versions: Python 3.6

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

From report at bugs.python.org  Tue May  3 08:50:06 2016
From: report at bugs.python.org (Johannes Ebke)
Date: Tue, 03 May 2016 12:50:06 +0000
Subject: [New-bugs-announce] [issue26923] asyncio.gather drops cancellation
Message-ID: <1462279806.1.0.880381545595.issue26923@psf.upfronthosting.co.za>


New submission from Johannes Ebke:

In a very specific case, asyncio.gather causes a cancel() call on the Task waiting on the _GatheringFuture to return a false positive. An example program demonstrating this is attached.

The context: asyncio.gather creates a _GatheringFuture with a list of child Futures. Each child Future carries a done callback that updates the _GatheringFuture, and once the last child done callback is executed, the _GatheringFuture sets its result.

The specific situation: When the last child future changes state to done it schedules its done callbacks, but does not immediately execute them. If the Task waiting on the gather is then cancelled before the last child done callback has run, the cancel method in asyncio/tasks.py:578 determines that the _GatheringFuture inspects itself and sees that it is not done() yet, and proceeds to cancel all child futures - which has no effect, since all of them are already done(). It still returns True, so the Tasks thinks all is well, and proceeds with its execution.

The behaviour I would expect is that if cancel() is called on the _GatheringFuture, and all children return False on cancel(), then _GatheringFuture.cancel() should also return False, i.e.:

def cancel(self):
    if self.done():
        return False
    at_least_one_child_cancelled = False
    for child in self._children:
        if child.cancel():
            at_least_one_child_cancelled = True
    return at_least_one_child_cancelled

If I replace _GatheringFuture.cancel with the above variant, the bug disappears for me.

More context: We hit this bug sporadically in an integration test of aioredis, where some timings conspired to make it appear with a chance of about 1 in 10. The minimal example calls the cancellation in a done_callback, so that it always hits the window. This was not the way the bug was discovered.

----------
components: asyncio
files: cancellation_test.py
messages: 264719
nosy: JohannesEbke, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.gather drops cancellation
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file42694/cancellation_test.py

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

From report at bugs.python.org  Tue May  3 09:37:56 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 03 May 2016 13:37:56 +0000
Subject: [New-bugs-announce] [issue26924] android: test_concurrent_futures
 fails
Message-ID: <1462282676.16.0.612748828.issue26924@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

test_concurrent_futures fails on an android emulator running an x86 system image at API level 21.

There are multiple ERRORs, all resulting in the same traceback:

Traceback (most recent call last):
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/test_concurrent_futures.py", line 68, in setU
p
    self.executor = self.executor_type(max_workers=self.worker_count)
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/concurrent/futures/process.py", line 390, in __init__
    EXTRA_QUEUED_CALLS)
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/multiprocessing/context.py", line 101, in Queue
    return Queue(maxsize, ctx=self.get_context())
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/multiprocessing/queues.py", line 42, in __init__
    self._rlock = ctx.Lock()
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/multiprocessing/context.py", line 66, in Lock
    return Lock(ctx=self.get_context())
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/multiprocessing/synchronize.py", line 163, in __in
it__
    SemLock.__init__(self, SEMAPHORE, 1, 1, ctx=ctx)
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/multiprocessing/synchronize.py", line 60, in __ini
t__
    unlink_now)
OSError: [Errno 38] Function not implemented

The ERRORs:
===========

test_duplicate_futures (test.test_concurrent_futures.ProcessPoolAsCompletedTests) ... ERROR
test_no_timeout (test.test_concurrent_futures.ProcessPoolAsCompletedTests) ... ERROR
test_zero_timeout (test.test_concurrent_futures.ProcessPoolAsCompletedTests) ... ERROR
test_killed_child (test.test_concurrent_futures.ProcessPoolExecutorTest) ... ERROR
test_map (test.test_concurrent_futures.ProcessPoolExecutorTest) ... ERROR
test_map_chunksize (test.test_concurrent_futures.ProcessPoolExecutorTest) ... ERROR
test_map_exception (test.test_concurrent_futures.ProcessPoolExecutorTest) ... ERROR
test_map_timeout (test.test_concurrent_futures.ProcessPoolExecutorTest) ... ERROR
test_max_workers_negative (test.test_concurrent_futures.ProcessPoolExecutorTest) ... ERROR
test_no_stale_references (test.test_concurrent_futures.ProcessPoolExecutorTest) ... ERROR
test_shutdown_race_issue12456 (test.test_concurrent_futures.ProcessPoolExecutorTest) ... ERROR
test_submit (test.test_concurrent_futures.ProcessPoolExecutorTest) ... ERROR
test_submit_keyword (test.test_concurrent_futures.ProcessPoolExecutorTest) ... ERROR
test_traceback (test.test_concurrent_futures.ProcessPoolExecutorTest) ... ERROR
test_context_manager_shutdown (test.test_concurrent_futures.ProcessPoolShutdownTest) ... ERROR
test_del_shutdown (test.test_concurrent_futures.ProcessPoolShutdownTest) ... ERROR
test_hang_issue12364 (test.test_concurrent_futures.ProcessPoolShutdownTest) ... ERROR
test_interpreter_shutdown (test.test_concurrent_futures.ProcessPoolShutdownTest) ... ERROR
test_processes_terminate (test.test_concurrent_futures.ProcessPoolShutdownTest) ... ERROR
test_run_after_shutdown (test.test_concurrent_futures.ProcessPoolShutdownTest) ... ERROR
test_all_completed (test.test_concurrent_futures.ProcessPoolWaitTests) ... ERROR
test_first_completed (test.test_concurrent_futures.ProcessPoolWaitTests) ... ERROR
test_first_completed_some_already_completed (test.test_concurrent_futures.ProcessPoolWaitTests) ...  ERROR
test_first_exception (test.test_concurrent_futures.ProcessPoolWaitTests) ... ERROR
test_first_exception_one_already_failed (test.test_concurrent_futures.ProcessPoolWaitTests) ... ERROR
test_first_exception_some_already_complete (test.test_concurrent_futures.ProcessPoolWaitTests) ... ERROR
test_timeout (test.test_concurrent_futures.ProcessPoolWaitTests) ... ERROR

----------
components: Cross-Build, Library (Lib)
messages: 264721
nosy: Alex.Willmer, bquinlan, xdegaye
priority: normal
severity: normal
status: open
title: android: test_concurrent_futures fails
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Tue May  3 09:46:52 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 03 May 2016 13:46:52 +0000
Subject: [New-bugs-announce] [issue26925] android:
 test_multiprocessing_main_handling fails
Message-ID: <1462283212.06.0.365791110432.issue26925@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

All the tests of test_multiprocessing_main_handling fail on an android emulator running an x86 system image at API level 21.
See the attached test_output.txt file.

----------
components: Cross-Build, Library (Lib)
files: test_output.txt
messages: 264723
nosy: Alex.Willmer, jnoller, sbt, xdegaye
priority: normal
severity: normal
status: open
title: android: test_multiprocessing_main_handling fails
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file42695/test_output.txt

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

From report at bugs.python.org  Tue May  3 09:55:37 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 03 May 2016 13:55:37 +0000
Subject: [New-bugs-announce] [issue26926] android: test_io fails
Message-ID: <1462283737.14.0.888848894928.issue26926@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

test_io fails on an android emulator running an x86 system image at API level 21.

======================================================================
ERROR: test_large_file_ops (test.test_io.CIOTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/test_io.py", line 537, in test_large_file_ops
    self.large_file_ops(f)
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/test_io.py", line 330, in large_file_ops
    self.assertEqual(f.seek(self.LARGE), self.LARGE)
OverflowError: Python int too large to convert to C long

======================================================================
ERROR: test_large_file_ops (test.test_io.PyIOTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/test_io.py", line 537, in test_large_file_ops
    self.large_file_ops(f)
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/test_io.py", line 330, in large_file_ops
    self.assertEqual(f.seek(self.LARGE), self.LARGE)
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/_pyio.py", line 1632, in seek
    return os.lseek(self._fd, pos, whence)
OverflowError: Python int too large to convert to C long

----------------------------------------------------------------------
Ran 541 tests in 32.829s

FAILED (errors=2, skipped=8)
test test_io failed
test_io took 33 sec
1 test failed:
    test_io
Total duration: 0:00:33

----------
components: Cross-Build, Library (Lib)
messages: 264725
nosy: Alex.Willmer, benjamin.peterson, stutzbach, xdegaye
priority: normal
severity: normal
status: open
title: android: test_io fails
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Tue May  3 10:00:33 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 03 May 2016 14:00:33 +0000
Subject: [New-bugs-announce] [issue26927] android: test_mmap fails
Message-ID: <1462284033.57.0.466364918672.issue26927@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

test_mmap fails on an android emulator running an x86 system image at API level 21.

======================================================================
ERROR: test_large_filesize (test.test_mmap.LargeMmapTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/test_mmap.py", line 755, in test_large_filesize
    with self._make_test_file(0x17FFFFFFF, b" ") as f:
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/test_mmap.py", line 738, in _make_test_file
    f.seek(num_zeroes)
ValueError: cannot fit 'int' into an offset-sized integer

======================================================================
ERROR: test_large_offset (test.test_mmap.LargeMmapTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/test_mmap.py", line 750, in test_large_offset
    with self._make_test_file(0x14FFFFFFF, b" ") as f:
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/test_mmap.py", line 738, in _make_test_file
    f.seek(num_zeroes)
ValueError: cannot fit 'int' into an offset-sized integer

----------------------------------------------------------------------
Ran 35 tests in 0.134s

FAILED (errors=2, skipped=6)
test test_mmap failed
1 test failed:
    test_mmap
Total duration: 0:00:01

----------
components: Cross-Build, Library (Lib)
messages: 264726
nosy: Alex.Willmer, twouters, xdegaye
priority: normal
severity: normal
status: open
title: android: test_mmap fails
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Tue May  3 10:06:05 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 03 May 2016 14:06:05 +0000
Subject: [New-bugs-announce] [issue26928] android: test_site fails
Message-ID: <1462284365.5.0.819379627022.issue26928@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

One test of test_site fails on an android emulator running an x86 system image at API level 21.

See the attached test_output.txt file.

----------
components: Cross-Build, Library (Lib)
files: test_output.txt
messages: 264728
nosy: Alex.Willmer, xdegaye
priority: normal
severity: normal
status: open
title: android: test_site fails
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file42696/test_output.txt

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

From report at bugs.python.org  Tue May  3 10:11:51 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 03 May 2016 14:11:51 +0000
Subject: [New-bugs-announce] [issue26929] android: test_strptime fails
Message-ID: <1462284711.76.0.324696843297.issue26929@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

test_strptime fails on an android emulator running an x86 system image at API level 21.

See the attached test_output.txt file.

----------
components: Cross-Build, Library (Lib)
files: test_output.txt
messages: 264729
nosy: Alex.Willmer, belopolsky, lemburg, xdegaye
priority: normal
severity: normal
status: open
title: android: test_strptime fails
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file42697/test_output.txt

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

From report at bugs.python.org  Tue May  3 10:19:34 2016
From: report at bugs.python.org (Alex Gaynor)
Date: Tue, 03 May 2016 14:19:34 +0000
Subject: [New-bugs-announce] [issue26930] Upgrade installers to OpenSSL
 1.0.2h
Message-ID: <1462285174.78.0.332365810571.issue26930@psf.upfronthosting.co.za>


New submission from Alex Gaynor:

https://www.openssl.org/news/secadv/20160503.txt

----------
keywords: security_issue
messages: 264731
nosy: alex, ned.deily, paul.moore, ronaldoussoren, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Upgrade installers to OpenSSL 1.0.2h

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

From report at bugs.python.org  Tue May  3 10:25:01 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 03 May 2016 14:25:01 +0000
Subject: [New-bugs-announce] [issue26931] android: test_distutils fails
Message-ID: <1462285501.44.0.0195995288955.issue26931@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

test_distutils fails on an android emulator running an x86 system image at API level 21.

See the attached test_output.txt file.

Some of these failed tests could be skipped, supposing that native compilation of extension modules on android itself (as opposed to using cross-compilation) is not supported.

----------
components: Cross-Build, Library (Lib)
files: test_output.txt
messages: 264732
nosy: Alex.Willmer, dstufft, eric.araujo, xdegaye
priority: normal
severity: normal
status: open
title: android: test_distutils fails
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file42698/test_output.txt

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

From report at bugs.python.org  Tue May  3 10:44:04 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 03 May 2016 14:44:04 +0000
Subject: [New-bugs-announce] [issue26932] android: test_posix fails
Message-ID: <1462286644.76.0.342167409924.issue26932@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

test_posix fails on an android emulator running an x86 system image at API level 21.

For the first ERROR, on android we have instead of a list of group IDs:
root at generic_x86:/data/local/tmp # id -G
uid=0(root) gid=0(root) groups=1003(graphics),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats) context=u:r:su:s0


======================================================================
ERROR: test_getgroups (test.test_posix.PosixTester)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/test_posix.py", line 815, in test_getgroups
    set([int(x) for x in groups.split()]),
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/test_posix.py", line 815, in <listcomp>
    set([int(x) for x in groups.split()]),
ValueError: invalid literal for int() with base 10: 'uid=0(root)'

======================================================================
ERROR: test_rtld_constants (test.test_posix.PosixTester)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/test_posix.py", line 1128, in test_rtld_constants
    posix.RTLD_LAZY
AttributeError: module 'posix' has no attribute 'RTLD_LAZY'

----------------------------------------------------------------------
Ran 83 tests in 0.114s

FAILED (errors=2, skipped=11)
test test_posix failed
1 test failed:
    test_posix
Total duration: 0:00:01

----------
components: Cross-Build, Library (Lib)
messages: 264733
nosy: Alex.Willmer, larry, xdegaye
priority: normal
severity: normal
status: open
title: android: test_posix fails
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Tue May  3 10:50:47 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 03 May 2016 14:50:47 +0000
Subject: [New-bugs-announce] [issue26933] android: test_posixpath fails
Message-ID: <1462287047.8.0.736502543167.issue26933@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

test_posixpath fails on an android emulator running an x86 system image at API level 21.

On android we have:
root at generic_x86:/data/local/tmp # python
Python 3.6.0a0 (default:f4c6dab59cd8+, May  3 2016, 10:42:45) 
[GCC 4.9 20140827 (prerelease)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import posixpath, pwd, os
>>> posixpath.expanduser("~")
'/data'
>>> pwd.getpwuid(os.getuid()).pw_dir
'/'
>>>


Test results:

======================================================================
FAIL: test_expanduser (test.test_posixpath.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/test_posixpath.py", line 247, in test_expanduser
    self.assertEqual(posixpath.expanduser("~"), home.rstrip("/"))
AssertionError: '/' != ''
- /
+ 


----------------------------------------------------------------------
Ran 54 tests in 0.046s

FAILED (failures=1)
test test_posixpath failed
1 test failed:
    test_posixpath
Total duration: 0:00:01

----------
components: Cross-Build, Library (Lib)
messages: 264734
nosy: Alex.Willmer, larry, xdegaye
priority: normal
severity: normal
status: open
title: android: test_posixpath fails
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Tue May  3 10:58:24 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 03 May 2016 14:58:24 +0000
Subject: [New-bugs-announce] [issue26934] android: test_faulthandler fails
Message-ID: <1462287504.69.0.311102051296.issue26934@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

test_faulthandler fails on an android emulator running an x86 system image at API level 21.

See the attached test_output.txt file.

----------
components: Cross-Build, Library (Lib)
files: test_output.txt
messages: 264735
nosy: Alex.Willmer, haypo, xdegaye
priority: normal
severity: normal
status: open
title: android: test_faulthandler fails
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file42699/test_output.txt

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

From report at bugs.python.org  Tue May  3 11:03:20 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 03 May 2016 15:03:20 +0000
Subject: [New-bugs-announce] [issue26935] android: test_os fails
Message-ID: <1462287800.22.0.0769666286965.issue26935@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

One test of test_os fails on an android emulator running an x86 system image at API level 21.

See the attached test_output.txt file.

----------
components: Cross-Build, Library (Lib)
files: test_output.txt
messages: 264736
nosy: Alex.Willmer, loewis, xdegaye
priority: normal
severity: normal
status: open
title: android: test_os fails
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file42700/test_output.txt

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

From report at bugs.python.org  Tue May  3 11:10:46 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 03 May 2016 15:10:46 +0000
Subject: [New-bugs-announce] [issue26936] android: test_socket fails
Message-ID: <1462288246.37.0.495121419926.issue26936@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

test_socket fails on an android emulator running an x86 system image at API level 21.


======================================================================
ERROR: testGetServBy (test.test_socket.GeneralModuleTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/test_socket.py", line 913, in testGetServBy
    port2 = socket.getservbyname(service)
OSError: service/proto not found

======================================================================
ERROR: testGetaddrinfo (test.test_socket.GeneralModuleTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/test_socket.py", line 1240, in testGetaddrinfo
    socket.getaddrinfo(HOST, "http")
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/socket.py", line 732, in getaddrinfo
    for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
socket.gaierror: [Errno 9] servname not supported for ai_socktype

----------------------------------------------------------------------
Ran 530 tests in 26.702s

FAILED (errors=2, skipped=75)
test test_socket failed
1 test failed:
    test_socket
Total duration: 0:00:27

----------
components: Cross-Build, Library (Lib)
messages: 264737
nosy: Alex.Willmer, xdegaye
priority: normal
severity: normal
status: open
title: android: test_socket fails
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Tue May  3 11:14:27 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 03 May 2016 15:14:27 +0000
Subject: [New-bugs-announce] [issue26937] android: test_tarfile fails
Message-ID: <1462288467.92.0.772791237683.issue26937@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

test_tarfile fails on an android emulator running an x86 system image at API level 21.


======================================================================                      [0/9481]
FAIL: test_extract_with_numeric_owner (test.test_tarfile.NumericOwnerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/unittest/mock.py", line 1175, in patched
    return func(*args, **keywargs)
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/test_tarfile.py", line 2483, in test_extract_
with_numeric_owner
    any_order=True)
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/unittest/mock.py", line 856, in assert_has_calls
    ) from cause
AssertionError: (call('/data/local/tmp/test_python_2938/@test_2938_tmp-tardir/numeric-owner-testfile
', 99, 98), call('/data/local/tmp/test_python_2938/@test_2938_tmp-tardir/dir/numeric-owner-testfile'
, 88, 87)) not all found in call list

======================================================================
FAIL: test_extractall_with_numeric_owner (test.test_tarfile.NumericOwnerTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/unittest/mock.py", line 1175, in patched
    return func(*args, **keywargs)
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/test_tarfile.py", line 2503, in test_extracta
ll_with_numeric_owner
    any_order=True)
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/unittest/mock.py", line 856, in assert_has_calls
    ) from cause
AssertionError: (call('/data/local/tmp/test_python_2938/@test_2938_tmp-tardir/numeric-owner-testfile
', 99, 98), call('/data/local/tmp/test_python_2938/@test_2938_tmp-tardir/dir', 77, 76), call('/data/
local/tmp/test_python_2938/@test_2938_tmp-tardir/dir/numeric-owner-testfile', 88, 87)) not all found
 in call list

----------------------------------------------------------------------
Ran 426 tests in 5.549s

FAILED (failures=2, skipped=80)
test test_tarfile failed
1 test failed:
    test_tarfile
Total duration: 0:00:06

----------
components: Cross-Build, Library (Lib)
messages: 264738
nosy: Alex.Willmer, lars.gustaebel, xdegaye
priority: normal
severity: normal
status: open
title: android: test_tarfile fails
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Tue May  3 11:32:10 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 03 May 2016 15:32:10 +0000
Subject: [New-bugs-announce] [issue26938] android: test_concurrent_futures
 hangs on armv7
Message-ID: <1462289530.91.0.204802241019.issue26938@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

test_concurrent_futures hangs on an android emulator running an armv7 system image (but not on x86) at API level 21. The test suite hangs at:

test_pending_calls_race (test.test_concurrent_futures.ThreadPoolWaitTests) ...

A cause of this problem may be related to the fact that the android arm emulator runs very, very slowly.

----------
components: Cross-Build, Library (Lib)
messages: 264740
nosy: Alex.Willmer, bquinlan, xdegaye
priority: normal
severity: normal
status: open
title: android: test_concurrent_futures hangs on armv7
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Tue May  3 11:37:46 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 03 May 2016 15:37:46 +0000
Subject: [New-bugs-announce] [issue26939] android: test_functools hangs on
 armv7
Message-ID: <1462289866.52.0.349587333392.issue26939@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

test_functools hangs on an android emulator running an armv7 system image (but not on x86) at API level 21. The test suite hangs at

test_lru_cache_threaded (test.test_functools.TestLRUC) ...

A cause of this problem may be related to the fact that the android arm emulator runs very, very slowly.

----------
components: Cross-Build, Library (Lib)
messages: 264742
nosy: Alex.Willmer, ncoghlan, rhettinger, xdegaye
priority: normal
severity: normal
status: open
title: android: test_functools hangs on armv7
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Tue May  3 11:42:14 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 03 May 2016 15:42:14 +0000
Subject: [New-bugs-announce] [issue26940] android: test_importlib hangs on
 armv7
Message-ID: <1462290134.16.0.615698223309.issue26940@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

test_importlib hangs on an android emulator running an armv7 system image (but not on x86) at API level 21. The test suite hangs at

test_deadlock (test.test_importlib.test_locks.Frozen_DeadlockAvoidanceTests) ...

A cause of this problem may be related to the fact that the android arm emulator runs very, very slowly.

----------
components: Cross-Build, Library (Lib)
messages: 264743
nosy: Alex.Willmer, brett.cannon, xdegaye
priority: normal
severity: normal
status: open
title: android: test_importlib hangs on armv7
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Tue May  3 11:47:06 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 03 May 2016 15:47:06 +0000
Subject: [New-bugs-announce] [issue26941] android: test_threading hangs on
 armv7
Message-ID: <1462290426.09.0.613967464154.issue26941@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

test_threading hangs on an android emulator running an armv7 system image (but not on x86) at API level 21. The test suite hangs at

test_is_alive_after_fork (test.test_threading.ThreadTests) ...

A cause of this problem may be related to the fact that the android arm emulator runs very, very slowly.

----------
components: Cross-Build, Library (Lib)
messages: 264744
nosy: Alex.Willmer, xdegaye
priority: normal
severity: normal
status: open
title: android: test_threading hangs on armv7
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Tue May  3 11:53:09 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 03 May 2016 15:53:09 +0000
Subject: [New-bugs-announce] [issue26942] android: test_ctypes crashes on
 armv7
Message-ID: <1462290789.53.0.483745295219.issue26942@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

test_ctypes crashes on an android emulator running an armv7 system image (but not on x86) at API level 21.


143|root at generic:/data/local/tmp # python -m test -v test_ctypes                                   
== CPython 3.6.0a0 (default:f4c6dab59cd8+, May 3 2016, 17:24:17) [GCC 4.9 20140827 (prerelease)]
==   Linux-3.4.67-01422-gd3ffcc7-dirty-armv7l-with-libc little-endian
==   hash algorithm: fnv 32bit
==   /data/local/tmp/test_python_2301
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_randomiza
tion=1, isolated=0)
Run tests sequentially
0:00:00 [1/1] test_ctypes
test_anon (ctypes.test.test_anon.AnonTest) ... ok
test_anon_nonmember (ctypes.test.test_anon.AnonTest) ... ok
test_anon_nonseq (ctypes.test.test_anon.AnonTest) ... ok
test_nested (ctypes.test.test_anon.AnonTest) ... ok
test (ctypes.test.test_array_in_pointer.Test) ... ok
test_2 (ctypes.test.test_array_in_pointer.Test) ... ok
test_bad_subclass (ctypes.test.test_arrays.ArrayTestCase) ... ok
test_cache (ctypes.test.test_arrays.ArrayTestCase) ... ok
test_classcache (ctypes.test.test_arrays.ArrayTestCase) ... ok
test_from_address (ctypes.test.test_arrays.ArrayTestCase) ... ok
test_from_addressW (ctypes.test.test_arrays.ArrayTestCase) ... ok
test_numeric_arrays (ctypes.test.test_arrays.ArrayTestCase) ... ok
test_simple (ctypes.test.test_arrays.ArrayTestCase) ... ok
test_subclass (ctypes.test.test_arrays.ArrayTestCase) ... ok
test_byval (ctypes.test.test_as_parameter.AsParamPropertyWrapperTestCase) ... ok
test_callbacks (ctypes.test.test_as_parameter.AsParamPropertyWrapperTestCase) ... Fatal Python error
: Segmentation fault

Current thread 0xb6f2eec8 (most recent call first):
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/ctypes/test/test_as_parameter.py", line 85 in test
_callbacks
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/unittest/case.py", line 600 in run
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/unittest/case.py", line 648 in __call__
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/unittest/suite.py", line 122 in run
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/unittest/suite.py", line 84 in __call__
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/unittest/suite.py", line 122 in run
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/unittest/suite.py", line 84 in __call__
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/unittest/suite.py", line 122 in run
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/unittest/suite.py", line 84 in __call__
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/unittest/suite.py", line 122 in run
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/unittest/suite.py", line 84 in __call__
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/unittest/suite.py", line 122 in run
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/unittest/suite.py", line 84 in __call__
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/unittest/runner.py", line 176 in run
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/support/__init__.py", line 1802 in _run_suite
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/support/__init__.py", line 1836 in run_unitte
st
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/libregrtest/runtest.py", line 166 in test_run
ner
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/libregrtest/runtest.py", line 167 in runtest_
inner
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/libregrtest/runtest.py", line 131 in runtest
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/libregrtest/main.py", line 332 in run_tests_s
equential
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/libregrtest/main.py", line 402 in run_tests
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/libregrtest/main.py", line 462 in _main
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/libregrtest/main.py", line 442 in main
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/libregrtest/main.py", line 504 in main
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/__main__.py", line 2 in <module>
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/runpy.py", line 85 in _run_code
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/runpy.py", line 184 in _run_module_as_main
Segmentation fault

----------
components: Cross-Build, Library (Lib)
messages: 264745
nosy: Alex.Willmer, amaury.forgeotdarc, belopolsky, meador.inge, xdegaye
priority: normal
severity: normal
status: open
title: android: test_ctypes crashes on armv7
type: crash
versions: Python 3.6

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

From report at bugs.python.org  Wed May  4 03:17:07 2016
From: report at bugs.python.org (Jens de Bruijn)
Date: Wed, 04 May 2016 07:17:07 +0000
Subject: [New-bugs-announce] [issue26943] Datetime.strptime crash
Message-ID: <1462346227.96.0.56286008604.issue26943@psf.upfronthosting.co.za>


New submission from Jens de Bruijn:

Datetime crashes while running script from the command line. When running the same date string from the interpreter (Ubuntu 16.04) it does not crash.

date = datetime.datetime.strptime('May 01 23:59:59 +0000 2016', '%b %d %H:%M:%S +0000 %Y')

----------
components: Extension Modules
files: Screenshot from 2016-05-04 08-52-30.png
messages: 264784
nosy: Jens de Bruijn
priority: normal
severity: normal
status: open
title: Datetime.strptime crash
type: crash
versions: Python 3.5
Added file: http://bugs.python.org/file42706/Screenshot from 2016-05-04 08-52-30.png

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

From report at bugs.python.org  Wed May  4 04:01:13 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 04 May 2016 08:01:13 +0000
Subject: [New-bugs-announce] [issue26944] android: test_posix fails
Message-ID: <1462348873.26.0.373017977506.issue26944@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

test_posix fails on an android emulator running an x86 system image at API level 21.

On android we have instead of a list of group IDs:
root at generic_x86:/data/local/tmp # id -G
uid=0(root) gid=0(root) groups=1003(graphics),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats) context=u:r:su:s0


======================================================================
ERROR: test_getgroups (test.test_posix.PosixTester)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/test_posix.py", line 815, in test_getgroups
    set([int(x) for x in groups.split()]),
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/test_posix.py", line 815, in <listcomp>
    set([int(x) for x in groups.split()]),
ValueError: invalid literal for int() with base 10: 'uid=0(root)'

----------------------------------------------------------------------
Ran 83 tests in 0.114s

FAILED (errors=1, skipped=11)
test test_posix failed
1 test failed:
    test_posix
Total duration: 0:00:01

----------
components: Cross-Build, Library (Lib)
messages: 264789
nosy: Alex.Willmer, larry, xdegaye
priority: normal
severity: normal
status: open
title: android: test_posix fails
versions: Python 3.6

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

From report at bugs.python.org  Wed May  4 06:18:37 2016
From: report at bugs.python.org (Fairuz Zack)
Date: Wed, 04 May 2016 10:18:37 +0000
Subject: [New-bugs-announce] [issue26945] difflib.HtmlDiff().make_file()
 treat few change as whole line change
Message-ID: <1462357117.75.0.264226223626.issue26945@psf.upfronthosting.co.za>


New submission from Fairuz Zack:

html diff threat 2.011 as whole line added instead of only "11" is changed. example file i want to diff is under bug_report.txt. seems the diff not reasonable for other line in the txt as well.

----------
components: Library (Lib)
files: bug_report.txt
messages: 264801
nosy: Fairuz Zack
priority: normal
severity: normal
status: open
title: difflib.HtmlDiff().make_file() treat few change as whole line change
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file42709/bug_report.txt

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

From report at bugs.python.org  Wed May  4 07:56:34 2016
From: report at bugs.python.org (Jon Morris)
Date: Wed, 04 May 2016 11:56:34 +0000
Subject: [New-bugs-announce] [issue26946] os.path.realpath.__name__ is
 'abspath'
Message-ID: <1462362994.62.0.587690697752.issue26946@psf.upfronthosting.co.za>


New submission from Jon Morris:

A minor issue, but the name property for realpath is actually 'abspath'.

Python 2.7.8 on Windows 6.1.7601 (7 sp1)

----------
messages: 264804
nosy: Jon Morris
priority: normal
severity: normal
status: open
title: os.path.realpath.__name__ is 'abspath'
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed May  4 08:21:35 2016
From: report at bugs.python.org (mPython)
Date: Wed, 04 May 2016 12:21:35 +0000
Subject: [New-bugs-announce] [issue26947] Documentation improvement needed
Message-ID: <1462364495.31.0.190726094652.issue26947@psf.upfronthosting.co.za>


New submission from mPython:

On following page: https://docs.python.org/3/glossary.html#term-hashable sentence "All of Python?s immutable built-in objects are hashable, while no mutable containers (such as lists or dictionaries) are." is not complete - probably a word "not" is needed on the end.

----------
assignee: docs at python
components: Documentation
messages: 264805
nosy: docs at python, mPython
priority: normal
severity: normal
status: open
title: Documentation improvement needed
versions: Python 3.5

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

From report at bugs.python.org  Wed May  4 08:48:17 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 04 May 2016 12:48:17 +0000
Subject: [New-bugs-announce] [issue26948] Simplify
 PyImport_ImportModuleLevelObject: avoid temporary tuple of
 str.partition/rpartition
Message-ID: <1462366096.99.0.505486204929.issue26948@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Attached patch simplifies PyImport_ImportModuleLevelObject to avoid the temporary tuple created by str.partition/rpartition(). I don't expect any difference on the performance, it's more to cleanup the code.

----------
files: import.patch
keywords: patch
messages: 264809
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Simplify PyImport_ImportModuleLevelObject: avoid temporary tuple of str.partition/rpartition
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file42714/import.patch

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

From report at bugs.python.org  Wed May  4 08:49:03 2016
From: report at bugs.python.org (ppperry)
Date: Wed, 04 May 2016 12:49:03 +0000
Subject: [New-bugs-announce] [issue26949] IDLE restarts when one debugs code
 raising SystemExit
Message-ID: <1462366143.54.0.608094769433.issue26949@psf.upfronthosting.co.za>


Changes by ppperry <mapreader at olum.org>:


----------
components: IDLE
nosy: ppperry
priority: normal
severity: normal
status: open
title: IDLE restarts when one debugs code raising SystemExit
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed May  4 09:45:42 2016
From: report at bugs.python.org (Joni Bekenstein)
Date: Wed, 04 May 2016 13:45:42 +0000
Subject: [New-bugs-announce] [issue26950] Typo in unittest.mock >
 Autospeccing documentation
Message-ID: <1462369542.26.0.815413375703.issue26950@psf.upfronthosting.co.za>


New submission from Joni Bekenstein:

In several code examples from unittest.mock > Autospeccing documentation you will find "assret_called_with" instead of "assert_called_with".

----------
assignee: docs at python
components: Documentation
messages: 264815
nosy: Joni Bekenstein, docs at python
priority: normal
severity: normal
status: open
title: Typo in unittest.mock > Autospeccing documentation
type: enhancement

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

From report at bugs.python.org  Wed May  4 10:34:33 2016
From: report at bugs.python.org (Corey Farwell)
Date: Wed, 04 May 2016 14:34:33 +0000
Subject: [New-bugs-announce] [issue26951] Unintuitive error when using
 generator expression in class property
Message-ID: <1462372473.02.0.946073615941.issue26951@psf.upfronthosting.co.za>


New submission from Corey Farwell:

```
class A:
    B = range(10)
    C = frozenset([4, 5, 6])
    D = list(i for i in B)
    E = list(i for i in B if i in C)
```

```

coreyf at frewbook-pro /tmp [1]> python3 a.py
Traceback (most recent call last):
  File "a.py", line 1, in <module>
    class A:
  File "a.py", line 5, in A
    E = list(i for i in B if i in C)
  File "a.py", line 5, in <genexpr>
    E = list(i for i in B if i in C)
NameError: name 'C' is not defined
```

Why should I be able to access B but not C?

----------
components: Interpreter Core
messages: 264819
nosy: corey
priority: normal
severity: normal
status: open
title: Unintuitive error when using generator expression in class property
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5

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

From report at bugs.python.org  Wed May  4 11:14:47 2016
From: report at bugs.python.org (Endre)
Date: Wed, 04 May 2016 15:14:47 +0000
Subject: [New-bugs-announce] [issue26952] argparse help formatter crashes
Message-ID: <1462374887.67.0.462060112057.issue26952@psf.upfronthosting.co.za>


New submission from Endre:

I am using argparse-1.4.0.

For this code exception is thrown when the script is started with the -h option:
http://pastebin.com/dFF1paFA

This exception is thrown:
Traceback (most recent call last):
  File "C:\Users\ebak\Picea\tools\buildsystem\python\kw_set_checkers.py", line 129, in <module>
    args = parser.parse_args()
  File "C:\Python27\lib\argparse.py", line 1688, in parse_args
    args, argv = self.parse_known_args(args, namespace)
  File "C:\Python27\lib\argparse.py", line 1720, in parse_known_args
    namespace, args = self._parse_known_args(args, namespace)
  File "C:\Python27\lib\argparse.py", line 1926, in _parse_known_args
    start_index = consume_optional(start_index)
  File "C:\Python27\lib\argparse.py", line 1866, in consume_optional
    take_action(action, args, option_string)
  File "C:\Python27\lib\argparse.py", line 1794, in take_action
    action(self, namespace, argument_values, option_string)
  File "C:\Python27\lib\argparse.py", line 994, in __call__
    parser.print_help()
  File "C:\Python27\lib\argparse.py", line 2327, in print_help
    self._print_message(self.format_help(), file)
  File "C:\Python27\lib\argparse.py", line 2301, in format_help
    return formatter.format_help()
  File "C:\Python27\lib\argparse.py", line 279, in format_help
    help = self._root_section.format_help()
  File "C:\Python27\lib\argparse.py", line 209, in format_help
    func(*args)
  File "C:\Python27\lib\argparse.py", line 317, in _format_usage
    action_usage = format(optionals + positionals, groups)
  File "C:\Python27\lib\argparse.py", line 388, in _format_actions_usage
    start = actions.index(group._group_actions[0])
IndexError: list index out of range

----------
components: Library (Lib)
messages: 264823
nosy: Endre
priority: normal
severity: normal
status: open
title: argparse help formatter crashes
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Wed May  4 11:18:05 2016
From: report at bugs.python.org (Marco)
Date: Wed, 04 May 2016 15:18:05 +0000
Subject: [New-bugs-announce] [issue26953] Failed building wheel for greenlet
Message-ID: <1462375085.34.0.162030856066.issue26953@psf.upfronthosting.co.za>


Changes by Marco <marcoconte_008 at fastwebnet.it>:


----------
components: Installation
nosy: marcoconte_008
priority: normal
severity: normal
status: open
title: Failed building wheel for greenlet
versions: Python 3.4

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

From report at bugs.python.org  Wed May  4 12:08:02 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 04 May 2016 16:08:02 +0000
Subject: [New-bugs-announce] [issue26954] Add Guido's rejection notice to
 the "with" FAQ
Message-ID: <1462378082.17.0.472643239372.issue26954@psf.upfronthosting.co.za>


New submission from Steven D'Aprano:

The FAQs include a discussion of the rejected Pascal "with" statement (different from the Python `with`). From time to time people propose variants of it, such as using a leading dot to make it unambiguous.

Guido has just firmly rejected the latest such proposal. The FAQ should be updated to make it clear that even with a leading dot the proposal is dead, with a link to Guido's pronouncement.

https://mail.python.org/pipermail/python-ideas/2016-May/040070.html

----------
assignee: docs at python
components: Documentation
messages: 264832
nosy: docs at python, steven.daprano
priority: normal
severity: normal
status: open
title: Add Guido's rejection notice to the "with" FAQ
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed May  4 12:17:44 2016
From: report at bugs.python.org (Sylvain Corlay)
Date: Wed, 04 May 2016 16:17:44 +0000
Subject: [New-bugs-announce] [issue26955] Implement equivalent to
 `pip.locations.distutils_scheme` in distutils
Message-ID: <1462378664.68.0.201238634465.issue26955@psf.upfronthosting.co.za>


New submission from Sylvain Corlay:

When installing a python package that has `headers`, these headers are usually installed under the main python include directory, which can be retrieved with `sysconfig.get_path('include')` or directly referred to as 'include' when setting the include directories of an extension module. 

However, on some systems like OS X, headers for extension modules are not located in under the python include directory (/usr/local/Cellar/pythonX/X.Y.Z/Frameworks/Python.framework/Versions/X.Y/include/pythonX.Y) but in `/usr/local/include/pythonX.Y`.

Is there a generic way to find the location where  headers are installed in a  python install?

pip.locations implements `distutils_scheme` which seems to be returning the right thing, but it seems to be a bit overkill to require pip. On the other side, no path returned by sysconfig corresponds to `/usr/local/include/pythonX.Y`

----------
messages: 264836
nosy: sylvain.corlay
priority: normal
severity: normal
status: open
title: Implement equivalent to `pip.locations.distutils_scheme` in distutils
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Wed May  4 12:27:45 2016
From: report at bugs.python.org (Jeff Peters)
Date: Wed, 04 May 2016 16:27:45 +0000
Subject: [New-bugs-announce] [issue26956] About Idle-x version not updated
 for 1.13
Message-ID: <1462379265.06.0.476376304833.issue26956@psf.upfronthosting.co.za>


New submission from Jeff Peters:

The help| about idleX | popup  still lists  the version as 1.12  this  throws off the check for updats functionality

----------
components: IDLE
messages: 264838
nosy: Jeff Peters
priority: normal
severity: normal
status: open
title: About Idle-x  version not updated for  1.13
versions: Python 3.4

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

From report at bugs.python.org  Wed May  4 15:03:30 2016
From: report at bugs.python.org (Alex Chan)
Date: Wed, 04 May 2016 19:03:30 +0000
Subject: [New-bugs-announce] [issue26957] Docs: remove duplicate "the" in
 description of `%z` in datetime docs
Message-ID: <1462388610.21.0.688244618598.issue26957@psf.upfronthosting.co.za>


New submission from Alex Chan:

The description of the `%z` format code in the datetime docs reads:

> UTC offset in the form +HHMM or -HHMM (empty string if the the object is naive).

This tiny patch removes the second "the".

The current wording goes at least as far back as Python 2.6; see https://docs.python.org/2.6/library/datetime.html?highlight=datetime#strftime-and-strptime-behavior.

----------
assignee: docs at python
components: Documentation
files: oneword.patch
keywords: patch
messages: 264848
nosy: alexwlchan, docs at python
priority: normal
severity: normal
status: open
title: Docs: remove duplicate "the" in description of `%z` in datetime docs
type: enhancement
Added file: http://bugs.python.org/file42719/oneword.patch

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

From report at bugs.python.org  Wed May  4 15:37:12 2016
From: report at bugs.python.org (Sudharsan R)
Date: Wed, 04 May 2016 19:37:12 +0000
Subject: [New-bugs-announce] [issue26958] Suggestion to imporve queue.full
 reliability
Message-ID: <1462390632.09.0.248563716558.issue26958@psf.upfronthosting.co.za>


New submission from Sudharsan R:

I was browsing through the code for queue.full and queue.put methods. The queue.full method claims it is not a reliable one. But, the same internal implementation - _qsize is used for put as well as full. "put" is thread safe and reliable and "full" is not.
Why can't the full method acquire self.not_full instead of self.mutex, which will make both of the methods accurate at that instance of time?

    def full(self):
        """Return True if the queue is full, False otherwise (not reliable!)."""
        self.mutex.acquire()
        n = 0 < self.maxsize == self._qsize()
        self.mutex.release()
        return n
    def put(self, item, block=True, timeout=None):
        """Put an item into the queue.

        If optional args 'block' is true and 'timeout' is None (the default),
        block if necessary until a free slot is available. If 'timeout' is
        a positive number, it blocks at most 'timeout' seconds and raises
        the Full exception if no free slot was available within that time.
        Otherwise ('block' is false), put an item on the queue if a free slot
        is immediately available, else raise the Full exception ('timeout'
        is ignored in that case).
        """
        self.not_full.acquire()
        try:
            if self.maxsize > 0:
                if not block:
                    if self._qsize() == self.maxsize:
                        raise Full

----------
messages: 264851
nosy: Sudharsan R
priority: normal
severity: normal
status: open
title: Suggestion to imporve queue.full reliability
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Wed May  4 20:13:46 2016
From: report at bugs.python.org (Vsevolod Velichko)
Date: Thu, 05 May 2016 00:13:46 +0000
Subject: [New-bugs-announce] [issue26959] pickle: respect dispatch for
 functions again
Message-ID: <1462407226.68.0.381104260984.issue26959@psf.upfronthosting.co.za>


New submission from Vsevolod Velichko:

The commit [2] removed support for handling unpicklable functions with copyreg override from cpickle due to lack of the same feature in pickle.
This patch restores that feature and adds the support of it to pickle.

[1] Original discussion: https://mail.python.org/pipermail/python-dev/2016-May/144426.html
[2] https://hg.python.org/cpython/rev/6bd1f0a27e8e

----------
components: Extension Modules
files: function_pickle.patch
keywords: patch
messages: 264866
nosy: torkve
priority: normal
severity: normal
status: open
title: pickle: respect dispatch for functions again
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file42727/function_pickle.patch

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

From report at bugs.python.org  Wed May  4 20:25:54 2016
From: report at bugs.python.org (Chris Beaumont)
Date: Thu, 05 May 2016 00:25:54 +0000
Subject: [New-bugs-announce] [issue26960] urllib hangs when closing
 connection
Message-ID: <1462407954.17.0.565805320206.issue26960@psf.upfronthosting.co.za>


New submission from Chris Beaumont:

http://bugs.python.org/issue16270 identified an issue with ftpwrapper.endtransfer that causes ftp fetches to hang in certain situations. A fix was applied to python 3. I see the same issue on python 2.7, and the patch from 16270 fixes it. Is there a reason this fix hasn't been backported to 2.7?

To reproduce:

import urllib
url = "ftp://ftp.fu-berlin.de/pub/misc/movies/database/ratings.list.gz"
fp = urllib.urlopen(url)
fp.close()  # hangs

----------
components: Library (Lib)
messages: 264868
nosy: Chris Beaumont, giampaolo.rodola
priority: normal
severity: normal
status: open
title: urllib hangs when closing connection
versions: Python 2.7

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

From report at bugs.python.org  Wed May  4 21:43:34 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 05 May 2016 01:43:34 +0000
Subject: [New-bugs-announce] [issue26961] Add operator.get_providing_type
Message-ID: <1462412614.49.0.691089118164.issue26961@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

Prompted by a discussion with Doug Hellmann, I'd like to suggest exposing some of the descriptor MRO walking logic as "operator.get_providing_type".

Specifically, where "getattr(obj, 'attrname')" performs a full attribute lookup and "getattr(type(obj), 'attrname'), performs a type-only attribute lookup, "operator.get_providing_type(obj, 'attrname')" would perform an attribute lookup in the vein of _PyType_Lookup, but report the *type* containing the relevant descriptor, rather than fulling resolving the descriptor protocol.

This would be intended primarily as a debugging aid, for cases where a super() call is reporting an error, but it isn't clear which particular mixin class is failing, and the traceback isn't providing sufficient detail to figure it out (e.g. due to C functions in the call chain).

----------
messages: 264869
nosy: doughellmann, ncoghlan
priority: normal
severity: normal
status: open
title: Add operator.get_providing_type

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

From report at bugs.python.org  Thu May  5 03:53:26 2016
From: report at bugs.python.org (Nathan Kerr)
Date: Thu, 05 May 2016 07:53:26 +0000
Subject: [New-bugs-announce] [issue26962] curses documenation- keys for Page
 Up and Page Down are reversed
Message-ID: <1462434806.76.0.440361178857.issue26962@psf.upfronthosting.co.za>


New submission from Nathan Kerr:

In the documentation for the curses module- 15.11 in Python 2.7 (https://docs.python.org/2.7/library/curses.html), the given key values for Page Up and Page Down are "KEY_NPAGE" and "KEY_PPAGE" respectively. These should be reversed.

This has been fixed in the documentation for 3.5 and 3.6 but not in the previous versions. See this bug report: http://bugs.python.org/issue26679

----------
assignee: docs at python
components: Documentation
messages: 264884
nosy: docs at python, nkerr
priority: normal
severity: normal
status: open
title: curses documenation- keys for Page Up and Page Down are reversed
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Thu May  5 04:19:50 2016
From: report at bugs.python.org (=?utf-8?b?5ZGo5Lyf6Ziz?=)
Date: Thu, 05 May 2016 08:19:50 +0000
Subject: [New-bugs-announce] [issue26963] compile() expected string without
 null bytes
Message-ID: <1462436390.77.0.0191019210095.issue26963@psf.upfronthosting.co.za>


New submission from ???:

"compile() expected string without null bytes"
I met this in python2.7.11, and python2.7.10 is fine.
ENV: DOCKER:2.7.11-alpine, pecan, ceph/pulpito

----------
components: IO
messages: 264894
nosy: ???
priority: normal
severity: normal
status: open
title: compile() expected string without null bytes
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu May  5 13:06:37 2016
From: report at bugs.python.org (Olav Morken)
Date: Thu, 05 May 2016 17:06:37 +0000
Subject: [New-bugs-announce] [issue26964] Incorrect documentation for
 `-u`-flag
Message-ID: <1462467997.8.0.490878249706.issue26964@psf.upfronthosting.co.za>


New submission from Olav Morken:

The documentation for the `-u`-flag (https://docs.python.org/3/using/cmdline.html#cmdoption-u) contains:

> The text I/O layer will still be line-buffered if writing to the console, or block-buffered if redirected to a non-interactive file.

This does not appear to be the case -- instead it is always line-buffered:

https://hg.python.org/cpython/file/v3.5.1/Python/pylifecycle.c#l1041

Attached is a trivial patch that simply removes everything after "line-buffered".

----------
assignee: docs at python
components: Documentation
files: fix-doc-unbuffered.patch
keywords: patch
messages: 264910
nosy: docs at python, olavmrk
priority: normal
severity: normal
status: open
title: Incorrect documentation for `-u`-flag
Added file: http://bugs.python.org/file42736/fix-doc-unbuffered.patch

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

From report at bugs.python.org  Thu May  5 14:50:06 2016
From: report at bugs.python.org (Karan Rawat)
Date: Thu, 05 May 2016 18:50:06 +0000
Subject: [New-bugs-announce] [issue26965] Turbotax Tech Support Mumber
 1!!888!!226!!1422 turbotax Usa Canada
Message-ID: <1462474206.86.0.381535493708.issue26965@psf.upfronthosting.co.za>


New submission from Karan Rawat:

Turbotax Service (43) 
turbotax customer service, turbotax customer service number 1**888**226**1422, turbotax customer service phone number 1**888**226**1422, turbotax phone number 1**888**226**1422 customer service, turbotax customer service phone, turbotax customer service line, turbotax phone number 1**888**226**1422 for customer service, turbotax customer service number 1**888**226**1422 phone, phone number 1**888**226**1422 for turbotax customer service, customer service number 1**888**226**1422 for turbotax, intuit turbotax customer service, contact turbotax customer service phone number 1**888**226**1422, customer service for turbotax, call turbotax customer service, intuit turbotax customer service phone number 1**888**226**1422, customer service turbotax, turbotax contact customer service, turbotax customer service hours, turbotax number 1**888**226**1422 customer service, contact turbotax customer service?
Contact Turbotax (38) 
turbotax contact number 1**888**226**1422, turbotax contact, contact turbotax, contact turbotax by phone, turbotax contact phone number 1**888**226**1422, turbotax contact info, turbotax contact phone, contact turbotax phone, contact number 1**888**226**1422 for turbotax, intuit turbotax contact number 1**888**226**1422, contact turbotax by phone number 1**888**226**1422, turbotax contact information, contact turbotax phone number 1**888**226**1422, turbotax number 1**888**226**1422 contact, turbotax phone contact, turbotax contact number 1**888**226**1422s, contacting turbotax, contacting turbotax by phone, contact turbotax support by phone, contact information for turbotax?
Free Turbo (22) 
free turbo tax, free turbo tax 2014, free turbo tax filing 2012, tax turbo free, federal free turbo tax, free tax turbo, free turbo tax state, free turbo taxes, free turbo tax filing, turbo tax questions free, free turbo tax federal, turbo tax free, free turbo tax 2013, free turbo tax filing 2013, free turbo tax return, turbo tax free edition, turbo taxes free, turbo tax free file, is turbo tax free, turbo tax for free?
Turbotax Help (23) 
turbotax help, turbotax help number 1**888**226**1422, turbotax help phone number 1**888**226**1422, turbotax help phone, turbotax help center phone number 1**888**226**1422, turbotax phone help, turbotax phone help line, turbotax tax help, turbotax number 1**888**226**1422 help, phone number 1**888**226**1422 for turbotax help, turbotax expert help phone number 1**888**226**1422, turbotax help center, turbotax help desk phone number 1**888**226**1422, turbotax number 1**888**226**1422 for help, turbotax phone number 1**888**226**1422 for help, help with turbotax, turbotax live help, turbotax help phone line, turbotax live help phone number 1**888**226**1422, turbotax online help phone number 1**888**226**1422?
Turbotax Business (14) 
turbotax business, turbotax home and business 2014, turbotax 2014 home and business, turbotax business 2014, turbotax business 2013, turbotax 2013 home and business, turbotax for business, turbotax business online, turbotax small business, turbotax for business online, turbotax online business, intuit turbotax business, turbotax business support, turbotax business 2013 online
Turbotax Support (14) 
turbotax support, turbotax phone support, turbotax customer support, turbotax support phone, turbotax customer support phone, turbotax tech support, turbotax support site, turbotax tech support phone, turbotax live support, turbotax support line, customer support turbotax, turbotax 2013 support, support turbotax, turbotax support hours
Turbotax State (18) 
turbotax state, turbotax federal and state 2013, turbotax 2013 federal and state, turbotax federal and state, turbotax state taxes, turbotax state refund, turbotax state tax calculator, state tax turbotax, turbotax state return, turbotax 2014 state, turbotax free state, turbotax state returns, turbotax state tax, turbotax state id number 1**888**226**1422, turbotax state download, state taxes turbotax, turbotax state free, turbotax state form availability
Turbotax Free (25) 
turbotax.com free, turbotax toll free number 1**888**226**1422, turbotax 2014 free, turbotax for free, free turbotax 2014, turbotax free 2014, turbotax toll free phone number 1**888**226**1422, free turbotax 2013, turbotax military free, toll free number 1**888**226**1422 for turbotax, turbotax free 2013, free turbotax, www.turbotax.com free edition, turbotax toll free, turbotax free, turbotax free edition, turbotax 2013 free, free 2013 turbotax, is turbotax free, 2013 turbotax free?
Call Turbotax (19) 
call turbotax, turbotax call center number 1**888**226**1422, turbotax number 1**888**226**1422 to call, turbotax phone number 1**888**226**1422 to call, turbotax call number 1**888**226**1422, turbotax call center, call turbotax support, turbotax call center phone number 1**888**226**1422, turbotax call, call turbotax customer support, call turbotax number 1**888**226**1422, call turbotax support phone number 1**888**226**1422, turbotax call support, call turbotax phone number 1**888**226**1422, call turbotax support phone, phone number 1**888**226**1422 to call turbotax, calling turbotax, calling turbotax support, turbotax call line
Turbo 2013 (18) 
turbo tax estimator 2013, turbo tax for 2013, turbo tax costs 2013, tax turbo 2013, turbo tax 2013, turbo taxes 2013, turbo tax corporate 2013, turbo tax return 2013, turbo tax premier 2013, 2013 turbo tax, turbo tax home and business 2013, turbo tax business 2013, turbo tax filing 2013, turbo tax updates 2013, turbo tax federal 2013, turbo tax 2013 return, turbo tax software 2013, turbo tax rebate 2013
Turbotax Price (8) 
turbotax price, turbotax prices, turbotax pricing 2013, price of turbotax, best price for turbotax 2013, turbotax pricing, best price on turbotax 2013, prices for turbotax
Turbotax Telephone (16) 
turbotax telephone number 1**888**226**1422, turbotax customer service telephone number 1**888**226**1422, turbotax telephone customer service, turbotax telephone number 1**888**226**1422s, telephone number 1**888**226**1422 for turbotax, turbotax telephone number 1**888**226**1422 customer service, turbotax contact telephone number 1**888**226**1422, turbotax telephone support, telephone number 1**888**226**1422 for turbotax customer service, turbotax telephone, turbotax telephone assistance, turbotax technical support telephone number 1**888**226**1422, turbotax telephone help, turbotax customer service telephone, turbotax customer support telephone number 1**888**226**1422, turbotax support telephone number 1**888**226**1422
2014 Turbo (10) 
2014 turbo tax, turbo taxes 2014, tax turbo 2014, turbo tax code 2014, turbo tax 2014, turbo tax for 2014, turbo tax refund 2014, turbo tax refund schedule 2014, turbo tax software 2014, turbo tax problems 2014
Turbotax Intuit (9) 
intuit turbotax 2013, intuit turbotax 2014, intuit turbotax support, turbotax.intuit.com, intuit turbotax, turbotax intuit, turbotax by intuit, intuit turbotax free, turbotax intuit free
Turbotax 2012 (16) 
turbotax 2012 tax return, turbotax for 2012, 2012 turbotax, turbotax 2012, turbotax business 2012, turbotax for 2012 tax year, turbotax 2012 return, intuit turbotax 2012, 2012 taxes turbotax, upgrade turbotax 2012 to 2013, 2012 turbotax online, turbotax 2012 online, access 2012 tax return turbotax, intuit 2012 turbotax, free turbotax 2012, turbotax online 2012
Turbotax Cost (12) 
cost of turbotax 2013, turbotax cost 2013, turbotax 2013 cost, turbotax state cost, how much does turbotax cost, turbotax cost, turbotax state return cost, turbotax costs, cost of turbotax 2013 online, turbotax state tax cost, cost of turbotax, cost of filing taxes with turbotax
Taxes Phone (13) 
turbo tax helpline phone number 1**888**226**1422, turbo tax hotline phone number 1**888**226**1422, turbo taxes phone number 1**888**226**1422, turbo tax questions phone number 1**888**226**1422, turbo tax assistance phone number 1**888**226**1422, turbo tax representative phone number 1**888**226**1422, phone number 1**888**226**1422 for turbo tax assistance, turbo tax question phone number 1**888**226**1422, turbo tax information phone number 1**888**226**1422, turbo tax refund phone number 1**888**226**1422, turbo tax phone number 1**888**226**1422, turbotax tax expert phone number 1**888**226**1422, turbotax live tax advice phone number 1**888**226**1422
Turbotax Filing (21) 
file 2012 taxes turbotax, free tax filing 2013 turbotax, turbotax free federal and state filing, turbotax file online, turbotax free file 2013, turbotax filing, turbotax free file 2014, free file turbotax, turbotax free filing, turbotax free file, filing taxes with turbotax, file taxes with turbotax, turbotax state filing fee, turbotax 2013 filing, turbotax online filing, filing with turbotax, file taxes turbotax, turbotax .tax file, upload turbotax file to turbotax online, turbotax file?
Download Turbotax (21) 
turbotax 2012 download, turbotax download, download turbotax 2013, turbotax 2013 download, download turbotax, turbotax download 2013, turbotax deluxe 2013 download, turbotax business 2013 download, turbotax 2011 download, turbotax 2014 download, download turbotax 2012, 2012 turbotax download, turbotax 2012 download free, turbotax free download, turbotax software download, turbotax download free, turbotax deluxe download, free turbotax download, turbotax downloads, download turbotax 2014?
Turbotax 1800 (8) 
turbotax customer service 1800 number 1**888**226**1422, turbotax 1800 number 1**888**226**1422, turbotax 1800 phone number 1**888**226**1422, 1800 number 1**888**226**1422 for turbotax, turbotax card 1800 number 1**888**226**1422, turbotax customer service 1800, turbotax 1800, 1800 turbotax
Turbotax 800 (6) 
turbotax 800 number 1**888**226**1422, turbotax 1 800 number 1**888**226**1422, turbotax 800 phone number 1**888**226**1422, turbotax 800 support number 1**888**226**1422, 800 number 1**888**226**1422 for turbotax, 1 800 number 1**888**226**1422 for turbotax
Turbotax Deals (6) 
turbotax deals 2014, turbotax 2013 deals, turbotax deals, turbotax online deals, turbotax deal, turbotax deals 2013
Support number 1**888**226**1422 (12) 
turbotax support phone number 1**888**226**1422, turbotax phone number 1**888**226**1422 support, turbotax tech support phone number 1**888**226**1422, number 1**888**226**1422 for turbotax support, turbotax tech support number 1**888**226**1422, turbotax phone support number 1**888**226**1422, phone number 1**888**226**1422 for turbotax support, turbotax phone number 1**888**226**1422s support, turbotax support phone number 1**888**226**1422s, turbotax audit support phone number 1**888**226**1422, turbotax com support phone number 1**888**226**1422, turbotax live support phone number 1**888**226**1422
number 1**888**226**1422 Customer (8) 
phone number 1**888**226**1422 for turbotax customer support, turbotax customer support number 1**888**226**1422, turbotax customer support phone number 1**888**226**1422, turbotax phone number 1**888**226**1422 customer support, turbotax phone number 1**888**226**1422 for customer support, turbotax customer phone number 1**888**226**1422, turbotax customer care number 1**888**226**1422, phone number 1**888**226**1422 turbotax customer support
Turbo Calculator (11) 
free turbo tax calculator 2013, turbo tax 2014 calculator, turbo tax return calculator, turbo tax 2013 calculator, 2013 turbo tax calculator, turbo tax refund calculator, turbo tax calculator, turbo tax calculator 2013, turbo tax calculator 2014, tax turbo calculator, free turbo tax calculator
Turbotax Code (14) 
turbotax rebate code, turbotax promo code 2014, turbotax service codes 2013, turbotax code, turbotax service codes, turbotax coupon code, turbotax discount code, turbotax promo code, service code for turbotax, turbotax service code, turbotax discount code 2013, turbotax service code 2014, turbotax service code free, turbotax discount code 2014
Turbotax 2014 (7) 
2014 turbotax, turbotax 2014 release date, turbotax fees 2014, turbotax 2014, turbotax premier 2014, turbotax 2014 phone number 1**888**226**1422, turbotax 2014 premier
Turbotax Tax (15) 
turbotax back taxes, turbotax 2013 tax calculator, turbotax tax, turbotax for 2013 tax year, turbotax for tax year 2013, turbotax taxes, 2013 tax calculator turbotax, turbotax 2013 tax year, turbotax tax year 2013, turbotax tax calculator, turbotax 2013 tax estimator, turbotax 2014 tax estimator, turbotax tax estimator, turbotax tax refund, tax refund turbotax
Turbotax Online (14) 
online turbotax, turbotax online 2014, turbotax 2014 online, turbotax 2013 online, 2013 turbotax online, turbotax online free, turbotax online, turbotax online 2013, turbotax online support, online turbotax free, free online turbotax, purchase turbotax online, turbotax free online, intuit turbotax online
Intuit Phone (9) 
intuit turbotax phone number 1**888**226**1422, intuit turbotax s

----------
components: Argument Clinic
files: ihaveanswer.jpg
messages: 264913
nosy: Karan Rawat, larry
priority: normal
severity: normal
status: open
title: Turbotax Tech Support Mumber 1!!888!!226!!1422 turbotax Usa Canada
type: security
versions: Python 3.6
Added file: http://bugs.python.org/file42738/ihaveanswer.jpg

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

From report at bugs.python.org  Thu May  5 14:54:31 2016
From: report at bugs.python.org (Karan Rawat)
Date: Thu, 05 May 2016 18:54:31 +0000
Subject: [New-bugs-announce] [issue26966] turbotax phone number
 1**888**226**1422 support,
 turbotax tech support phone number 1**888**226**1422
Message-ID: <1462474471.08.0.192781449816.issue26966@psf.upfronthosting.co.za>


New submission from Karan Rawat:

Turbotax Service (43) 
turbotax customer service, turbotax customer service number 1**888**226**1422, turbotax customer service phone number 1**888**226**1422, turbotax phone number 1**888**226**1422 customer service, turbotax customer service phone, turbotax customer service line, turbotax phone number 1**888**226**1422 for customer service, turbotax customer service number 1**888**226**1422 phone, phone number 1**888**226**1422 for turbotax customer service, customer service number 1**888**226**1422 for turbotax, intuit turbotax customer service, contact turbotax customer service phone number 1**888**226**1422, customer service for turbotax, call turbotax customer service, intuit turbotax customer service phone number 1**888**226**1422, customer service turbotax, turbotax contact customer service, turbotax customer service hours, turbotax number 1**888**226**1422 customer service, contact turbotax customer service?
Contact Turbotax (38) 
turbotax contact number 1**888**226**1422, turbotax contact, contact turbotax, contact turbotax by phone, turbotax contact phone number 1**888**226**1422, turbotax contact info, turbotax contact phone, contact turbotax phone, contact number 1**888**226**1422 for turbotax, intuit turbotax contact number 1**888**226**1422, contact turbotax by phone number 1**888**226**1422, turbotax contact information, contact turbotax phone number 1**888**226**1422, turbotax number 1**888**226**1422 contact, turbotax phone contact, turbotax contact number 1**888**226**1422s, contacting turbotax, contacting turbotax by phone, contact turbotax support by phone, contact information for turbotax?
Free Turbo (22) 
free turbo tax, free turbo tax 2014, free turbo tax filing 2012, tax turbo free, federal free turbo tax, free tax turbo, free turbo tax state, free turbo taxes, free turbo tax filing, turbo tax questions free, free turbo tax federal, turbo tax free, free turbo tax 2013, free turbo tax filing 2013, free turbo tax return, turbo tax free edition, turbo taxes free, turbo tax free file, is turbo tax free, turbo tax for free?
Turbotax Help (23) 
turbotax help, turbotax help number 1**888**226**1422, turbotax help phone number 1**888**226**1422, turbotax help phone, turbotax help center phone number 1**888**226**1422, turbotax phone help, turbotax phone help line, turbotax tax help, turbotax number 1**888**226**1422 help, phone number 1**888**226**1422 for turbotax help, turbotax expert help phone number 1**888**226**1422, turbotax help center, turbotax help desk phone number 1**888**226**1422, turbotax number 1**888**226**1422 for help, turbotax phone number 1**888**226**1422 for help, help with turbotax, turbotax live help, turbotax help phone line, turbotax live help phone number 1**888**226**1422, turbotax online help phone number 1**888**226**1422?
Turbotax Business (14) 
turbotax business, turbotax home and business 2014, turbotax 2014 home and business, turbotax business 2014, turbotax business 2013, turbotax 2013 home and business, turbotax for business, turbotax business online, turbotax small business, turbotax for business online, turbotax online business, intuit turbotax business, turbotax business support, turbotax business 2013 online
Turbotax Support (14) 
turbotax support, turbotax phone support, turbotax customer support, turbotax support phone, turbotax customer support phone, turbotax tech support, turbotax support site, turbotax tech support phone, turbotax live support, turbotax support line, customer support turbotax, turbotax 2013 support, support turbotax, turbotax support hours
Turbotax State (18) 
turbotax state, turbotax federal and state 2013, turbotax 2013 federal and state, turbotax federal and state, turbotax state taxes, turbotax state refund, turbotax state tax calculator, state tax turbotax, turbotax state return, turbotax 2014 state, turbotax free state, turbotax state returns, turbotax state tax, turbotax state id number 1**888**226**1422, turbotax state download, state taxes turbotax, turbotax state free, turbotax state form availability
Turbotax Free (25) 
turbotax.com free, turbotax toll free number 1**888**226**1422, turbotax 2014 free, turbotax for free, free turbotax 2014, turbotax free 2014, turbotax toll free phone number 1**888**226**1422, free turbotax 2013, turbotax military free, toll free number 1**888**226**1422 for turbotax, turbotax free 2013, free turbotax, www.turbotax.com free edition, turbotax toll free, turbotax free, turbotax free edition, turbotax 2013 free, free 2013 turbotax, is turbotax free, 2013 turbotax free?
Call Turbotax (19) 
call turbotax, turbotax call center number 1**888**226**1422, turbotax number 1**888**226**1422 to call, turbotax phone number 1**888**226**1422 to call, turbotax call number 1**888**226**1422, turbotax call center, call turbotax support, turbotax call center phone number 1**888**226**1422, turbotax call, call turbotax customer support, call turbotax number 1**888**226**1422, call turbotax support phone number 1**888**226**1422, turbotax call support, call turbotax phone number 1**888**226**1422, call turbotax support phone, phone number 1**888**226**1422 to call turbotax, calling turbotax, calling turbotax support, turbotax call line
Turbo 2013 (18) 
turbo tax estimator 2013, turbo tax for 2013, turbo tax costs 2013, tax turbo 2013, turbo tax 2013, turbo taxes 2013, turbo tax corporate 2013, turbo tax return 2013, turbo tax premier 2013, 2013 turbo tax, turbo tax home and business 2013, turbo tax business 2013, turbo tax filing 2013, turbo tax updates 2013, turbo tax federal 2013, turbo tax 2013 return, turbo tax software 2013, turbo tax rebate 2013
Turbotax Price (8) 
turbotax price, turbotax prices, turbotax pricing 2013, price of turbotax, best price for turbotax 2013, turbotax pricing, best price on turbotax 2013, prices for turbotax
Turbotax Telephone (16) 
turbotax telephone number 1**888**226**1422, turbotax customer service telephone number 1**888**226**1422, turbotax telephone customer service, turbotax telephone number 1**888**226**1422s, telephone number 1**888**226**1422 for turbotax, turbotax telephone number 1**888**226**1422 customer service, turbotax contact telephone number 1**888**226**1422, turbotax telephone support, telephone number 1**888**226**1422 for turbotax customer service, turbotax telephone, turbotax telephone assistance, turbotax technical support telephone number 1**888**226**1422, turbotax telephone help, turbotax customer service telephone, turbotax customer support telephone number 1**888**226**1422, turbotax support telephone number 1**888**226**1422
2014 Turbo (10) 
2014 turbo tax, turbo taxes 2014, tax turbo 2014, turbo tax code 2014, turbo tax 2014, turbo tax for 2014, turbo tax refund 2014, turbo tax refund schedule 2014, turbo tax software 2014, turbo tax problems 2014
Turbotax Intuit (9) 
intuit turbotax 2013, intuit turbotax 2014, intuit turbotax support, turbotax.intuit.com, intuit turbotax, turbotax intuit, turbotax by intuit, intuit turbotax free, turbotax intuit free
Turbotax 2012 (16) 
turbotax 2012 tax return, turbotax for 2012, 2012 turbotax, turbotax 2012, turbotax business 2012, turbotax for 2012 tax year, turbotax 2012 return, intuit turbotax 2012, 2012 taxes turbotax, upgrade turbotax 2012 to 2013, 2012 turbotax online, turbotax 2012 online, access 2012 tax return turbotax, intuit 2012 turbotax, free turbotax 2012, turbotax online 2012
Turbotax Cost (12) 
cost of turbotax 2013, turbotax cost 2013, turbotax 2013 cost, turbotax state cost, how much does turbotax cost, turbotax cost, turbotax state return cost, turbotax costs, cost of turbotax 2013 online, turbotax state tax cost, cost of turbotax, cost of filing taxes with turbotax
Taxes Phone (13) 
turbo tax helpline phone number 1**888**226**1422, turbo tax hotline phone number 1**888**226**1422, turbo taxes phone number 1**888**226**1422, turbo tax questions phone number 1**888**226**1422, turbo tax assistance phone number 1**888**226**1422, turbo tax representative phone number 1**888**226**1422, phone number 1**888**226**1422 for turbo tax assistance, turbo tax question phone number 1**888**226**1422, turbo tax information phone number 1**888**226**1422, turbo tax refund phone number 1**888**226**1422, turbo tax phone number 1**888**226**1422, turbotax tax expert phone number 1**888**226**1422, turbotax live tax advice phone number 1**888**226**1422
Turbotax Filing (21) 
file 2012 taxes turbotax, free tax filing 2013 turbotax, turbotax free federal and state filing, turbotax file online, turbotax free file 2013, turbotax filing, turbotax free file 2014, free file turbotax, turbotax free filing, turbotax free file, filing taxes with turbotax, file taxes with turbotax, turbotax state filing fee, turbotax 2013 filing, turbotax online filing, filing with turbotax, file taxes turbotax, turbotax .tax file, upload turbotax file to turbotax online, turbotax file?
Download Turbotax (21) 
turbotax 2012 download, turbotax download, download turbotax 2013, turbotax 2013 download, download turbotax, turbotax download 2013, turbotax deluxe 2013 download, turbotax business 2013 download, turbotax 2011 download, turbotax 2014 download, download turbotax 2012, 2012 turbotax download, turbotax 2012 download free, turbotax free download, turbotax software download, turbotax download free, turbotax deluxe download, free turbotax download, turbotax downloads, download turbotax 2014?
Turbotax 1800 (8) 
turbotax customer service 1800 number 1**888**226**1422, turbotax 1800 number 1**888**226**1422, turbotax 1800 phone number 1**888**226**1422, 1800 number 1**888**226**1422 for turbotax, turbotax card 1800 number 1**888**226**1422, turbotax customer service 1800, turbotax 1800, 1800 turbotax
Turbotax 800 (6) 
turbotax 800 number 1**888**226**1422, turbotax 1 800 number 1**888**226**1422, turbotax 800 phone number 1**888**226**1422, turbotax 800 support number 1**888**226**1422, 800 number 1**888**226**1422 for turbotax, 1 800 number 1**888**226**1422 for turbotax
Turbotax Deals (6) 
turbotax deals 2014, turbotax 2013 deals, turbotax deals, turbotax online deals, turbotax deal, turbotax deals 2013
Support number 1**888**226**1422 (12) 
turbotax support phone number 1**888**226**1422, turbotax phone number 1**888**226**1422 support, turbotax tech support phone number 1**888**226**1422, number 1**888**226**1422 for turbotax support, turbotax tech support number 1**888**226**1422, turbotax phone support number 1**888**226**1422, phone number 1**888**226**1422 for turbotax support, turbotax phone number 1**888**226**1422s support, turbotax support phone number 1**888**226**1422s, turbotax audit support phone number 1**888**226**1422, turbotax com support phone number 1**888**226**1422, turbotax live support phone number 1**888**226**1422
number 1**888**226**1422 Customer (8) 
phone number 1**888**226**1422 for turbotax customer support, turbotax customer support number 1**888**226**1422, turbotax customer support phone number 1**888**226**1422, turbotax phone number 1**888**226**1422 customer support, turbotax phone number 1**888**226**1422 for customer support, turbotax customer phone number 1**888**226**1422, turbotax customer care number 1**888**226**1422, phone number 1**888**226**1422 turbotax customer support
Turbo Calculator (11) 
free turbo tax calculator 2013, turbo tax 2014 calculator, turbo tax return calculator, turbo tax 2013 calculator, 2013 turbo tax calculator, turbo tax refund calculator, turbo tax calculator, turbo tax calculator 2013, turbo tax calculator 2014, tax turbo calculator, free turbo tax calculator
Turbotax Code (14) 
turbotax rebate code, turbotax promo code 2014, turbotax service codes 2013, turbotax code, turbotax service codes, turbotax coupon code, turbotax discount code, turbotax promo code, service code for turbotax, turbotax service code, turbotax discount code 2013, turbotax service code 2014, turbotax service code free, turbotax discount code 2014
Turbotax 2014 (7) 
2014 turbotax, turbotax 2014 release date, turbotax fees 2014, turbotax 2014, turbotax premier 2014, turbotax 2014 phone number 1**888**226**1422, turbotax 2014 premier
Turbotax Tax (15) 
turbotax back taxes, turbotax 2013 tax calculator, turbotax tax, turbotax for 2013 tax year, turbotax for tax year 2013, turbotax taxes, 2013 tax calculator turbotax, turbotax 2013 tax year, turbotax tax year 2013, turbotax tax calculator, turbotax 2013 tax estimator, turbotax 2014 tax estimator, turbotax tax estimator, turbotax tax refund, tax refund turbotax
Turbotax Online (14) 
online turbotax, turbotax online 2014, turbotax 2014 online, turbotax 2013 online, 2013 turbotax online, turbotax online free, turbotax online, turbotax online 2013, turbotax online support, online turbotax free, free online turbotax, purchase turbotax online, turbotax free online, intuit turbotax online
Intuit Phone (9) 
intuit turbotax phone number 1**888**226**1422, intuit turbotax s

----------
components: Argument Clinic
files: Gmail Customer Service Number +1-888-226-1422 USA  Gmail Password Recovery Toll Free Number.pdf
messages: 264914
nosy: Karan Rawat, larry
priority: normal
severity: normal
status: open
title: turbotax phone number 1**888**226**1422 support, turbotax tech support phone number 1**888**226**1422
versions: Python 3.5
Added file: http://bugs.python.org/file42739/Gmail Customer Service Number +1-888-226-1422 USA  Gmail Password Recovery Toll Free Number.pdf

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

From report at bugs.python.org  Thu May  5 15:04:46 2016
From: report at bugs.python.org (Michael Kruse)
Date: Thu, 05 May 2016 19:04:46 +0000
Subject: [New-bugs-announce] [issue26967] argparse: allow_abbrev=False stops
 -vv from working
Message-ID: <1462475086.65.0.670765920247.issue26967@psf.upfronthosting.co.za>


New submission from Michael Kruse:

#! /usr/bin/env python3
import argparse

parser = argparse.ArgumentParser(allow_abbrev=True)
parser.add_argument('-v', '--verbose', action='count')
print(parser.parse_args(['-vv']))

parser = argparse.ArgumentParser(allow_abbrev=False)
parser.add_argument('-v', '--verbose', action='count')
print(parser.parse_args(['-vv']))


Observed Output:
Namespace(verbose=2)
usage: test.py [-h] [-v]
test.py: error: unrecognized arguments: -vv


Expected Output:
Namespace(verbose=2)
Namespace(verbose=2)

----------
components: Library (Lib)
messages: 264915
nosy: meinersbur
priority: normal
severity: normal
status: open
title: argparse: allow_abbrev=False stops -vv from working
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Thu May  5 15:38:31 2016
From: report at bugs.python.org (Krzysztof Warzecha)
Date: Thu, 05 May 2016 19:38:31 +0000
Subject: [New-bugs-announce] [issue26968] glob.glob incorrect results under
 windows when pathname exists but interpreter does not have access
 permissions to pathname
Message-ID: <1462477111.96.0.426689886808.issue26968@psf.upfronthosting.co.za>


New submission from Krzysztof Warzecha:

Hello,

I'm running python 3.5.1 under windows and I've noticed glob.glob is returning incorrect results when I'm using full path name to directory to which I don't have access permissions.

Please consider this:

    >> glob.glob('c:\\PerfLog*')
    ['c:\\PerfLogs']
    >> glob.glob('c:\\PerfLogs')
    []
    >> glob.glob('c:\\PerfLogs*')
    ['c:\\PerfLogs']

I tried to replicate this under Linux with "chmod 000", but so far I'm unable to. One more example from Windows: "c:\\System Volume Information". This is also the case for user-created directories where python interpreter does not have access rights to directory - I have one like that on my client's machine.

----------
components: Library (Lib), Windows
messages: 264917
nosy: kwarzecha7, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: glob.glob incorrect results under windows when pathname exists but interpreter does not have access permissions to pathname
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Fri May  6 02:52:18 2016
From: report at bugs.python.org (Ilya Kulakov)
Date: Fri, 06 May 2016 06:52:18 +0000
Subject: [New-bugs-announce] [issue26969] ascynio should provide a policy to
 address pass-loop-everywhere problem
Message-ID: <1462517538.3.0.176027238089.issue26969@psf.upfronthosting.co.za>


New submission from Ilya Kulakov:

Currently if one needs lazily resolve event loop depending on where awaitable is being awaited have to pass loop everywhere explicitly. That quickly becomes an unnecessary noise in interfaces of callables. 

Consider an example where a coroutine which constructs other awaitables can be executed in arbitrary loop:

    import asyncio
    import datetime

    async def foo_coro(loop):
        await some_other_coro(loop)

    async def bar_coro(loop):
        await asyncio.ensure_future(..., loop=loop)

    async def baz_coro(loop):
        await asyncio.gather(foo_coro(loop), bar_coro(loop), loop=loop)

    loop = asyncio.get_event_loop()
    loop.run_until_complete(multiple_coros(loop))
    loop.close()

It would be nice, if all functions that belong to an event loop instance as well as asyncio helpers that accept a loop would set default event loop to one that was passed to these functions. So that the example above could be rewritten as:

    import asyncio
    import datetime

    async def foo_coro():
        await some_other_coro()

    async def bar_coro():
        await asyncio.ensure_future(...)

    async def baz_coro():
        await asyncio.gather(foo_coro(), bar_coro())

    loop = asyncio.get_event_loop()
    loop.run_until_complete(multiple_coros())
    loop.close()

----------
components: asyncio
messages: 264941
nosy: Ilya.Kulakov, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: ascynio should provide a policy to address pass-loop-everywhere problem
type: enhancement
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri May  6 05:10:27 2016
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 06 May 2016 09:10:27 +0000
Subject: [New-bugs-announce] [issue26970] Replace OpenSSL's CPRNG with
 system entropy source
Message-ID: <1462525827.05.0.33480267606.issue26970@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The patch adds a new RAND engine for OpenSSL. The engine uses the system's entropy source (/dev/urandom, CryptGenRandom(), getentropy() ...). The engine is automatically installed with OpenSSL as default RAND engine. The new engine fixes the fork() bug once and for all (https://gist.github.com/tiran/a9ba8c51cc7d1b75d3bc1d3f24411b4c)

The engine is a reimplementation of https://cryptography.readthedocs.io/en/latest/hazmat/backends/openssl/?highlight=engine#os-random-engine and a new take on #18747.

I have added a couple of private helper methods to the _ssl module. I'm not sure if we should keep them, remove them or make them public.

----------
components: Extension Modules
files: 0001-Add-new-CPRNG-ENGINE.patch
keywords: patch
messages: 264948
nosy: alex, christian.heimes, dstufft, giampaolo.rodola, haypo, janssen, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Replace OpenSSL's CPRNG with system entropy source
type: security
versions: Python 3.6
Added file: http://bugs.python.org/file42747/0001-Add-new-CPRNG-ENGINE.patch

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

From report at bugs.python.org  Sat May  7 09:41:22 2016
From: report at bugs.python.org (Jaroslav Urban)
Date: Sat, 07 May 2016 13:41:22 +0000
Subject: [New-bugs-announce] [issue26971] python v3.5.1: sys.paths not
 respecting DESTDIRS and DESTSHARED
Message-ID: <1462628482.0.0.926875224828.issue26971@psf.upfronthosting.co.za>


New submission from Jaroslav Urban:

#wget https://www.python.org/ftp/python/3.5.1/Python-3.5.1.tar.xz
#xz -d Python-3.5.1.tar.xz
#tar xvf Python-3.5.1.tar
#cd Python-3.5.1
#./configure --prefix=/usr
#make
#make altinstall

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

so far so good

but afterwards

$python3.5
>>>import base64

results in

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.5/base64.py", line 10, in <module>
    import struct
  File "/usr/lib/python3.5/struct.py", line 13, in <module>
    from _struct import *
ImportError: No module named '_struct'

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

>>>import sys
>>>sys.path
['', '/usr/lib/python35.zip', '/usr/lib/python3.5', '/usr/lib/python3.5/plat-linux', '/usr/lib/lib-dynload', '/usr/lib/python3.5/site-packages']

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

this path is wrong '/usr/lib/lib-dynload'
correctly it should point to the '/usr/lib64/python3.5/lib-dynload' as per the destination folders generated and used via configure / make / make altinstall

thank you
yaro-yaro

----------
components: Installation
files: _sysconfigdata.py
messages: 265069
nosy: yaro-yaro
priority: normal
severity: normal
status: open
title: python v3.5.1: sys.paths not respecting DESTDIRS and DESTSHARED
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file42767/_sysconfigdata.py

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

From report at bugs.python.org  Sat May  7 12:16:06 2016
From: report at bugs.python.org (Oren Milman)
Date: Sat, 07 May 2016 16:16:06 +0000
Subject: [New-bugs-announce] [issue26972] mistakes in docstrings in the
 import machinery
Message-ID: <1462637766.06.0.0379757360626.issue26972@psf.upfronthosting.co.za>


New submission from Oren Milman:

the proposed changes:
I believe there are some mistakes in the following docstrings:
    1. in Lib/importlib/_bootstrap.py:
        - _module_repr - a typo
        - _exec - I believe 'Execute the module specified by the spec' is more accurate than 'Execute the spec'. 
        This docstring wasn't changed since this version of _exec was added in revision 90915 (this version of _exec replaced the one that was in _SpecMethods), so I guess the exact phrasing of that docstring wasn't already challenged.
        - _find_spec - I believe "Find a module's spec." is more accurate than "Find a module's loader.", as the function returns a spec and not a loader. It might be argued that ultimately the function does find a loader. However, we have the perfectly normal case where it is a namespace package, and _find_spec doesn't find any loader. 
        This docstring was the docstring of _find_module, and was left as is when _find_spec replaced _find_module in revision 87347 (which implemented PEP 451), so I guess the exact phrasing of that docstring (in the context of _find_spec) wasn't already challenged.
    2. in Lib/importlib/_bootstrap_external.py:
        - PathFinder._path_hooks - It seems the function's docstring was left as is when issue #14605 was addressed, and thus, since revision 76566, the docstring is inaccurate. 
        - PathFinder.find_spec - I believe "Try to find a spec for 'fullname' on..." is more accurate than "find the module on..." (I took the phrasing from Doc\library\importlib.rst). 
        It seems this docstring was copied from PathFinder.find_module when it was added in revision 87347, and was never changed since, so I guess its exact phrasing wasn't already challenged. 
        - FileFinder.find_spec - It seems this docstring was copied from FileFinder.find_loader when it was added in revision 87347, and was never changed since. Again, I took the phrasing of my proposed new docstring from Doc\library\importlib.rst.


diff:
The patches diff is attached.


tests:
I played a little with the interpreter, and everything worked as usual. I also verified that CPython was indeed compiled with my patched frozen modules (made by _freeze_importlib.exe), by reading patched docstrings interactively via 'import _frozen_importlib' and 'import _frozen_importlib_external'.

In addition, I run 'python -m test' (on my 64-bit Windows 10) before and after applying the patch, and got quite the same output.
the outputs of both runs are attached.

----------
components: Library (Lib)
files: issue.diff
keywords: patch
messages: 265076
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: mistakes in docstrings in the import machinery
versions: Python 3.6
Added file: http://bugs.python.org/file42770/issue.diff

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

From report at bugs.python.org  Sun May  8 00:24:59 2016
From: report at bugs.python.org (Joshua Morton)
Date: Sun, 08 May 2016 04:24:59 +0000
Subject: [New-bugs-announce] [issue26973] Dict View binops permit non-set
 types
Message-ID: <1462681499.01.0.123702812837.issue26973@psf.upfronthosting.co.za>


New submission from Joshua Morton:

Following the comments in python ideas [1], I'm submitting a bug report. In python 3, dictionary views (KeysView and ItemsView specifically) do not adhere to the same interface as Sets. Specifically, the __and__, __or__, __xor__, and __sub__ methods on Views will accept a non-set type (`{}.keys() | []`), while the same throws a TypeError on a Set. The suggested, not-backwards-compatible solution, was to have dictviews raise errors in the same way. 

[1] https://mail.python.org/pipermail/python-ideas/2016-April/039469.html

----------
messages: 265110
nosy: Joshua Morton
priority: normal
severity: normal
status: open
title: Dict View binops permit non-set types
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Sun May  8 01:13:47 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 May 2016 05:13:47 +0000
Subject: [New-bugs-announce] [issue26974] Crash in Decimal.from_float
Message-ID: <1462684427.76.0.86950702335.issue26974@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Following example causes a segmentation fault.

from decimal import Decimal
class BadFloat(float):
    def as_integer_ratio(self):
        return 1
    def __abs__(self):
        return self

Decimal.from_float(BadFloat(1.2))

----------
components: Extension Modules
messages: 265113
nosy: facundobatista, mark.dickinson, rhettinger, serhiy.storchaka, skrah
priority: normal
severity: normal
status: open
title: Crash in Decimal.from_float
type: crash
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun May  8 02:45:45 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 May 2016 06:45:45 +0000
Subject: [New-bugs-announce] [issue26975] Decimal.from_float works
 incorrectly for non-binary floats
Message-ID: <1462689945.43.0.203317585545.issue26975@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Decimal.from_float() works correctly only if the denominator of as_integer_ratio() of argument is the power of two. Example:

>>> from decimal import Decimal
>>> class DecimalFloat(float):
...     def as_integer_ratio(self):
...         return Decimal(str(self)).as_integer_ratio()
...     def __abs__(self):
...         return self
... 
>>> DecimalFloat(1.2).as_integer_ratio()
(6, 5)
>>> Decimal.from_float(DecimalFloat(1.2))
Decimal('1.50')

----------
components: Extension Modules, Library (Lib)
messages: 265116
nosy: facundobatista, mark.dickinson, rhettinger, serhiy.storchaka, skrah
priority: normal
severity: normal
status: open
title: Decimal.from_float works incorrectly for non-binary floats
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun May  8 07:15:48 2016
From: report at bugs.python.org (Davide Rizzo)
Date: Sun, 08 May 2016 11:15:48 +0000
Subject: [New-bugs-announce] [issue26976] pathlib equivalent for
 os.path.realpath()
Message-ID: <1462706148.1.0.443359172953.issue26976@psf.upfronthosting.co.za>


New submission from Davide Rizzo:

pathlib doesn't provide an exact replacement for os.path.realpath().

Path.resolve() is the closest equivalent, but differs in behavior in one case: when the path does not exist.

>>> os.path.realpath('/foo')
'/foo'

>>> Path('/foo').resolve()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/lib/python3.5/pathlib.py", line 1094, in resolve
    s = self._flavour.resolve(self)
  File "/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/lib/python3.5/pathlib.py", line 330, in resolve
    return _resolve(base, str(path)) or sep
  File "/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/lib/python3.5/pathlib.py", line 315, in _resolve
    target = accessor.readlink(newpath)
  File "/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/lib/python3.5/pathlib.py", line 422, in readlink
    return os.readlink(path)
FileNotFoundError: [Errno 2] No such file or directory: '/foo'

This impairs pathlib usefulness to sanitize user input when I am about to create a file or a directory. The file does not exist yet, and pathlib doesn't provide an easy mean to validate whether the provided input is safe.

----------
components: Library (Lib)
messages: 265128
nosy: davide.rizzo
priority: normal
severity: normal
status: open
title: pathlib equivalent for os.path.realpath()
versions: Python 3.6

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

From report at bugs.python.org  Sun May  8 07:56:09 2016
From: report at bugs.python.org (Ian Foote)
Date: Sun, 08 May 2016 11:56:09 +0000
Subject: [New-bugs-announce] [issue26977] Unnecessary line in
 statistics.pvariance
Message-ID: <1462708569.69.0.176390210867.issue26977@psf.upfronthosting.co.za>


New submission from Ian Foote:

In statistics.pvariance, the sum of squares helper function (_ss) is called twice and the first return value is unused: https://github.com/python/cpython/blob/9043c80b0daaddb5bff1e37432d503910506727f/Lib/statistics.py#L596

----------
components: Library (Lib)
messages: 265131
nosy: Ian Foote
priority: normal
severity: normal
status: open
title: Unnecessary line in statistics.pvariance
versions: Python 3.6

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

From report at bugs.python.org  Sun May  8 12:22:03 2016
From: report at bugs.python.org (Ram Rachum)
Date: Sun, 08 May 2016 16:22:03 +0000
Subject: [New-bugs-announce] [issue26978] Implement pathlib.Path.link (Using
 os.link)
Message-ID: <1462724523.47.0.917337612912.issue26978@psf.upfronthosting.co.za>


Changes by Ram Rachum <ram at rachum.com>:


----------
components: Library (Lib)
nosy: cool-RR
priority: normal
severity: normal
status: open
title: Implement pathlib.Path.link (Using os.link)
versions: Python 3.6

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

From report at bugs.python.org  Sun May  8 14:24:38 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 May 2016 18:24:38 +0000
Subject: [New-bugs-announce] [issue26979] The danger of PyType_FromSpec()
Message-ID: <1462731878.82.0.9073654009.issue26979@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

There is a catch when convert static types to dynamic types using PyType_FromSpec(). tp_new is not inherited for static types whose base class is 'object' (see a comment in inherit_special() in Objects/typeobject.c:4569 for explanation). Such types left not callable and not pickleable unless tp_new is explicitly specified. But since PyType_FromSpec() creates heap types, tp_new is inherited from the base 'object' class. Converted types unexpectedly becomes callable and pickleable. Since object.__new__ wouldn't insure the invariants that the extension type's own factory function ensures, instantiated object can be in inconsistent state. Using it can lead to a crash. We already fallen two time in this catch with _tkinter (issue15721) and curses.panel (issue14936) modules (fixed in issue23815).

We should document this catch and a way to avoid it (explicitly set tp_new to NULL for the result of PyType_FromSpec()). Both the C API documentation and PEP 384 should be updated. Would be great if standard examples include a case of non-callable heap type.

As option we can introduce more handy way to set tp_new to NULL by adding {Py_tp_new, NULL} to slots array (currently this doesn't have any effect). But this is new feature.

----------
assignee: docs at python
components: Documentation
messages: 265152
nosy: docs at python, loewis, serhiy.storchaka
priority: high
severity: normal
status: open
title: The danger of PyType_FromSpec()
type: security
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun May  8 17:39:08 2016
From: report at bugs.python.org (texttheater)
Date: Sun, 08 May 2016 21:39:08 +0000
Subject: [New-bugs-announce] [issue26980] The path argument of
 asyncio.BaseEventLoop.create_unix_connection is not documented
Message-ID: <1462743548.86.0.976035936413.issue26980@psf.upfronthosting.co.za>


New submission from texttheater:

The documentation does not say what this argument is for.

It says "See the BaseEventLoop.create_connection() method for parameters", but that method does not have a path argument.

The argument seems to be required unless the keyword argument sock is given.

----------
assignee: docs at python
components: Documentation
messages: 265170
nosy: docs at python, texttheater
priority: normal
severity: normal
status: open
title: The path argument of asyncio.BaseEventLoop.create_unix_connection is not documented
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun May  8 19:45:21 2016
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 08 May 2016 23:45:21 +0000
Subject: [New-bugs-announce] [issue26981] add compatibility shim for enum34
 backport
Message-ID: <1462751121.21.0.925705458571.issue26981@psf.upfronthosting.co.za>


New submission from Ethan Furman:

_sunder_ methods are reserved for internal Enum use, and if the user tries to use any an exception is raised.

Consequently, the enum34 backport uses __order__ instead of _order_ to specify a definition order for its members.

I would like to do two things:

1) add _order_ to the stdlib version

2) ensure the actual definition order is the same as what is specified
   in _order_

----------
assignee: ethan.furman
messages: 265174
nosy: barry, eli.bendersky, ethan.furman
priority: normal
severity: normal
stage: needs patch
status: open
title: add compatibility shim for enum34 backport
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Sun May  8 21:11:51 2016
From: report at bugs.python.org (James Tatum)
Date: Mon, 09 May 2016 01:11:51 +0000
Subject: [New-bugs-announce] [issue26982] Clarify forward annotations in PEP
 484
Message-ID: <1462756311.8.0.304204398387.issue26982@psf.upfronthosting.co.za>


New submission from James Tatum:

In https://github.com/python/typeshed/issues/180, we discussed a slight ambiguity with PEP 484's mention of forward references. It wasn't entirely clear that they don't apply unless using function annotations. This patch attempts to clear up the ambiguity.

----------
assignee: docs at python
components: Documentation
files: forward_references.patch
keywords: patch
messages: 265177
nosy: James.Tatum, docs at python
priority: normal
severity: normal
status: open
title: Clarify forward annotations in PEP 484
Added file: http://bugs.python.org/file42785/forward_references.patch

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

From report at bugs.python.org  Mon May  9 09:46:33 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 May 2016 13:46:33 +0000
Subject: [New-bugs-announce] [issue26983] float() can return not exact float
 instance
Message-ID: <1462801593.23.0.789372695786.issue26983@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The float constructor can return an instance of float subclass.

>>> class FloatSubclass(float):
...     pass
... 
>>> class BadFloat:
...     def __float__(self):
...         return FloatSubclass(1.2)
... 
>>> type(float(BadFloat()))
<class '__main__.FloatSubclass'>

Comparing with other types, complex() always returns complex:

>>> class ComplexSubclass(complex):
...     pass
... 
>>> class BadComplex:
...     def __complex__(self):
...         return ComplexSubclass(1.2, 3.4)
... 
>>> type(complex(BadComplex()))
<class 'complex'>

And int() can return an instance of int subclass, but this behavior is deprecated:

>>> class BadInt:
...     def __int__(self):
...         return True
... 
>>> int(BadInt())
__main__:1: DeprecationWarning: __int__ returned non-int (type bool).  The ability to return an instance of a strict subclass of int is deprecated, and may be removed in a future version of Python.
True

May be we should either deprecate __float__ returning non-float (as for int), or convert the result to exact float (as for complex).

The constructor of float subclass always returns an instance of correct type.

>>> class FloatSubclass2(float):
...     pass
... 
>>> type(FloatSubclass2(BadFloat()))
<class '__main__.FloatSubclass2'>

----------
components: Interpreter Core
messages: 265191
nosy: mark.dickinson, serhiy.storchaka
priority: normal
severity: normal
status: open
title: float() can return not exact float instance
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Mon May  9 10:02:31 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 May 2016 14:02:31 +0000
Subject: [New-bugs-announce] [issue26984] int() can return not exact int
 instance
Message-ID: <1462802551.63.0.282711121635.issue26984@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

The int constructor can return an instance of int subclass.

>>> class BadTrunc:
...     def __trunc__(self):
...         return True
... 
>>> int(BadTrunc())
True

When __int__ returns non-exact int, at least a warning is emitted:

>>> class BadInt:
...     def __int__(self):
...         return True
... 
>>> int(BadInt())
__main__:1: DeprecationWarning: __int__ returned non-int (type bool).  The ability to return an instance of a strict subclass of int is deprecated, and may be removed in a future version of Python.
True

The constructor of int subclass always return an instance of correct type:

>>> class IntSubclass(int):
...     pass
... 
>>> type(IntSubclass(BadTrunc()))
<class '__main__.IntSubclass'>
>>> type(IntSubclass(BadInt()))
__main__:1: DeprecationWarning: __int__ returned non-int (type bool).  The ability to return an instance of a strict subclass of int is deprecated, and may be removed in a future version of Python.
<class '__main__.IntSubclass'>

I don't know if it is worth to deprecate __trunc__ returning non-exact int, since this special method is used in math.trunc(). But I think that the int constructor should convert its result to exact int. If some preparatory period is needed, it can first start to emit FutureWarning.

----------
components: Interpreter Core
messages: 265196
nosy: mark.dickinson, serhiy.storchaka
priority: normal
severity: normal
status: open
title: int() can return not exact int instance
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Mon May  9 10:11:42 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 09 May 2016 14:11:42 +0000
Subject: [New-bugs-announce] [issue26985] Information about CodeType in
 inspect documentation is outdated
Message-ID: <1462803102.24.0.542356144335.issue26985@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

Information about CodeType in inspect documentation is outdated. It lacks attributes: co_kwonlyargcount, co_freevars, co_cellvars. And co_flags lacks many more options. These also apply to the comments of inspect.iscode source code.

----------
assignee: docs at python
components: Documentation
messages: 265197
nosy: docs at python, xiang.zhang
priority: normal
severity: normal
status: open
title: Information about CodeType in inspect documentation is outdated
versions: Python 3.6

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

From report at bugs.python.org  Mon May  9 11:49:02 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 09 May 2016 15:49:02 +0000
Subject: [New-bugs-announce] [issue26986] Enhance PyFunction_New
 documentation
Message-ID: <1462808942.73.0.503495552069.issue26986@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

Doc of PyFunction_New[1] is not perfect. 

1. *__module__* is not retrieved from *code* but *globals*.
2. Add descriptions for annotations and qualname.

[1] https://docs.python.org/3/c-api/function.html#c.PyFunction_New

----------
files: PyFunction_New_doc.patch
keywords: patch
messages: 265201
nosy: xiang.zhang
priority: normal
severity: normal
status: open
title: Enhance PyFunction_New documentation
Added file: http://bugs.python.org/file42791/PyFunction_New_doc.patch

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

From report at bugs.python.org  Mon May  9 12:26:28 2016
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 09 May 2016 16:26:28 +0000
Subject: [New-bugs-announce] [issue26987] Comment/implementation
 disagreement in Thread._bootstrap_inner
Message-ID: <1462811188.69.0.863333138348.issue26987@psf.upfronthosting.co.za>


New submission from Zachary Ware:

The comment at Lib/threading.py:925 notes that sys.stderr should be used if possible, but the implementation uses self._stderr in spite of checking _sys.stderr is not None.  I believe this was just an oversight in 644b677c2ae5, which added the check and also switched from _sys.stderr.write(...) to print(... file=...).

----------
components: Library (Lib)
messages: 265208
nosy: serhiy.storchaka, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Comment/implementation disagreement in Thread._bootstrap_inner
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon May  9 21:34:31 2016
From: report at bugs.python.org (John Hagen)
Date: Tue, 10 May 2016 01:34:31 +0000
Subject: [New-bugs-announce] [issue26988] Add AutoNumberedEnum to stdlib
Message-ID: <1462844071.91.0.106881823757.issue26988@psf.upfronthosting.co.za>


New submission from John Hagen:

I suggest that the AutoNumberedEnum be added to the standard library for the following reasons:

1) Provides a fundamental tool for defining a unique, abstract set of coupled members
2) Avoids boilerplate @enum.unique for a very common use case of enumerations
3) The code already exists in the Python documentation, so it has been vetted at some level

The AutoNumberedEnum also allows the developer to make a clearer distinction
between enumerations whose values have special meaning and those that do not.

Consider:

@enum.unique
class Color(enum.Enum):
    red = 1
    blue = 2
    green = 3

@enum.unique
class Shape(enum.Enum):
    """Member values denote number of sides."""
    circle = 1
    triangle = 3
    square = 4

With AutoNumberedEnum it's possible to better express the intent that 
the value of Color members does not hold special meaning, while
Shape members do:

class Color(enum.AutoNumberedEnum):
    red = ()
    blue = ()
    green = ()

@enum.unique
class Shape(enum.Enum):
    """Member values denote number of sides."""
    circle = 1
    triangle = 3
    square = 4

For enumerations with many members (10s), there becomes a maintenance
issue when inserting new enumerations into the list:

@enum.unique
class Color(enum.Enum):
    aquamarine = 1
    blue = 2
    fushia = 3
    # inserting a member here (perhaps because it's clearest to keep these in alphabetic order)
    # results in having to increment all following members
    ...
    green = 40
    red = 41

Most other languages have support for naming enumerations
without explicitly declaring their values (albeit with 
specialized syntax that makes it cleaner):

C++: http://en.cppreference.com/w/cpp/language/enum
C#: https://msdn.microsoft.com/en-us/library/sbbt4032.aspx
Java: https://docs.oracle.com/javase/tutorial/java/javaOO/enum.html
Rust: https://doc.rust-lang.org/book/enums.html

Currently, a developer can copy the code from the Python docs into
his or her project, or add a dependency on aenum.  I would argue
that it belongs in the standard library.

If there are objections to it being too magical, I would argue
it's already spelled out in the docs, so it's being prescribed
as a solution already.  I think it should be very clear when you
derive from "AutoNumberedEnum" what is going on.

The code is very simple, so I would
hope maintenance would not be difficult.

----------
components: Library (Lib)
messages: 265214
nosy: John Hagen, ethan.furman
priority: normal
severity: normal
status: open
title: Add AutoNumberedEnum to stdlib
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Mon May  9 22:19:43 2016
From: report at bugs.python.org (wangluyao)
Date: Tue, 10 May 2016 02:19:43 +0000
Subject: [New-bugs-announce] [issue26989] error in installation of
 ez_setup.py
Message-ID: <1462846783.15.0.752722442438.issue26989@psf.upfronthosting.co.za>


New submission from wangluyao:

There were some wrong in my installion of my ez_setup.py.Because my compute is 64 bits,so I have to install ez_setup.py before I want to install pyserial-3.0.1-py2.py3-none-any.whl this model.
 But it tells me that"urllib2.URLError:<urlopen error [Errno 11004]getaddrinfo failed>"

----------
components: Installation
files: QQ??20160510101142.png
messages: 265219
nosy: wangluyao
priority: normal
severity: normal
status: open
title: error in installation of ez_setup.py
versions: Python 2.7
Added file: http://bugs.python.org/file42792/QQ??20160510101142.png

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

From report at bugs.python.org  Mon May  9 23:34:33 2016
From: report at bugs.python.org (mfmain)
Date: Tue, 10 May 2016 03:34:33 +0000
Subject: [New-bugs-announce] [issue26990] file.tell affect decoding
Message-ID: <1462851273.73.0.390821132844.issue26990@psf.upfronthosting.co.za>


New submission from mfmain:

C:\tmp>hexdump badtell.txt

    000000: 61 20 6B 0D 0A D2 BB B0-E3                       a k......

C:\tmp>type test.py

    with open(r'c:\tmp\badtell.txt', "r", encoding='gbk') as f:
        while True:
            pos = f.tell()
            line = f.readline();
            if not line: break
            print(line)

C:\tmp>python test.py

    a k
    
    Traceback (most recent call last):
      File "test.py", line 4, in <module>
        line = f.readline();
    UnicodeDecodeError: 'gbk' codec can't decode byte 0xd2 in position 0:  incomplete multibyte sequence


When I remove f.tell() statement, it decoded successfully.
I tried python3.4/3.5 x64 on win7/win10, it is all the same.

----------
components: Unicode
messages: 265224
nosy: ezio.melotti, haypo, mfmain
priority: normal
severity: normal
status: open
title: file.tell affect decoding
versions: Python 3.5

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

From report at bugs.python.org  Tue May 10 07:00:17 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 10 May 2016 11:00:17 +0000
Subject: [New-bugs-announce] [issue26991] Possible reference leak in
 MAKE_FUNCTION
Message-ID: <1462878017.45.0.401291205212.issue26991@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

*names* is not Py_DECREFed in MAKE_FUNCTION in error case.

----------
files: make_function_reference_leak.patch
keywords: patch
messages: 265235
nosy: serhiy.storchaka, xiang.zhang
priority: normal
severity: normal
status: open
title: Possible reference leak in MAKE_FUNCTION
versions: Python 3.6
Added file: http://bugs.python.org/file42794/make_function_reference_leak.patch

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

From report at bugs.python.org  Tue May 10 09:20:35 2016
From: report at bugs.python.org (Sam Taylor)
Date: Tue, 10 May 2016 13:20:35 +0000
Subject: [New-bugs-announce] [issue26992] 64-bit Python 2.7.11 hangs in
 64-bit Windows 10 - CMD and Git Bash
Message-ID: <1462886435.44.0.374942055679.issue26992@psf.upfronthosting.co.za>


New submission from Sam Taylor:

We have seen an issue where the 64-bit 2.7.11 Python Interpreter hangs whilst trying to run it in either Command Prompt or Git Bash on 64-bit Windows 10.

The issue is intermittent, the interpreter will run sometimes but will often hang immediately after typing 'python + ENTER' in either of the terminals.  There seems to be no pattern when it won't work.

We haven't seen this issue in 64-bit Windows 8.1.

The workaround was to install the 32-bit version of python 2.7.11 on 64-bit Windows 10 PC's - the interpreter is completely reliable in this case and running 32-bit has no effect on our work.

I haven't found the exact same issue elsewhere on the python bugs forum but similar issues point to Windows 10 dropping some functionality which Windows 8.1 and earlier versions had.

Setting up pseudo terminals does help but is a messy workaround.  Adding and removing PYTHONPATH etc from the environment variables doesn't have any effect.

Everything is working fine so this isn't really an issue.  I'm just interested if anyone else has experienced this and if they can shed any light onto what causes it.

----------
components: Interpreter Core, Windows
messages: 265246
nosy: paul.moore, sam.taylor.bs, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: 64-bit Python 2.7.11 hangs in 64-bit Windows 10 - CMD and Git Bash
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Tue May 10 14:27:47 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 10 May 2016 18:27:47 +0000
Subject: [New-bugs-announce] [issue26993] Copy idlelib *.py files with new
 names
Message-ID: <1462904867.82.0.814804625056.issue26993@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Proposal: duplicate nearly all of the existing idlelib *.py files, with new names.  This would implement the intention of PEP 434 with respect to freely changing idlelib APIs.  I view it as a prerequisite for most anticipated patches.  A longer than usual explanation follows.

Last August/September, I realized that the way to modernize and improve IDLE, while maintaining backward compatibility, would be to add copies of existing .py files.  The copies with new names (the idle3 set) could be freely edited  while existing files (the idle2 set) could be pretty much left alone until deleted.  IDLE would temporarily, for a time yet to be decided, have two operating modes.  The idle2 mode would only use exiting files and tk widgets.  The idle3 mode would use new files and ttk widgets.

Renaming and refactoring files, including PEP 8 updates, is needed for bug fixing, testing, and feature upgrades, including addition of a single window multiple pane design.  However, doing so with existing files would break direct imports and subsequent calls (see #24225, for some discussion).  Ttk widgets cannot be used on systems with tcl/tk 8.4. (This and related issues was discussed with Nick, Ned, and release managers, as well as in #24759, especially msg247993 & msg248031, and in #24750).

I originally planned to add new files one or a few at a time.  I did not start doing do immediately, before the November-December releases, because I wanted to fix some bugs in the existing files before they were bifurcated. I did not start doing so after the releases because I could not figure out how to safely manage an 'idle3/ttk' mode that mixed a shrinking subset of idle2 files and the growing set of new idle3 files.  It seemed like a recipe for introducing bugs.  I decided instead that the best solution would be to create a complete, tested idle3 set all at once, using the following steps.  (Idlelib/idle_test/*.py files will be handled similarly, but with differences discussed later.)

0. Decide on the new names.
1. Copy idlelib/*.py files and hg add them.
2. Revise imports in new idle3 files.
3. Test to make sure that the idle3 set works right. 
4. Upload patch for review, and commit.

Possible variation: push after step 1, so that the revisions in step 2 are a separate patch instead of being folded into a combined patch.  I do not propose that because the new files would be useless until revised.


DETAILS OF CURRENT PLAN:

0. @newnames.txt, https://bugs.python.org/file42678/%40newnames.txt is attached to issue #24225.  It lists old name, Sweigart's new name, and my current new name.  Bikeshedding names can be done on that issue.

Leaving aside the unused and deprecated 'idlever' and the startup files, all of which are omitted from the list, there are currently three short lowercase names: 'help', 'rpc', and 'run'.  To reuse these names for the idle3 set, these could be renamed, in a preliminary patch, to have a captital letter.  I think this should be okay because  'help' specifies that is it subject to change, and the other two are extremely unlikely to be used outside of IDLE.  If this were done, implementation files could be identified as 'idle2' versus 'idle3' by the presence of an uppercase letter in the name.

Serhiy requested on #24225 that renames of existing 3.5 files be backported to 2.7.  Since I do not anticipate many patches to idle2 files, let alone backports to 2.7, I am not sure that this is needed.

Alternatively, I could name the copies help3, rpc3, and run3.

1. Use the name list from step 0 to create copyall.bat, to be run in the 3.5 repository idlelib directory.  It will have 'copy src dst' for each file and end with 'hg add ../idlelib' (or 'cd ..; hg add idlelib') to 'add' them all.  I am aware of 'hg copy', but the docs are not clear on whether there is any lingering effect after pushing the adds.  The pre-commit merge effect seems unneeded as no one else is pushing idlelib commits (except Serhiy ocassionally, as part of multifile patches, and he should be reading this ;-).

2. Review Al Sweigart's 'idle_updating_imports.patch' from #24225.  Al ran revised unittests, but the coverage is too spotty to adequately test.  So review is needed.

The tricky part is that many modules and classes have the same name, such as AutoComplete the module and AutoComplete the class.  Module references must be changed to the new name; class references must not be touched.  I would use IDLE's File in Files (grep) with each module name to find references to check.  The import in each client module ('import X' versus 'from X import X' determines how bare 'X' is used in rest of the module.

If the patch seems correct, or mostly so, perhaps after a few corrections,  write a script, using the step 0 name list, to replace Al's new names with my new names, where they are different.

Apply the patch.  Since Al's patch is a year old, some chunks will fail to apply.  Do these by hand.

3. Testing: Make sure that all new files can be imported.  Does test___all__ do this?  Run revised idle_test/htest.py, which creates an example of all visible windows and widgets, and invites some human manipulation. Run revised unittest files, though coverage is spotty. Run idle3 with 'python -m idlelib.shell' and try all menu options.

4. With respect to idlelib, the patch will consist only of additions (of revised versions of copies with new names).  To check the macosx copy, 'python -m idlelib.shell' should be run on a Mac after applying the patch.


OTHER ISSUES

Unittests: The current 'test_xyz' files in 'idle_test' have lowercase names, anticipating the new names proposed here .  For instance, the tests for AutoComplete.py are in 'test_autocomplete.py' rather than 'test_AutoComplete.py'.  If it is desired to keep the incomplete set of tests for idle2 files, the files would have to be copied (with uppercase-containing names) before the imports in the current test files are updated.  A few of the current files will have to be renamed to match new names different from what I anticipated.

The incomplete automated unittests are supplemented by much more complete semi-automated human-mediated tests (htest.py).  But testing is still inadequate.  The November/December releases had the most patches for a long while, but also three regressions.  Two did not manifest on my Windows machine.  The worst (#26673, posted March30) appears to be linux-tk8.6 specific.

IDLE issues need to start following the 'test needed' rule.  To do so, it must be sensibly possible to write complete coverage tests, and that often requires refactoring.  Contemplating 'What tests could have caught the [first two] regressions?" is what prodded me to switch to this all-at-once plan.

Once written, the tests need to be run on all three platforms, perhaps with both tk 8.6 and tk 8.5 on Linux and Mac.  It would help if there were Linux buildbots that ran tkinter and idlelib tests that need a gui resource.  Short of that, refactoring is sometimes needed to separate gui from non-gui code.  I otherwise need to be more aggressive in getting myself and others to do what the buildbots don't or can't.


Revisiion history:  The repository history will stay with idle2 files.  The planned splitting and merging of files in the idle3 group would mix up history anyway.  I plan to add comments to modules, classes, and functions as to where they were copied from, so the history of particular code sections can be  manually traced.


Deletion of idle2 files:  The reason to copy rather than rename files is because renaming has not been considered currently possible.  However, Al Sweigart reported that the IdleX extension test suite ran after his renaming. If our only other back-compatibility concern were running on old Macs, the following might work: copy idlelib to, say, idlelib2; modernize idlelib as described here, except for starting with renames rather than copies; when making an old Mac installer, copy the frozen idlelib2 on top of idlelib.

Barring that alternative, the idle2 files will be deprecated and removed sometime from 3.6 to the planned removal of deprecated modules, after 2.7 support ends.  


PEP 434 and idlelib: PEP 434 declared idlelib 'mostly private', though we have not yet been willing to much act on that.  The purpose was to allow the changes described above, not to deny that some modules are or could be useful as library modules for other code.  With this issue, the idle2 files will be deprecated and mostly untouched, so there will be no point to calling them private.

I want to add an 'idlelib' section to the doc that briefly explains the package contents.  It might say something like "The main purpose of idlelib files is to implement IDLE.  There are two sets of files.  The idle2 files, stable and deprecated, are listed in README2.txt.  The idle3 files, discussed in README3.txt, are permanently private/provisional except and to the degree documented below."

The section would also document public APIs.  For the idle2 files, this would include how to use IDLE's syntax highlighting (as in turtledemo), and probably IDLE's scrolled widgets (unless and until moved to tkinter/).  In February, there were 2 Stackoverflow questions about using idlelib modules. One was about syntax hightlighting (answer: 'See turtledemo').  The other was about autocompletion (answer: "I don't know.  Refactoring is needed.").  So at least a few people are trying to use idlelib modules.

The planned refactoring of idle3 files to make things more usable within IDLE and easier to test will also make the same files more usable outside of IDLE.  For example, class ClassBrowser is hardcoded as a standalone Toplevel window.  The renamed ModuleBrowser will be a widget that can be placed on a Toplevel window, a pane of a PanedWindow, a tab of a Notebook, or anywhere else a widget can be put.  

ClassBrowser also hardcodes the double-click action as calling IDLE's filelist.open.  It has a rather opaque signature.  After refactoring, the new browser module should not need any indlelib imports and the renamed class might be documented as follows:

"browser.ModuleBrowser(master, module, opener, cnf={}, **kw).
 A ttk-based widget that displays the classes and functions of a module.  It comprises a ttk Frame, Treeview, and Scrollbars.  *module* is a path string, Path, or iterable of lines (open file or list of lines).  Double-clicking a tree item calls *opener*(module, line). Details are subject to change."  The allowed configuration options would also be listed.

Idle would pass 'opener=filelist.open'.  Tests would pass a mock that records calls.  Other users would pass their own click handler.  


IDLE and the stdlib:  Guido, last August on idle-sig, you both approved improving IDLE and expressed, as I understood it, an intention to delete idlelib as soon as you felt you could.  What is your intention now, after reading this concrete proposal?  Deprecate and someday remove everything? or keep improved IDLE indefinitely?

I think we need this decided now.  Once idlelib becomes in part a package of reusable and documented editor/IDE components, it would be much harder to remove.  On the otherhand, no one, including me, wants to spend substantial time on code expected to be deleted.

----------
assignee: terry.reedy
components: IDLE
messages: 265254
nosy: gvanrossum, markroseman, ncoghlan, ned.deily, serhiy.storchaka, terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: Copy idlelib *.py files with new names
type: enhancement
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue May 10 14:30:29 2016
From: report at bugs.python.org (Nathan Naze)
Date: Tue, 10 May 2016 18:30:29 +0000
Subject: [New-bugs-announce] [issue26994] unexpected behavior for booleans
 in argparse
Message-ID: <1462905029.96.0.678738443976.issue26994@psf.upfronthosting.co.za>


New submission from Nathan Naze:

Setting a boolean type in argparse gives unexpected behavior when setting "True", "False", etc.

https://gist.github.com/nanaze/db63e3f63e318408e3223bf1245d9752

Would have expected parsing to fail for unclear input that doesn't neatly map to a boolean value.

----------
components: Library (Lib)
messages: 265256
nosy: Nathan Naze
priority: normal
severity: normal
status: open
title: unexpected behavior for booleans in argparse
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue May 10 14:58:35 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 May 2016 18:58:35 +0000
Subject: [New-bugs-announce] [issue26995] Add tests for parsing float and
 object arguments
Message-ID: <1462906715.34.0.789444535015.issue26995@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch adds tests for direct testing argument parsing C API with format units "f", "d", "D" (float, double, complex) and "S", "Y", "U" (PyObject* of type bytes, bytearray and str).

----------
components: Tests
files: test_getargs_floats_objects.patch
keywords: patch
messages: 265261
nosy: mark.dickinson, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Add tests for parsing float and object arguments
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42806/test_getargs_floats_objects.patch

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

From report at bugs.python.org  Tue May 10 22:54:38 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 11 May 2016 02:54:38 +0000
Subject: [New-bugs-announce] [issue26996] Add secrets module as per PEP 506.
Message-ID: <1462935278.01.0.338603165746.issue26996@psf.upfronthosting.co.za>


New submission from Steven D'Aprano:

(This is already done, but I should have added a ticket before committing the new module.)

See PEP-0506.

----------
assignee: steven.daprano
components: Library (Lib)
messages: 265288
nosy: steven.daprano
priority: normal
severity: normal
status: open
title: Add secrets module as per PEP 506.
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Wed May 11 06:40:33 2016
From: report at bugs.python.org (Martin Jones)
Date: Wed, 11 May 2016 10:40:33 +0000
Subject: [New-bugs-announce] [issue26997] Docs for pdb should note that
 __future__ magic doesn't work
Message-ID: <1462963233.92.0.988524057924.issue26997@psf.upfronthosting.co.za>


New submission from Martin Jones:

when debugging a program at the pdb prompt, attempting to import from the __future__ module appears successful, but actually doesn't work:

(Pdb) from __future__ import division
(Pdb) 2/3
0

This leads to inconsistencies between statements evaluated on the pdb prompt and those evaluated in the program, which can hamper debugging. It would be good to have a note added to the 2.7 documentation for pdb along the lines of:

Note: importing from the __future__ module does not work under pdb.

----------
assignee: docs at python
components: Documentation
messages: 265300
nosy: Martin Jones, docs at python
priority: normal
severity: normal
status: open
title: Docs for pdb should note that __future__ magic doesn't work
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Wed May 11 07:00:28 2016
From: report at bugs.python.org (AlexWMF)
Date: Wed, 11 May 2016 11:00:28 +0000
Subject: [New-bugs-announce] [issue26998] Unable to import "site" in an
 embedded application
Message-ID: <1462964428.89.0.669222260806.issue26998@psf.upfronthosting.co.za>


New submission from AlexWMF:

Unable to import "site" error occurs in an embedded application.
I have made small research and found why this module isn't visible for python core.

I have run the python 2.7.11 x86 (for all users) at my win 7x64.
The installer writes the registry key "Software\Wow6432Node\Python\PythonCore\%s\", where "%s" is equal to "32" on my machine.
Difference between x86 and x86_64 registry keys is only in "Wow6432Node" subkey in that key path. 
Tracing the application, I have got to getpythonregpath(...) function. This function reads the registry key to determine "PythonPath".
The python core tries to open the following key "Software\Wow6432Node\Python\PythonCore\2.7-32\PythonPath" and fails due to absence of that key.

In this case, the DLL was compiled with PyWin_DLLVersionString = "2.7-32".
Because of this, the python core can't open this key and the "sys.path" stays not fully filled with paths from registry.

The PyWin_DLLVersionString is compiles from MS_DLL_ID="$(SysWinVer)", which is equal to "2.7-32" on my system.
It's defined in .\PCbuild\python.props file as 
<SysWinVer>$(MajorVersionNumber).$(MinorVersionNumber)</SysWinVer>
<SysWinVer Condition="$(Platform) == 'Win32' or $(Platform) == 'x86'">$(SysWinVer)-32</SysWinVer>

So, the simplest solution of this bug is to fix installer to store proper key

----------
components: Installation
messages: 265303
nosy: AlexWMF
priority: normal
severity: normal
status: open
title: Unable to import "site" in an embedded application
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed May 11 09:11:07 2016
From: report at bugs.python.org (Richard Neumann)
Date: Wed, 11 May 2016 13:11:07 +0000
Subject: [New-bugs-announce] [issue26999] Add child seperator keyword to
 logging.basicConfig and use it in Logger.getChild()
Message-ID: <1462972267.52.0.758666146863.issue26999@psf.upfronthosting.co.za>


New submission from Richard Neumann:

Currently Python's logging library has the Child-Separator hard-coded in Logger.getChild() as '.'.
It would be useful to have the ability to preset this via an optional basicConfig() argument like 'child_sep=' and preset it to '.' to retain the current behaviour.
In my case I will need to monkey-patch the getChild() method to use a different separator ('->') because I use '.' for different purposes within the loggers' names.
The current behaviour would lead to ugly and mistakable output.

----------
components: Library (Lib)
messages: 265312
nosy: Richard Neumann
priority: normal
severity: normal
status: open
title: Add child seperator keyword to logging.basicConfig and use it in Logger.getChild()
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Wed May 11 12:45:55 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 11 May 2016 16:45:55 +0000
Subject: [New-bugs-announce] [issue27000] improve document of filter
Message-ID: <1462985155.22.0.859825042381.issue27000@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

I think filter's doc can be improved[1]:

1. It doesn't mention ``bool``. ``bool`` is treated the same way as ``None``. It is not called. But this is not mentioned.
2. 'the identity function is assumed' is confusing, at least for me. It looks like when ``None`` is passed, *function* is set to a default func, lambda x: x. Then *function* is called and we identify the return value True or False. But this is not the truth. There is no default value and no function is applied. I think this should be deleted.

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

----------
assignee: docs at python
components: Documentation
files: filter_doc.patch
keywords: patch
messages: 265325
nosy: docs at python, xiang.zhang
priority: normal
severity: normal
status: open
title: improve document of filter
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42818/filter_doc.patch

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

From report at bugs.python.org  Wed May 11 14:52:22 2016
From: report at bugs.python.org (Erik Rasmussen)
Date: Wed, 11 May 2016 18:52:22 +0000
Subject: [New-bugs-announce] [issue27001] Python Interface X-Plane 10.45
Message-ID: <1462992742.15.0.272722103174.issue27001@psf.upfronthosting.co.za>


New submission from Erik Rasmussen:

Hi Python!!  Thanks for your work on python .. really appreciated.

Program to integrate python in X-Plane 10.45+
It worked fine on Python 2.7.10 but after the new release
X-Plane Crashes completely with plugin .. ??  
Assistance please... 

Kindly
Erik (The Viking) Rasmussen
Odense, Denmark.

----------
components: Windows
files: PythonInterface.rar
messages: 265333
nosy: Erik Rasmussen, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Python Interface X-Plane 10.45
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file42820/PythonInterface.rar

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

From report at bugs.python.org  Wed May 11 14:54:44 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 May 2016 18:54:44 +0000
Subject: [New-bugs-announce] [issue27002] Support different modes in
 posixpath.realpath()
Message-ID: <1462992884.19.0.13993979036.issue27002@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

For now posixpath.realpath() don't raise an exception if encounter broken link. Instead it just lefts broken link name and following path components unresolved. This is dangerous since broken link name can be collapsed with following ".." and resulting valid path can point at wrong location. May be this is even security issue.

On other hand, Path.resolve() raises an exception when encounters broken link. This is not always desirable, there is a wish to make it more lenient. See issue19717 for more information.

The readlink utility from GNU coreutils has three mode for resolving file path:

       -f, --canonicalize
              canonicalize by following every symlink in every component of the given name recursively; all but the last component must exist

       -e, --canonicalize-existing
              canonicalize by following every symlink in every component of the given name recursively, all components must exist

       -m, --canonicalize-missing
              canonicalize by following every symlink in every component of the given name recursively, without requirements on components existence

Current behavior of posixpath.realpath() is matches (besides one minor detail) to `readlink -m`. The behavior of Path.resolve() matches `readlink -e`.

Proposed preliminary patch implements the support of all three modes in posixpath.realpath(): CAN_MISSING, CAN_ALL_BUT_LAST and CAN_EXISTING. It exactly matches the behavior of readlink. The default mode is CAN_MISSING.

There is minor behavior difference in the default mode. If there is a file "file", a link "link" that points to "file" and a broken link "broken", then "broken/../link" was resolved to "link" and now it is resolved to "file".

The patch lacks the documentation. Ternary flag looks as not the best API. Binary flag would be better. But I don't know what can be dropped. CAN_MISSING is needed for compatibility, but it looks less useful and may be insecure (not more than normpath()). CAN_EXISTING and CAN_ALL_BUT_LAST is needed in different cases. I think that in many cases CAN_ALL_BUT_LAST is actually needed instead of CAN_MISSING.

After resolving this issue the solution will be adopted for Path.resolve().

----------
components: Library (Lib)
files: realpath_mode.patch
keywords: patch
messages: 265335
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Support different modes in posixpath.realpath()
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42821/realpath_mode.patch

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

From report at bugs.python.org  Wed May 11 15:23:16 2016
From: report at bugs.python.org (Bennet Fauber)
Date: Wed, 11 May 2016 19:23:16 +0000
Subject: [New-bugs-announce] [issue27003] Python 3.5.1 fails at HTTPSTest
 with SSL CERT error
Message-ID: <1462994596.94.0.421418085673.issue27003@psf.upfronthosting.co.za>


New submission from Bennet Fauber:

I downloaded the source tar file for Python 3.5.1 and compiled.  Upon running make test, it fails at

test_networked_good_cert (test_httplib.HTTPSTest) ... ERROR

Abbreviated Traceback looks like:

======================================================================
ERROR: test_networked_good_cert (test_httplib.HTTPSTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/tmp/bennet/Python-3.5.1/Lib/test/test_httplib.py", line 1325, in test_networked_good_cert
    h.request('GET', '/')
. . . .
  File "/tmp/local/python-3.5.1/lib/python3.5/ssl.py", line 628, in do_handshake
    self._sslobj.do_handshake()
ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:645)

I have replicated this on CentOS 7, RHEL 6.5, and Ubuntu 16.04 Xenial with GCC versions 4.8.5, 4.8.5, and 5.3.1, respectively.

There was a previous bug reported about expired certificates that was closed.  It appears that it's using CERT_localhost, defined at the top to be keycert.pem, and that appears to be valid:

[bennet at flux-build-centos7-dev test]$ openssl x509 -in keycert.pem -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 15548457918976213582 (0xd7c7381919afc24e)
. . . .
        Validity
            Not Before: Oct  8 23:01:56 2010 GMT
            Not After : Oct  5 23:01:56 2020 GMT

I can replicate the test outside of make with the attached script.

I tried to be complete reporting and searching for this first; I apologize if I missed an obvious solution.

----------
components: Build
files: test-python3-httplib.py
messages: 265339
nosy: Bennet Fauber
priority: normal
severity: normal
status: open
title: Python 3.5.1 fails at HTTPSTest with SSL CERT error
type: compile error
versions: Python 3.5
Added file: http://bugs.python.org/file42822/test-python3-httplib.py

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

From report at bugs.python.org  Wed May 11 15:39:10 2016
From: report at bugs.python.org (Orion Poplawski)
Date: Wed, 11 May 2016 19:39:10 +0000
Subject: [New-bugs-announce] [issue27004] Handle script shbang options
Message-ID: <1462995550.58.0.0858558226193.issue27004@psf.upfronthosting.co.za>


New submission from Orion Poplawski:

Fedora would like to enforce that python scripts installed into /usr/bin use the "-s" option.  We have tried to enforce this by doing:

python setup.py build --executable '/usr/bin/python2 -s'

However, as reported here: https://bugzilla.redhat.com/show_bug.cgi?id=1335203

this breaks scripts that already have options in them as the options are tacked onto the end, e.g.:

#!/usr/bin/python2 -s -E

Which linux doesn't handle.

It seems we have a couple options:

- Replace the entire shbang line with the argument to --executable
- Try to merge options into a single one (-sE)
- Have a separate option, say --executable-args to specify the options.  Although the question still remains as to whether or not to replace the existing option or append.

----------
components: Distutils
messages: 265343
nosy: dstufft, eric.araujo, opoplawski
priority: normal
severity: normal
status: open
title: Handle script shbang options
versions: Python 2.7, Python 3.6

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

From report at bugs.python.org  Thu May 12 02:48:22 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 May 2016 06:48:22 +0000
Subject: [New-bugs-announce] [issue27005] Faster float.fromhex()
Message-ID: <1463035702.18.0.00292240428989.issue27005@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch makes float.fromhex() faster for exact float.

$ ./python -m timeit -s "h = float.hex(1.23)" -- "float.fromhex(h)"

Unpatched: 1000000 loops, best of 3: 0.886 usec per loop
Patched:   1000000 loops, best of 3: 0.519 usec per loop

----------
components: Interpreter Core
files: float_fromhex.patch
keywords: patch
messages: 265366
nosy: mark.dickinson, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Faster float.fromhex()
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file42824/float_fromhex.patch

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

From report at bugs.python.org  Thu May 12 03:15:44 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 May 2016 07:15:44 +0000
Subject: [New-bugs-announce] [issue27006] C implementation of
 Decimal.from_float() bypasses __new__ and __init__
Message-ID: <1463037344.61.0.425475414297.issue27006@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Python implementation of Decimal.from_float() calls __new__ and __init__ methods of subclass.

>>> from _pydecimal import Decimal
>>> class D(Decimal):
...     def __new__(cls, *args, **kwargs):
...         print('__new__')
...         return Decimal.__new__(cls, *args, **kwargs)
...     def __init__(self, *args, **kwargs):
...         print('__init__')
... 
>>> print(type(D.from_float(42)))
__new__
__init__
<class '__main__.D'>
>>> print(type(D.from_float(42.0)))
__new__
__init__
<class '__main__.D'>

But C implementation doesn't.

>>> from decimal import Decimal
>>> class D(Decimal):
...     def __new__(cls, *args, **kwargs):
...         print('__new__')
...         return Decimal.__new__(cls, *args, **kwargs)
...     def __init__(self, *args, **kwargs):
...         print('__init__')
... 
>>> print(type(D.from_float(42)))
<class '__main__.D'>
>>> print(type(D.from_float(42.0)))
<class '__main__.D'>

This means that resulting instance of Decimal subclass can be in not valid state.

Example is Decimal enums (see also issue23640).

>>> from decimal import Decimal
>>> from enum import Enum
>>> class D(Decimal, Enum):
...     A = Decimal('3.25')
... 
>>> D(Decimal(3.25))
<D.A: Decimal('3.25')>
>>> D(3.25)
<D.A: Decimal('3.25')>
>>> D.from_float(3.25)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/serhiy/py/cpython/Lib/enum.py", line 486, in __repr__
    self.__class__.__name__, self._name_, self._value_)
AttributeError: 'D' object has no attribute '_name_'

A solution is to reproduce Python implementation in C code:

        result = ... # create exact Decimal
        if cls is not Decimal:
            result = cls(result)
        return result

----------
components: Extension Modules
messages: 265368
nosy: facundobatista, mark.dickinson, rhettinger, serhiy.storchaka, skrah
priority: normal
severity: normal
status: open
title: C implementation of Decimal.from_float() bypasses __new__ and __init__
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu May 12 04:03:19 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 May 2016 08:03:19 +0000
Subject: [New-bugs-announce] [issue27007] Alternate constructors
 bytes.fromhex() and bytearray.fromhex() return an instance of base type
Message-ID: <1463040199.11.0.588158577385.issue27007@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

According to the discussion on Python-Dev [1] alternate constructors should return an instance of the subclass (else why invoke it through the subclass). bytes.fromhex() and bytearray.fromhex() are the only exceptions.

I think bytes.fromhex() and bytearray.fromhex() should be changed to match the behavior of all other alternate constructors.

[1] http://comments.gmane.org/gmane.comp.python.devel/157649

----------
components: Interpreter Core
messages: 265375
nosy: georg.brandl, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Alternate constructors bytes.fromhex() and bytearray.fromhex() return an instance of base type
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Thu May 12 04:04:50 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 12 May 2016 08:04:50 +0000
Subject: [New-bugs-announce] [issue27008] error message of ord is not
 intuitive
Message-ID: <1463040290.52.0.305686008758.issue27008@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

The error message of ``ord`` is not that right. It says 'ord() expected string of length 1'. I don't think in Py3.x string can refer to both bytes and unicodes.

----------
messages: 265376
nosy: xiang.zhang
priority: normal
severity: normal
status: open
title: error message of ord is not intuitive
versions: Python 3.6

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

From report at bugs.python.org  Thu May 12 08:08:47 2016
From: report at bugs.python.org (Hartmann)
Date: Thu, 12 May 2016 12:08:47 +0000
Subject: [New-bugs-announce] [issue27009] multiprocessing Connection data
 length limited to max(int32)
Message-ID: <1463054927.27.0.521137668509.issue27009@psf.upfronthosting.co.za>


New submission from Hartmann:

I wonder if size restriction for the data blobs send via multiprocessing.Connection is intentionally. Otherwise it would be nice to get rid of that restriction.

File "python3.5/multiprocessing/connection.py", line 393, in _send_bytes
    header = struct.pack("!i", n)

----------
messages: 265396
nosy: cimatosa
priority: normal
severity: normal
status: open
title: multiprocessing Connection data length limited to max(int32)
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Thu May 12 11:41:58 2016
From: report at bugs.python.org (Fedele Mantuano)
Date: Thu, 12 May 2016 15:41:58 +0000
Subject: [New-bugs-announce] [issue27010] Attachments not detected from
 email library
Message-ID: <1463067718.45.0.558318505018.issue27010@psf.upfronthosting.co.za>


New submission from Fedele Mantuano:

We are receiving a lot of mail with attachments not detected from email library.
I also tested Tika parser and it have the same issue:

mail: http://pastebin.com/kSEJnzSa
mail parsed: http://pastebin.com/7HaVPcTq

I can read only these content types:
multipart/mixed
multipart/alternative
text/plain
text/html

there isn't Content-Type: application/zip.

With a normal mail client I can read the attachment.

Where is the issue?

----------
components: email
files: mail
messages: 265413
nosy: Fedele Mantuano, barry, r.david.murray
priority: normal
severity: normal
status: open
title: Attachments not detected from email library
versions: Python 2.7
Added file: http://bugs.python.org/file42830/mail

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

From report at bugs.python.org  Thu May 12 12:54:58 2016
From: report at bugs.python.org (Stepan)
Date: Thu, 12 May 2016 16:54:58 +0000
Subject: [New-bugs-announce] [issue27011] Identation error
Message-ID: <1463072098.87.0.97273870503.issue27011@psf.upfronthosting.co.za>


Changes by Stepan <stepanstepan0000 at gmail.com>:


----------
files: ident.patch
keywords: patch
nosy: Ma3aXaKa
priority: normal
severity: normal
status: open
title: Identation error
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42832/ident.patch

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

From report at bugs.python.org  Thu May 12 15:16:46 2016
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 12 May 2016 19:16:46 +0000
Subject: [New-bugs-announce] [issue27012] Rename the posix module to _os
Message-ID: <1463080606.17.0.881585678376.issue27012@psf.upfronthosting.co.za>


New submission from Brett Cannon:

It's always bugged me that the posix module changes its name based on what OS you're running under. I think it would be better to name the module _os as that it's consistent. We can alias the name to posix/nt for backwards compatibility (and even do this in importlib since it uses the module, so no worries of missing the aliasing). It also helps reinforce the note at the top of the posix module that it shouldn't be imported directly.

----------
components: Library (Lib)
messages: 265421
nosy: brett.cannon
priority: low
severity: normal
status: open
title: Rename the posix module to _os
type: enhancement

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

From report at bugs.python.org  Fri May 13 05:00:33 2016
From: report at bugs.python.org (Tal Einat)
Date: Fri, 13 May 2016 09:00:33 +0000
Subject: [New-bugs-announce] [issue27013] IDLE completion for dict keys
Message-ID: <1463130033.92.0.0595376142117.issue27013@psf.upfronthosting.co.za>


New submission from Tal Einat:

I just wanted to mention that I once added this feature to IDLE and it's really great for interactive work, especially with data structures such as tables or JSON. If there's ever interest, I can try to hunt down my old code.

----------
components: IDLE
messages: 265457
nosy: kbk, roger.serwy, taleinat, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE completion for dict keys
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri May 13 08:57:16 2016
From: report at bugs.python.org (Roy Shmueli)
Date: Fri, 13 May 2016 12:57:16 +0000
Subject: [New-bugs-announce] [issue27014] maximum recursion depth when using
 typing options
Message-ID: <1463144236.79.0.623590161328.issue27014@psf.upfronthosting.co.za>


New submission from Roy Shmueli:

While creating class of List and using a Optional as part of the typing system. I have got an error when I was importing one of my module. I was able to simplify the problem by creating a one module that replicate the crash.

----------
files: bug.py
messages: 265473
nosy: Roy Shmueli
priority: normal
severity: normal
status: open
title: maximum recursion depth when using typing options
type: crash
versions: Python 3.5
Added file: http://bugs.python.org/file42840/bug.py

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

From report at bugs.python.org  Fri May 13 12:59:09 2016
From: report at bugs.python.org (Taywee)
Date: Fri, 13 May 2016 16:59:09 +0000
Subject: [New-bugs-announce] [issue27015] subprocess.CalledProcessError's
 repr changes based on kwargs, and doesn't unpickle
Message-ID: <1463158749.5.0.182634970623.issue27015@psf.upfronthosting.co.za>


New submission from Taywee:

When using kwargs to construct a CalledProcessError, the repr doesn't show those args, and using kwargs also breaks pickling:

>>> import pickle; from subprocess import CalledProcessError
>>> CalledProcessError(2, 'foo')
CalledProcessError(2, 'foo')
>>> CalledProcessError(2, 'foo').returncode
2
>>> CalledProcessError(2, 'foo').cmd
'foo'
>>> CalledProcessError(returncode=2, cmd='foo')
CalledProcessError()
>>> CalledProcessError(returncode=2, cmd='foo').returncode
2
>>> CalledProcessError(returncode=2, cmd='foo').cmd
'foo'
>>> pickle.loads(pickle.dumps(CalledProcessError(2, 'foo')))
CalledProcessError(2, 'foo')
>>> pickle.loads(pickle.dumps(CalledProcessError(returncode=2, cmd='foo')))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: __init__() missing 2 required positional arguments: 'returncode' and 'cmd'
>>>

----------
components: Library (Lib)
messages: 265482
nosy: Taywee
priority: normal
severity: normal
status: open
title: subprocess.CalledProcessError's repr changes based on kwargs, and doesn't unpickle
type: behavior
versions: Python 3.4, Python 3.5

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

From report at bugs.python.org  Fri May 13 22:03:39 2016
From: report at bugs.python.org (padraic cunningham)
Date: Sat, 14 May 2016 02:03:39 +0000
Subject: [New-bugs-announce] [issue27016] BlockingIOError not raised inside
 function.
Message-ID: <1463191419.08.0.084074707962.issue27016@psf.upfronthosting.co.za>


New submission from padraic cunningham:

When the following code snippets are run from two separate shells, the code inside the function does not raise any error on the second call while the second snippet successfully raises a BlockingIOError on the second run: 


# No error raised.
def func():
    lockfile = open('lockfile', 'w')
    fcntl.flock(lockfile, fcntl.LOCK_EX | fcntl.LOCK_NB)
    input() # no error raised, can be sleep etc..


func()

# Error raised.
lockfile = open('lockfile', 'w')
fcntl.flock(lockfile, fcntl.LOCK_EX | fcntl.LOCK_NB)
input() # no error raised

----------
components: IO
messages: 265501
nosy: pcunningham80 at gmail.com
priority: normal
severity: normal
status: open
title: BlockingIOError not raised inside function.
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat May 14 02:55:40 2016
From: report at bugs.python.org (Ray)
Date: Sat, 14 May 2016 06:55:40 +0000
Subject: [New-bugs-announce] [issue27017] Python3.5.1: type().startswith()
Message-ID: <1463208940.1.0.915796688613.issue27017@psf.upfronthosting.co.za>


New submission from Ray:

This doesn't look like proper functionality

    Python 3.5.1 (v3.5.1:37a07cee5969, Dec  6 2015, 01:54:25) [MSC v.1900 64 bit (AMD64)] on win32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> type('')
    <class 'str'>
    >>> type('').startswith('s')
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: startswith() takes at least 1 argument (0 given)
    >>> type('').startswith('s', 's')
    True

----------
components: Windows
messages: 265505
nosy: VertigoRay, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Python3.5.1: type().startswith()
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Sat May 14 06:24:37 2016
From: report at bugs.python.org (=?utf-8?q?Salvo_=E2=80=9CLtWorf=E2=80=9D_Tomaselli?=)
Date: Sat, 14 May 2016 10:24:37 +0000
Subject: [New-bugs-announce] [issue27018] Incorrect documentation of select
 module
Message-ID: <1463221477.58.0.675652051466.issue27018@psf.upfronthosting.co.za>


New submission from Salvo ?LtWorf? Tomaselli:

import select
help(select.epoll)

It mentions that the default mask is EPOLL_IN | EPOLL_OUT | EPOLL_PRI.

However there are no such constants.

They are called EPOLLIN EPOLLOUT and EPOLLPRI.

Please fix.

----------
assignee: docs at python
components: Documentation
messages: 265513
nosy: Salvo ?LtWorf? Tomaselli, docs at python
priority: normal
severity: normal
status: open
title: Incorrect documentation of select module
versions: Python 3.5

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

From report at bugs.python.org  Sat May 14 12:41:41 2016
From: report at bugs.python.org (David Bolen)
Date: Sat, 14 May 2016 16:41:41 +0000
Subject: [New-bugs-announce] [issue27019] Reduce marshal stack depth for 2.7
 on Windows debug build
Message-ID: <1463244101.49.0.212240462675.issue27019@psf.upfronthosting.co.za>


New submission from David Bolen:

I'd like to propose backporting the change in issue 22734 to the 2.7 branch.  The marshal recursion depth appears to be at the root of the failures of the Windows 8 and 10 buildbots in test_marshal on that branch, which is still using a depth of 2000.

The one thing I haven't yet been able to figure out is why this only seems to happen under Windows 8/10, and not 7/XP, but I don't think the change is harmful in any case.

The attached patch, adapted from issue 22734 is against the current 2.7 tip.

----------
components: Tests
files: marshal-27.patch
keywords: patch
messages: 265533
nosy: db3l, pitrou, steve.dower
priority: normal
severity: normal
status: open
title: Reduce marshal stack depth for 2.7 on Windows debug build
versions: Python 2.7
Added file: http://bugs.python.org/file42849/marshal-27.patch

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

From report at bugs.python.org  Sat May 14 13:30:43 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Sat, 14 May 2016 17:30:43 +0000
Subject: [New-bugs-announce] [issue27020] os.writev() does not accept
 generators (as buffers argument)
Message-ID: <1463247043.26.0.60216509871.issue27020@psf.upfronthosting.co.za>


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

Unlike socket.sendmsg(), os.writev() does not support generators.

Proof:

In [4]: os.writev(1, [b'aa', b'bb', b'\n'])
aabb
Out[4]: 5

In [5]: os.writev(1, (i for i in [b'aa', b'bb', b'\n']))
...
TypeError: writev() arg 2 must be a sequence

----------
components: Library (Lib)
messages: 265536
nosy: mmarkk
priority: normal
severity: normal
status: open
title: os.writev() does not accept generators (as buffers argument)
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/issue27020>
_______________________________________

From report at bugs.python.org  Sat May 14 13:34:06 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Sat, 14 May 2016 17:34:06 +0000
Subject: [New-bugs-announce] [issue27021] It is not documented that
 os.writev() suffer from SC_IOV_MAX
Message-ID: <1463247246.11.0.121733863987.issue27021@psf.upfronthosting.co.za>


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

Really, os.writev() suffer from SC_IOV_MAX. This is documented for socket.sendmsg(), but not for os.writev():

The operating system may set a limit (sysconf() value SC_IOV_MAX) on the number of buffers that can be used.

----------
assignee: docs at python
components: Documentation
messages: 265537
nosy: docs at python, mmarkk
priority: normal
severity: normal
status: open
title: It is not documented that os.writev() suffer from SC_IOV_MAX
type: enhancement
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat May 14 13:39:02 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Sat, 14 May 2016 17:39:02 +0000
Subject: [New-bugs-announce] [issue27022] expose sendmmsg() syscall in
 sockets API
Message-ID: <1463247542.08.0.661246316661.issue27022@psf.upfronthosting.co.za>


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

This syscall allows to send multiple messages at once.

----------
components: Library (Lib)
messages: 265538
nosy: mmarkk
priority: normal
severity: normal
status: open
title: expose sendmmsg() syscall  in sockets API
type: enhancement
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat May 14 13:39:43 2016
From: report at bugs.python.org (ProgVal)
Date: Sat, 14 May 2016 17:39:43 +0000
Subject: [New-bugs-announce] [issue27023] Documentation of
 tempfile.gettempdir() does not mention it only supports existing
 directories
Message-ID: <1463247583.74.0.311593159637.issue27023@psf.upfronthosting.co.za>


New submission from ProgVal:

Documentation of tempfile.gettempdir() <https://docs.python.org/3/library/tempfile.html#tempfile.gettempdir> does not mention it only supports existing directories.

This led to this question on Stackoverflow: http://stackoverflow.com/q/37229398/539465

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 265539
nosy: Valentin.Lorentz, docs at python
priority: normal
severity: normal
status: open
title: Documentation of tempfile.gettempdir() does not mention it only supports existing directories
versions: Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun May 15 01:25:46 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 15 May 2016 05:25:46 +0000
Subject: [New-bugs-announce] [issue27024] IDLE shutdown glitch when started
 by import
Message-ID: <1463289946.09.0.360878393598.issue27024@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Win10, 3.5.1: Run 'python' in interactive mode.
>>> import idlelib.idle  # open idle shell
# or import idlelib.__main__
# only works once in an interactive session as re-import does not rerun
# In IDLE, open editor to some file.  For instance, alt-M, idlelib.run.

# Close editor, close shell.  In python, see something like
>>> bgerror failed to handle background error.
    Original error: invalid command name "2361007434952font_timer_event"
    Error in bgerror: can't invoke "tk" command: application has been destroyed"

Exit python, restart, import to start idle.
Close shell, close editor.  In python window, see
>>> invalid command name "1220802489864timer_event"
    while executing
"1220802489864timer_event"
    ("after" script)
invalid command name "1220865810504font_timer_event"
    while executing
"1220865810504font_timer_event"
    ("after" script)

Opening IDLE directly with 'python -m idlelib' (or 'idlelib.idle') does not show the problem.  So this is not a problem for the vast majority of users who run idle in an idle process.

My guess is that shutting down the entire process instead of just the idle part of a process shuts down tcl/tk and any pending callbacks.  Perhaps some tkinter class is called without passing the explicit IDLE root.  Though I then would not understand why the callback fails.

My guess is that the order dependence is associated with the startup and shutdown code being part of PyShell instead of being in an independent app module.  (I hope to change this.)

Serhiy, do you have any additiional insight into what is going on and what I should look for?

----------
components: IDLE
messages: 265581
nosy: serhiy.storchaka, terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: IDLE shutdown glitch when started by import
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun May 15 04:04:05 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 May 2016 08:04:05 +0000
Subject: [New-bugs-announce] [issue27025] More human readable generated
 widget names
Message-ID: <1463299445.94.0.887025569149.issue27025@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

For now Tkinter generates Tk widget names just from Widget instance id.

>>> import tkinter
>>> root = tkinter.Tk()
>>> frame = tkinter.Frame(root)
>>> button = tkinter.Button(frame)
>>> str(button)
'.3070531884.3055478668'

These names are not very readable and distinguishable. I think it would be better to generate names from widget type and short sequential number. For example '.frame#1.button#2' or '.1frame.2button'.

There are some questions:

1. Should numbering be continuous or separate for different types of widgets?

2. Should a number precede or follow a widget type?

3. What separator, prefix or suffix be used? "#" looks too common and can lead to conflicts with user defined names or names generated by Tk or special Tk syntax.

----------
components: Tkinter
messages: 265591
nosy: serhiy.storchaka, terry.reedy
priority: normal
severity: normal
status: open
title: More human readable generated widget names
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Sun May 15 04:06:20 2016
From: report at bugs.python.org (Hong Minhee)
Date: Sun, 15 May 2016 08:06:20 +0000
Subject: [New-bugs-announce] [issue27026] async/await keywords are missing
 from reference docs
Message-ID: <1463299580.57.0.0973198258941.issue27026@psf.upfronthosting.co.za>


New submission from Hong Minhee:

The async/await keywords are missing from ?2.3.1. Keywords in reference docs.

The attached patch adds two missing keywords to Doc/reference/lexical_analysis.rst file.

----------
assignee: docs at python
components: Documentation
files: patch.diff
hgrepos: 343
keywords: patch
messages: 265593
nosy: docs at python, hongminhee
priority: normal
severity: normal
status: open
title: async/await keywords are missing from reference docs
type: enhancement
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42856/patch.diff

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

From report at bugs.python.org  Sun May 15 06:11:15 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 15 May 2016 10:11:15 +0000
Subject: [New-bugs-announce] [issue27027] add is_android in test.support to
 detect Android platform
Message-ID: <1463307075.8.0.646834682003.issue27027@psf.upfronthosting.co.za>


New submission from Xavier de Gaye:

Needed by tests specific to Android or that must be skipped on Android.

----------
components: Tests
messages: 265609
nosy: ezio.melotti, michael.foord, pitrou, xdegaye
priority: normal
severity: normal
status: open
title: add is_android in test.support to detect Android platform
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Sun May 15 11:00:49 2016
From: report at bugs.python.org (Mehrzad Irani)
Date: Sun, 15 May 2016 15:00:49 +0000
Subject: [New-bugs-announce] [issue27028] BasicInterpolation issue with %()
Message-ID: <1463324449.1.0.433434193016.issue27028@psf.upfronthosting.co.za>


New submission from Mehrzad Irani:

The below code works fine with ExtendedInterpolation; however with BasicInterpolation it _url fails with invalid variable reference.

The INI file:
[DEFAULT]
domain=abc.labs.com

[machine-details]
compilation_machine=abc1
compilation_machine_url=%(compilation_machine).%(domain)
compilation_machine_url2=${compilation_machine}.${domain}

Python Version:
Python 3.5.1

Environment:
Arch Linux

----------
components: Library (Lib)
files: bg.py
messages: 265617
nosy: i.mehrzad
priority: normal
severity: normal
status: open
title: BasicInterpolation issue with %()
type: compile error
versions: Python 3.5
Added file: http://bugs.python.org/file42859/bg.py

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

From report at bugs.python.org  Sun May 15 14:23:22 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 May 2016 18:23:22 +0000
Subject: [New-bugs-announce] [issue27029] Remove support of deprecated mode
 'U' in zipfile
Message-ID: <1463336602.94.0.363644818568.issue27029@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch removes support of modes 'U' and 'rU' in zipfile.ZipFile.open. This support was baggy and not consistent with other binary file objects. It was deprecated since Python 3.4.

----------
components: Library (Lib)
files: zipfile_remove_deprecated.patch
keywords: patch
messages: 265640
nosy: alanmcintyre, serhiy.storchaka, twouters
priority: normal
severity: normal
stage: patch review
status: open
title: Remove support of deprecated mode 'U' in zipfile
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42861/zipfile_remove_deprecated.patch

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

From report at bugs.python.org  Sun May 15 14:38:17 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 May 2016 18:38:17 +0000
Subject: [New-bugs-announce] [issue27030] Remove deprecated re features
Message-ID: <1463337497.02.0.81864271809.issue27030@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch removes following deprecated re features:

* Three unused not documented functions:  isident(), isdigit() and isname(). They were deprecated since Python 3.3 (issue14462).

* '\' + ASCII character now is error if this combination is not defined. This allows to add new control combinations without breaking compatibility. This was deprecated since Python 3.5 (issue23622).

* Support for re.LOCALE with string patterns or with re.ASCII. This was deprecated since Python 3.5 (issue22407).

----------
components: Library (Lib), Regular Expressions
files: re_remove_deprecated.patch
keywords: patch
messages: 265641
nosy: ezio.melotti, mrabarnett, pitrou, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Remove deprecated re features
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42862/re_remove_deprecated.patch

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

From report at bugs.python.org  Sun May 15 14:53:11 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 May 2016 18:53:11 +0000
Subject: [New-bugs-announce] [issue27031] Remove interface to obsolete Tk
 commands
Message-ID: <1463338391.3.0.784874070077.issue27031@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch removes the tk_menuBar() and tk_bindForTraversal() dummy methods in Tkinter widget classes. Previously these methods called commands that were obsolete since Tk 4.0. The deprecation was added in all branches in issue22061.

----------
components: Library (Lib), Tkinter
files: tkinter_remove_deprecated.patch
keywords: patch
messages: 265642
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Remove interface to obsolete Tk commands
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42863/tkinter_remove_deprecated.patch

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

From report at bugs.python.org  Sun May 15 15:05:46 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 May 2016 19:05:46 +0000
Subject: [New-bugs-announce] [issue27032] Remove deprecated
 html.parser.HTMLParser.unescape()
Message-ID: <1463339146.08.0.655083281356.issue27032@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch removes the unescape() method in the html.parser.HTMLParser class. This was deprecated since Python 3.4 (issue19688).

----------
components: Library (Lib)
files: html_parser_remove_deprecated.patch
keywords: patch
messages: 265643
nosy: ezio.melotti, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Remove deprecated html.parser.HTMLParser.unescape()
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42864/html_parser_remove_deprecated.patch

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

From report at bugs.python.org  Sun May 15 15:20:39 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 May 2016 19:20:39 +0000
Subject: [New-bugs-announce] [issue27033] Change the decode_data default in
 smtpd to False
Message-ID: <1463340039.51.0.670985844702.issue27033@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch changes the default value of the decode_data parameter for smtpd.SMTPChannel and smtpd.SMTPServer constructors. The default value True was deprecated since adding this parameter in issue19662.

----------
components: Library (Lib)
files: smtpd_decode_data_false.patch
keywords: patch
messages: 265645
nosy: Arfrever, Duke.Dougal, Illirgway, barry, haypo, jesstess, lpolzer, maciej.szulik, python-dev, r.david.murray, richard, serhiy.storchaka, sreepriya, zvyn
priority: normal
severity: normal
stage: patch review
status: open
title: Change the decode_data default in smtpd to False
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42865/smtpd_decode_data_false.patch

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

From report at bugs.python.org  Sun May 15 15:32:54 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 May 2016 19:32:54 +0000
Subject: [New-bugs-announce] [issue27034] Remove derecated asynchat.fifo
Message-ID: <1463340774.13.0.31758132832.issue27034@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch removes deprecated class fifo from the asynchat module and any remnants from the documentation. See also issue6916.

----------
components: Library (Lib)
files: asynchat_remove_deprecated.patch
keywords: patch
messages: 265646
nosy: BreamoreBoy, berker.peksag, ezio.melotti, georg.brandl, giampaolo.rodola, haypo, josiahcarlson, lehmannro, rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Remove derecated asynchat.fifo
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42866/asynchat_remove_deprecated.patch

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

From report at bugs.python.org  Mon May 16 03:57:08 2016
From: report at bugs.python.org (=?utf-8?b?TWlyb3NsYXYgTWF0xJtqxa8=?=)
Date: Mon, 16 May 2016 07:57:08 +0000
Subject: [New-bugs-announce] [issue27035] Cannot set exit code in atexit
 callback
Message-ID: <1463385428.15.0.762354704325.issue27035@psf.upfronthosting.co.za>


New submission from Miroslav Mat?j?:

I want to set exit code of my script in a function registered in the atexit module. (See https://stackoverflow.com/q/37178636/711006.) Calling sys.exit() in that function results in the following error:

Error in atexit._run_exitfuncs:
Traceback (most recent call last):
  File "atexit_test.py", line 3, in myexit
    sys.exit(2)
SystemExit: 2

Despite the printed error, the exit code is set to 0. (This might be related with #1257.)

This problem seems to affect Python 3.x. I experienced it with Python 3.5.1 on Windows 7 x64 and I am able to reproduce it with Python 3.4.3 on Linux (x64). Python 2.7.6 on the same Linux machine works as expected: Exits without additional messages and the desired exit code is set.

A simple test case:

def myexit():
  import sys
  sys.exit(2)

import atexit
atexit.register(myexit)

----------
components: Extension Modules
messages: 265678
nosy: Melebius
priority: normal
severity: normal
status: open
title: Cannot set exit code in atexit callback
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Mon May 16 04:33:49 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 May 2016 08:33:49 +0000
Subject: [New-bugs-announce] [issue27036] Mark up of references in different
 form
Message-ID: <1463387629.05.0.783453150634.issue27036@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

When there is a reference from the term in different form (e.g. in plural), the modified part can be appended outside of the reference: ":term:`bytes-like object`\ s". But this looks not very nice in rendered document, since only a part of the word is undescored. Proposed patch expands similar references to full words: ":term:`bytes-like objects <bytes-like object>`".

----------
assignee: docs at python
components: Documentation
files: refs_forms.patch
keywords: patch
messages: 265686
nosy: docs at python, georg.brandl, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Mark up of references in different form
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42869/refs_forms.patch

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

From report at bugs.python.org  Mon May 16 10:46:54 2016
From: report at bugs.python.org (David Pitchford)
Date: Mon, 16 May 2016 14:46:54 +0000
Subject: [New-bugs-announce] [issue27037] Universal newline support for
 zipFile.ZipExtFile.read() is not working (deprecated?),
 and the missing functionality not documented
Message-ID: <1463410014.02.0.132222711737.issue27037@psf.upfronthosting.co.za>


New submission from David Pitchford:

Universal newline support for the read method of ZipFileExt objects created by calling the ZipFile.open method is not working. The attached archive contains a test script for demonstrating the behavior; unzip the files into the same directory and run the script. It tests opening a text file with all three types of line endings in five different ways: with the file.read method in modes 'rU', 'r', and 'rb', and with the zipfile.ZipFileExt.read and readlines methods in mode 'rU'.

The first two and last methods both read the file with the expected universal newline support; the '\r' and '\r\n' endings are translated to '\n'. But zipfile.ZipFileExt.read, even with universal newline support, leaves these endings untouched, just like the 'rb' mode.

This issue seems to have been raised in the past (http://bugs.python.org/issue6759) for Python 3.3, with the decision apparently made to deprecate universal newline support for this method. Is this also the case for Python 2.7, and if so, why does the zipfile documentation for both versions not mention this missing functionality? As a user, I can say that this deprecation is certainly disrupting my workflow; it is not at all the behavior I expected.

I am running Python 2.7.11 on a 64-bit copy of Windows 7 Professional SP1.

----------
components: Library (Lib)
files: TestNewlines.zip
messages: 265697
nosy: David Pitchford
priority: normal
severity: normal
status: open
title: Universal newline support for zipFile.ZipExtFile.read() is not working (deprecated?), and the missing functionality not documented
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file42873/TestNewlines.zip

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

From report at bugs.python.org  Mon May 16 11:43:35 2016
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 16 May 2016 15:43:35 +0000
Subject: [New-bugs-announce] [issue27038] Make os.DirEntry exist
Message-ID: <1463413415.02.0.145090656269.issue27038@psf.upfronthosting.co.za>


New submission from Brett Cannon:

The docs claim that os.DirEntry exists (https://docs.python.org/3/library/os.html#os.DirEntry) but it actually does not (it is internal to the posix module). Should probably actually make os.DirEntry exist (but continue to not document the constructor).

----------
components: Library (Lib)
messages: 265700
nosy: brett.cannon
priority: normal
severity: normal
status: open
title: Make os.DirEntry exist
versions: Python 3.6

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

From report at bugs.python.org  Mon May 16 12:29:48 2016
From: report at bugs.python.org (Damien George)
Date: Mon, 16 May 2016 16:29:48 +0000
Subject: [New-bugs-announce] [issue27039] bytearray.remove cannot remove
 bytes with value greater than 127
Message-ID: <1463416188.61.0.0822560128487.issue27039@psf.upfronthosting.co.za>


New submission from Damien George:

The following code fails with a ValueError (but I expect it to succeed):

>>> bytearray([128]).remove(128)

Tested with Python 2.7.11 and 3.5.1.  Probably it's a case of comparing a char (signed byte) with an unsigned value.

----------
components: Interpreter Core
messages: 265709
nosy: Damien George
priority: normal
severity: normal
status: open
title: bytearray.remove cannot remove bytes with value greater than 127
type: behavior
versions: Python 2.7, Python 3.5

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

From report at bugs.python.org  Mon May 16 15:19:40 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 16 May 2016 19:19:40 +0000
Subject: [New-bugs-announce] [issue27040] asyncio: Add
 loop.get_exception_handler method
Message-ID: <1463426380.52.0.735203322245.issue27040@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

This is a proxy issue for https://github.com/python/asyncio/pull/345

----------
assignee: yselivanov
components: asyncio
messages: 265723
nosy: gvanrossum, haypo, yselivanov
priority: normal
severity: normal
stage: resolved
status: open
title: asyncio: Add loop.get_exception_handler method
type: enhancement
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon May 16 15:21:34 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 16 May 2016 19:21:34 +0000
Subject: [New-bugs-announce] [issue27041] asyncio: Add loop.create_future
 method
Message-ID: <1463426494.21.0.869664306544.issue27041@psf.upfronthosting.co.za>


New submission from Yury Selivanov:

This is a proxy issue for https://github.com/python/asyncio/pull/290

----------
assignee: yselivanov
components: asyncio
messages: 265724
nosy: gvanrossum, haypo, yselivanov
priority: normal
severity: normal
stage: resolved
status: open
title: asyncio: Add loop.create_future method
type: enhancement
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon May 16 18:12:05 2016
From: report at bugs.python.org (Eric Wieser)
Date: Mon, 16 May 2016 22:12:05 +0000
Subject: [New-bugs-announce] [issue27042] Incorrect grammar for function
 definitions
Message-ID: <1463436725.68.0.177476383596.issue27042@psf.upfronthosting.co.za>


New submission from Eric Wieser:

https://docs.python.org/3.2/reference/compound_stmts.html#function-definitions 

and onwards say the following

    decorator      ::=  "@" dotted_name ["(" [parameter_list [","]] ")"] NEWLINE

This is a regression from the 2.7 docs, which correctly said

    decorator      ::=  "@" dotted_name ["(" [argument_list [","]] ")"] NEWLINE

The implication is that the following is supposedly valid in python 3:

    @deco(what : "is this" = "supposed to mean")
    def foo(annotations: "are only for here" = "right?"):
        pass

The interpreter disagrees with the docs, and correctly rejects this syntax as garbage

----------
assignee: docs at python
components: Documentation
messages: 265735
nosy: Eric.Wieser, docs at python
priority: normal
severity: normal
status: open
title: Incorrect grammar for function definitions
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon May 16 20:42:37 2016
From: report at bugs.python.org (Ben Finney)
Date: Tue, 17 May 2016 00:42:37 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue27043=5D_Describe_what_?=
 =?utf-8?b?4oCYaW5zcGVjdC5jbGVhbmRvY+KAmSBkb2VzIHRvIHN5bm9wc2lzIGxpbmUu?=
Message-ID: <1463445757.83.0.886794484792.issue27043@psf.upfronthosting.co.za>


New submission from Ben Finney:

The library documentation for ?inspect.cleandoc? describes the transformation that occurs to ?the second line onwards?, but makes no mention of what processing occurs to the synopsis (first) line.

Please update the library documentation for this function, to explicitly describe how it processes each of the different parts of a docstring.

If possible, this should be guided by PEP 257's discussion of how indentation is transformed: https://www.python.org/dev/peps/pep-0257/#handling-docstring-indentation

----------
assignee: docs at python
components: Documentation
messages: 265741
nosy: bignose, docs at python
priority: normal
severity: normal
status: open
title: Describe what ?inspect.cleandoc? does to synopsis line.
type: enhancement
versions: Python 2.7, Python 3.6

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

From report at bugs.python.org  Mon May 16 21:18:48 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 17 May 2016 01:18:48 +0000
Subject: [New-bugs-announce] [issue27044] Stop test_idle memory leaks
Message-ID: <1463447928.95.0.827348262469.issue27044@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

test_idle leaked [2648, 2648, 2648] references, sum=7944
test_idle leaked [938, 940, 940] memory blocks, sum=2818

I traced this to test_configdialog and then to ConfigDialog.AttachVarCallbacks, which has 18 call like
        self.fontSize.trace_variable('w', self.VarChanged_font)
Currently, root.destroy does not destroy associated callbacks.  Serhiy has a patch to change this, but will do explicit cleanup for the test anyway.

----------
assignee: terry.reedy
messages: 265743
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Stop test_idle memory leaks
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Mon May 16 21:33:25 2016
From: report at bugs.python.org (Ed Doxtator)
Date: Tue, 17 May 2016 01:33:25 +0000
Subject: [New-bugs-announce] [issue27045] Forward slashes in Windows paths
Message-ID: <1463448805.55.0.933820705649.issue27045@psf.upfronthosting.co.za>


New submission from Ed Doxtator:

In the documentation for pyvenv (https://docs.python.org/dev/library/venv.html), there is a table that shows by platform the command required to activate a virtual environment by OS.  For Windows, the values are:

Platform        Shell       Command to activate virtual environment
-------------------------------------------------------------------
Windows         cmd.exe     C:> <venv>/Scripts/activate.bat
  	        PowerShell  PS C:> <venv>/Scripts/Activate.ps1

The commands are incorrect-- they contain forward slashes and should be back slashes.

----------
assignee: docs at python
components: Documentation
messages: 265744
nosy: doc, docs at python
priority: normal
severity: normal
status: open
title: Forward slashes in Windows paths
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Tue May 17 03:59:34 2016
From: report at bugs.python.org (vishvajit pathak)
Date: Tue, 17 May 2016 07:59:34 +0000
Subject: [New-bugs-announce] [issue27046] Emoji support in Pie Chart legend
 with matplotlib
Message-ID: <1463471974.35.0.410853070824.issue27046@psf.upfronthosting.co.za>


New submission from vishvajit pathak:

I unable to find this support for showing emoji in legend while drawing the pie chart with matplotlib.

----------
components: Library (Lib)
messages: 265761
nosy: wishmore191 at gmail.com
priority: normal
severity: normal
status: open
title: Emoji support in Pie Chart legend with matplotlib
type: enhancement
versions: Python 2.7

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

From report at bugs.python.org  Tue May 17 15:41:40 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 May 2016 19:41:40 +0000
Subject: [New-bugs-announce] [issue27047] O(1) deque indexing
Message-ID: <1463514100.28.0.824610562849.issue27047@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch changes the complexity of deque indexing from linear to constant. All other operations preserves its amortized cost.

New deque implementation use two-level array instead of linked list. Since free space is reserved at both side, new blocks can be added at both sides for constant time. Memory consumption is almost the same.

----------
assignee: rhettinger
components: Extension Modules
files: deque_array.patch
keywords: patch
messages: 265773
nosy: rhettinger, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: O(1) deque indexing
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42879/deque_array.patch

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

From report at bugs.python.org  Tue May 17 16:09:12 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Tue, 17 May 2016 20:09:12 +0000
Subject: [New-bugs-announce] [issue27048] Breakages in subprocess.Popen with
 non-ascii characters in environment
Message-ID: <1463515752.85.0.457941663559.issue27048@psf.upfronthosting.co.za>


New submission from Emanuel Barry:

I got a random UnicodeDecodeError while trying to install a module with distutils. Traced it back and it being my name having a non-ascii character floating around in my environment.

I'm including two patches: subprocess_errors_simple_1.patch simply adds 'errors="replace"' to the stdin, stdout and stderr, while subprocess_distutils_errors_1.patch fixes this a bit more thoroughly.

I haven't added any tests yet, I'll add them to the proper patch when a concensus on which one to use is reached.

----------
components: Library (Lib), Unicode
files: subprocess_errors_simple_1.patch
keywords: patch
messages: 265774
nosy: ebarry, ezio.melotti, haypo
priority: normal
severity: normal
stage: patch review
status: open
title: Breakages in subprocess.Popen with non-ascii characters in environment
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file42880/subprocess_errors_simple_1.patch

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

From report at bugs.python.org  Tue May 17 20:56:45 2016
From: report at bugs.python.org (RoadrunnerWMC)
Date: Wed, 18 May 2016 00:56:45 +0000
Subject: [New-bugs-announce] [issue27049] Typo in "The Python Language
 Reference" 7.11 -- "individiual"
Message-ID: <1463533005.82.0.812822205208.issue27049@psf.upfronthosting.co.za>


New submission from RoadrunnerWMC:

In the Python 3.3 documentation onward, in "The Python Language Reference" section 7.11 (https://docs.python.org/3/reference/simple_stmts.html#import), the following sentence appears:

    "When the statement contains multiple clauses (separated by commas) the two steps are carried out separately for each clause, just as though the clauses had been separated out into individiual import statements."

The word "individual" is misspelled there as "individiual."

----------
assignee: docs at python
components: Documentation
messages: 265795
nosy: RoadrunnerWMC, docs at python
priority: normal
severity: normal
status: open
title: Typo in "The Python Language Reference" 7.11 -- "individiual"
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/issue27049>
_______________________________________

From report at bugs.python.org  Wed May 18 01:11:45 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 18 May 2016 05:11:45 +0000
Subject: [New-bugs-announce] [issue27050] Demote run() below the high level
 APIs in subprocess docs
Message-ID: <1463548305.72.0.232219818049.issue27050@psf.upfronthosting.co.za>


New submission from Nick Coghlan:

The new subprocess.run() API is a swiss-army-knife API like subprocess.Popen before it.

1. You have to pass a boolean toggle to indicate whether or not you want the return code checked
2. You have to pass magic constants to keyword arguments to indicate whether or not you want output captured
3. You have to understand and deconstruct a complex object in order to get useful information from it

By contrast, the *actual* high-level API encodes all those requests in the name of the function you call.

(This isn't a request to change anything functional, it's a request to undo the harm done to the subprocess documentation by backing away from the claim that this is a high level API on par with call, check_call and check_output - it's not, it's just not quite as low level as subprocess.Popen)

----------
messages: 265806
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Demote run() below the high level APIs in subprocess docs

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

From report at bugs.python.org  Wed May 18 01:47:49 2016
From: report at bugs.python.org (Upendra Kumar)
Date: Wed, 18 May 2016 05:47:49 +0000
Subject: [New-bugs-announce] [issue27051] Create PIP gui
Message-ID: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za>


New submission from Upendra Kumar:

This is new issue opened for creating a GUI (tkinter) front end for pip. It is in continuation with Issue #23551.

----------
components: Tkinter
messages: 265810
nosy: terry.reedy, upendra-k14
priority: normal
severity: normal
status: open
title: Create PIP gui
type: enhancement

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

From report at bugs.python.org  Wed May 18 02:38:21 2016
From: report at bugs.python.org (=?utf-8?q?J=C3=A1n_Jockusch?=)
Date: Wed, 18 May 2016 06:38:21 +0000
Subject: [New-bugs-announce] [issue27052] Python2.7.11+ as in Debian testing
 and Ubuntu 16.04 LTS crashes with segfault
Message-ID: <1463553501.27.0.152340887562.issue27052@psf.upfronthosting.co.za>


New submission from J?n Jockusch:

Python2.7.11+ as distributed by Ubuntu 16.04LTS and Debian testing crashes with a segmentation fault when running a simple Zope2 instance.

Python.org's Python2.7.11 does not exhibit the same crash.

It is possible that one of the patches in debian/patches or another factor of the Debianization introduces a regression or a new issue.

The issue has been registered with Ubuntu here:

https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1580577

Matthias Klose, Debian maintainer for the package, has asked me to
report this problem upstream, because otherwise we will invariably run
into this regression in 2.7.12.

I have attached the script I use to produce the segmentation fault. I involves installing Zope2 from the internet, but other that that, it only requires a standard Python2.7 installation (with zlib support).

I have also succeeded in calling and producing this error in gdb, but I don't know how to move on from there.

Any hints on how I can locate the problem are very welcome!

----------
files: testing_script.sh
messages: 265814
nosy: J?n Jockusch
priority: normal
severity: normal
status: open
title: Python2.7.11+ as in Debian testing and Ubuntu 16.04 LTS crashes with segfault
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file42889/testing_script.sh

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

From report at bugs.python.org  Wed May 18 03:43:11 2016
From: report at bugs.python.org (Wolfgang Langner)
Date: Wed, 18 May 2016 07:43:11 +0000
Subject: [New-bugs-announce] [issue27053] Python Windows x86-64 embeddable
 zip file missing module encodings
Message-ID: <1463557391.11.0.911851091126.issue27053@psf.upfronthosting.co.za>


New submission from Wolfgang Langner:

Tried to extract Windows x86-64 embeddable zip file and execute it.
But following error happened (3.6.0a1):

Fatal Python error: Py_Initialize: unable to load the file system codec
ImportError: No module named 'encodings'

Current thread 0x000017c4 (most recent call first):

----

Also tried release version 3.5.1, this version works fine.

----------
components: Installation
messages: 265818
nosy: steve.dower, tds333
priority: normal
severity: normal
status: open
title: Python Windows x86-64 embeddable zip file missing module encodings
versions: Python 3.6

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

From report at bugs.python.org  Wed May 18 17:59:26 2016
From: report at bugs.python.org (Hugh C. Lauer)
Date: Wed, 18 May 2016 21:59:26 +0000
Subject: [New-bugs-announce] [issue27054] Python installation problem: No
 module named 'encodings'
Message-ID: <45B64D1540141C4AA0F8F3974D714AEA64D3D93D@S197.admin.wpi.edu>


New submission from Hugh C. Lauer:

Hello,

I am a university professor who regularly teaches classes in Python programming, particular to students who are NOT computer science majors.

In preparing my course materials for next fall, I have been struggling with setting up a Python 3.5.1 environment on my Windows computer (similar to what most of my students will use).

I continually get the error "Fatal Python error: Py_Initialize: unable to load the file system codec
                                                ImportError: No module named 'encodings'"

This seems to happen with Python 3.5.1 as well as Python 3.5.0.

Nothing related to Python works:- not Python itself, not pip.

My platform is Windows 7 Enterprise, Service Pack 1.

*         I used the installation file "python-3.5.1-amd64.exe" downloaded from the official Python download site.

*         During installation, I selected "Add Python 3.5 to PATH" and "Customize installation".

*         Under "Advanced Options," I selected "Install for all users"

I have tried various other installation options, and nothing is better.

I also tried it on a Windows 10 platform. In that case, Python and IDLE are installed correctly, but I any attempt to use pip to add or install other packages fails with a different error.

For pedagogical reasons, I prefer the simply Python-IDLE environment to the packages such as Miniconda3, but installing Miniconda3 did not help either.

Am I missing something obvious?

Regards,

Hugh C. Lauer\
Department of Computer Science
Worcester Polytechnic Institute
Worcester, Massachusetts, USA

----------
messages: 265838
nosy: lauer at wpi.edu
priority: normal
severity: normal
status: open
title: Python installation problem: No module named 'encodings'

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

From report at bugs.python.org  Wed May 18 21:04:24 2016
From: report at bugs.python.org (Dmitry)
Date: Thu, 19 May 2016 01:04:24 +0000
Subject: [New-bugs-announce] [issue27055] python fails to run zipapp when
 zip contains comments
Message-ID: <1463619864.57.0.781907137117.issue27055@psf.upfronthosting.co.za>


New submission from Dmitry:

python fails to run zipapp when zip contains comments
when zip archive downloaded from github it contains tip hash in comment. 

Python 3.5.1 (v3.5.1:37a07cee5969, Dec  6 2015, 01:38:48) [MSC v.1900 32 bit (Intel)] on win32

example:

```
import zipfile


if __name__ == '__main__':
    with open('__main__.py', "w") as m:
      m.write("print('hello')")
    

    zipf = zipfile.ZipFile('zipapp_bad.zip', 'w', zipfile.ZIP_DEFLATED)
    #add zip comment
    zipf.comment=b"123321"
    zipf.write("__main__.py")
    zipf.close()

    zipf = zipfile.ZipFile('zipapp_good.zip', 'w', zipfile.ZIP_DEFLATED)
    zipf.write("__main__.py")
    zipf.close()
```

D:\pywork\zip>python zipapp_good.zip
hello

D:\pywork\zip>python zipapp_bad.zip
  File "zipapp_bad.zip", line 1
    PK???
      ^
SyntaxError: invalid syntax

----------
files: attach.zip
messages: 265839
nosy: Denisov
priority: normal
severity: normal
status: open
title: python fails to run zipapp when zip contains comments
type: crash
versions: Python 3.5
Added file: http://bugs.python.org/file42894/attach.zip

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

From report at bugs.python.org  Thu May 19 08:02:29 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 May 2016 12:02:29 +0000
Subject: [New-bugs-announce] [issue27056] pickle: constant propagation in
 _Unpickler_Read()
Message-ID: <1463659349.35.0.28600421781.issue27056@psf.upfronthosting.co.za>


New submission from STINNER Victor:

According to Linux perf, the unpickle_list benchmark (of the CPython benchmark suite) heavily depends on the performance of load() and _Unpickler_Read() functions. While running benchmarks with PGO+LTO compilation, I noticed a difference around 5% because one build uses constant propation on _Unpickler_Read() (fast), wheras another build doesn't (slow).

Depending on the result of the PGO, depending on the OS and the compiler, you may or may not get this nice optimization. I propose to implement it manually to not depend on the compiler.

Attached short patch implements manually the optimization. It looks to have a big impact on unpickle_list, but no impact (benchmark is not significant) on fastunpickle and pickle_list:
---
$ taskset -c 3 python3 perf.py ../ref_default/rel/python ../default/rel/python -b unpickle_list,fastunpickle,pickle_list --rigorous -v 
(...)
Report on Linux smithers 4.4.9-300.fc23.x86_64 #1 SMP Wed May 4 23:56:27 UTC 2016 x86_64 x86_64
Total CPU cores: 4

### fastunpickle ###
Avg: 0.527359 +/- 0.005932 -> 0.518548 +/- 0.00953: 1.02x faster
Not significant


### pickle_list ###
Avg: 0.269307 +/- 0.017465 -> 0.266015 +/- 0.00423: 1.01x faster
Not significant


### unpickle_list ###
Avg: 0.255805 +/- 0.006942 -> 0.231444 +/- 0.00394: 1.11x faster
Significant (t=21.58)
---

It would be interesting to also evaluate the computed goto optimization for the load() function. (And also try computed goto for the re/_sre module, but that's a different issue.)

I tuned my system and patched perf.py (of the CPython benchmark suite) to get stable benchmark results.

----------
files: unpickle_read.patch
keywords: patch
messages: 265852
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: pickle: constant propagation in _Unpickler_Read()
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file42896/unpickle_read.patch

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

From report at bugs.python.org  Thu May 19 08:15:56 2016
From: report at bugs.python.org (=?utf-8?q?Micha=C5=82_Bednarski?=)
Date: Thu, 19 May 2016 12:15:56 +0000
Subject: [New-bugs-announce] [issue27057] os.set_inheritable(): fall back to
 fcntl() if ioctl() fails with EACCES
Message-ID: <1463660156.43.0.991763402804.issue27057@psf.upfronthosting.co.za>


New submission from Micha? Bednarski:

When SELinux forbids ioctl() it fails with EACCES and whole os.set_inheritable raises exception.

As in https://bugs.python.org/issue22258 code was added to fall back to fcntl when ioctl() fails with ENOTTY I'm adding EACCES value to same condition to fall back to fcntl().

----------
files: set_inheritable-eacces.diff
keywords: patch
messages: 265853
nosy: Micha? Bednarski
priority: normal
severity: normal
status: open
title: os.set_inheritable(): fall back to fcntl() if ioctl() fails with EACCES
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file42897/set_inheritable-eacces.diff

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

From report at bugs.python.org  Thu May 19 11:12:58 2016
From: report at bugs.python.org (Kevin)
Date: Thu, 19 May 2016 15:12:58 +0000
Subject: [New-bugs-announce] [issue27058] Tkinter's canvas' dashed lines
 have incorrect segment lengths
Message-ID: <1463670778.9.0.698531599823.issue27058@psf.upfronthosting.co.za>


New submission from Kevin:

When creating a dashed line using `Canvas.create_line`. Minimal reproducing example:

    from Tkinter import *
    root = Tk()
    canvas = Canvas(root, width=100, height=30, bg="black")
    canvas.pack()
    canvas.create_line((0,10,100,10), dash=(20,), fill="red")
    canvas.create_line((0,20,100,20), dash=(20,20), fill="green")
    root.mainloop()

Expected result: each line segment should be 20 pixels wide, separated by gaps 20 pixels wide.

Actual result: each line segment is 18 pixels wide, separated by gaps 6 pixels wide. See attached file for screenshot.

Additional information: this problem appears to only occur on Windows. The Stack Overflow Python chat room attempted to replicate this issue, starting around here: http://chat.stackoverflow.com/transcript/message/30645798#30645798. Users of Windows 7, 8, and 10 were able to replicate the incorrect segmenting behavior. Users of Linux had correct segment lengths. (some Windows & 2.7 users also noticed that their green line was 3 pixel segments with 3 pixel gaps, but this seems to be an independent bug which was already fixed somewhere between 2.7.2 and 2.7.10.)

----------
components: Tkinter, Windows
files: output.PNG
messages: 265868
nosy: kms70847, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Tkinter's canvas' dashed lines have incorrect segment lengths
versions: Python 2.7, Python 3.5
Added file: http://bugs.python.org/file42901/output.PNG

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

From report at bugs.python.org  Thu May 19 14:49:53 2016
From: report at bugs.python.org (Gerrit Ansmann)
Date: Thu, 19 May 2016 18:49:53 +0000
Subject: [New-bugs-announce] [issue27059] find_spec and find_loader ignore
 package/path argument
Message-ID: <1463683793.33.0.38773604471.issue27059@psf.upfronthosting.co.za>


New submission from Gerrit Ansmann:

According to my understanding, the `package`/`path` argument of the `find_loader`/`find_spec` command should enable it to find modules in other directories than the current one. Instead, these arguments seem to be ignored and even changing the working directory from within Python (using os.chdir) does not yield the expected results with `find_spec`.

I append a script with several test cases that should succeed in my understanding, but some of which don?t.

Python version: 3.4.3.
OS: Ubuntu 14.04.4
Pertinent Stack Overflow question: http://stackoverflow.com/a/37260391/2127008

----------
components: Library (Lib)
files: test.py
messages: 265882
nosy: Wrzlprmft, brett.cannon
priority: normal
severity: normal
status: open
title: find_spec and find_loader ignore package/path argument
type: behavior
versions: Python 3.4
Added file: http://bugs.python.org/file42903/test.py

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

From report at bugs.python.org  Thu May 19 16:05:14 2016
From: report at bugs.python.org (Vitaly)
Date: Thu, 19 May 2016 20:05:14 +0000
Subject: [New-bugs-announce] [issue27060] Documentation of assertItemsEqual
 in unittest is VERY misleading in 2.7
Message-ID: <1463688314.75.0.696545829281.issue27060@psf.upfronthosting.co.za>


New submission from Vitaly:

Python 2.7 documentation is VERY misleading about the functionality of assertItemsEqual. The implementation only compares item counts, but the documentation actually claims to compare not only the counts, but the actual sorted elements themselves. This documentation mislead my group to use this method for comparing the elements. See https://hg.python.org/cpython/file/d9921cb6e3cd/Doc/library/unittest.rst, which is what appears on https://docs.python.org/2.7/library/unittest.html#unittest.TestCase.assertItemsEqual:

   .. method:: assertItemsEqual(actual, expected, msg=None)

      Test that sequence *expected* contains the same elements as *actual*,
      regardless of their order. When they don't, an error message listing the
      differences between the sequences will be generated.

      Duplicate elements are *not* ignored when comparing *actual* and
      *expected*. It verifies if each element has the same count in both
      sequences. It is the equivalent of ``assertEqual(sorted(expected),
      sorted(actual))`` but it works with sequences of unhashable objects as
      well.

----------
messages: 265889
nosy: vitaly
priority: normal
severity: normal
status: open
title: Documentation of assertItemsEqual in unittest is VERY misleading in 2.7

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

From report at bugs.python.org  Thu May 19 16:12:07 2016
From: report at bugs.python.org (Paul Bloch)
Date: Thu, 19 May 2016 20:12:07 +0000
Subject: [New-bugs-announce] [issue27061] 2.7.11 OS X pkg doesn't put proper
 version in the receipts
Message-ID: <1463688727.6.0.20787305635.issue27061@psf.upfronthosting.co.za>


New submission from Paul Bloch:

Python 2.7.6 writes the version number (2.7.6) into the installed receipts. Python 2.7.11 calls the version "0". That isn't very helpful for managed installs.

----------
components: Macintosh
files: typescript.txt
messages: 265891
nosy: Paul Bloch, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: 2.7.11 OS X pkg doesn't put proper version in the receipts
versions: Python 2.7
Added file: http://bugs.python.org/file42904/typescript.txt

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

From report at bugs.python.org  Thu May 19 16:29:43 2016
From: report at bugs.python.org (Franklin? Lee)
Date: Thu, 19 May 2016 20:29:43 +0000
Subject: [New-bugs-announce] [issue27062] `inspect` doesn't have `__all__`
Message-ID: <1463689783.23.0.292900715898.issue27062@psf.upfronthosting.co.za>


New submission from Franklin? Lee:

`inspect`'s names are pretty close to unique, except for `stack`, `unwrap`, and `trace`. It doesn't define `__all__`, though.

----------
components: Library (Lib)
messages: 265893
nosy: leewz
priority: normal
severity: normal
status: open
title: `inspect` doesn't have `__all__`
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu May 19 16:31:12 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 May 2016 20:31:12 +0000
Subject: [New-bugs-announce] [issue27063] Some unittest loader tests are
 silently skipped by mistake
Message-ID: <1463689872.02.0.411561520769.issue27063@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Due to bug in the decorator some tests in Lib/unittest/test/test_loader.py are silently skipped. Proposed patch fixes this as well as other bugs in the decorator and tests.

----------
components: Tests
files: test_loader.patch
keywords: patch
messages: 265894
nosy: ezio.melotti, michael.foord, rbcollins, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Some unittest loader tests are silently skipped by mistake
type: behavior
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42905/test_loader.patch

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

From report at bugs.python.org  Thu May 19 17:36:05 2016
From: report at bugs.python.org (Paul Moore)
Date: Thu, 19 May 2016 21:36:05 +0000
Subject: [New-bugs-announce] [issue27064] Make py.exe default to Python 3
 when used interactively
Message-ID: <1463693765.53.0.683202020216.issue27064@psf.upfronthosting.co.za>


New submission from Paul Moore:

By default, the launcher tries to launch (the latest version of) Python 2 on the user's machine. This can be altered with the configuration file, and if the user doesn't have Python 2 installed Python 3 will be used. Now that we are at Python 3.6, it's about time to change that default to try Python 3 first.

This was discussed on python-ideas in the thread starting at https://mail.python.org/pipermail/python-ideas/2016-March/038667.html. My summary of the consensus was at https://mail.python.org/pipermail/python-ideas/2016-March/038759.html

The key points were:

1. For interactive use, make py.exe launch the latest version
installed on the machine, without special-casing a preference for
Python 2.
2. For shebang lines where an unversioned name is used, retain the
current behaviour (for compatibility with Unix).
3. When the user explicitly chooses a version, or has configured the
launcher via the ini file or environment variables, no change to
current behaviour.
4. The change is small enough that it doesn't need a PEP.

The attached patch implements this behaviour.

I assume the patch is to be applied only to Python 3.6, as it is changed behaviour, not a bug fix.

----------
assignee: paul.moore
components: Windows
files: launcher.diff
keywords: needs review, patch
messages: 265898
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Make py.exe default to Python 3 when used interactively
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file42906/launcher.diff

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

From report at bugs.python.org  Thu May 19 19:21:48 2016
From: report at bugs.python.org (John Nagle)
Date: Thu, 19 May 2016 23:21:48 +0000
Subject: [New-bugs-announce] [issue27065] robotparser user agent considered
 hostile by mod_security rules.
Message-ID: <1463700108.4.0.745938506232.issue27065@psf.upfronthosting.co.za>


New submission from John Nagle:

"robotparser" uses the default Python user agent when reading the "robots.txt" file, and there's no parameter for changing that.

Unfortunately, the "mod_security" add-on for Apache web server, when used with the standard OWASP rule set, blacklists the default Python USER-AGENT in Rule 990002, User Agent Identification. It doesn't like certain HTTP USER-AGENT values. One of them is "python-httplib2". So any program in Python which accesses the web site will trigger this rule and be blocked form access.  

For regular HTTP accesses, it's possible to put a user agent string in the Request object and work around this. But "robotparser" has no such option. 

Worse, if "robotparser" has its read of "robots.txt" rejected, it interprets that as a "deny all" robots.txt file, and returns False for all "can_fetch()" requests.

----------
components: Library (Lib)
messages: 265900
nosy: nagle
priority: normal
severity: normal
status: open
title: robotparser user agent considered hostile by mod_security rules.
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Thu May 19 19:50:49 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 19 May 2016 23:50:49 +0000
Subject: [New-bugs-announce] [issue27066] SystemError if custom opener
 returns -1
Message-ID: <1463701849.23.0.646090431797.issue27066@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw:

Let's say you use a custom opener, and that opener happens to return exactly -1.  You end up with a SystemError because NULL got returned without an exception being set:

def negative(fname, flags):
    return -1


with open('/tmp/foo.txt', 'w', encoding='utf-8', opener=negative) as fp:
    print('oops', file=fp)


% python3 /tmp/foo.py 
Traceback (most recent call last):
  File "/tmp/foo.py", line 5, in <module>
    with open('/tmp/foo.txt', 'w', encoding='utf-8', opener=negative) as fp:
SystemError: <class '_io.FileIO'> returned NULL without setting an error


Anything else and you get a relatively decent exception.  E.g. return -2 and you get an OSError.  Raise an exception and you get that exception.

The problem is pretty clear to see; when an opener is set, after coercing the fd to an integer, the check is made for that integer being -1, and then it jumps right to the exit.

Let's say you return some non-integer, like 'foo'.  Then the _PyLong_AsInt() will fail and a proper exception will be set.  So I think the "if (self->fd == -1)" clause just needs to check for an exception set first and set one if there isn't one before it does the "goto error".  I guess you'd want to see the same exception as if it returned say, -2:

Traceback (most recent call last):
  File "/tmp/foo.py", line 5, in <module>
    with open('/tmp/foo.txt', 'w', encoding='utf-8', opener=negative) as fp:
OSError: [Errno 0] Error: '/tmp/foo.txt'

----------
components: IO
messages: 265901
nosy: barry
priority: normal
severity: normal
stage: needs patch
status: open
title: SystemError if custom opener returns -1
type: crash
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri May 20 04:02:35 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 May 2016 08:02:35 +0000
Subject: [New-bugs-announce] [issue27067] Improve curses tests
Message-ID: <1463731355.86.0.176847535381.issue27067@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch improves curses tests. Main improvements are:

* Tests now run even if sys.stdout is not terminal.
* The screen is not spoiled during tests.
* Reported the name and arguments of failed function.
* Testing optional functionality is extracted in separated tests. They are reported as skipped if optional functions are not available.

----------
components: Tests
files: test_curses_2.patch
keywords: patch
messages: 265914
nosy: serhiy.storchaka, twouters, zach.ware
priority: normal
severity: normal
stage: patch review
status: open
title: Improve curses tests
type: enhancement
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42909/test_curses_2.patch

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

From report at bugs.python.org  Fri May 20 06:19:44 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 May 2016 10:19:44 +0000
Subject: [New-bugs-announce] [issue27068] Add a detach() method to
 subprocess.Popen
Message-ID: <1463739584.18.0.0161123331788.issue27068@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The issue #26741 modified the subprocess.Popen destructor to emit a ResourceWarning if the child process is still running.

According to Martin Panter, it can be deliberate to let the subprocess running if the management of the subprocess is delegated to a different object. I'm not convinced that it's safe to do that, but I chose to open this issue to discuss the feature.

My fear is that subprocess.Popen handles many private objects required by the subprocess, not only its pid. For example, on Windows Popen stores the handle of the subprocess. Popen also contains pipe objects when stdin, stdout and/or stderr is redirected.

I guess that detach() makes sense when the developer knows what he/she is doing and knows how to handle all resources attached to a subprocess.

----------
components: Library (Lib)
messages: 265929
nosy: haypo
priority: normal
severity: normal
status: open
title: Add a detach() method to subprocess.Popen
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Fri May 20 08:23:17 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 May 2016 12:23:17 +0000
Subject: [New-bugs-announce] [issue27069] webbrowser creates zombi processes
 in the background mode
Message-ID: <1463746997.46.0.620771266968.issue27069@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The webbrowser opens almost all browsers in background mode, it looks like only Elinks is not opened in this mode.

Problem: the webbrowser doesn't read the exit status of the browser, and so create zombi process. On Python 3.6, the subprocess module now emits a ResourceWarning in this case (issue #26741).

For example, the following script shows a zombi process ("<defunc>"):
---
import webbrowser, os

b = webbrowser.get("firefox")
b.open("https://bugs.python.org/issue26741")
b = None

os.system("ps ax|grep firefox")
input("press ENTER when firefox exited")
os.system("ps ax|grep firefox")
---

I guess that Python should use os.fork() somehow to fix this issue.

Another option is to hack the Popen object to not display the warning, but I don't think that it's a safe option.

See also the issue #27068 "Add a detach() method to subprocess.Popen", but I don't think that it is directly related to background processes run by webbrowser.

----------
messages: 265939
nosy: haypo, martin.panter
priority: normal
severity: normal
status: open
title: webbrowser creates zombi processes in the background mode
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri May 20 17:52:33 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Fri, 20 May 2016 21:52:33 +0000
Subject: [New-bugs-announce] [issue27070] Add ability to freeze (seal)
 mutable objects
Message-ID: <1463781153.76.0.520759085036.issue27070@psf.upfronthosting.co.za>


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

I mean making mutable object immutable. I speak about List(), Set(), bytearray(), memoryview(), mmap() and so on.

bytearray already have `hold`, to lock size only, but it still not represented in Python.

----------
components: Library (Lib)
messages: 265965
nosy: mmarkk
priority: normal
severity: normal
status: open
title: Add ability to freeze (seal) mutable objects
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Fri May 20 19:53:00 2016
From: report at bugs.python.org (Vitaly)
Date: Fri, 20 May 2016 23:53:00 +0000
Subject: [New-bugs-announce] [issue27071] unittest.TestCase.assertCountEqual
 is a very misleading name
Message-ID: <1463788380.52.0.782790370377.issue27071@psf.upfronthosting.co.za>


New submission from Vitaly:

Somewhere in 3.x assertItemsEqual was renamed to assertCountEqual.

assertCountEqual sounds like a really inappropriate, misleading name for what it does. It misleads users into thinking that it only compares the number of elements in each sequence, whereas it actually asserts that equivalent items are present in both sequences, regardless of order. The original name from 2.7 assertItemsEqual was so much more meaningful.

----------
components: Library (Lib)
messages: 265980
nosy: vitaly
priority: normal
severity: normal
status: open
title: unittest.TestCase.assertCountEqual is a very misleading name
versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat May 21 02:07:50 2016
From: report at bugs.python.org (Steven Barker)
Date: Sat, 21 May 2016 06:07:50 +0000
Subject: [New-bugs-announce] [issue27072] random.getrandbits is limited to
 2**31-1 bits on 64-bit Windows
Message-ID: <1463810870.39.0.980113200971.issue27072@psf.upfronthosting.co.za>


New submission from Steven Barker:

The C implementation of `_random.Random.getrandbits` is unnecessarily limited in the number of bits it can produce on 64-bit Windows systems. I learned about this issue in discussion of my answer to this stack overflow question:

 http://stackoverflow.com/questions/37356338/is-there-a-predictable-replacement-for-os-urandom-using-pythons-random-module

The argument parsing code in `getrandbits` forces its Python `int` argument to fit into a C `int` variable. On my 64-bit Windows system, any value larger than `2**31-1` causes a `OverflowError`.

Since the number of bits is directly related to how much memory we need to allocate (in the non-fast case), I think `Py_ssize_t` would be more appropriate type than a regular `int`. This probably isn't an issue on non-Windows or 64-bit systems, where `int` and `Py_ssize_t` will have the same size.

I'm attaching a very simple patch that changes the types of the relevant variables and the format code in the call to `PyArg_ParseTuple`. The code works and still passes its tests with the patch. I considered adding an additional test for this issue, but passing test cases would require allocations of several gigabytes of memory which seems a rather unfriendly thing to add in a test for a fairly minor issue.

This issue doesn't effect the pure Python implementation of `random.SystemRandom.getrandbits`, which already worked fine when large numbers of bits were requested. The documentation for `random.getrandbits` doesn't mention any limitation on the number of bits provided, so I don't imagine there will be backwards compatibility issues. I also don't expect the change to have any impact on third party `Random` replacement classes.

For convenience, here's the contents of the very short patch (which I'll also attach):

diff --git a/Modules/_randommodule.c b/Modules/_randommodule.c
index fd6b230..3bf564f 100644
--- a/Modules/_randommodule.c
+++ b/Modules/_randommodule.c
@@ -348,12 +348,12 @@ random_setstate(RandomObject *self, PyObject *state)
 static PyObject *
 random_getrandbits(RandomObject *self, PyObject *args)
 {
-    int k, i, words;
+    Py_ssize_t k, i, words;
     PY_UINT32_T r;
     PY_UINT32_T *wordarray;
     PyObject *result;

-    if (!PyArg_ParseTuple(args, "i:getrandbits", &k))
+    if (!PyArg_ParseTuple(args, "n:getrandbits", &k))
         return NULL;

     if (k <= 0) {

----------
components: Library (Lib)
files: getrandbits.diff
keywords: patch
messages: 265987
nosy: Steven.Barker
priority: normal
severity: normal
status: open
title: random.getrandbits is limited to 2**31-1 bits on 64-bit Windows
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42919/getrandbits.diff

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

From report at bugs.python.org  Sat May 21 03:41:40 2016
From: report at bugs.python.org (Oren Milman)
Date: Sat, 21 May 2016 07:41:40 +0000
Subject: [New-bugs-announce] [issue27073] redundant checks in long_add and
 long_sub
Message-ID: <1463816500.87.0.013124059613.issue27073@psf.upfronthosting.co.za>


New submission from Oren Milman:

------------ the proposed changes ------------
I believe the following checks are redundant:
    1. in Objects/longobject.c in long_add:
        In case both a and b are negative, their absolute values are added using x_add, with the result stored in z.
        If (z != NULL), it must be that x_add succeeded, and also it must be that (Py_SIZE(z) > 0), as it is guaranteed that the absolute values of a and b are both bigger than zero.
        Thus, the check (Py_SIZE(z) != 0) here is redundant.
    2. in Objects/longobject.c in long_sub:
        In case a is negative, the absolute values of a and b are subtracted or added using x_sub or x_add, with the result stored in z.
        Later on, if (z != NULL && Py_SIZE(z) != 0), then Py_SIZE(z) is negated. However, even though it might be that Py_SIZE(z) == 0, it doesn't really matter.
        doing 'Py_SIZE(z) = -(Py_SIZE(z));' in that case would do nothing.
        Thus, the check (Py_SIZE(z) != 0) here is redundant.

    The original versions of both of these checks were added in revision 443 (November 1991!). Back then, ob_size's was implemented using one's complement, and negating it was actually doing 'z->ob_size = ~z->ob_size;'. 
    Of course, in that case the check (z->ob_size != 0) was necessary, but then, in revision 590, ob_size was changed to use two's complement, and the check (z->ob_size != 0) was left untouched, and remained there to this day.


------------ diff ------------
The patches diff is attached.


------------ tests ------------
I built the patched CPython for x86, and played with it a little. Everything seemed to work as usual.

In addition, I ran 'python -m test' (on my 64-bit Windows 10) before and after applying the patch, and got quite the same output.
the outputs of both runs are attached.

----------
components: Interpreter Core
files: issue.diff
keywords: patch
messages: 265989
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: redundant checks in long_add and long_sub
Added file: http://bugs.python.org/file42920/issue.diff

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

From report at bugs.python.org  Sat May 21 03:45:05 2016
From: report at bugs.python.org (Antti Haapala)
Date: Sat, 21 May 2016 07:45:05 +0000
Subject: [New-bugs-announce] [issue27074] Confusing text about __all__ in
 __init__.py in tutorial
Message-ID: <1463816705.73.0.630465423608.issue27074@psf.upfronthosting.co.za>


New submission from Antti Haapala:

https://docs.python.org/3/tutorial/modules.html#importing-from-a-package

says that 

"The import statement uses the following convention: if a package?s __init__.py code defines a list named __all__, it is taken to be the list of module names that should be imported when from package import * is encountered."

However, of course this is not true. The behaviour is that `__all__` lists the names that are to be imported from the package with from package import *; only only those names that raise AttributeError at the time of import would be attempted to be imported as submodules.

----------
assignee: docs at python
components: Documentation
messages: 265990
nosy: docs at python, ztane
priority: normal
severity: normal
status: open
title: Confusing text about __all__ in __init__.py in tutorial
type: enhancement

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

From report at bugs.python.org  Sat May 21 04:26:13 2016
From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=)
Date: Sat, 21 May 2016 08:26:13 +0000
Subject: [New-bugs-announce] [issue27075] Link to StreamReader/Writer from
 codecs.getreader/writer
Message-ID: <1463819173.18.0.0746227587463.issue27075@psf.upfronthosting.co.za>


New submission from Ville Skytt?:

Patch attached.

----------
assignee: docs at python
components: Documentation
files: codeclinks.patch
keywords: patch
messages: 265991
nosy: docs at python, scop
priority: normal
severity: normal
status: open
title: Link to StreamReader/Writer from codecs.getreader/writer
type: enhancement
Added file: http://bugs.python.org/file42923/codeclinks.patch

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

From report at bugs.python.org  Sat May 21 04:31:19 2016
From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=)
Date: Sat, 21 May 2016 08:31:19 +0000
Subject: [New-bugs-announce] [issue27076] Doc and comment spelling fixes
Message-ID: <1463819479.86.0.838684690734.issue27076@psf.upfronthosting.co.za>


New submission from Ville Skytt?:

Patch attached.

----------
assignee: docs at python
components: Documentation, Library (Lib)
files: docs.patch
keywords: patch
messages: 265992
nosy: docs at python, scop
priority: normal
severity: normal
status: open
title: Doc and comment spelling fixes
type: enhancement
Added file: http://bugs.python.org/file42924/docs.patch

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

From report at bugs.python.org  Sat May 21 08:27:09 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 21 May 2016 12:27:09 +0000
Subject: [New-bugs-announce] [issue27077] test_port_parameter_types fails
 with BytesWarning
Message-ID: <1463833629.03.0.694431281551.issue27077@psf.upfronthosting.co.za>


New submission from Berker Peksag:

The relevant changeset is 1570e3855ce8. Here is a traceback from a random buildbot:

======================================================================
ERROR: test_port_parameter_types (test.test_asyncio.test_base_events.BaseEventTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/dje/cpython-buildarea/3.x.edelsohn-debian-z/build/Lib/test/test_asyncio/test_base_events.py", line 143, in test_port_parameter_types
    base_events._ipaddr_info('1.2.3.4', b'1', INET, STREAM, TCP))
BytesWarning: Comparison between bytes and string

http://buildbot.python.org/all/builders/s390x%20Debian%203.x/builds/1100/steps/test/logs/stdio

----------
components: Tests
messages: 265998
nosy: berker.peksag, yselivanov
priority: normal
severity: normal
stage: needs patch
status: open
title: test_port_parameter_types fails with BytesWarning
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat May 21 15:18:36 2016
From: report at bugs.python.org (Antti Haapala)
Date: Sat, 21 May 2016 19:18:36 +0000
Subject: [New-bugs-announce] [issue27078] Make f'' strings faster than
 .format: BUILD_STRING opcode?
Message-ID: <1463858316.54.0.292581402272.issue27078@psf.upfronthosting.co.za>


New submission from Antti Haapala:

I benchmarked some f'' strings against .format, and surprisingly f'' was slower than .format in about all the simple cases I could think of. I guess this is because f'' strings implicitly use `''.join([])`.

The byte code for f'foo is {foo}' currently is

  1           0 LOAD_CONST               1 ('')
              3 LOAD_ATTR                0 (join)
              6 LOAD_CONST               2 ('foo is ')
              9 LOAD_GLOBAL              1 (foo)
             12 FORMAT_VALUE             0
             15 BUILD_LIST               2
             18 CALL_FUNCTION            1 (1 positional, 0 keyword pair)

It was mentioned here https://bugs.python.org/issue24965 but since I came up with the idea when inspecting this, I'd propose again here that a new opcode be added for f'' strings - BUILD_STRING n, with which f'foo is {foo}' could be compiled to 

              0 LOAD_CONST               2 ('foo is ')
              3 LOAD_GLOBAL              1 (foo)
              6 FORMAT_VALUE             0
              9 BUILD_STRING             2

instead. Internally this wouldn't even need to call `PyUnicode_Join`, but instead `seplen == 0` case could be refactored into a separate function. Not only with this is it possible to know the length of the string, but also the number of string components are already known, so it'd be possible to build a tuple fast from the values on stack.

And that way people doing micro benchmarks would find out that the new Python 3.6 feature would not only look nice but also be a way to write better-performing code.

----------
components: Interpreter Core
messages: 266016
nosy: ztane
priority: normal
severity: normal
status: open
title: Make f'' strings faster than .format: BUILD_STRING opcode?
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Sat May 21 16:09:59 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 May 2016 20:09:59 +0000
Subject: [New-bugs-announce] [issue27079] Bugs in curses.ascii predicates
Message-ID: <1463861399.98.0.689088484472.issue27079@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Most curses.ascii predicates corresponds C functions declared in <ctype.h>. But there are some differences:

1. isblank() returns True for space and backspace instead of space and tab.

2. ispunct() returns True for non-ASCII and control characters.

3. iscntrl() returns False for '\x7f'. Note that there is different function isctrl().

These differences look as bugs. Proposed patch fixes them and adds tests for all curses.ascii functions.

----------
components: Library (Lib)
files: curses_ascii.patch
keywords: patch
messages: 266020
nosy: serhiy.storchaka, twouters
priority: normal
severity: normal
stage: patch review
status: open
title: Bugs in curses.ascii predicates
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42931/curses_ascii.patch

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

From report at bugs.python.org  Sat May 21 16:38:09 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 21 May 2016 20:38:09 +0000
Subject: [New-bugs-announce] [issue27080] Implement the formatting part of
 PEP 515, '_' in numeric literals.
Message-ID: <1463863089.86.0.119019547094.issue27080@psf.upfronthosting.co.za>


New submission from Eric V. Smith:

I've separated this out from issue 26331, so as to not interfere with discussions and code reviews for the parsing portion of the PEP.

----------
assignee: eric.smith
components: Interpreter Core
messages: 266023
nosy: eric.smith
priority: normal
severity: normal
status: open
title: Implement the formatting part of PEP 515, '_' in numeric literals.
type: enhancement

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

From report at bugs.python.org  Sat May 21 17:04:33 2016
From: report at bugs.python.org (ppperry)
Date: Sat, 21 May 2016 21:04:33 +0000
Subject: [New-bugs-announce] [issue27081] Multiprocessing is not robust
 against sys.stderr changes
Message-ID: <1463864673.26.0.0758761622573.issue27081@psf.upfronthosting.co.za>


New submission from ppperry:

In this code, one would expect that the entire traceback from the uncaught recursion error would get put onto the queue, where it could be read in the main process.
  queue = multiprocessing.Queue()
  def do_stderr(queue):
   	class f:
		def write(self, data):
			queue.put(data)
		def flush(self):
			pass
	import sys
	sys.stderr = f()
	def g():
		g()
	g()
    multiprocessing.Process(target=do_stderr,args=(queue,)).start()

However, only some of the output actually gets enqueued:

 Process IdleProcess-6:
 Traceback (most recent call last):
 File "C:\Python34\lib\multiprocessing\process.py", line 254, in _bootstrap
    self.run()
  File "C:\Python34\lib\multiprocessing\process.py", line 93, in run
    self._target(*self._args, **self._kwargs)
  File "<pyshell#446>", line 12, in do_stderr
  File "<pyshell#446>", line 11, in g
  File "<pyshell#446>", line 11, in g
  File "<pyshell#446>", line 11, in g
  File "<pyshell#446>", line 11, in g
  File "<pyshell#446>", line 11, in g
  File "<pyshell#446>", line 11, in g
  File "<pyshell#446>", line 11, in g
  File "<pyshell#446>", line 11, in g
  File "<pyshell#446>", line 11, in g
  File "<pyshell#446>", line 11, in g
  File "<pyshell#446>", line 11, in g
  File "<pyshell#446>", line 11, in g
  File "<pyshell#446>", line 11, in g

The rest of the data is not accessible.

----------
components: Library (Lib)
messages: 266026
nosy: ppperry
priority: normal
severity: normal
status: open
title: Multiprocessing is not robust against sys.stderr changes
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sat May 21 21:43:03 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 22 May 2016 01:43:03 +0000
Subject: [New-bugs-announce] [issue27082] IDLE seriously degrades during and
 after printing large single line strings
Message-ID: <1463881383.42.0.876902574545.issue27082@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

IDLE should check the size of lines in a result string before printing it.  Perhaps it should have a "..." after some user settable limit is reached.

>>> '=' * 100000            # Destroys IDLE
>>> json.load(somebigfile)  # Makes IDLE unusably sluggish

The problem only occurs when an individual line is long:

>>> s = 'some reasonable single line\n' * 1000)
>>> print(s)      # Separate lines are no problem
>>> s             # A big single line repr renders IDLE sluggish

Note, the sluggishness persists across sessions -- a "Restart Shell" doesn't help.

In my Python classes, this is a common and recurring problem that negatively impacts the learner's user experience.

----------
assignee: terry.reedy
components: IDLE
messages: 266041
nosy: rhettinger, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE seriously degrades during and after printing large single line strings
type: resource usage

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

From report at bugs.python.org  Sun May 22 02:45:32 2016
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 22 May 2016 06:45:32 +0000
Subject: [New-bugs-announce] [issue27083] PYTHONCASEOK is ignored on Windows
Message-ID: <1463899532.05.0.0164205622545.issue27083@psf.upfronthosting.co.za>


New submission from Eryk Sun:

importlib ignores the PYTHONCASEOK environment variable on Windows. _relax_case checks for b'PYTHONCASEOK' in os.environ, which is never true because os.environ is Unicode. On Windows, _make_relax_case should return a function that instead checks for 'PYTHONCASEOK'.

The following test demonstrates that case-insensitive imports otherwise appear to work correctly in 3.5:

    >>> import sys, importlib, glob
    >>> glob.glob('*.py')
    ['Test.py']

    >>> importlib._bootstrap_external._relax_case()
    False
    >>> import test
    >>> test.__file__
    'C:\\Program Files\\Python35\\lib\\test\\__init__.py'

patched:

    >>> src = "_relax_case = lambda: 'PYTHONCASEOK' in _os.environ"
    >>> exec(src, vars(importlib._bootstrap_external))
    >>> importlib._bootstrap_external._relax_case()
    True
    >>> del sys.modules['test']
    >>> import test
    this is a test
    >>> test.__file__
    'C:\\Temp\\test.py'

It would be better if __file__ were the actual filename "Test.py" instead of "test.py".

----------
components: Library (Lib), Windows
keywords: easy
messages: 266057
nosy: brett.cannon, eryksun, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: PYTHONCASEOK is ignored on Windows
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun May 22 13:53:26 2016
From: report at bugs.python.org (Evgeny Kapun)
Date: Sun, 22 May 2016 17:53:26 +0000
Subject: [New-bugs-announce] [issue27084] Add dir_fd and follow_symlinks
 kwargs to os.listdir and os.scandir
Message-ID: <1463939606.34.0.914282319382.issue27084@psf.upfronthosting.co.za>


New submission from Evgeny Kapun:

Many functions in os module support dir_fd and follow_symlinks keyword arguments. I think that os.listdir and os.scandir should do likewise.

See also: issue25996.

----------
components: Library (Lib)
messages: 266091
nosy: abacabadabacaba
priority: normal
severity: normal
status: open
title: Add dir_fd and follow_symlinks kwargs to os.listdir and os.scandir
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Sun May 22 14:08:24 2016
From: report at bugs.python.org (Evgeny Kapun)
Date: Sun, 22 May 2016 18:08:24 +0000
Subject: [New-bugs-announce] [issue27085] Make it possible to select return
 type for os.listdir
Message-ID: <1463940504.88.0.721320439319.issue27085@psf.upfronthosting.co.za>


New submission from Evgeny Kapun:

Currently, os.listdir returns a list of strings, unless called with a bytes argument, in which case a list of byte strings is returned. I think that there should be a keyword argument to override this selection.

----------
components: Library (Lib)
messages: 266093
nosy: abacabadabacaba
priority: normal
severity: normal
status: open
title: Make it possible to select return type for os.listdir
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Sun May 22 14:15:32 2016
From: report at bugs.python.org (Evgeny Kapun)
Date: Sun, 22 May 2016 18:15:32 +0000
Subject: [New-bugs-announce] [issue27086] Add closefd argument to os.listdir
Message-ID: <1463940932.93.0.542961773489.issue27086@psf.upfronthosting.co.za>


New submission from Evgeny Kapun:

Currently, when given a file descriptor, os.listdir will duplicate it so that the original file descriptor is not closed. In many cases, a file descriptor is not needed anymore after directory is listed, so this is not necessary. I propose adding a keyword argument closefd to os.listdir which, if set to True, will make os.listdir take ownership of the passed file descriptor and close it at the end.

----------
components: Library (Lib)
messages: 266094
nosy: abacabadabacaba
priority: normal
severity: normal
status: open
title: Add closefd argument to os.listdir
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Sun May 22 16:08:53 2016
From: report at bugs.python.org (Nick McElwaine)
Date: Sun, 22 May 2016 20:08:53 +0000
Subject: [New-bugs-announce] [issue27087] unable to use socket send and
 sendall due to type error
Message-ID: <1463947733.27.0.680379704915.issue27087@psf.upfronthosting.co.za>


New submission from Nick McElwaine:

import socket               # Import socket module
s = socket.socket(socket.AF_INET,socket.SOCK_STREAM)  
s.connect(hostname,port) # this works
message = 'text'
s.sendall(message) TypeError: a bytes-like object is required, not 'str'

    s.sendall(message)
TypeError: a bytes-like object is required, not 'str'

----------
components: Extension Modules
messages: 266102
nosy: Dhruve
priority: normal
severity: normal
status: open
title: unable to use socket send and sendall   due to type error
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Sun May 22 19:39:31 2016
From: report at bugs.python.org (Steve Ford)
Date: Sun, 22 May 2016 23:39:31 +0000
Subject: [New-bugs-announce] [issue27088] doc: select: epoll.poll: incorrect
 timeout units, missing maxevents
Message-ID: <1463960371.93.0.0941923922389.issue27088@psf.upfronthosting.co.za>


New submission from Steve Ford:

The short description of epoll.poll is correct (gives timeout unit as seconds [float]; includes maxevents).  However, the long description lists the timeout units as milliseconds ("If timeout is given, it specifies the length of time in milliseconds which the system will wait for events before returning."), and does not include maxevents at all.

See https://docs.python.org/3.5/library/select.html#select.poll.poll

See also https://docs.python.org/2.7/library/select.html#select.poll.poll

----------
assignee: docs at python
components: Documentation
messages: 266118
nosy: docs at python, fordsfords
priority: normal
severity: normal
status: open
title: doc: select: epoll.poll: incorrect timeout units, missing maxevents
versions: Python 2.7, Python 3.6

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

From report at bugs.python.org  Mon May 23 04:06:30 2016
From: report at bugs.python.org (Feng A)
Date: Mon, 23 May 2016 08:06:30 +0000
Subject: [New-bugs-announce] [issue27089] I think this is a small bug in
 urlparse.py
Message-ID: <1463990790.48.0.380768478643.issue27089@psf.upfronthosting.co.za>


New submission from Feng A:

=====================================================
BUG:

run : urlparse.urlparse('http://google.com]')
then: raise ValueError("Invalid IPv6 URL")

=====================================================
SOURCE:

    if url[:2] == '//':

        netloc, url = _splitnetloc(url, 2)

        if (('[' in netloc and ']' not in netloc) or

                (']' in netloc and '[' not in netloc)):

            raise ValueError("Invalid IPv6 URL")

=====================================================
SOLUTION:

I THINK IT IS BETTER TO JUST REMOVE THE LAST 3 LINES ABOVE

----------
components: Library (Lib)
messages: 266125
nosy: Feng A
priority: normal
severity: normal
status: open
title: I think this is a small bug in urlparse.py
type: behavior
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Mon May 23 06:10:49 2016
From: report at bugs.python.org (Richard Penman)
Date: Mon, 23 May 2016 10:10:49 +0000
Subject: [New-bugs-announce] [issue27090] Python 3 import error after
 installation
Message-ID: <1463998249.7.0.0539436508645.issue27090@psf.upfronthosting.co.za>


New submission from Richard Penman:

I installed latest release (https://www.python.org/downloads/release/python-351/) on OSX and get this error:

$ python3
...
ImportError: This package should not be accessible on Python 3. Either you are trying to run from the python-future src folder or your installation of python-future is corrupted.

Also tried installing via brew and got same error.

----------
components: Installation, Macintosh
messages: 266133
nosy: Richard Penman, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Python 3 import error after installation
type: crash
versions: Python 3.5

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

From report at bugs.python.org  Mon May 23 08:40:03 2016
From: report at bugs.python.org (Christian Kleineidam)
Date: Mon, 23 May 2016 12:40:03 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue27091=5D_Python_IDLE_doesn?=
 =?utf-8?b?J3QgbGlrZSDwn5KZ?=
Message-ID: <1464007203.98.0.542395550852.issue27091@psf.upfronthosting.co.za>


New submission from Christian Kleineidam:

When I past ? into the Python IDLE it closes automatically. 
I would be fine with the IDLE not being able to display the character. Automatically closing seems however excessive.

----------
components: IDLE
messages: 266138
nosy: Christian.Kleineidam
priority: normal
severity: normal
status: open
title: Python IDLE doesn't like ?
versions: Python 3.5

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

From report at bugs.python.org  Mon May 23 08:53:59 2016
From: report at bugs.python.org (Christoph Wruck)
Date: Mon, 23 May 2016 12:53:59 +0000
Subject: [New-bugs-announce] [issue27092] ord() raises TypeError in string
 input
Message-ID: <1464008039.38.0.432855281585.issue27092@psf.upfronthosting.co.za>


New submission from Christoph Wruck:

Hi,
is there any reason why ord() raises a TypeError instead of ValueError on string/bytes input with wrong length?

The chr() function will raise a ValueError on negative integers such as chr(-1).

Required behaviour:

try:
    n = ord(input_string)
except ValueError as e:
    # it's a string/bytes-string, process potential escape sequence and
    # get an ordinal number of decoded escape sequence, otherwise raise
    ...

with kind regards,
Chris

----------
components: Unicode
messages: 266142
nosy: cwr, ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: ord() raises TypeError in string input
versions: Python 3.4

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

From report at bugs.python.org  Mon May 23 09:44:14 2016
From: report at bugs.python.org (Demur Rumed)
Date: Mon, 23 May 2016 13:44:14 +0000
Subject: [New-bugs-announce] [issue27093] Silence warning in cjkcodecs.h
Message-ID: <1464011054.7.0.0824737908148.issue27093@psf.upfronthosting.co.za>


New submission from Demur Rumed:

gcc6 now warns about indentation of code. find_paireencmap raised such warnings. This patch silences that warning while updating the code to be more PEP7 friendly wrt curlies

----------
files: cjkcodecs.patch
keywords: patch
messages: 266148
nosy: Demur Rumed
priority: normal
severity: normal
status: open
title: Silence warning in cjkcodecs.h
type: compile error
versions: Python 3.6
Added file: http://bugs.python.org/file42955/cjkcodecs.patch

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

From report at bugs.python.org  Mon May 23 16:44:13 2016
From: report at bugs.python.org (Seth Norton)
Date: Mon, 23 May 2016 20:44:13 +0000
Subject: [New-bugs-announce] [issue27094] Floating Point Printing Error with
 2+.8553 or 3+.8553
Message-ID: <1464036253.1.0.85205428645.issue27094@psf.upfronthosting.co.za>


New submission from Seth Norton:

In a basic command line interpreter, adding 2 or 3 to .8553 will cause the result to be displayed as if a rounding error occurred. The number is so small that I expect it is not a mathematical error but rather in how the number is printed.

The displayed answer is 2.8552999999999997.

This also occurs in python 2.7.4. I am running Ubuntu 14.04 (64-bit).

----------
components: Interpreter Core
messages: 266183
nosy: Seth Norton
priority: normal
severity: normal
status: open
title: Floating Point Printing Error with 2+.8553 or 3+.8553
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Mon May 23 17:26:20 2016
From: report at bugs.python.org (Demur Rumed)
Date: Mon, 23 May 2016 21:26:20 +0000
Subject: [New-bugs-announce] [issue27095] Simplify MAKE_FUNCTION
Message-ID: <1464038780.83.0.81155899453.issue27095@psf.upfronthosting.co.za>


New submission from Demur Rumed:

Implemented as per https://mail.python.org/pipermail/python-dev/2016-April/144135.html

----------
files: mkfu.patch
keywords: patch
messages: 266187
nosy: Demur Rumed
priority: normal
severity: normal
status: open
title: Simplify MAKE_FUNCTION
type: performance
Added file: http://bugs.python.org/file42959/mkfu.patch

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

From report at bugs.python.org  Mon May 23 18:37:26 2016
From: report at bugs.python.org (Campbell Barton)
Date: Mon, 23 May 2016 22:37:26 +0000
Subject: [New-bugs-announce] [issue27096] Ability to get random bits from
 random.Random (as with os.urandom)
Message-ID: <1464043046.76.0.140037772611.issue27096@psf.upfronthosting.co.za>


New submission from Campbell Barton:

Currently, getting random bits can be done with os.urandom,

However recently I was faced with having to make a test (with reproducible behavior), so I needed to replace os.urandom with a random generator that took a seed value.

It turns out there are 3 ways (at least) to handle this, but none are really that great.

- Create a list, fill with Random.randint(0, 255), then convert to bytes with bytes.join.
- Call Random.getrandbits(), then int.to_bytes.
- Override urandom at a system level (possible on Linux [0]).

While these work, they are either slow (creating a list), non trivial (OS-level) or limited - Random.getrandbits hits internal limits of an int, and accidentally using the int (running repr on it for example, locks up Python), currently CPython will fail to create values above 256mb since bits is limited to INT_MAX [1].

In short, to keep tests running fast, and without messing about and accounting for internal limits of CPython, there isn't a convenient way to get random bits in Python.

Since bits are a primitive type and since its already supported by os.urandom, I think its reasonable the random module could support returning random bits.

If this is accepted, I can provide a patch for this, I'm just checking to know if the functionality would be accepted.

Suggest to call random.randbits(n).

----

[0]: http://stackoverflow.com/questions/26053875/bypass-dev-urandomrandom-for-testing
[1]: http://bugs.python.org/issue27072

----------
components: Library (Lib)
messages: 266202
nosy: ideasman42
priority: normal
severity: normal
status: open
title: Ability to get random bits from random.Random (as with os.urandom)
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Mon May 23 20:08:19 2016
From: report at bugs.python.org (Demur Rumed)
Date: Tue, 24 May 2016 00:08:19 +0000
Subject: [New-bugs-announce] [issue27097] ceval: Wordcode follow up,
 explicit unsigned short read
Message-ID: <1464048499.12.0.811410474415.issue27097@psf.upfronthosting.co.za>


New submission from Demur Rumed:

Attached is a patch based off #26647 which converts ceval to read opcode/oparg by casting next_instr to an unsigned short. I don't believe we need to complicate the code with checking the pointer alignment of the instruction stream; some effort must be gone through to generate bytecode off alignment, & if the issue comes up it's because someone's using the C API on a CPU that doesn't support unaligned reads to generate their own custom bytecode. Anyways pybench went from 16.5 on wordcode to 16.0 for me

The change works through replacing NEXTOP/NEXTARG with a NEXTOPARG macro

----------
components: Interpreter Core
files: ushort.patch
keywords: patch
messages: 266209
nosy: Demur Rumed
priority: normal
severity: normal
status: open
title: ceval: Wordcode follow up, explicit unsigned short read
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file42961/ushort.patch

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

From report at bugs.python.org  Mon May 23 21:37:55 2016
From: report at bugs.python.org (Memeplex)
Date: Tue, 24 May 2016 01:37:55 +0000
Subject: [New-bugs-announce] [issue27098] Pickle of memoryview not raising
 error
Message-ID: <1464053875.71.0.444720123134.issue27098@psf.upfronthosting.co.za>


New submission from Memeplex:

In [1]: mv = memoryview(b'123')
In [2]: mv.__reduce__()
    TypeError: can't pickle memoryview objects

But then:

In [3]: pickle.dumps(mv)
    b'\x80\x03cbuiltins\nmemoryview\nq\x00)\x81q\x01.'

Even worse:

In [4]: pickle.loads(pickle.dumps(mv))
    TypeError: Required argument 'object' (pos 1) not found

According to the module documentation: Attempts to pickle unpicklable objects will raise the PicklingError exception.

----------
components: Extension Modules
messages: 266212
nosy: memeplex
priority: normal
severity: normal
status: open
title: Pickle of memoryview not raising error
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Mon May 23 22:02:40 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 24 May 2016 02:02:40 +0000
Subject: [New-bugs-announce] [issue27099] IDLE: turn builting extensions
 into regular modules
Message-ID: <1464055360.13.0.626532918919.issue27099@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

Followup to #24225, which renamed idlelib files.

Currently, an arbitrary set of 9 (of 10, if Check Module is counted as a separate feature) IDLE features are implemented as extensions.  Their menu names are as follows:
  Edit - Show Completions
  Edit - Expand Word
  Edit - Show call tip
  Edit - Show surrounding parens
  Format - Format Paragraph
  Format - Strip trailing whitespace
  Run - Check Module (same file as below)
  Run - Run Module
  Options - Code Context
  Window - Zoom Height

This issue proposes to turn these into normal features implemented in regular code. 

1. The menu entries for extensions are not included in the main menu definition file (mainmenu, previously Bindings).  Rather, they are appended when the file is read.  This is constricting.  The order of the 4 edit entries is the alphabetical order of the corresponding file names. Run Module should be at the top of the Run menu, rather than being shoved down further if and when more non-extension entries are added.

2. Each feature is a separate file, usually small to medium with one class.  This bloats the number of modules in idlelib (now about 60).  I am considering combining autoexpand and parenmatch, paragraph and rstrip, and codecontext and zoomheight (and moving codecontext to the Window menu).  They might be joined with other features from the same menu.

3. The user customization system is not very compatible with change.  The problems with extension customization and changing file names is discussed in the second half of msg266213.  If extensions are not converted, another solution will be needed.

I have not yet tested the effect of adding new key bindings to config-keys.def and config-keys.cfg.  If this causes a problem for current releases, then this is a problem we need to face.  I anticipate wanting to add other new keybindings, such as one to switch tabs when we use a notebook.

----------
assignee: terry.reedy
messages: 266214
nosy: ned.deily, terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: IDLE: turn builting extensions into regular modules
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Mon May 23 23:28:37 2016
From: report at bugs.python.org (Jonathan Ellington)
Date: Tue, 24 May 2016 03:28:37 +0000
Subject: [New-bugs-announce] [issue27100] Attempting to use class with both
 __enter__ & __exit__ undefined yields __exit__ attribute error
Message-ID: <1464060517.76.0.559675330412.issue27100@psf.upfronthosting.co.za>


New submission from Jonathan Ellington:

Attempting to use class that has both __exit__() and __enter__() undefined as a context manager yields an AttributeError referring to __exit__:

>>> class A():
...     pass
...
>>> with A():
...     pass
...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: A instance has no attribute '__exit__'


Knowing that the 'with' statement should first execute __enter__, this is unexpected.

The patch ensures the attribute error refers to __enter__() when both methods are undefined.

----------
components: Interpreter Core
files: with.patch
keywords: patch
messages: 266219
nosy: ellingtonjp, rhettinger
priority: normal
severity: normal
status: open
title: Attempting to use class with both __enter__ & __exit__ undefined yields __exit__ attribute error
type: behavior
Added file: http://bugs.python.org/file42962/with.patch

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

From report at bugs.python.org  Tue May 24 01:14:47 2016
From: report at bugs.python.org (Petr Ovtchenkov)
Date: Tue, 24 May 2016 05:14:47 +0000
Subject: [New-bugs-announce] [issue27101] Compilation of python (modules)
 for foreign target platform problem.
Message-ID: <1464066887.71.0.116030526807.issue27101@psf.upfronthosting.co.za>


New submission from Petr Ovtchenkov:

Compilation of python for foreign target platform problem.

Host arch is x86_64, target arch is arm (arm32).

Configuration is (target arch part):

        (cd build-python && \
        DESTDIR=${SYSROOT} \
        PKG_CONFIG=true \
        LIBFFI_INCLUDEDIR= \
        PATH=${CURDIR}/host-python-home/bin:$$PATH \
        PYTHONHOME=${CURDIR}/host-python-home/lib \
        PYTHONPATH=${CURDIR}/host-python-home/lib/python3.5 \
        ../cpython/configure \
          --host=${TARGET_CROSS} \
          --build=${BUILD_M_ARCH}-unknown-linux-gnu \
          --prefix=/usr \
          --sysconfdir=/etc \
          --localstatedir=/var \
          --enable-shared \
          --disable-ipv6 \
          --with-system-ffi \
          --with-system-expat \
          --without-ensurepip \
          --cache-file=config.cache\
        )
        sed -e 's/#define HAVE_ATTRIBUTE_FORMAT_PARSETUPLE 1/#undef HAVE_ATTRIBUTE_FORMAT_PARSETUPLE/' -i build-python/pyconfig.h
        sed -e '/^PGEN=/ s|=.*$$|=\t\t${CURDIR}/build-python-native/Parser/pgen|' -e '/^LDFLAGS=/ s|=.*$$|=\t\t-L.|' -e '/^\$$(PGEN):/,+1d' -e '/^LIBFFI_INCLUDEDIR=/ s|=.*$$|=|' -i build-python/Makefile

Problem: option -I/usr/include passed to compiler during modules compilation. This lead to fails, due to target platform is different from host.

Suggested patch resolve the issue for me.

BTW, pass -I/usr/include is useless even for native builds.

----------
components: Cross-Build
files: cpython.patch
keywords: patch
messages: 266225
nosy: Alex.Willmer, complement
priority: normal
severity: normal
status: open
title: Compilation of python (modules) for foreign target platform problem.
type: compile error
versions: Python 3.5
Added file: http://bugs.python.org/file42963/cpython.patch

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

From report at bugs.python.org  Tue May 24 09:40:56 2016
From: report at bugs.python.org (cerberos)
Date: Tue, 24 May 2016 13:40:56 +0000
Subject: [New-bugs-announce] [issue27102] nice story
Message-ID: <0000629394c7$45bbfcaf$0277fcd5$@whywouldwe.com>


New submission from cerberos:

Hello,

There are a cople of stories I wanted to share with you, please, read more here <http://wonojespe.susanred.com/aekcsqy>

Thanks for your consideration, info at whywouldwe.com

----------
messages: 266251
nosy: cerberos
priority: normal
severity: normal
status: open
title: nice story

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

From report at bugs.python.org  Tue May 24 11:20:30 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 May 2016 15:20:30 +0000
Subject: [New-bugs-announce] [issue27103] regrtest: capture stdout (-W)
 option is incompatible with refleak hunter (-R)
Message-ID: <1464103230.09.0.503477330066.issue27103@psf.upfronthosting.co.za>


New submission from STINNER Victor:

The -R option of regrtest replaces sys.stdout with a io.StringIO object. Problem: the refleak are hunted after stdout is replaced, and so each print() increaes the total reference counter which is seen as a leak.

Example:

$ cat Lib/test/test_noop.py 
"noop"

$ ./python -u -m test -R 3:3 -W test_noop 
Run tests sequentially
0:00:00 [1/1] test_noop

----------------------------------------------------------------------
Ran 0 tests in 0.000s

OK
beginning 6 repetitions
123456

----------------------------------------------------------------------
Ran 0 tests in 0.000s

OK
.
(...)
test_noop leaked [9, 9, 9] references, sum=27
test_noop failed
1 test failed:
    test_noop
Total duration: 0:00:01

----------
components: Tests
messages: 266254
nosy: haypo
priority: normal
severity: normal
status: open
title: regrtest: capture stdout (-W) option is incompatible with refleak hunter (-R)
versions: Python 3.6

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

From report at bugs.python.org  Tue May 24 13:10:08 2016
From: report at bugs.python.org (Alexandra Beebe)
Date: Tue, 24 May 2016 17:10:08 +0000
Subject: [New-bugs-announce] [issue27104] enable-framework
Message-ID: <1464109808.75.0.969768619517.issue27104@psf.upfronthosting.co.za>


New submission from Alexandra Beebe:

When trying to build a framework on osx getting this error during install.

Mage:Python-3.4.4 alexandra$ sudo make install
Password:
Creating directory /Library/Frameworks/Python.framework/Versions/3.4/Resources/English.lproj
Creating directory /Library/Frameworks/Python.framework/Versions/3.4/lib
ln -fsn include/python3.4m /Library/Frameworks/Python.framework/Versions/3.4/Headers
sed 's/%VERSION%/'"`DYLD_FRAMEWORK_PATH=/Volumes/RAM/Python-3.4.4 ./python.exe -c 'import platform; print(platform.python_version())'`"'/g' < Mac/Resources/framework/Info.plist > /Library/Frameworks/Python.framework/Versions/3.4/Resources/Info.plist
sed: 1: "s/%VERSION%/3.4.4
PyMod ...": unescaped newline inside substitute pattern
make: *** [frameworkinstallstructure] Error 1

----------
components: Installation, Macintosh
messages: 266255
nosy: alexandra.beebe at gmail.com, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: enable-framework
type: compile error
versions: Python 3.4

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

From report at bugs.python.org  Tue May 24 16:26:15 2016
From: report at bugs.python.org (=?utf-8?q?Jacek_Ko=C5=82odziej?=)
Date: Tue, 24 May 2016 20:26:15 +0000
Subject: [New-bugs-announce] [issue27105] cgi.__all__ is incomplete
Message-ID: <1464121575.73.0.75569808483.issue27105@psf.upfronthosting.co.za>


New submission from Jacek Ko?odziej:

That's a child issue of #23883, created to propose a patch fixing cgi module's __all__ list.

----------
components: Library (Lib)
files: cgi_all.patch
keywords: patch
messages: 266265
nosy: Unit03
priority: normal
severity: normal
status: open
title: cgi.__all__ is incomplete
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42967/cgi_all.patch

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

From report at bugs.python.org  Tue May 24 16:28:25 2016
From: report at bugs.python.org (=?utf-8?q?Jacek_Ko=C5=82odziej?=)
Date: Tue, 24 May 2016 20:28:25 +0000
Subject: [New-bugs-announce] [issue27106] configparser.__all__ is incomplete
Message-ID: <1464121705.13.0.123221989673.issue27106@psf.upfronthosting.co.za>


New submission from Jacek Ko?odziej:

That's a child issue of #23883, created to propose a patch fixing configparser module's __all__ list.

----------
components: Library (Lib)
files: configparser_all.patch
keywords: patch
messages: 266266
nosy: Unit03
priority: normal
severity: normal
status: open
title: configparser.__all__ is incomplete
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42968/configparser_all.patch

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

From report at bugs.python.org  Tue May 24 16:30:14 2016
From: report at bugs.python.org (=?utf-8?q?Jacek_Ko=C5=82odziej?=)
Date: Tue, 24 May 2016 20:30:14 +0000
Subject: [New-bugs-announce] [issue27107] mailbox.__all__ list is incomplete
Message-ID: <1464121814.28.0.86378219066.issue27107@psf.upfronthosting.co.za>


New submission from Jacek Ko?odziej:

That's a child issue of #23883, created to propose a patch fixing mailbox module's __all__ list.

----------
components: Library (Lib)
files: mailbox_all.patch
keywords: patch
messages: 266267
nosy: Unit03
priority: normal
severity: normal
status: open
title: mailbox.__all__ list is incomplete
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42969/mailbox_all.patch

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

From report at bugs.python.org  Tue May 24 16:31:36 2016
From: report at bugs.python.org (=?utf-8?q?Jacek_Ko=C5=82odziej?=)
Date: Tue, 24 May 2016 20:31:36 +0000
Subject: [New-bugs-announce] [issue27108] mimetypes.__all__ list is
 incomplete
Message-ID: <1464121896.07.0.577561794509.issue27108@psf.upfronthosting.co.za>


New submission from Jacek Ko?odziej:

That's a child issue of #23883, created to propose a patch fixing mimetypes module's __all__ list.

----------
components: Library (Lib)
files: mimetypes_all.patch
keywords: patch
messages: 266268
nosy: Unit03
priority: normal
severity: normal
status: open
title: mimetypes.__all__ list is incomplete
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42970/mimetypes_all.patch

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

From report at bugs.python.org  Tue May 24 16:32:52 2016
From: report at bugs.python.org (=?utf-8?q?Jacek_Ko=C5=82odziej?=)
Date: Tue, 24 May 2016 20:32:52 +0000
Subject: [New-bugs-announce] [issue27109] plistlib.__all__ list is incomplete
Message-ID: <1464121972.25.0.312623599868.issue27109@psf.upfronthosting.co.za>


New submission from Jacek Ko?odziej:

That's a child issue of #23883, created to propose a patch fixing plistlib module's __all__ list.

----------
components: Library (Lib)
files: plistlib_all.patch
keywords: patch
messages: 266269
nosy: Unit03
priority: normal
severity: normal
status: open
title: plistlib.__all__ list is incomplete
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42971/plistlib_all.patch

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

From report at bugs.python.org  Tue May 24 16:41:47 2016
From: report at bugs.python.org (=?utf-8?q?Jacek_Ko=C5=82odziej?=)
Date: Tue, 24 May 2016 20:41:47 +0000
Subject: [New-bugs-announce] [issue27110] smtpd.__all__ list is incomplete
Message-ID: <1464122507.71.0.719319292765.issue27110@psf.upfronthosting.co.za>


New submission from Jacek Ko?odziej:

That's a child issue of #23883, created to propose a patch fixing smtpd module's __all__ list.

----------
components: Library (Lib)
files: smtpd_all.patch
keywords: patch
messages: 266270
nosy: Unit03
priority: normal
severity: normal
status: open
title: smtpd.__all__ list is incomplete
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42972/smtpd_all.patch

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

From report at bugs.python.org  Tue May 24 16:43:24 2016
From: report at bugs.python.org (Oren Milman)
Date: Tue, 24 May 2016 20:43:24 +0000
Subject: [New-bugs-announce] [issue27111] redundant variables in long_add
 and long_sub
Message-ID: <1464122604.65.0.69831533642.issue27111@psf.upfronthosting.co.za>


New submission from Oren Milman:

------------ the proposed changes ------------
In Objects/longobject.c in long_add and long_sub, the variables 'result' and 'r' (respectively), are used only once, and don't seem to make the code any clearer.

It seems the 'result' and 'r' variables were added in revision 40751. Back then, CONVERT_BINOP was used, and required calling Py_DECREF for a and b before returning.
Later on, in revision 43313, CONVERT_BINOP was removed, along with the calls to Py_DECREF it required, but the 'result' and 'r' variables were left untouched, and remained there to this day.


------------ diff ------------
The patches diff is attached.


------------ tests ------------
I built the patched CPython for x86, and played with it a little. Everything seemed to work as usual.

In addition, I ran 'python -m test' (on my 64-bit Windows 10) before and after applying the patch, and got quite the same output.
the outputs of both runs are attached.

----------
components: Interpreter Core
files: proposedPatches.diff
keywords: patch
messages: 266271
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: redundant variables in long_add and long_sub
versions: Python 3.6
Added file: http://bugs.python.org/file42973/proposedPatches.diff

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

From report at bugs.python.org  Tue May 24 16:56:35 2016
From: report at bugs.python.org (=?utf-8?q?Jacek_Ko=C5=82odziej?=)
Date: Tue, 24 May 2016 20:56:35 +0000
Subject: [New-bugs-announce] [issue27112] tokenize.__all__ list is incomplete
Message-ID: <1464123395.58.0.823594635343.issue27112@psf.upfronthosting.co.za>


New submission from Jacek Ko?odziej:

That's a child issue of #23883, created to propose a patch fixing tokenize module's __all__ list.

Changes in tests go farther: I've changed import from

    from tokenize import ...

to

    import tokenize

and adjusted all its usages accordingly.

The module must be imported in order to test its __all__ list through test.support.check__all__ helper and just adding this single import would either force us to either do
* import tokenize as tokenize_module
* or from tokenize import tokenize as tokenize_function

I think going third way: with just "import tokenize" and changing its uses in the rest of tests result in celarer code, but of course I guess this may be too much for a single patch.

----------
components: Library (Lib)
files: tokenize_all.patch
keywords: patch
messages: 266275
nosy: Unit03
priority: normal
severity: normal
status: open
title: tokenize.__all__ list is incomplete
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42976/tokenize_all.patch

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

From report at bugs.python.org  Tue May 24 17:36:29 2016
From: report at bugs.python.org (Dave Sawyer)
Date: Tue, 24 May 2016 21:36:29 +0000
Subject: [New-bugs-announce] [issue27113] sqlite3 open parameter
 "check_same_thread" not documented
Message-ID: <1464125789.84.0.570004715823.issue27113@psf.upfronthosting.co.za>


New submission from Dave Sawyer:

The sqlite3.connect method has 6 parameters. 5 of them are documented.  See below and search for "check_same_thread".  Patch adds documentation for this parameter.

sqlite3.connect(database[, timeout, detect_types, isolation_level, check_same_thread, factory, cached_statements])
Opens a connection to the SQLite database file database. You can use ":memory:" to open a database connection to a database that resides in RAM instead of on disk.

When a database is accessed by multiple connections, and one of the processes modifies the database, the SQLite database is locked until that transaction is committed. The timeout parameter specifies how long the connection should wait for the lock to go away until raising an exception. The default for the timeout parameter is 5.0 (five seconds).

For the isolation_level parameter, please see the Connection.isolation_level property of Connection objects.

SQLite natively supports only the types TEXT, INTEGER, REAL, BLOB and NULL. If you want to use other types you must add support for them yourself. The detect_types parameter and the using custom converters registered with the module-level register_converter() function allow you to easily do that.

detect_types defaults to 0 (i. e. off, no type detection), you can set it to any combination of PARSE_DECLTYPES and PARSE_COLNAMES to turn type detection on.

By default, the sqlite3 module uses its Connection class for the connect call. You can, however, subclass the Connection class and make connect() use your class instead by providing your class for the factory parameter.

Consult the section SQLite and Python types of this manual for details.

The sqlite3 module internally uses a statement cache to avoid SQL parsing overhead. If you want to explicitly set the number of statements that are cached for the connection, you can set the cached_statements parameter. The currently implemented default is to cache 100 statements.

----------
assignee: docs at python
components: Documentation
files: doc_parm.patch
keywords: patch
messages: 266281
nosy: Dave Sawyer, docs at python
priority: normal
severity: normal
status: open
title: sqlite3 open parameter "check_same_thread" not documented
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file42978/doc_parm.patch

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

From report at bugs.python.org  Tue May 24 18:24:35 2016
From: report at bugs.python.org (Steve Dower)
Date: Tue, 24 May 2016 22:24:35 +0000
Subject: [New-bugs-announce] [issue27114]
 SSLContext._load_windows_store_certs fails with PermissionError
Message-ID: <1464128675.76.0.296997884833.issue27114@psf.upfronthosting.co.za>


New submission from Steve Dower:

In some restricted server scenarios, it is not possible to enumerate the Windows machine certificate store. A PermissionError is raised and the operation aborted.

Instead, we should simply return no certificates from _load_windows_store_certs. This will most likely cause the SSL request to fail (as the certificate cannot be verified), but it allows the use of SSL_CERT_FILE to use certificates from a local file. Without handling the PermissionError, it doesn't matter whether the environment variable is set or not - we simply fail every time.

----------
assignee: steve.dower
components: Windows
messages: 266285
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: SSLContext._load_windows_store_certs fails with PermissionError
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue May 24 19:26:29 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 24 May 2016 23:26:29 +0000
Subject: [New-bugs-announce] [issue27115] IDLE/tkinter: in simpledialog,
 <Return> != [OK] click
Message-ID: <1464132389.32.0.350798699754.issue27115@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

On Win 10, Python 3.5 or 3.6, IDLE Shell or Editor with at least a few lines of text: hit Alt-G to open 'Goto' window.  Enter a line # other than the current one.  Hit <Return>.  Cursor moves to line enter, though it shrinks to one pixel wide from two pixels.  Line:col in status bar is updated.

Instead of hitting return, click [OK] button.  Same thing happens except that status bar line:col is NOT updated.  Here is relevant code in EditorWindow, about line 610

    def goto_line_event(self, event):
        text = self.text
        lineno = tkSimpleDialog.askinteger("Goto",
                "Go to line number:",parent=text)
        text.mark_set("insert", "%d.0" % lineno)
        text.see("insert")

Changing parent=text to parent=self.root makes no difference.  I have not yet tried simulating the interaction with button.invoke and event_generate('<Key-Return>.

My guess is that one of the last two tk methods is supposed to generate a cursor moved event that is bound to a reset status bar function.  But somehow the previous click instead of keypress inhibits the event.  So this seems a tk bug.  Sethiy, what do you think?

The workaround for IDLE is to manually invoke a status bar update.

----------
components: IDLE, Tkinter
messages: 266289
nosy: serhiy.storchaka, terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: IDLE/tkinter: in simpledialog, <Return> != [OK] click
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue May 24 22:24:52 2016
From: report at bugs.python.org (dananntang)
Date: Wed, 25 May 2016 02:24:52 +0000
Subject: [New-bugs-announce] [issue27116] Documentation for regular
 expression alphanumeric matching are swapped.
 https://docs.python.org/2/library/re.html#regular-expression-syntax
Message-ID: <1464143092.14.0.677352167387.issue27116@psf.upfronthosting.co.za>


New submission from dananntang:

https://docs.python.org/2/library/re.html#regular-expression-syntax
Section 7.2.1. Regular Expression Syntax

Documentation for \w and \W are wrong.
To be specific:
\w is to match any non-alphanumeric character, while \W is to match alphanumeric character

Fix: swap documentation for \w and \W

----------
assignee: docs at python
components: Documentation
messages: 266291
nosy: dananntang, docs at python
priority: normal
severity: normal
status: open
title: Documentation for regular expression alphanumeric matching are swapped. https://docs.python.org/2/library/re.html#regular-expression-syntax
versions: Python 2.7

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

From report at bugs.python.org  Tue May 24 23:02:19 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 25 May 2016 03:02:19 +0000
Subject: [New-bugs-announce] [issue27117] turtledemo does not work with
 IDLE's new dark theme.
Message-ID: <1464145339.77.0.706051446081.issue27117@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

turtledemo imports IDLE's Percolator, ColorDelegator, and read-only text viewer and uses the first two to colorize demo text it loads into the text viewer.  This works fine for traditional dark on white text color themes but not for IDLE's new white, etc, on dark theme (IDLE Dark).  The reason is that the text viewer was designed to display black on white text, not colorized  code.  IDLE's editor tells tk how to display normal text.  The text view does not, so normal text is the default black on white.  The result is that special items are color on 'black' (dark blue actually) while normal text is black on white.  The strange result can be viewed by selecting IDLE Dark in the preferences dialog and then selecting Help - Turtledemo or running 'python -m turtledemo' in a console.

The immediate workaround is for anyone running turtledemo to use a normal color theme, at least temporarily.  A longer-term solution might be to add a startup option to the text viewer to use the 'normal text' colors of the current theme.

----------
messages: 266293
nosy: terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: turtledemo does not work with IDLE's new dark theme.
type: behavior
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed May 25 02:12:40 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 25 May 2016 06:12:40 +0000
Subject: [New-bugs-announce] [issue27118] Several Py_XDECREFs are not
 necessary
Message-ID: <1464156760.73.0.28265991298.issue27118@psf.upfronthosting.co.za>


New submission from Xiang Zhang:

Several Py_XDECREFs are not necessary since the pointers they handle cannot be NULL.

----------
files: Py_XDECREF_in_typeobject.diff
keywords: patch
messages: 266307
nosy: xiang.zhang
priority: normal
severity: normal
status: open
title: Several Py_XDECREFs are not necessary
Added file: http://bugs.python.org/file42985/Py_XDECREF_in_typeobject.diff

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

From report at bugs.python.org  Wed May 25 02:42:47 2016
From: report at bugs.python.org (Franklin? Lee)
Date: Wed, 25 May 2016 06:42:47 +0000
Subject: [New-bugs-announce] [issue27119] `compile` doesn't compile into an
 AST object as specified
Message-ID: <1464158567.97.0.0204496298527.issue27119@psf.upfronthosting.co.za>


New submission from Franklin? Lee:

>From `compile`'s doc:
    "Compile the source into a code or AST object."

The docs don't say how to compile into an AST object with `compile`, though. As it says later:
    "If you want to parse Python code into its AST representation, see ast.parse()."

I checked 3.4-3.2, 3.0, 2.7, and 2.6. Versions before 3.4, and version 2.6, are missing the `ast.parse` line, but still have the first line.

----------
assignee: docs at python
components: Documentation
messages: 266311
nosy: docs at python, leewz
priority: normal
severity: normal
status: open
title: `compile` doesn't compile into an AST object as specified
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed May 25 05:09:33 2016
From: report at bugs.python.org (Enrico)
Date: Wed, 25 May 2016 09:09:33 +0000
Subject: [New-bugs-announce] [issue27120] xmllib unable to parse in UTF8
 format
Message-ID: <1464167373.86.0.726090753957.issue27120@psf.upfronthosting.co.za>


New submission from Enrico:

The xmllib.XMLParser seems to be unable to parse 
an XML file that contains cyrillic characters.


   File "xmllib.pyc", line 172, in feed
   File "xmllib.pyc", line 268, in goahead
   File "xmllib.pyc", line 798, in syntax_error
 Error: Syntax error at line 8: illegal character in content

----------
components: XML
messages: 266322
nosy: enrico.terraneo at scamesistemi.it
priority: normal
severity: normal
status: open
title: xmllib unable to parse in UTF8 format
versions: Python 2.7

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

From report at bugs.python.org  Wed May 25 06:00:47 2016
From: report at bugs.python.org (=?utf-8?q?Ren=C3=A9_L=C3=B8we_Jacobsen?=)
Date: Wed, 25 May 2016 10:00:47 +0000
Subject: [New-bugs-announce] [issue27121] imghdr does not support jpg files
 with Lavc bytes
Message-ID: <1464170447.09.0.218380322577.issue27121@psf.upfronthosting.co.za>


New submission from Ren? L?we Jacobsen:

Some jpegs might have Lavc instead of JFIF or Exif. I have added a picture for you to test with.

----------
files: 5ZK0umWbRmsQwGkUb4LhIV6L9YnInn6t_thumb.jpg
messages: 266327
nosy: Ren? L?we Jacobsen
priority: normal
severity: normal
status: open
title: imghdr does not support jpg files with Lavc bytes
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42987/5ZK0umWbRmsQwGkUb4LhIV6L9YnInn6t_thumb.jpg

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

From report at bugs.python.org  Wed May 25 07:48:00 2016
From: report at bugs.python.org (Valentin David)
Date: Wed, 25 May 2016 11:48:00 +0000
Subject: [New-bugs-announce] [issue27122] Hang with contextlib.ExitStack and
 subprocess.Popen (regression)
Message-ID: <1464176880.25.0.308106356091.issue27122@psf.upfronthosting.co.za>


New submission from Valentin David:

The attached script hangs while using 100% on Python 3.5.1 but not on Python 3.4.3. Tested both on Gentoo Linux and Ubuntu Linux.

The loop seems to be in PyErr_SetObject in a loop that recursively go through PyException_GetContext.

subprocess.Popen seems to cause the issue while calling io.open. strace reveals a error on call to lseek on a pipe.

The issue does not happen when using nested "with" instead of ExitStack.

----------
files: hang_bug.py
messages: 266333
nosy: Valentin David
priority: normal
severity: normal
status: open
title: Hang with contextlib.ExitStack and subprocess.Popen (regression)
versions: Python 3.5
Added file: http://bugs.python.org/file42989/hang_bug.py

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

From report at bugs.python.org  Wed May 25 10:24:35 2016
From: report at bugs.python.org (Sylvain Corlay)
Date: Wed, 25 May 2016 14:24:35 +0000
Subject: [New-bugs-announce] [issue27123] Allow `install_headers` command to
 follow specific directory structure
Message-ID: <1464186275.75.0.908359845764.issue27123@psf.upfronthosting.co.za>


New submission from Sylvain Corlay:

(instead of making a flat copy of the specified list of headers)

Unlike wheel's `data_files`, which allows to specify data files as a list of tuples

`[(target_directory, [list of files for target directory])]` 

the `headers` setup keyword argument only let's you specify a list of files that will be copied over to a sub-directory of `sysconfig.get_path('include')`.

It would be useful to enable the same feature for headers as we have for data files.

----------
components: Distutils
messages: 266360
nosy: dstufft, eric.araujo, sylvain.corlay
priority: normal
severity: normal
status: open
title: Allow `install_headers` command to follow specific directory structure
type: enhancement
versions: Python 2.7, Python 3.6

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

From report at bugs.python.org  Wed May 25 11:42:31 2016
From: report at bugs.python.org (Lennart Grahl)
Date: Wed, 25 May 2016 15:42:31 +0000
Subject: [New-bugs-announce] [issue27124] binascii.a2b_hex raises
 binascii.Error, not TypeError
Message-ID: <1464190951.12.0.309980767012.issue27124@psf.upfronthosting.co.za>


New submission from Lennart Grahl:

When using binascii.a2b_hex (or binascii.unhexlify) and the argument is invalid, the doc states that it should raise a TypeError for invalid arguments (e.g. passing an odd-length string).

However, it does raise binascii.Error instead of TypeError:

try:
    binascii.a2b_hex('a')
except Exception as exc:
    print(type(exc))

----------
assignee: docs at python
components: Documentation
messages: 266368
nosy: Lennart Grahl, docs at python
priority: normal
severity: normal
status: open
title: binascii.a2b_hex raises binascii.Error, not TypeError
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Wed May 25 18:43:05 2016
From: report at bugs.python.org (Phoenix)
Date: Wed, 25 May 2016 22:43:05 +0000
Subject: [New-bugs-announce] [issue27125] Typo in Python 2 multiprocessing
 documentation
Message-ID: <1464216185.35.0.531405853541.issue27125@psf.upfronthosting.co.za>


New submission from Phoenix:

At https://docs.python.org/2/library/multiprocessing.html#authentication-keys there is a typo in the documentation:

"If authentication is requested but do authentication key is specified ..."

s/b (emphasis added)

"If authentication is requested but **no** authentication key is specified..."

----------
assignee: docs at python
components: Documentation
messages: 266393
nosy: docs at python, phx
priority: normal
severity: normal
status: open
title: Typo in Python 2 multiprocessing documentation
versions: Python 2.7

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

From report at bugs.python.org  Wed May 25 19:05:05 2016
From: report at bugs.python.org (Evan Jones)
Date: Wed, 25 May 2016 23:05:05 +0000
Subject: [New-bugs-announce] [issue27126] Mac system sqlite3 not fork safe:
 Bundle a version?
Message-ID: <1464217505.87.0.0701340905112.issue27126@psf.upfronthosting.co.za>


New submission from Evan Jones:

The system version of libsqlite3 that is included in Mac OS X is not fork safe. This means that if a process forks, and the child calls into it, it will crash with the stack trace below.

I've reproduced this with both Python 2.7.10 and Python 3.5.1 on Mac OS X 10.11.5. There are a number of reports about this issue on the Internet. The only way I can think to solve this problem is to bundle SQLite with the Python source code, and build an included version. This will avoid the problem, since only Apple's fork of SQLite uses the problematic libdispatch library.


Details:

* Apple ships a version of sqlite3 that uses their "Grand Central Dispatch" libdispatch library.

* Grand Central Dispatch is explicitly *not* thread safe. From their docs:

https://developer.apple.com/library/mac/documentation/Performance/Reference/GCD_libdispatch_Ref/index.html

"Be careful when mixing GCD with the fork system call. If a process makes GCD calls prior to calling fork, it is not safe to make additional GCD calls in the resulting child process until after a successful call to exec or related functions."

* Some System APIs also seem to call into this library. In my case: urllib/urllib2 access the system's proxy settings.


Related bugs:
* I believe this is the root cause of https://bugs.python.org/issue20353
* Celery also has a detailed bug report: https://github.com/celery/celery/issues/869
* Pure native code can cause this crash: http://ludovicrousseau.blogspot.com/2015/01/os-x-yosemite-bug-pcsc-functions-crash.html



Crash details from Mac OS X's system Python:

Application Specific Information:
crashed on child side of fork pre-exec

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libdispatch.dylib               0x00007fff92e8b162 _dispatch_barrier_async_f_slow + 356
1   libsqlite3.dylib                0x00007fff8a607656 sqlite3_initialize + 2950
2   libsqlite3.dylib                0x00007fff8a605b21 openDatabase + 65
3   _sqlite3.so                     0x0000000105bb9a55 pysqlite_connection_init + 509
4   org.python.python               0x000000010567bc24 0x10562f000 + 314404
5   org.python.python               0x0000000105639202 PyObject_Call + 99
6   _sqlite3.so                     0x0000000105bbdbf0 0x105bb8000 + 23536
7   org.python.python               0x00000001056b5a0b PyEval_EvalFrameEx + 13400
8   org.python.python               0x00000001056b8541 0x10562f000 + 562497
9   org.python.python               0x00000001056b530c PyEval_EvalFrameEx + 11609
10  org.python.python               0x00000001056b23c1 PyEval_EvalCodeEx + 1583
11  org.python.python               0x00000001056b1d8c PyEval_EvalCode + 54
12  org.python.python               0x00000001056d1a42 0x10562f000 + 666178
13  org.python.python               0x00000001056d1ae5 PyRun_FileExFlags + 133
14  org.python.python               0x00000001056d1634 PyRun_SimpleFileExFlags + 698
15  org.python.python               0x00000001056e3011 Py_Main + 3137
16  libdyld.dylib                   0x00007fff8eb225ad start + 1

----------
components: Macintosh
files: osx_python_crash.py
messages: 266396
nosy: evan.jones at bluecore.com, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Mac system sqlite3 not fork safe: Bundle a version?
versions: Python 2.7, Python 3.5
Added file: http://bugs.python.org/file43003/osx_python_crash.py

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

From report at bugs.python.org  Wed May 25 21:44:24 2016
From: report at bugs.python.org (Demur Rumed)
Date: Thu, 26 May 2016 01:44:24 +0000
Subject: [New-bugs-announce] [issue27127] Never have GET_ITER not followed
 by FOR_ITER
Message-ID: <1464227064.89.0.81963094053.issue27127@psf.upfronthosting.co.za>


New submission from Demur Rumed:

This is a small change to comprehensions pass in their iterable rather than calling GET_ITER before CALL_FUNCTION. This makes it so that the compiler never generates GET_ITER without following it with FOR_ITER, nor does it generate FOR_ITER without preceding it by GET_ITER

This is the standalone portion of a more constructive patch I'm wanting to submit: Replace GET_ITER with a FOR_BEGIN which effectively acts as GET_ITER/FOR_ITER. Then modify FOR_ITER to replace the JUMP_ABSOLUTE by changing it to a JABS instruction which jumps if the iterator does not return null. This reduces the bytecode of by 2 bytes for every for loop & reduces the dispatch count per loop by 1 (As we merge GET_ITER/FOR_ITER & JUMP_ABSOLUTE/FOR_ITER)

----------
components: Interpreter Core
files: gitfit.patch
keywords: patch
messages: 266400
nosy: Demur Rumed
priority: normal
severity: normal
status: open
title: Never have GET_ITER not followed by FOR_ITER
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file43006/gitfit.patch

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

From report at bugs.python.org  Thu May 26 06:15:56 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 26 May 2016 10:15:56 +0000
Subject: [New-bugs-announce] [issue27128] Add _PyObject_FastCall()
Message-ID: <1464257756.81.0.101125062969.issue27128@psf.upfronthosting.co.za>


New submission from STINNER Victor:

Since the issue #26814 proved that avoiding the creation of temporary tuples to call Python and C functions makes Python faster (between 2% and 29% depending on the benchmark), I extracted a first "minimal" patch to start merging this work.

The first patch adds new functions:

* PyObject_CallNoArg(func) and PyObject_CallArg1(func, arg): public functions
* _PyObject_FastCall(func, args, nargs, kwargs): private function

I hesitate between the C types "int" and "Py_ssize_t" for nargs. I read once that using "int" can cause performance issues on a loop using "i++" and "data[i]" because the compiler has to handle integer overflow of the int type.

The "int" type is also annoying on Windows 64-bit, it causes compiler warnings on downcast like PyTuple_GET_SIZE(co->co_argcount) stored into a C int.


_PyObject_FastCall() avoids the creation of tuple for:

* All Python functions (PyFunction_Check)
* C functions using METH_NOARGS or METH_O

The patch removes the "cache tuple" optimization from property_descr_get(), it uses PyObject_CallArg1() instead. It means that the optimization is (currently) missed in some cases compared to the current code, but the code is safer and simpler.


The patch adds Python/pystack.c which currently only contains _PyStack_AsTuple(), but will contain more code later.


I tried to write the smallest patch, but I started to use PyObject_CallNoArg() and PyObject_CallArg1() when the code already created a tuple at each call: PyObject_CallObject(), call_function_tail() and PyEval_CallObjectWithKeywords().


In the patch, keywords are not used in fast calls. But they will be used later. I prefer to start directly with keywords than changing the calling convention once again later.

--

Later, I will propose other patches to:

* add METH_FASTCALL calling convention for C functions
* modify Argument Clinic to use METH_FASTCALL

So the fast call will be taken in more cases.

--

The long term plan is to slowly use the new FASTCALL calling convention "everywhere". The tricky point are tp_new, tp_init and tp_call attributes of type objects. In the issue #26814, I wrote a patch adding Py_TPFLAGS_FASTNEW, Py_TPFLAGS_FASTINIT and Py_TPFLAGS_FASTCALL flags to use the FASTCALL calling convention for tp_new, tp_init and tp_call. The problem is that calling directly these methods looks common. If we can the calling convention of these methods, it will break the C API, I propose to discuss that later ;-)

An alternative is to add a tp_fastcall method to PyTypeObject and use a wrapper for tp_call for backward compatibility. This option has also drawbacks. Again, I propose to discuss this later, and first start to focus on the changes that don't break anything ;-)

----------
files: fastcall.patch
keywords: patch
messages: 266422
nosy: haypo, serhiy.storchaka, yselivanov
priority: normal
severity: normal
status: open
title: Add _PyObject_FastCall()
type: performance
versions: Python 3.6
Added file: http://bugs.python.org/file43011/fastcall.patch

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

From report at bugs.python.org  Thu May 26 09:13:07 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 May 2016 13:13:07 +0000
Subject: [New-bugs-announce] [issue27129] Wordcode, part 2
Message-ID: <1464268387.83.0.862540030058.issue27129@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

This is the second stage of converting to wordcode (issue26647).

Proposed patch makes bytecodecode consisting of code units (16-bit words) instead of bytes. It includes following changes:

* Changes meaning of jump offsets. They counts not bytes, but code units. This extends the range addressed by short commands (from 256 bytes to 256 words) and simplifies ceval.c.

* Changes f_lasti, tb_lasti etc to count code units instead of bytes.

* Changes disassembler to show addresses in code units, not bytes.

* Refactores the code.

These changes break compatibility (already broken by switching to 16-bit bytecode). The first one breaks compatibility with compiled bytecode and needs incrementing the magic number.

----------
components: Interpreter Core
files: wordcode2.patch
keywords: patch
messages: 266431
nosy: haypo, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Wordcode, part 2
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file43015/wordcode2.patch

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

From report at bugs.python.org  Thu May 26 09:40:42 2016
From: report at bugs.python.org (Klamann)
Date: Thu, 26 May 2016 13:40:42 +0000
Subject: [New-bugs-announce] [issue27130] zlib: OverflowError while trying
 to compress 2^32 bytes or more
Message-ID: <1464270042.87.0.0233765451432.issue27130@psf.upfronthosting.co.za>


New submission from Klamann:

zlib fails to compress files larger than 4gb due to some 32bit issues.

I've tested this in Python 3.4.3 and 3.5.1:

> python3 -c "import zlib; zlib.compress(b'a' * (2**32 - 1))"
> python3 -c "import zlib; zlib.compress(b'a' * (2**32))"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
OverflowError: Size does not fit in an unsigned int

For Python 2.7, the issue starts at 2^31 byte (due to signed 32bit integers):

> python2 -c "import zlib; zlib.compress(b'a' * (2**31 - 1))"
> python2 -c "import zlib; zlib.compress(b'a' * (2**31))"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
OverflowError: size does not fit in an int

Decompressing files larger than 4GB works just fine.

----------
components: Library (Lib)
messages: 266436
nosy: Klamann
priority: normal
severity: normal
status: open
title: zlib: OverflowError while trying to compress 2^32 bytes or more
versions: Python 2.7, Python 3.4, Python 3.5

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

From report at bugs.python.org  Thu May 26 11:28:08 2016
From: report at bugs.python.org (jonathan.kross)
Date: Thu, 26 May 2016 15:28:08 +0000
Subject: [New-bugs-announce] [issue27131] Unit test random shuffle
Message-ID: <1464276488.09.0.745578152563.issue27131@psf.upfronthosting.co.za>


Changes by jonathan.kross <kross.jonathan at gmail.com>:


----------
components: Tests
files: test_random_shuffle.patch
keywords: patch
nosy: jonathan.kross
priority: normal
severity: normal
status: open
title: Unit test random shuffle
versions: Python 3.6
Added file: http://bugs.python.org/file43017/test_random_shuffle.patch

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

From report at bugs.python.org  Thu May 26 16:48:13 2016
From: report at bugs.python.org (Maciej Szulik)
Date: Thu, 26 May 2016 20:48:13 +0000
Subject: [New-bugs-announce] [issue27132] New assert method that checks an
 error message for a list of strings
Message-ID: <1464295693.41.0.439639952512.issue27132@psf.upfronthosting.co.za>


New submission from Maciej Szulik:

To quote David from http://bugs.python.org/review/25591/diff/16398/Lib/test/test_imaplib.py:

"I've been thinking I'd like a new assert method that checks an error message for a list of strings in any order, but I haven't opened an issue for it :)"

----------
components: Tests
messages: 266454
nosy: maciej.szulik, r.david.murray
priority: normal
severity: normal
status: open
title: New assert method that checks an error message for a list of strings
type: enhancement

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

From report at bugs.python.org  Thu May 26 17:47:31 2016
From: report at bugs.python.org (Dennis Clarke)
Date: Thu, 26 May 2016 21:47:31 +0000
Subject: [New-bugs-announce] [issue27133] python 3.5.1 will not compile
 because libffi module uses wrong CFLAGS
Message-ID: <1464299251.55.0.694249257494.issue27133@psf.upfronthosting.co.za>


New submission from Dennis Clarke:

While compiling from sources I see in the process :

.
.
.
creating build/temp.solaris-2.10-sun4v.64bit-3.5/libffi
checking build system type... sparc-sun-solaris2.10
checking host system type... sparc-sun-solaris2.10
checking target system type... sparc-sun-solaris2.10
checking for gsed... /usr/local/bin/gsed
checking for a BSD-compatible install... /usr/local/build/python-3.5.1_SunOS5.10_sparcv9.002/Modules/_ctypes/libffi/install-sh -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/local/build/python-3.5.1_SunOS5.10_sparcv9.002/Modules/_ctypes/libffi/install-sh -c -d
checking for gawk... /usr/local/bin/gawk
checking whether /usr/local/bin/gmake sets $(MAKE)... yes
checking whether /usr/local/bin/gmake supports nested variables... yes
checking for gcc... /opt/solarisstudio12.4/bin/cc
checking whether the C compiler works... no
configure: error: in `/usr/local/build/python-3.5.1_SunOS5.10_sparcv9.002/build/temp.solaris-2.10-sun4v.64bit-3.5/libffi':
configure: error: C compiler cannot create executables
See `config.log' for more details


The reason for this error is that the build process down in the libffi directory seems to spawn its own "configure" stage wherein the CFLAGS are lost, forgotten or simply not used and therefore a trivial compile fails because of :

configure:3873: /opt/solarisstudio12.4/bin/cc  -I/usr/local/include -I/usr/local/ssl/include -D_TS_ERRNO -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE  conftest.c  >&5
ld: fatal: file /opt/solarisstudio12.4/lib/compilers/crti.o: wrong ELF class: ELFCLASS32
ld: fatal: file processing errors. No output written to a.out
configure:3877: $? = 2
configure:3915: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "libffi"
| #define PACKAGE_TARNAME "libffi"
| #define PACKAGE_VERSION "3.1"
| #define PACKAGE_STRING "libffi 3.1"
| #define PACKAGE_BUGREPORT "http://github.com/atgreen/libffi/issues"
| #define PACKAGE_URL ""
| #define PACKAGE "libffi"
| #define VERSION "3.1"
| /* end confdefs.h.  */
|
| int
| main ()
| {
|
|   ;
|   return 0;
| }
configure:3920: error: in `/usr/local/build/python-3.5.1_SunOS5.10_sparcv9.002/build/temp.solaris-2.10-sun4v.64bit-3.5/libffi':
configure:3922: error: C compiler cannot create executables
See `config.log' for more details


The configure process MUST use the CFLAGS that were passed to the original configure stage and reside in the Makefile.  The absence of the flag -m64 causes a 32-bit compile here and thus the compile fails.

----------
components: Build
messages: 266458
nosy: blastwave
priority: normal
severity: normal
status: open
title: python 3.5.1 will not compile because libffi module uses wrong CFLAGS
type: compile error
versions: Python 3.5

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

From report at bugs.python.org  Thu May 26 22:35:15 2016
From: report at bugs.python.org (Daniel Holth)
Date: Fri, 27 May 2016 02:35:15 +0000
Subject: [New-bugs-announce] [issue27134] allow str(bytes) raises an
 exception to be controlled programmatically
Message-ID: <1464316515.99.0.657478307138.issue27134@psf.upfronthosting.co.za>


New submission from Daniel Holth:

When I discovered str(b'bytes') in my Python 3 program was causing errors to be serialized to disk, I was unhappy. It turns out there is a command line option to turn it off, but the vulnerable serialization code is not going to be able to set that argument; or the one-argument-per-shebang limit we have in Linux was already used for something else.

Instead, provide a threadlocal variable that causes str(bytes) to raise. A context manager makes it simple to use for just a portion of your code:

with string.StrBytesRaises():
   no_str_bytes_here()

If not set or False then Python behaves as before.

----------
components: Unicode
files: strbytes.patch
keywords: patch
messages: 266465
nosy: dholth, ezio.melotti, haypo
priority: normal
severity: normal
status: open
title: allow str(bytes) raises an exception to be controlled programmatically
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file43024/strbytes.patch

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

From report at bugs.python.org  Fri May 27 01:25:00 2016
From: report at bugs.python.org (Matthew Tanous)
Date: Fri, 27 May 2016 05:25:00 +0000
Subject: [New-bugs-announce] [issue27135] nested list produced with
 multiplication is linked to the same list
Message-ID: <1464326700.96.0.464435009997.issue27135@psf.upfronthosting.co.za>


New submission from Matthew Tanous:

If I produce a list in this fashion:

l = [[x] * n] * n

I would expect that I would obtain a matrix-like structure.  Instead, I get a list of the *same* list, such that the statement:

l[x][y] = z

would change, in essence, every value in "column" y.  This is different from the case where the list contains a string or integer value, where the new list points to separate instances of the internal values.

In my view, this is strange and counter-intuitive behavior.  If I want to create a matrix-like set to None to start, instead of using:

 mat = [[None] * N] * N

I have to use:

 mat = [[None] * N for i in range(N)]

If there is any possibility for it to be changed, I think that would improve things considerably.  In almost no cases, in my opinion, would I want a list of lists that are forced to be the same.

----------
components: Interpreter Core
messages: 266475
nosy: Matthew Tanous
priority: normal
severity: normal
status: open
title: nested list produced with multiplication is linked to the same list
versions: Python 2.7, Python 3.5

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

From report at bugs.python.org  Fri May 27 07:02:18 2016
From: report at bugs.python.org (pyptr2)
Date: Fri, 27 May 2016 11:02:18 +0000
Subject: [New-bugs-announce] [issue27136] sock_connect fails for bluetooth
 (and probably others)
Message-ID: <1464346938.98.0.196127839357.issue27136@psf.upfronthosting.co.za>


New submission from pyptr2:

Base{Selector,Proactor}EventLoop each have a sock_connect() method, both of which unconditionally "try" to run base_events' _check_resolved_address() which is apparently meant to raise an exception when called with an unresolved IP hostname. (because on some OSes it cannot be done asynchronously? WTF?)

Anyhow, the current implementation prevents ANY address family other than IP (and UNIX, which is special cased) to raise the exception, no matter if it's resolved or not.

So please, call _ipaddr_info() for IP only.

----------
components: asyncio
files: check_resolved.patch
keywords: patch
messages: 266486
nosy: gvanrossum, haypo, pyptr2, yselivanov
priority: normal
severity: normal
status: open
title: sock_connect fails for bluetooth (and probably others)
type: behavior
versions: Python 3.6
Added file: http://bugs.python.org/file43027/check_resolved.patch

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

From report at bugs.python.org  Fri May 27 12:39:18 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Fri, 27 May 2016 16:39:18 +0000
Subject: [New-bugs-announce] [issue27137] functools.partial: Inconsistency
 between Python and C implementations
Message-ID: <1464367158.87.0.208604382314.issue27137@psf.upfronthosting.co.za>


New submission from Emanuel Barry:

functools.partial is a class in C, but the Python implementation is a function. This doesn't matter for most use cases where you only want the end result of the call to partial.

A simple line in the REPL tells me enough (or so I thought) that I wouldn't need to check the implementation:

>>> functools.partial
<class 'functools.partial'>

Oh, it's a class, which means I can subclass it to add a custom repr for my needs.

Unsurprisingly, it works. It may not be the best idea to subclass something that is meant to be final, but I'm simply overriding a single method, what could possibly go wrong? Besides one of the implementations not actually being a class.

I'm suggesting to make the Python implementation also a class, for consistency and making sure that both the C and Python implementation match, in case someone else wants to do that too.

The documentation ( https://docs.python.org/3/library/functools.html#functools.partial ) doesn't state that the Python and C implementations differ, but IMO this isn't a documentation bug.

I haven't written a patch yet, will probably be done by tomorrow.

Note: I haven't actually encountered this issue, but I suspect that it might arise if someone doesn't have access to _functools for whatever reason. And IMO, Python and C implementations of a feature should be fully equivalent (modulo implementation details ? la OrderedDict.__root).

Thoughts?

----------
components: Library (Lib)
messages: 266503
nosy: ebarry, ncoghlan, rhettinger
priority: normal
severity: normal
stage: needs patch
status: open
title: functools.partial: Inconsistency between Python and C implementations
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Fri May 27 14:26:16 2016
From: report at bugs.python.org (Eric Snow)
Date: Fri, 27 May 2016 18:26:16 +0000
Subject: [New-bugs-announce] [issue27138] FileFinder.find_spec() docstring
 needs to be corrected.
Message-ID: <1464373576.22.0.0993428685624.issue27138@psf.upfronthosting.co.za>


New submission from Eric Snow:

Looks like we weren't careful when we added find_spec(). :)  This issue is just to track the change.  I'll push the fix shortly.

----------
assignee: eric.snow
messages: 266506
nosy: brett.cannon, eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: FileFinder.find_spec() docstring needs to be corrected.
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri May 27 15:26:04 2016
From: report at bugs.python.org (Julio C Cardoza)
Date: Fri, 27 May 2016 19:26:04 +0000
Subject: [New-bugs-announce] [issue27139] Increased test coverage for
 statistics.median_grouped
Message-ID: <1464377164.35.0.0212620857627.issue27139@psf.upfronthosting.co.za>


Changes by Julio C Cardoza <21ago77ju at gmail.com>:


----------
components: Tests
files: test_median_grouped.patch
keywords: patch
nosy: juliojr77
priority: normal
severity: normal
status: open
title: Increased test coverage for statistics.median_grouped
versions: Python 3.6
Added file: http://bugs.python.org/file43031/test_median_grouped.patch

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

From report at bugs.python.org  Fri May 27 16:40:40 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 May 2016 20:40:40 +0000
Subject: [New-bugs-announce] [issue27140] Opcode for creating dict with
 constant keys
Message-ID: <1464381640.82.0.0689379791356.issue27140@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

BUILD_MAP, BUILD_MAP_UNPACK and BUILD_MAP_UNPACK_WITH_CALL need pushing key-value pairs on the stack. If keys and values are not constant, this is correct order of evaluating them. But if keys are constant (very common case), the order of pushing them doesn't affect semantic. We can pack them in constant tuple and push on the stack by one instruction.

I think there would be a benefit from adding new opcodes that take a sequence of values and a tuple of keys instead of a sequence of key-value pairs.

New MAKE_FUNCTION (issue27095) and new CALL_FUNCTION (issue yet not opened) could have a benefit.

----------
components: Interpreter Core
messages: 266511
nosy: Demur Rumed, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Opcode for creating dict with constant keys
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Fri May 27 17:29:02 2016
From: report at bugs.python.org (Bar Harel)
Date: Fri, 27 May 2016 21:29:02 +0000
Subject: [New-bugs-announce] [issue27141] Fix collections.UserList shallow
 copy
Message-ID: <1464384542.41.0.303372176211.issue27141@psf.upfronthosting.co.za>


New submission from Bar Harel:

I have encountered a weird behavior in collections.UserList.
Using copy.copy() on an instance results in a new instance of UserList but with the same underlying list. Seems like self.copy() works great but __copy__ was not overridden to allow copy.copy to work too.
The patch just assigns __copy__ to self.copy triggering the correct behavior.

----------
components: Library (Lib)
files: UserList.patch
keywords: patch
messages: 266515
nosy: bar.harel
priority: normal
severity: normal
status: open
title: Fix collections.UserList shallow copy
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file43032/UserList.patch

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

From report at bugs.python.org  Fri May 27 18:17:42 2016
From: report at bugs.python.org (Julien)
Date: Fri, 27 May 2016 22:17:42 +0000
Subject: [New-bugs-announce] [issue27142] Default int value with xmlrpclib /
 xmlrpc.client
Message-ID: <1464387462.23.0.765030008479.issue27142@psf.upfronthosting.co.za>


New submission from Julien:

I tried to execute the following code, but `xmlrpclib` is raising an exception:

    >>> import xmlrpclib
    >>> data = """<?xml version="1.0"?> 
    ... <methodCall>
    ...     <methodName>test_method</methodName>
    ...     <params>
    ...         <param>
    ...             <value>
    ...                 <int/>
    ...             </value>
    ...         </param>
    ...     </params>
    ... </methodCall>"""
    >>> xmlrpclib.loads(data)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "/usr/lib64/python2.7/xmlrpclib.py", line 1141, in loads
        p.feed(data)
      File "/usr/lib64/python2.7/xmlrpclib.py", line 558, in feed
        self._parser.Parse(data, 0)
      File "/usr/lib64/python2.7/xmlrpclib.py", line 829, in end
        return f(self, join(self._data, ""))
      File "/usr/lib64/python2.7/xmlrpclib.py", line 864, in end_int
        self.append(int(data))
    ValueError: invalid literal for int() with base 10: ''

The behaviour is the same with `<int></int>`, and in python 3.4 with xmlrpc.client .
However, I tried to parse the same data with PHP, and it works without any trouble.

    php > $data = '<?xml version="1.0"?><methodCall><methodName>test_method</methodName><params><param><value><int/></value></param></params></methodCall>';
    php > print_r(xmlrpc_decode($data));
    Array
    (
        [0] => 0
    )

The .NET documentation of XML-RPC also suggests that `<int/>` is interpreted as 0 (although I couldn't try it myself):
> If an XML-RPC struct member is missing its corresponding .NET struct member will be set to null instead of the default value for the type if a non-nullable type had been used, for example null instead of zero for an integer.

Is it a feature in .NET and PHP implementations of XML-RPC, or a bug in the python implementation? I didn't find any documentation about the XML-RPC protocol itself on this topic.

----------
components: Library (Lib), XML
messages: 266517
nosy: julienc
priority: normal
severity: normal
status: open
title: Default int value with xmlrpclib / xmlrpc.client
type: behavior
versions: Python 2.7, Python 3.4

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

From report at bugs.python.org  Fri May 27 20:26:15 2016
From: report at bugs.python.org (=?utf-8?q?Rub=C3=A9n_Rivero_Capriles?=)
Date: Sat, 28 May 2016 00:26:15 +0000
Subject: [New-bugs-announce] [issue27143] python 3.5 conflict with Mailman,
 ebtables and firewalld
Message-ID: <1464395175.01.0.190089225196.issue27143@psf.upfronthosting.co.za>


New submission from Rub?n Rivero Capriles:

My current python version is 3.5 which I installed yesterday. How can I get rid of 2,7. Python 3.5 should be the one running.

While: Installing mailman.
An internal error occurred due to a bug in either zc.buildout or in a
recipe being used:
Traceback (most recent call last):
  File "/root/Python-3.5.0/venv/lib/python2.7/site-packages/zc/buildout/buildout.py", line 1992, in main
    getattr(buildout, command)(args)
  File "/root/Python-3.5.0/venv/lib/python2.7/site-packages/zc/buildout/buildout.py", line 666, in install
    installed_files = self[part]._call(recipe.install)
  File "/root/Python-3.5.0/venv/lib/python2.7/site-packages/zc/buildout/buildout.py", line 1407, in _call
    return f()
  File "/root/mailman-bundler/eggs/collective.recipe.cmd-0.11-py2.7.egg/collective/recipe/cmd/__init__.py", line 56, in install
    self.execute()
  File "/root/mailman-bundler/eggs/collective.recipe.cmd-0.11-py2.7.egg/collective/recipe/cmd/__init__.py", line 69, in execute
    run_commands(cmds, self.shell)
  File "/root/mailman-bundler/eggs/collective.recipe.cmd-0.11-py2.7.egg/collective/recipe/cmd/__init__.py", line 39, in run_commands
    check_call('%s %s' % (shell, tmpfile), shell=True)
  File "/usr/lib64/python2.7/subprocess.py", line 542, in check_call
    raise CalledProcessError(retcode, cmd)
CalledProcessError: Command 'sh /tmp/tmpnI0SlP/run' returned non-zero exit status 127
(venv)[root at mlp mailman-bundler]# groupadd mailman
groupadd: group 'mailman' already exists

I had many firewalld conflicts today with the pythos 3.5 I installed yesterday. Iptables didn't work either. So I uninstalled both of them and downloaded from source firewalld-0.4.1.2.tar.bz2 but can't install it either due to a bug in gobject.stp.in', needed by 'gobject.stp

sudo firewall-cmd --permanent --add-service=ssh
Error: Traceback (most recent call last):
File "/usr/lib64/python2.7/site-packages/dbus/service.py", line 707, in message_cb
retval = candidate_method(self, args, *keywords)
File "/usr/lib/python2.7/site-packages/slip/dbus/service.py", line 148, in wrapped_method
reply_handler=reply_handler, error_handler=error_handler)
File "/usr/lib/python2.7/site-packages/slip/dbus/polkit.py", line 270, in IsSystemBusNameAu thorizedAsync
reply_handler, error_handler, challenge, details)
File "/usr/lib/python2.7/site-packages/slip/dbus/polkit.py", line 256, in IsSystemBusNameAu thorizedAsync
timeout=method_call_no_timeout)
File "/usr/lib64/python2.7/site-packages/dbus/proxies.py", line 137, in __call_
**keywords)
File "/usr/lib64/python2.7/site-packages/dbus/connection.py", line 584, in call_async
message.append(signature=signature, *args)
ValueError: Unable to guess signature from an empty dict

[root at mlp config]# sudo firewall-cmd --permanent --add-service=http
Error: Traceback (most recent call last):
File "/usr/lib64/python2.7/site-packages/dbus/service.py", line 707, in message_cb
retval = candidate_method(self, args, *keywords)
File "/usr/lib/python2.7/site-packages/slip/dbus/service.py", line 148, in wrapped_method
reply_handler=reply_handler, error_handler=error_handler)
File "/usr/lib/python2.7/site-packages/slip/dbus/polkit.py", line 270, in IsSystemBusNameAu thorizedAsync
reply_handler, error_handler, challenge, details)
File "/usr/lib/python2.7/site-packages/slip/dbus/polkit.py", line 256, in IsSystemBusNameAu thorizedAsync
timeout=method_call_no_timeout)
File "/usr/lib64/python2.7/site-packages/dbus/proxies.py", line 137, in __call_
**keywords)
File "/usr/lib64/python2.7/site-packages/dbus/connection.py", line 584, in call_async
message.append(signature=signature, *args)
ValueError: Unable to guess signature from an empty dict

[root at mlp config]# sudo firewall-cmd --permanent --add-service=https
Error: Traceback (most recent call last):
File "/usr/lib64/python2.7/site-packages/dbus/service.py", line 707, in message_cb
retval = candidate_method(self, args, *keywords)
File "/usr/lib/python2.7/site-packages/slip/dbus/service.py", line 148, in wrapped_method
reply_handler=reply_handler, error_handler=error_handler)
File "/usr/lib/python2.7/site-packages/slip/dbus/polkit.py", line 270, in IsSystemBusNameAu thorizedAsync
reply_handler, error_handler, challenge, details)
File "/usr/lib/python2.7/site-packages/slip/dbus/polkit.py", line 256, in IsSystemBusNameAu thorizedAsync
timeout=method_call_no_timeout)
File "/usr/lib64/python2.7/site-packages/dbus/proxies.py", line 137, in __call_
**keywords)
File "/usr/lib64/python2.7/site-packages/dbus/connection.py", line 584, in call_async
message.append(signature=signature, *args)
ValueError: Unable to guess signature from an empty dict

[root at mlp config]# sudo firewall-cmd --permanent --add-service=smtp
Error: Traceback (most recent call last):
File "/usr/lib64/python2.7/site-packages/dbus/service.py", line 707, in message_cb
retval = candidate_method(self, args, *keywords)
File "/usr/lib/python2.7/site-packages/slip/dbus/service.py", line 148, in wrapped_method
reply_handler=reply_handler, error_handler=error_handler)
File "/usr/lib/python2.7/site-packages/slip/dbus/polkit.py", line 270, in IsSystemBusNameAu thorizedAsync
reply_handler, error_handler, challenge, details)
File "/usr/lib/python2.7/site-packages/slip/dbus/polkit.py", line 256, in IsSystemBusNameAu thorizedAsync
timeout=method_call_no_timeout)
File "/usr/lib64/python2.7/site-packages/dbus/proxies.py", line 137, in __call_
**keywords)
File "/usr/lib64/python2.7/site-packages/dbus/connection.py", line 584, in call_async
message.append(signature=signature, *args)
ValueError: Unable to guess signature from an empty dict

[root at mlp config]# firewall-cmd --add-service=dns
Error: Traceback (most recent call last):
File "/usr/lib64/python2.7/site-packages/dbus/service.py ", line 707, in message_cb
retval = candidate_method(self, args, *keywords)
File "/usr/lib/python2.7/site-packages/slip/dbus/service .py", line 148, in wrapped_method
reply_handler=reply_handler, error_handler=error_handl er)
File "/usr/lib/python2.7/site-packages/slip/dbus/polkit. py", line 270, in IsSystemBusNameAuthorizedAsync
reply_handler, error_handler, challenge, details)
File "/usr/lib/python2.7/site-packages/slip/dbus/polkit. py", line 256, in IsSystemBusNameAuthorizedAsync
timeout=method_call_no_timeout)
File "/usr/lib64/python2.7/site-packages/dbus/proxies.py ", line 137, in __call_
**keywords)
File "/usr/lib64/python2.7/site-packages/dbus/connection .py", line 584, in call_async
message.append(signature=signature, *args)
ValueError: Unable to guess signature from an empty dict

[root at mlp config]# sudo firewall-cmd --get-services
Error: Traceback (most recent call last):
File "/usr/lib64/python2.7/site-packages/dbus/service.py", line 707, in message_cb
retval = candidate_method(self, args, *keywords)
File "/usr/lib/python2.7/site-packages/slip/dbus/service.py", line 148, in wrapped_method
reply_handler=reply_handler, error_handler=error_handler)
File "/usr/lib/python2.7/site-packages/slip/dbus/polkit.py", line 270, in IsSystemBusNameAu thorizedAsync
reply_handler, error_handler, challenge, details)
File "/usr/lib/python2.7/site-packages/slip/dbus/polkit.py", line 256, in IsSystemBusNameAu thorizedAsync
timeout=method_call_no_timeout)
File "/usr/lib64/python2.7/site-packages/dbus/proxies.py", line 137, in __call_
**keywords)
File "/usr/lib64/python2.7/site-packages/dbus/connection.py", line 584, in call_async
message.append(signature=signature, *args)
ValueError: Unable to guess signature from an empty dict

[root at mlp config]# sudo firewall-cmd --permanent --list-all
Error: Traceback (most recent call last):
File "/usr/lib64/python2.7/site-packages/dbus/service.py", line 707, in message_cb
retval = candidate_method(self, args, *keywords)
File "/usr/lib/python2.7/site-packages/slip/dbus/service.py", line 148, in wrapped_method
reply_handler=reply_handler, error_handler=error_handler)
File "/usr/lib/python2.7/site-packages/slip/dbus/polkit.py", line 270, in IsSystemBusNameAu thorizedAsync
reply_handler, error_handler, challenge, details)
File "/usr/lib/python2.7/site-packages/slip/dbus/polkit.py", line 256, in IsSystemBusNameAu thorizedAsync
timeout=method_call_no_timeout)
File "/usr/lib64/python2.7/site-packages/dbus/proxies.py", line 137, in __call_
**keywords)
File "/usr/lib64/python2.7/site-packages/dbus/connection.py", line 584, in call_async
message.append(signature=signature, *args)
ValueError: Unable to guess signature from an empty dict

[root at mlp config]# sudo firewall-cmd --reload
Error: Traceback (most recent call last):
File "/usr/lib64/python2.7/site-packages/dbus/service.py", line 707, in message_cb
retval = candidate_method(self, args, *keywords)
File "/usr/lib/python2.7/site-packages/slip/dbus/service.py", line 148, in wrapped_method
reply_handler=reply_handler, error_handler=error_handler)
File "/usr/lib/python2.7/site-packages/slip/dbus/polkit.py", line 270, in IsSystemBusNameAu thorizedAsync
reply_handler, error_handler, challenge, details)
File "/usr/lib/python2.7/site-packages/slip/dbus/polkit.py", line 256, in IsSystemBusNameAu thorizedAsync
timeout=method_call_no_timeout)
File "/usr/lib64/python2.7/site-packages/dbus/proxies.py", line 137, in __call_
**keywords)
File "/usr/lib64/python2.7/site-packages/dbus/connection.py", line 584, in call_async
message.append(signature=signature, *args)
ValueError: Unable to guess signature from an empty dict

systemctl status firewalld.service

firewalld.service - firewalld - dynamic firewall daemon Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled) Active: failed (Result: timeout) since Fri 2016-05-27 17:09:14 BOT; 11s ago Process: 2202 ExecStart=/usr/sbin/firewalld --nofork --nopid $FIREWALLD_ARGS (code=exited, status=0/SUCCESS) Main PID: 2202 (code=exited, status=0/SUCCESS)
May 27 17:07:44 mlp systemd[1]: Starting firewalld - dynamic firewall daemon...
May 27 17:07:44 mlp firewalld[2202]: 2016-05-27 17:07:44 ERROR: ebtables not usable, disabling ethernet bridge firewall.
May 27 17:09:14 mlp systemd[1]: firewalld.service start operation timed out. Terminating.
May 27 17:09:14 mlp systemd[1]: Failed to start firewalld - dynamic firewall daemon.
May 27 17:09:14 mlp systemd[1]: Unit firewalld.service entered failed state.
May 27 17:09:14 mlp systemd[1]: firewalld.service failed.

ps -efc
root 915 898 TS 19 16:40 pts/0 00:00:00 /usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid --debug 10
root 1882 898 TS 19 16:51 pts/0 00:00:00 /usr/bin/python -Es /usr/bin/firewall-cmd --permanent --add-service=ssh

It seems there are bugs everywhere and I can't install anything

----------
components: Installation
messages: 266522
nosy: Rub?n Rivero Capriles
priority: normal
severity: normal
status: open
title: python 3.5 conflict with Mailman, ebtables and firewalld
type: crash
versions: Python 3.5

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

From report at bugs.python.org  Sat May 28 09:25:35 2016
From: report at bugs.python.org (Grzegorz Grzywacz)
Date: Sat, 28 May 2016 13:25:35 +0000
Subject: [New-bugs-announce] [issue27144] concurrent.futures.as_completed()
 memory inefficiency
Message-ID: <1464441935.81.0.0559700033116.issue27144@psf.upfronthosting.co.za>


New submission from Grzegorz Grzywacz:

as_complite generator keeps reference of all passed futures until StopIteration. It may lead to serious memory inefficiency.

Solution is to remove reference from lists and yield future ad-hoc.

I have submitted patch and reproduce sample.

I can create backport for older versions if needed.

----------
components: Library (Lib)
files: reproduce.py
messages: 266552
nosy: bquinlan, grzgrzgrz3
priority: normal
severity: normal
status: open
title: concurrent.futures.as_completed() memory inefficiency
type: resource usage
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file43037/reproduce.py

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

From report at bugs.python.org  Sat May 28 11:58:37 2016
From: report at bugs.python.org (Oren Milman)
Date: Sat, 28 May 2016 15:58:37 +0000
Subject: [New-bugs-announce] [issue27145] long_add and long_sub might return
 a new int where &small_ints[x] could be returned
Message-ID: <1464451117.45.0.85462287723.issue27145@psf.upfronthosting.co.za>


New submission from Oren Milman:

------------ the current state ------------
>>> if is32BitCPython:
...   PyLong_SHIFT = 15
... elif is64BitCPython:
...   PyLong_SHIFT = 30
...
>>> ##### case A #####
>>> a = 2 ** PyLong_SHIFT - 1
>>> b = 2 ** PyLong_SHIFT - 2
>>> a - b
1
>>> a - b is 1
True
>>> a + (-b) is 1
True
>>>
>>> ##### case B #####
>>> a = 2 ** PyLong_SHIFT
>>> b = 2 ** PyLong_SHIFT - 1
>>> a - b
1
>>> a - b is 1
False
>>> a + (-b) is 1
False
>>>
>>> ##### case C #####
>>> a = 2 ** PyLong_SHIFT + 1
>>> b = 2 ** PyLong_SHIFT
>>> a - b
1
>>> a - b is 1
False
>>> a + (-b) is 1
False
>>>

This behavior is caused by the implementation of long_add and long_sub:
    Both long_add and long_sub check whether both a and b are single-digit ints, and then do (respectively):
        return PyLong_FromLong(MEDIUM_VALUE(a) + MEDIUM_VALUE(b));
        or
        return PyLong_FromLong(MEDIUM_VALUE(a) - MEDIUM_VALUE(b));
    Otherwise, long_add and long_sub call x_add or x_sub to do a calculation on the absolute values of a and b.
    At last, long_add and long_sub negate the result of the calculation, if needed, and return the final result. 

Where both a and b are single-digit ints (e.g. case A), the result of the calculation is passed to PyLong_FromLong, which uses CHECK_SMALL_INT, and so a reference to an element of small_ints is returned where appropriate.
Where a and/or b are not single-digit ints (e.g. cases B and C), x_add or x_sub is called. Both x_add and x_sub don't check whether the result is a small int (except for a case in x_sub where the result is zero), and so long_add and long_sub might return a new int, even where an element of small_ints could be reused.

Due to the way CPython uses them, the issue is relevant to x_sub and not to x_add, as the calculation the former performs might result in a small int, while that of the latter would always result in a multiple-digit int.
(Except for being called by long_add and long_sub, x_add might be called by k_mul, but in that case also the calculation would certainly result in a multiple-digit int.)


------------ Note ------------
I am not sure whether this is actually an issue that we want to fix.
It seems to me that my proposed changes introduce a slight performance gain (in terms of memory, and probably also speed), and a more consistent behavior of CPython.
The performance gain would probably be much more relevant if and when greater default values are chosen for NSMALLNEGINTS and NSMALLPOSINTS.

Anyway, I guess documenting the issue here, along with a proposal for a fix, is better than nothing.
(As far as I know, since the unification of int and long in revision 40626, this issue never came up.)


------------ the proposed changes ------------
All of the proposed changes are in Objects/longobject.c:
1. in x_sub:
    To make sure x_sub returns a small int where appropriate, I simply wrapped the return value of x_sub with the function maybe_small_long.

2. in long_sub:
    The previous patch alone would create a nasty bug.
    In case both a and b are negative, long_sub calls x_sub, and then negates the result in-place by doing 'Py_SIZE(z) = -(Py_SIZE(z));'.
    If x_sub returned a reference to a statically allocated small int (which is not zero), long_sub would actually change that statically allocated small int.

    To prevent that, I replaced that in-place negating with a call to _PyLong_Negate.

3. in _PyLong_Negate:
    The previous patches, along with http://bugs.python.org/issue27073 (another issue I have opened recently), would cause long_sub to call _PyLong_Negate for a zero int, in case a and b are the same multiple-digit negative int. 
    Moreover, in the default CPython branch, in case long_mul receives a multiple-digit negative int and zero, long_mul would call _PyLong_Negate for a zero int.

    To prevent doing 'PyLong_FromLong(-MEDIUM_VALUE(x))' where x is a zero int, I have added a check before that (along with a little addition to the function comment), so that _PyLong_Negate would do nothing if x is a zero int. 
    It should be noted that MEDIUM_VALUE also checks whether x is a zero int (for its own reasons), so thanks to the wisdom of nowadays compilers, the check I propose to add shouldn't introduce a performance penalty.
    (Actually, when comparing the assembly of _PyLong_Negate (for win32) of the default CPython branch and the patched one, the latter looks simpler.)

    With regard to similar changes made in the past, _PyLong_Negate wasn't changed since it replaced the macro NEGATE in revision 84698.

4. in x_sub:
    The previous patches made it safe for x_sub to return a reference to a statically allocated small int, and thus made it possible to implement the following optimization.
    In case a and b have the same number of digits, x_sub finds the most significant digit where a and b differ. Then, if there is no such digit, it means a and b are equal, and so x_sub does 'return (PyLongObject *)PyLong_FromLong(0);'.
    I propose to add another check after that, to determine whether the least significant digit is the only digit where a and b differ. In that case, we can do something very similar to what long_add and long_sub do when they realize they are dealing with single-digit ints (as mentioned in 'the current state' section): 
        return (PyLongObject *)PyLong_FromLong((sdigit)a->ob_digit[0] - 
                                               (sdigit)b->ob_digit[0]);


------------ alternative changes ------------
As an alternative to these 4 changes, I also thought of simply wrapping the return value of long_add and long_sub with the function maybe_small_long (i.e. change the last line of each of them to 'return (PyObject *)maybe_small_long(z);').

This change might be more simple, but I believe it would introduce a performance penalty, as it adds checks also to flows of long_add and long_sub that would never result in a small int.
Furthermore, this change won't save any allocations of small ints. For example, in case C (that was mentioned in 'the current state' section), both in (a - b) and in (a + (-b)):
    1. A new int of value 1 would be allocated by x_sub.
    2. In the end of long_add or long_sub, maybe_small_long would realize an element of small_ints could be used.
    3. maybe_small_long would use Py_DECREF on the new int of value 1, which would cause the deallocation of it.

In contrast, in case C, the 4th change (in the proposed changes section) would cause x_sub to realize in advance that the result is going to be a single-digit. Consequently, no new int would be futilely allocated in the process.

However, in case B (that was mentioned in 'the current state' section), both the alternative changes and the proposed changes (and also the default CPython branch), won't prevent x_sub from allocating a new int.
    

------------ micro-benchmarking ------------
    I did some micro-benchmarking:
    - subtraction of multiple-digit ints with the same number of digits, while the result fits in the small_ints array:
        python -m timeit "[i - (i + 1) for i in range(2 ** 67, 2 ** 67 + 1000)]" -> The patched CPython is approximately 8% faster.
    - subtraction of multiple-digit ints with the same number of digits, which differ only in the least significant digit (while the result doesn't fit in the small_ints array):
        python -m timeit "[i - (i + 6) for i in range(2 ** 67, 2 ** 67 + 1000)]" -> The patched CPython is approximately 3% faster.
    - subtraction of multiple-digit ints with the same number of digits, which differ (among others) in the most significant digit:
        python -m timeit "[i * 2 - i for i in range(2 ** 67, 2 ** 67 + 1000)]" -> The patched CPython is approximately 1% slower.
    - subtraction of multiple-digit ints with different number of digits:
        python -m timeit "[i ** 2 - i * 3 for i in range(2 ** 67, 2 ** 67 + 500)]" -> The patched CPython is approximately 2% faster. 
        I expected the patched CPython to be somewhat slower here. Either I have missed something, or some compiler optimization magic was used here.


------------ diff ------------
The patches diff is attached.


------------ tests ------------
I built the patched CPython for x86, and played with it a little. Everything seemed to work as usual. 
Also, where cases B and C (that were mentioned in 'the current state' section) returned 'False', the patched CPython returned 'True', as expected.

In addition, I ran 'python_d.exe -m test' (on my 64-bit Windows 10) with and without the patches, and got quite the same output.
the outputs of both runs are attached.

----------
components: Interpreter Core
files: proposedPatches.diff
keywords: patch
messages: 266557
nosy: Oren Milman
priority: normal
severity: normal
status: open
title: long_add and long_sub might return a new int where &small_ints[x] could be returned
type: behavior
Added file: http://bugs.python.org/file43041/proposedPatches.diff

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

From report at bugs.python.org  Sat May 28 13:03:27 2016
From: report at bugs.python.org (Phil Thompson)
Date: Sat, 28 May 2016 17:03:27 +0000
Subject: [New-bugs-announce] [issue27146] posixmodule.c needs stdio.h
Message-ID: <1464455007.27.0.77870799101.issue27146@psf.upfronthosting.co.za>


New submission from Phil Thompson:

posixmodule.c needs to #include <stdio.h> to get the declaration of ctermid(). On most platforms this happens as a side effect of including other .h files but does not on Android.

----------
components: Library (Lib)
messages: 266561
nosy: philthompson10
priority: normal
severity: normal
status: open
title: posixmodule.c needs stdio.h
type: compile error
versions: Python 3.6

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

From report at bugs.python.org  Sat May 28 13:53:58 2016
From: report at bugs.python.org (Eric Snow)
Date: Sat, 28 May 2016 17:53:58 +0000
Subject: [New-bugs-announce] [issue27147] importlib docs do not mention PEP
 420
Message-ID: <1464458038.31.0.784289682435.issue27147@psf.upfronthosting.co.za>


New submission from Eric Snow:

PEP 420 should be mentioned in the introduction section of the importlib docs.  I'll push a change to fix this in a minute.

----------
assignee: eric.snow
components: Documentation
messages: 266565
nosy: brett.cannon, eric.snow
priority: normal
severity: normal
stage: needs patch
status: open
title: importlib docs do not mention PEP 420
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Sat May 28 23:57:35 2016
From: report at bugs.python.org (Jon Nabozny)
Date: Sun, 29 May 2016 03:57:35 +0000
Subject: [New-bugs-announce] [issue27148] Make VENV_DIR relative to Script
 directory
Message-ID: <1464494255.1.0.144712628992.issue27148@psf.upfronthosting.co.za>


New submission from Jon Nabozny:

I would like to see some enhancement where the activate.bat and activate scripts allow the script to determine where the python executable resides.

When the executable cannot be found (because the path doesn't exist for some reason), the system will ultimately find the installed version of python. This can cause side effects that may be non-obvious to users.

Example:
    User creates a virtual environment:
        python -m venv C:\Location\To\Project venv

     User manually changes location of project:
        xcopy /E C:\Location\To\Project C:\New\Project\Location

     User runs activate.bat:
        (venv) C:\New\Project\Location

     At this point, the user will get the modified prompt, but will         
     actually be using his/her globally installed python. Therefore,
     running anything like pip will taint their install. Further, if
     they had set up the environment previously, it can cause errors
     because modules won't be found (because it's pointing at the
     wrong Lib\site-packages folder).

Code:
    activate.bat
        ;Replace set "VIRTUAL_ENV=__VENV_DIR__"
        set "VIRTUAL_ENV=%~dp0..\"

    activate
        FILE=$(readlink -f "$0")
        FILE_DIR=$(dirname "$FILE")
        # Replace VIRTUAL_ENV="__VENV_DIR__"
        VIRTUAL_ENV="$FILE_DIR/../"

Somewhat related, I've also found that's it's incredibly convenient to also include activate and deactivate files at the root of the venv:

     python -m venv C:\project venv

     # Now, C:\project looks like this:
     .\venv
     .\activate.bat
     .\deactivate.bat

     # activate and deactivate are very simple:
     ;activate.bat
     @ECHO OFF

     pushd env\Scripts
     call activate
     popd

     ;deactivate.bat
     @ECHO OFF

     pushd env\Scripts
     call deactivate
     popd

----------
components: Demos and Tools
messages: 266583
nosy: widmo
priority: normal
severity: normal
status: open
title: Make VENV_DIR relative to Script directory
type: enhancement
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun May 29 01:50:34 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Sun, 29 May 2016 05:50:34 +0000
Subject: [New-bugs-announce] [issue27149] Implement socket.sendmsg() for
 Windows
Message-ID: <1464501034.91.0.597053336572.issue27149@psf.upfronthosting.co.za>


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

Please add, but do not emulate, since atomicity of that IO must be kept, as said in man-page.

----------
components: Library (Lib), Windows
messages: 266586
nosy: mmarkk, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Implement socket.sendmsg() for Windows
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Sun May 29 03:34:25 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Sun, 29 May 2016 07:34:25 +0000
Subject: [New-bugs-announce] [issue27150] PEP446 (CLOEXEC by default)
 violation with fcntl.fcntl(..., fcntl.F_DUPFD)
Message-ID: <1464507265.78.0.794599717766.issue27150@psf.upfronthosting.co.za>


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

1. Need fix the code
2. Fix documentation
3. Update PEP446 description.

There is F_DUPFD_CLOEXEC constant, that must be used instead of F_DUPFD transparently when kernel >= 2.6.24.

----------
messages: 266591
nosy: mmarkk
priority: normal
severity: normal
status: open
title: PEP446 (CLOEXEC by default) violation with fcntl.fcntl(..., fcntl.F_DUPFD)

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

From report at bugs.python.org  Sun May 29 06:59:54 2016
From: report at bugs.python.org (Roman Bolshakov)
Date: Sun, 29 May 2016 10:59:54 +0000
Subject: [New-bugs-announce] [issue27151] multiprocessing.Process leaves
 read pipes open (Process.sentinel)
Message-ID: <1464519594.44.0.838880586419.issue27151@psf.upfronthosting.co.za>


New submission from Roman Bolshakov:

There's no code that closes read pipe(Process.sentinel) when a Process is joined. That creates issues in long running programs as the pipe's file descriptors are effectively leaked.

----------
components: Library (Lib)
files: leak.py
messages: 266598
nosy: Roman Bolshakov
priority: normal
severity: normal
status: open
title: multiprocessing.Process leaves read pipes open (Process.sentinel)
type: resource usage
versions: Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file43046/leak.py

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

From report at bugs.python.org  Sun May 29 11:25:19 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 May 2016 15:25:19 +0000
Subject: [New-bugs-announce] [issue27152] Additional assert methods for
 unittest
Message-ID: <1464535519.92.0.0853489345335.issue27152@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka:

Proposed patch adds the ExtraAssertions mix-in that provides additional assert methods. These methods provide better failure report than assertTrue/assertFalse with a result of corresponding function. For example assertStartsWith outputs shorten reprs of the start of the string and prefix.

These checks are quite popular and can be used tens or hundreds times in tests (the patch makes tests using new assert methods):

assertHasAttr       121 times
assertNotHasAttr     99 times
assertIsSubclass    243 times
assertNotIsSubclass  95 times
assertStartsWith    131 times
assertEndsWith       73 times

----------
components: Tests
files: extra_assertions.patch
keywords: patch
messages: 266600
nosy: ezio.melotti, michael.foord, r.david.murray, rbcollins, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Additional assert methods for unittest
type: enhancement
versions: Python 3.6
Added file: http://bugs.python.org/file43047/extra_assertions.patch

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

From report at bugs.python.org  Sun May 29 12:39:34 2016
From: report at bugs.python.org (Colin Morris)
Date: Sun, 29 May 2016 16:39:34 +0000
Subject: [New-bugs-announce] [issue27153] Default value shown by
 argparse.ArgumentDefaultsHelpFormatter is backwards for
 action='store_false'
Message-ID: <1464539974.48.0.860363682331.issue27153@psf.upfronthosting.co.za>


New submission from Colin Morris:

Small example:

    import argparse
    parser = argparse.ArgumentParser(formatter_class=argparse.ArgumentDefaultsHelpFormatter)
    parser.add_argument('--no-foo', dest='foo', action='store_false', help="Suppress foo")
    args = parser.parse_args()
    print('foo = {}'.format(args.foo))

Output with "-h":

optional arguments:
  -h, --help  show this help message and exit
  --no-foo    Suppress foo (default: True)

A reasonable person reading that would think that we suppress foo by default. But actually, foo is True by default - "--no-foo" is off by default. I would suggest that if action='store_false', the default value reported by the formatter should be flipped.

----------
components: Library (Lib)
messages: 266602
nosy: Colin Morris
priority: normal
severity: normal
status: open
title: Default value shown by argparse.ArgumentDefaultsHelpFormatter is backwards for action='store_false'
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Sun May 29 13:41:19 2016
From: report at bugs.python.org (Alexey Borzenkov)
Date: Sun, 29 May 2016 17:41:19 +0000
Subject: [New-bugs-announce] [issue27154] Regression in file.writelines
 behavior
Message-ID: <1464543679.71.0.415502254928.issue27154@psf.upfronthosting.co.za>


New submission from Alexey Borzenkov:

There's a regression in file.writelines behavior for binary files when writing unicode strings, which seems to have first appeared in Python 2.7.7. The problem is that when writing unicode strings the internal representation (UCS2 or UCS4) is written instead of the actual text, which also directly contradicts documentation, which states "This is equivalent to calling write() for each string". However on Python 2.7.7+ they are no longer equivalent:

>>> open('testfile.bin', 'wb').writelines([u'Hello, world!'])
>>> open('testfile.bin', 'rb').read()
'H\x00e\x00l\x00l\x00o\x00,\x00 \x00w\x00o\x00r\x00l\x00d\x00!\x00'
>>> open('testfile.bin', 'wb').write(u'Hello, world!')
>>> open('testfile.bin', 'rb').read()
'Hello, world!'

This code worked correctly no Python 2.7.6.

----------
components: IO
messages: 266605
nosy: snaury
priority: normal
severity: normal
status: open
title: Regression in file.writelines behavior
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun May 29 15:15:29 2016
From: report at bugs.python.org (Ben Kane)
Date: Sun, 29 May 2016 19:15:29 +0000
Subject: [New-bugs-announce] [issue27155] '-' sign typo in example
Message-ID: <1464549329.65.0.961898669229.issue27155@psf.upfronthosting.co.za>


New submission from Ben Kane:

On page https://docs.python.org/3/library/subprocess.html#replacing-os-system

it looks like the code in the realistic example has a spurious '-' sign.
The line:

        print("Child was terminated by signal", -retcode, file=sys.stderr)

shouldn't have the minus sign negating the retcode:

        print("Child was terminated by signal", retcode, file=sys.stderr)

Full code in the example:

try:
    retcode = call("mycmd" + " myarg", shell=True)
    if retcode < 0:
        print("Child was terminated by signal", -retcode, file=sys.stderr)
    else:
        print("Child returned", retcode, file=sys.stderr)
except OSError as e:
    print("Execution failed:", e, file=sys.stderr)

should be:

try:
    retcode = call("mycmd" + " myarg", shell=True)
    if retcode < 0:
        print("Child was terminated by signal", retcode, file=sys.stderr)
    else:
        print("Child returned", retcode, file=sys.stderr)
except OSError as e:
    print("Execution failed:", e, file=sys.stderr)

Thanks, and apologies if I erred somewhere in this report.

----------
assignee: docs at python
components: Documentation
messages: 266614
nosy: Ben Kane, docs at python
priority: normal
severity: normal
status: open
title: '-' sign typo in example
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Sun May 29 16:21:44 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 29 May 2016 20:21:44 +0000
Subject: [New-bugs-announce] [issue27156] IDLE: remove unused code
Message-ID: <1464553304.91.0.34770795987.issue27156@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

With 3.6 not bound by compatibility with external imports, dead code can go.  It is an annoying distraction.  The resource saved is space in package and module content listings and maintainer time and attention.  

1. module idlever.py.  It is obsolete at least since 2.6 and deprecated in 2.7.11 and 3.4.4+ in #24199.  If  IDLE is ever separately versioned again, idlever should be an attribute in idlelib.__init__.

2. file help.txt and its dedicated viewer editor.HelpDialog.  help.txt is out-of-date and not maintained, as it was replaced years ago by Docs/library/idle.rst.  Since Fall 2015, IDLE uses help.py to display help.html with formatting and index. See #16893.

3. stackviewer.StackBrowser.keys.  I removed this trivial and no-longer used method in #24790, and then restored it in the face of an objection and the lack of overt criteria for such removals.  I expect the class to get far more drastic changes than this.

Note: 'unused' is determined by grepping the name in consideration in .../idlelib/*.py, where ... == <repository path>/Lib.  IDLE => Edit => Find in Files, Alt-F3.

----------
assignee: terry.reedy
messages: 266629
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: IDLE: remove unused code
type: resource usage
versions: Python 3.6

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

From report at bugs.python.org  Sun May 29 18:46:08 2016
From: report at bugs.python.org (ppperry)
Date: Sun, 29 May 2016 22:46:08 +0000
Subject: [New-bugs-announce] [issue27157] Unhelpful error message when one
 calls a subclass of type
Message-ID: <1464561968.54.0.551105312321.issue27157@psf.upfronthosting.co.za>


New submission from ppperry:

>>>class x(type):pass
>>> x(x)
Traceback (most recent call last):
  File "<pyshell#335>", line 1, in <module>
    x(x)
TypeError: type() takes 1 or 3 arguments

I am giving it one argument, and yet it's complaining that `type` expects one or three arguments. How unhelpful.

----------
components: Interpreter Core
messages: 266643
nosy: ppperry
priority: normal
severity: normal
status: open
title: Unhelpful error message when one calls a subclass of type
type: behavior
versions: Python 3.4

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

From report at bugs.python.org  Sun May 29 18:52:41 2016
From: report at bugs.python.org (ppperry)
Date: Sun, 29 May 2016 22:52:41 +0000
Subject: [New-bugs-announce] [issue27158] `isnstance` builtin does not
 handle types that are their own type
Message-ID: <1464562361.71.0.727466697005.issue27158@psf.upfronthosting.co.za>


New submission from ppperry:

If one executes the following statements:

>>> class metatype(type):pass
>>> class x(type,metaclass=metatype):pass
>>> x.__class__ = x

, one gets a type that is it's own type: (`type(x) is x`). However, `isinstance(x,x)` unexpectedly returns False. How is my `x` type not an instance of itself.

----------
components: Interpreter Core
messages: 266644
nosy: ppperry
priority: normal
severity: normal
status: open
title: `isnstance` builtin does not handle types that are their own type
versions: Python 3.4

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

From report at bugs.python.org  Mon May 30 06:38:18 2016
From: report at bugs.python.org (Sean Hunt)
Date: Mon, 30 May 2016 10:38:18 +0000
Subject: [New-bugs-announce] [issue27159] Python 3.5.1's websocket's lib
 crashes in event that internet connection stops.
Message-ID: <1464604698.4.0.495142476658.issue27159@psf.upfronthosting.co.za>


New submission from Sean Hunt:

I know that websockets has a issue with when a internet connection is dropped and prints a bad traceback. However I have to manually recreate it when the exception happens which is a pain as when it does it crashes aiohttp sessions as well.

Also I wonder how I can bytecompile some dependencies that would normally be in site-packages to install manually to the embed version of python so that way I do not have to append to sys.path?

And 1 more thing why does importlib fail when you try to reload a relativly imported module. Do you guys plan to add support for it someday? I hope so as it sucks that I cant do such thing as ```py
from .somefile import someclass``` and be able to reload it by only knowing ``someclass``

Also it would be nice if there was a mode in python 3.5.1 that allows you to generate bytecode that you can use in the embed copy of the same version. Or to allow the embed version to generate bytecode that you can use to add to ``python35.zip`` eaily using WinRAR.

----------
messages: 266686
nosy: Sean Hunt
priority: normal
severity: normal
status: open
title: Python 3.5.1's websocket's lib crashes in event that internet connection stops.

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

From report at bugs.python.org  Mon May 30 10:52:24 2016
From: report at bugs.python.org (Kenneth Lim)
Date: Mon, 30 May 2016 14:52:24 +0000
Subject: [New-bugs-announce] [issue27160] Silent truncation of kwargs when
 passing keywords containing colons
Message-ID: <1464619944.37.0.938540391114.issue27160@psf.upfronthosting.co.za>


New submission from Kenneth Lim:

Passing a dict with colon-containing keys as kwargs to a function results in a KeyError stemming from a silent truncation of the keys.

Error does not clearly describe the issue in this case.

----------
components: Interpreter Core
files: poc.py
messages: 266696
nosy: Kenneth Lim
priority: normal
severity: normal
status: open
title: Silent truncation of kwargs when passing keywords containing colons
type: behavior
versions: Python 3.5
Added file: http://bugs.python.org/file43058/poc.py

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

From report at bugs.python.org  Mon May 30 20:22:15 2016
From: report at bugs.python.org (Antony Lee)
Date: Tue, 31 May 2016 00:22:15 +0000
Subject: [New-bugs-announce] [issue27161] Confusing exception in
 Path().with_name
Message-ID: <1464654135.6.0.522820749972.issue27161@psf.upfronthosting.co.za>


New submission from Antony Lee:

`Path().with_name` can fail with a lot of different exceptions:

    >>> Path("foo").with_name(0)
    Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    File "/usr/lib/python3.5/pathlib.py", line 800, in with_name
        raise ValueError("Invalid name %r" % (name))
    ValueError: Invalid name 0

    >>> Path("foo").with_name(1)
    Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    File "/usr/lib/python3.5/pathlib.py", line 797, in with_name
        drv, root, parts = self._flavour.parse_parts((name,))
    File "/usr/lib/python3.5/pathlib.py", line 62, in parse_parts
        drv, root, rel = self.splitroot(part)
    File "/usr/lib/python3.5/pathlib.py", line 268, in splitroot
        if part and part[0] == sep:
    TypeError: 'int' object is not subscriptable

    >>> Path("foo").with_name({})
    Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    File "/usr/lib/python3.5/pathlib.py", line 800, in with_name
        raise ValueError("Invalid name %r" % (name))
    ValueError: Invalid name {}

    >>> Path("foo").with_name({0: 1})
    Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    File "/usr/lib/python3.5/pathlib.py", line 797, in with_name
        drv, root, parts = self._flavour.parse_parts((name,))
    File "/usr/lib/python3.5/pathlib.py", line 69, in parse_parts
        parsed.append(sys.intern(rel))
    TypeError: must be str, not dict

    >>> Path("foo").with_name({"a": "b"})
    Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    File "/usr/lib/python3.5/pathlib.py", line 797, in with_name
        drv, root, parts = self._flavour.parse_parts((name,))
    File "/usr/lib/python3.5/pathlib.py", line 62, in parse_parts
        drv, root, rel = self.splitroot(part)
    File "/usr/lib/python3.5/pathlib.py", line 268, in splitroot
        if part and part[0] == sep:
    KeyError: 0

While most are fairly clear, the last one is particularly confusing IMO; additionally, looking at the implementation of `_Flavour.parse_parts` there seems to be room for even more confusion with a properly crafted dict.

Of course, with Python's dynamicity a lot of exceptions can be triggered at weird places using carefully crafted objects, but I think pathlib should at least raise a clear exception when passed an incorrect builtin type.

----------
components: Library (Lib)
messages: 266724
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: Confusing exception in Path().with_name
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue May 31 02:46:46 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 31 May 2016 06:46:46 +0000
Subject: [New-bugs-announce] [issue27162] Add idlelib.interface module
Message-ID: <1464677206.97.0.125904884409.issue27162@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

In msg243635 of the renaming issue #24225, Nick suggested

"One path you may want to consider is progressively factoring out a public "idlelib.extensions" API, and treat everything else in idlelib as fair game for renaming. Folks tend to be more tolerant of disruption if the new state of affairs is also clearly better for them, not just the folks making the change."

This issue is an implementation of that idea, except that I want to reserve 'extension' for modules added by 3rd parties using the extension interface.  The new module would consist of callables that make builtin IDLE features available to non-IDLE tkinter code.

The first callable would replace the following from turtledemo.__main__

from idlelib.colorizer import ColorDelegator, color_config
from idlelib.percolator import Percolator
...
        Percolator(self.text).insertfilter(ColorDelegator())
...
        color_config(text)

with

from idlelib.interface import colorize
...
        colorize(text)

At the moment, interface would have the imports and 

def colorize(text):
    color_config(text)
    Percolator(self.text).insertfilter(ColorDelegator())

Future enhancements might be to accept a color scheme name and to return the Percolator instance (or a wrapper thereof), but these would not break code.  In any case, colorize would be re-written if the needed incantation changed, and turtledemo would continue to work without change.

An new public module should not be backported for the usual reasons.  New callables should also not be added except in comments.  I plan to only add features that are requested, and perhaps a very few others, rather than everything and everything possible.

----------
assignee: terry.reedy
components: ctypes
messages: 266739
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Add idlelib.interface module
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Tue May 31 02:58:05 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 31 May 2016 06:58:05 +0000
Subject: [New-bugs-announce] [issue27163] IDLE entry for What's New in
 Python 3.6
Message-ID: <1464677885.83.0.244887022976.issue27163@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

File: Doc/whatsnew/3.6.rst
Location within file: Under 'Improved Modules', as 'idlelib (IDLE)' (?)
Draft test:
"Idlelib is being revamped to make IDLE look better and work better and to make it easier to maintain and improve IDLE. Part of making IDLE look better, especially on Linux and Mac, is using ttk widgets.  As a result, IDLE no longer runs with tcl/tk 8.4.  It now requires tcl/tk 8.5 or 8.6 and availability of ttk widgets.  We recommend running the latest release of either.

'Revamping' includes renaming, refactoring, and consolidation of idlelib modules. As a result, imports of idlelib files that worked in 3.5 will usually not work in 3.6.  At least a module name change will be needed, sometimes more.  Information will be added to idlelib.  In compensation, the eventual result with be that some idlelib classes will be easier to use, with better APIs and docstrings explaining them."

This should be added before 3.6.0a2 and considered critical for that release, but after patches that make it true. #24759, using a revision of Serhiy's code from #24750, will make 3.5 and successful loading of ttk a requirement for IDLE (first paragraph).  New issue #27162 will add compatibility info and a new module (second paragraph) and require that the second paragraph be re-written a bit.

----------
assignee: terry.reedy
components: ctypes
messages: 266740
nosy: ncoghlan, ned.deily, terry.reedy
priority: low
severity: normal
stage: needs patch
status: open
title: IDLE entry for What's New in Python 3.6
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Tue May 31 05:41:03 2016
From: report at bugs.python.org (Vladimir Mihailenco)
Date: Tue, 31 May 2016 09:41:03 +0000
Subject: [New-bugs-announce] [issue27164] zlib can't decompress DEFLATE
 using shared dictionary
Message-ID: <1464687663.75.0.126366287594.issue27164@psf.upfronthosting.co.za>


New submission from Vladimir Mihailenco:

Consider following code:

```
import zlib


hello = b'hello'

# Compress data using deflate and shared/predefined dict.
co = zlib.compressobj(wbits=-zlib.MAX_WBITS, zdict=hello)
data = co.compress(hello) + co.flush()

# Decompress deflate by providing same dict.
do = zlib.decompressobj(wbits=-zlib.MAX_WBITS, zdict=hello)
data = do.decompress(data)

print(data)
```

Decompression fails with "zlib.error: Error -3 while decompressing data: invalid distance too far back".

My original task was to decompress data I get from Golang library - https://golang.org/pkg/compress/flate/#NewWriterDict

----------
components: Library (Lib)
messages: 266747
nosy: Vladimir Mihailenco
priority: normal
severity: normal
status: open
title: zlib can't decompress DEFLATE using shared dictionary
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Tue May 31 06:05:12 2016
From: report at bugs.python.org (=?utf-8?q?Adam_Biela=C5=84ski?=)
Date: Tue, 31 May 2016 10:05:12 +0000
Subject: [New-bugs-announce] [issue27165] Skip callables when displaying
 exception fields in cgitb
Message-ID: <1464689112.02.0.764355408735.issue27165@psf.upfronthosting.co.za>


New submission from Adam Biela?ski:

Issue: cgitb text formatter outputs all members of exception object, using standard dir() to get their names.

My patch changes its behaviour to skip fields which are callable, since printing them only clutters the output but is rarely helpful.


HTML formatter skips members starting with underscore (_), which is slightly different behaviour and I can alter my patch to make both formatters behave in the same way, should the need be. Both can skip members starting with underscore, callables, or callables and values starting with underscore - any option will be better than printing them all.


Current change alters output for exception value Exception("123412312") from:

<type 'exceptions.Exception'>: 123412312
    __class__ = <type 'exceptions.Exception'>
    __delattr__ = <method-wrapper '__delattr__' of exceptions.Exception object>
    __dict__ = {}
    __doc__ = 'Common base class for all non-exit exceptions.'
    __format__ = <built-in method __format__ of exceptions.Exception object>
    __getattribute__ = <method-wrapper '__getattribute__' of exceptions.Exception object>
    __getitem__ = <method-wrapper '__getitem__' of exceptions.Exception object>
    __getslice__ = <method-wrapper '__getslice__' of exceptions.Exception object>
    __hash__ = <method-wrapper '__hash__' of exceptions.Exception object>
    __init__ = <method-wrapper '__init__' of exceptions.Exception object>
    __new__ = <built-in method __new__ of type object>
    __reduce__ = <built-in method __reduce__ of exceptions.Exception object>
    __reduce_ex__ = <built-in method __reduce_ex__ of exceptions.Exception object>
    __repr__ = <method-wrapper '__repr__' of exceptions.Exception object>
    __setattr__ = <method-wrapper '__setattr__' of exceptions.Exception object>
    __setstate__ = <built-in method __setstate__ of exceptions.Exception object>
    __sizeof__ = <built-in method __sizeof__ of exceptions.Exception object>
    __str__ = <method-wrapper '__str__' of exceptions.Exception object>
    __subclasshook__ = <built-in method __subclasshook__ of type object>
    __unicode__ = <built-in method __unicode__ of exceptions.Exception object>
    args = ('123412312',)
    message = '123412312'


to:

<type 'exceptions.Exception'>: 123412312
    __dict__ = {}
    __doc__ = 'Common base class for all non-exit exceptions.'
    args = ('123412312',)
    message = '123412312'

----------
components: Library (Lib)
files: cgitb.diff
keywords: patch
messages: 266749
nosy: Adam.Biela?ski
priority: normal
severity: normal
status: open
title: Skip callables when displaying exception fields in cgitb
type: enhancement
versions: Python 3.5, Python 3.6
Added file: http://bugs.python.org/file43065/cgitb.diff

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

From report at bugs.python.org  Tue May 31 07:06:05 2016
From: report at bugs.python.org (Rogi)
Date: Tue, 31 May 2016 11:06:05 +0000
Subject: [New-bugs-announce] [issue27166] interesting info
Message-ID: <0000796a1ba1$c2bdccb3$7f51b733$@linuxmail.org>


New submission from Rogi:

Hi, I found some info and I thought it might be interesting for you, please read more at <http://gerdutrihy.itwasbad.com/aeebrrez>

rogi at linuxmail.org

----------
messages: 266751
nosy: Rogi
priority: normal
severity: normal
status: open
title: interesting info

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

From report at bugs.python.org  Tue May 31 12:35:00 2016
From: report at bugs.python.org (David MacKenzie)
Date: Tue, 31 May 2016 16:35:00 +0000
Subject: [New-bugs-announce] [issue27167] subprocess reports signal as
 negative exit status, not documented
Message-ID: <1464712500.44.0.979958949461.issue27167@psf.upfronthosting.co.za>


New submission from David MacKenzie:

If a command run by subprocess.check_call() exits because of a signal, e.g. SIGPIPE, Popen._handle_exitstatus() encodes the signal number as a negative return code. check_call() then raises that as a CalledProcessError, which describes it as "returned non-zero exit status -13". This is misleading and undocumented. 

CalledProcessError.__str__() should check if self.returncode is negative and if so return a string indicating that it was "signal 13", not "exit status -13". Better yet, it should include the descriptive name of the signal, e.g., SIGPIPE.

And, the documentation for the subprocess module should note that a signal is converted into a negative returncode.

----------
components: Library (Lib)
messages: 266758
nosy: dmacnet
priority: normal
severity: normal
status: open
title: subprocess reports signal as negative exit status, not documented
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Tue May 31 14:06:54 2016
From: report at bugs.python.org (Nathaniel Smith)
Date: Tue, 31 May 2016 18:06:54 +0000
Subject: [New-bugs-announce] [issue27168] Yury isn't sure comprehensions and
 await interact correctly
Message-ID: <1464718014.77.0.520069298007.issue27168@psf.upfronthosting.co.za>


New submission from Nathaniel Smith:

So he asked me to file a bug reminding him to write more unit tests.

Interesting cases:

async def f():
    return (x for x in await g())

async def f():
    return (await x for x in g())

(and ditto for [], {} comprehensions)

----------
components: Interpreter Core
messages: 266763
nosy: njs, yselivanov
priority: normal
severity: normal
status: open
title: Yury isn't sure comprehensions and await interact correctly
versions: Python 3.5, Python 3.6

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

From report at bugs.python.org  Tue May 31 14:50:58 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Tue, 31 May 2016 18:50:58 +0000
Subject: [New-bugs-announce] [issue27169] __debug__ is not optimized out at
 compile time for anything but `if:` and `while:` blocks
Message-ID: <1464720658.3.0.0366082537286.issue27169@psf.upfronthosting.co.za>


New submission from Josh Rosenberg:

Issue #22091 points out a quirk in the compile function and use of the __debug__ "constant" causing inconsistent behavior when the optimize level of the compile call differs from that of the main interpreter; __debug__ in an `if` or `while` statement is compiled out, but all other uses load it dynamically (at runtime), so in a mixed environment (interpreter at optimization=0, compile at optimize=2), you get non-obvious behavior.

This behavior appears to be a consequence of __debug__ being handled by a special case for the `if` and `while` statements in compile.c that statements of that form to be compiled out, but *not* for similar constructs, e.g. `a if __debug__ else b` and `__debug__ or a` are always evaluated at runtime, whether or not `compile` is involved. The `expr_constant` function here https://hg.python.org/cpython/file/fd0ac7ba091e/Python/compile.c#l3542 is responsible for this (and only called in the same file, for `if` and `while` statements).

I'm not sure I understand the peephole optimizer, but if it can operate recursively (that is, an initial replacement of A->B where B could be optimized from B->C is optimized in a subsequent pass, turning all uses of A to C eventually), it seems like the "correct" solution would be to piggyback on optimizations for True and False, by having the peephole optimizer replace LOAD_NAME/LOAD_GLOBAL for __debug__ with an appropriate LOAD_CONST, True or False, based on the compile environment. This would fix this bug (making __debug__ evaluate in the `compile` call, so the environment when the compiled code is executed doesn't matter), and it would optimize all the other cases that the current special cases for `if` and `while` don't cover by letting the recursive pass optimize them out the same way uses of literal True and False is optimized, so uses of ternary expressions, non-`if`/`while` boolean operations, and all other operations using __debug__ are optimized using a constant (and possibly optimized out of existence) without needing to independently maintain separate optimizations all over the codebase for __debug__. Might also allow the removal of the explicit special case for __debug__ in compile.c for `if` and `while`, simplifying that code a bit.

This would fix the problem from #22091 and also make __debug__ reliably useful for "optimization", since all uses of it would "compile out" to optimized runtime code, where right now only two cases do so.

Does this seem reasonable?

Note: I added the nosy list from #22091 here, since that bug is really just a special case of this one for `compile` only.

----------
components: Interpreter Core
messages: 266769
nosy: SilentGhost, arigo, eryksun, josh.r
priority: normal
severity: normal
status: open
title: __debug__ is not optimized out at compile time for anything but `if:` and `while:` blocks
versions: Python 3.6

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

From report at bugs.python.org  Tue May 31 16:02:11 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 31 May 2016 20:02:11 +0000
Subject: [New-bugs-announce] [issue27170] IDLE: remove Toggle Auto Coloring
 or add to edit menu & doc
Message-ID: <1464724931.74.0.507384074731.issue27170@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

On Stackoverflow, person asked why syntax coloring sometimes stopped working, seemingly at random.  https://stackoverflow.com/questions/37511276/how-to-make-python-idle-editor-to-change-line-colors-according-to-the-color-map

The OP finally traced the problem to hitting ctrl-/ because of habit from using PyCharm, which bind ^/ to something else.  In IDLE, cntrl-/ is bound to <<toggle-auto-coloring>>, but that is not easy to discover.  (If I ever halfway knew about it, I had forgotten.)  There is no menu entry and, I am sure, no mention in the doc. There is only the hard-to-search list in the Keys tab of the configuration dialog.  T think that this feature should either be visible on the menu and documented and enhanced, or deleted.

I am currently inclined to delete it as I cannot see hardly any use, and doubt that is sees real use, especially by beginners. It only affects the current window.  It only affects future keystrokes (and pasted text), leaving current colorization as is.  There is no indication that coloring is off until one types something that should be colored, and many will not know all the fine details.  (This is why the SO OP had trouble pinning down the trigger.)  If the toggle is kept, there should be an indication added to the status bar.

Searching all IDLE issues for 'toggle' returned 24 hits, none for color.  I should check hg annotate for the author of the code and issue #, if not part of the original submission.

----------
components: 2to3 (2.x to 3.x conversion tool)
messages: 266773
nosy: terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: IDLE: remove Toggle Auto Coloring or add to edit menu & doc
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Tue May 31 23:57:50 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 01 Jun 2016 03:57:50 +0000
Subject: [New-bugs-announce] [issue27171] Fix various typos
Message-ID: <1464753470.11.0.0270588746388.issue27171@psf.upfronthosting.co.za>


New submission from Martin Panter:

This fixes various spelling mistakes in documentation, code comments, and test function names.

There is also a correction to an exception message in Modules/_ctypes/callproc.c, which I propose to fix only in 3.6.

----------
files: typos.py3.patch
keywords: patch
messages: 266797
nosy: martin.panter
priority: normal
severity: normal
stage: patch review
status: open
title: Fix various typos
versions: Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file43076/typos.py3.patch

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