From report at bugs.python.org  Sun May  1 00:28:29 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 01 May 2016 04:28:29 +0000
Subject: [issue26896] mix-up with the terms 'importer', 'finder',
 'loader' in the import system and related code
In-Reply-To: <1462046496.61.0.778323150916.issue26896@psf.upfronthosting.co.za>
Message-ID: <1462076909.62.0.948288665698.issue26896@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +brett.cannon
stage:  -> patch review

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

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: [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 00:45:35 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 01 May 2016 04:45:35 +0000
Subject: [issue26896] mix-up with the terms 'importer', 'finder',
 'loader' in the import system and related code
In-Reply-To: <1462046496.61.0.778323150916.issue26896@psf.upfronthosting.co.za>
Message-ID: <1462077935.26.0.440121029242.issue26896@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch. I left two review comments about unused variables on Rietveld.

----------
nosy: +berker.peksag

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

From report at bugs.python.org  Sun May  1 02:07:05 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 01 May 2016 06:07:05 +0000
Subject: [issue23960] PyErr_SetImportError doesn't clean up on some errors
In-Reply-To: <1429053168.87.0.990858167954.issue23960@psf.upfronthosting.co.za>
Message-ID: <20160501060701.84637.84336.D8439DC3@psf.io>


Roundup Robot added the comment:

New changeset 5871b48f4c2e by Berker Peksag in branch '3.5':
Issue #23960: Cleanup args and kwargs on error in PyErr_SetImportError
https://hg.python.org/cpython/rev/5871b48f4c2e

New changeset 94471357db08 by Berker Peksag in branch 'default':
Issue #23960: Cleanup args and kwargs on error in PyErr_SetImportError
https://hg.python.org/cpython/rev/94471357db08

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

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

From report at bugs.python.org  Sun May  1 02:07:28 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 01 May 2016 06:07:28 +0000
Subject: [issue23960] PyErr_SetImportError doesn't clean up on some errors
In-Reply-To: <1429053168.87.0.990858167954.issue23960@psf.upfronthosting.co.za>
Message-ID: <1462082848.93.0.390659559266.issue23960@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks!

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

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

From report at bugs.python.org  Sun May  1 02:55:08 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 01 May 2016 06:55:08 +0000
Subject: [issue26849] android does not support versioning in SONAME
In-Reply-To: <1461662690.12.0.966004358302.issue26849@psf.upfronthosting.co.za>
Message-ID: <1462085708.13.0.219036733213.issue26849@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Python builds and runs fine on android without this patch. I cannot reproduce the 'Fatal Python error: PyThreadState_Get: no current thread' abort either.

Closing the issue.

----------
resolution:  -> works for me
status: open -> closed

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

From report at bugs.python.org  Sun May  1 03:08:58 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 01 May 2016 07:08:58 +0000
Subject: [issue26884] cross-compilation of extension module links to the wrong
 python library
In-Reply-To: <1461925930.98.0.579147295527.issue26884@psf.upfronthosting.co.za>
Message-ID: <1462086538.8.0.785834058647.issue26884@psf.upfronthosting.co.za>


Changes by Xavier de Gaye <xdegaye at gmail.com>:


----------
nosy: +dstufft, eric.araujo

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

From report at bugs.python.org  Sun May  1 03:11:18 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 01 May 2016 07:11:18 +0000
Subject: [issue26851] android compilation and link flags
In-Reply-To: <1461673211.54.0.945034926098.issue26851@psf.upfronthosting.co.za>
Message-ID: <1462086678.62.0.81204214601.issue26851@psf.upfronthosting.co.za>


Changes by Xavier de Gaye <xdegaye at gmail.com>:


----------
nosy: +twouters

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

From report at bugs.python.org  Sun May  1 03:12:24 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 01 May 2016 07:12:24 +0000
Subject: [issue26852] add a COMPILEALL_FLAGS Makefile variable
In-Reply-To: <1461674611.23.0.732409522866.issue26852@psf.upfronthosting.co.za>
Message-ID: <1462086744.46.0.287144075561.issue26852@psf.upfronthosting.co.za>


Changes by Xavier de Gaye <xdegaye at gmail.com>:


----------
nosy: +twouters

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

From report at bugs.python.org  Sun May  1 03:15:08 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 01 May 2016 07:15:08 +0000
Subject: [issue26858] setting SO_REUSEPORT fails on android
In-Reply-To: <1461677842.81.0.574068471289.issue26858@psf.upfronthosting.co.za>
Message-ID: <1462086908.32.0.919581397404.issue26858@psf.upfronthosting.co.za>


Changes by Xavier de Gaye <xdegaye at gmail.com>:


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

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

From report at bugs.python.org  Sun May  1 03:40:10 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 01 May 2016 07:40:10 +0000
Subject: [issue26163] FAIL: test_hash_effectiveness
 (test.test_set.TestFrozenSet)
In-Reply-To: <1453293464.25.0.570690037157.issue26163@psf.upfronthosting.co.za>
Message-ID: <1462088410.11.0.698449494124.issue26163@psf.upfronthosting.co.za>


Berker Peksag added the comment:

I just saw the same failure on s390x RHEL 3.x: http://buildbot.python.org/all/builders/s390x%20RHEL%203.x/builds/1004/steps/test/logs/stdio

======================================================================
FAIL: test_hash_effectiveness (test.test_set.TestFrozenSet)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z/build/Lib/test/test_set.py", line 738, in test_hash_effectiveness
    self.assertGreater(4*u, t)
AssertionError: 124 not greater than 128

======================================================================
FAIL: test_hash_effectiveness (test.test_set.TestFrozenSetSubclass)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z/build/Lib/test/test_set.py", line 738, in test_hash_effectiveness
    self.assertGreater(4*u, t)
AssertionError: 124 not greater than 128

It looks like the failed assert was added in 1d0038dbd8f8.

----------
nosy: +berker.peksag, rhettinger
resolution: out of date -> 
status: closed -> open
type:  -> behavior

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

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: [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 04:12:06 2016
From: report at bugs.python.org (SilentGhost)
Date: Sun, 01 May 2016 08:12:06 +0000
Subject: [issue26898] Error in the
In-Reply-To: <1462089977.93.0.233622268862.issue26898@psf.upfronthosting.co.za>
Message-ID: <1462090326.69.0.246729700834.issue26898@psf.upfronthosting.co.za>


SilentGhost added the comment:

LGTM

----------
nosy: +SilentGhost
stage:  -> commit review

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

From report at bugs.python.org  Sun May  1 04:27:56 2016
From: report at bugs.python.org (Marco Buttu)
Date: Sun, 01 May 2016 08:27:56 +0000
Subject: [issue26898] Typo in the documentation of math.isclose()
In-Reply-To: <1462089977.93.0.233622268862.issue26898@psf.upfronthosting.co.za>
Message-ID: <1462091276.89.0.436841558101.issue26898@psf.upfronthosting.co.za>


Changes by Marco Buttu <marco.buttu at gmail.com>:


----------
title: Error in the -> Typo in the documentation of math.isclose()

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

From report at bugs.python.org  Sun May  1 04:28:43 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 01 May 2016 08:28:43 +0000
Subject: [issue26898] Typo in the documentation of math.isclose()
In-Reply-To: <1462089977.93.0.233622268862.issue26898@psf.upfronthosting.co.za>
Message-ID: <20160501082840.21665.49432.C2902BFB@psf.io>


Roundup Robot added the comment:

New changeset 469bc90e8922 by Berker Peksag in branch '3.5':
Issue #26898: Fix typo in math.isclose() docstring
https://hg.python.org/cpython/rev/469bc90e8922

New changeset 634764b4675c by Berker Peksag in branch 'default':
Issue #26898: Fix typo in math.isclose() docstring
https://hg.python.org/cpython/rev/634764b4675c

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

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

From report at bugs.python.org  Sun May  1 04:29:55 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 01 May 2016 08:29:55 +0000
Subject: [issue26898] Typo in the documentation of math.isclose()
In-Reply-To: <1462089977.93.0.233622268862.issue26898@psf.upfronthosting.co.za>
Message-ID: <1462091395.36.0.181804017555.issue26898@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks!

----------
nosy: +berker.peksag
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed
type:  -> behavior

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

From report at bugs.python.org  Sun May  1 04:51:28 2016
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 01 May 2016 08:51:28 +0000
Subject: [issue26711] Fix comparison of plistlib.Data
In-Reply-To: <1460059602.28.0.307914137302.issue26711@psf.upfronthosting.co.za>
Message-ID: <1462092688.04.0.105485840829.issue26711@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

Serhiy,

I slightly prefer the second patch, but either one would be fine.  

The reason I asked about explicitly calling __eq__ is that this is an uncommon pattern (at least for me). 

Ronald

----------

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

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: [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:54 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 May 2016 10:17:54 +0000
Subject: [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 06:37:09 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 01 May 2016 10:37:09 +0000
Subject: [issue26711] Fix comparison of plistlib.Data
In-Reply-To: <1460059602.28.0.307914137302.issue26711@psf.upfronthosting.co.za>
Message-ID: <20160501103705.39154.80325.91A2328A@psf.io>


Roundup Robot added the comment:

New changeset 41afb83cffac by Serhiy Storchaka in branch '3.5':
Issue #26711: Fixed the comparison of plistlib.Data with other types.
https://hg.python.org/cpython/rev/41afb83cffac

New changeset dbdd5bc4df99 by Serhiy Storchaka in branch 'default':
Issue #26711: Fixed the comparison of plistlib.Data with other types.
https://hg.python.org/cpython/rev/dbdd5bc4df99

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

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

From report at bugs.python.org  Sun May  1 06:46:01 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 May 2016 10:46:01 +0000
Subject: [issue26711] Fix comparison of plistlib.Data
In-Reply-To: <1460059602.28.0.307914137302.issue26711@psf.upfronthosting.co.za>
Message-ID: <1462099561.33.0.69513827582.issue26711@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

For simplicity I left "==" and fixed only obvious bug.

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

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

From report at bugs.python.org  Sun May  1 08:04:37 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 May 2016 12:04:37 +0000
Subject: [issue26900] Exclude the private API from the stable API
In-Reply-To: <1462097873.28.0.0706601779139.issue26900@psf.upfronthosting.co.za>
Message-ID: <1462104277.76.0.466099351707.issue26900@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Added

PyAPI_FUNC(PyObject *) _PyObject_GenericGetAttrWithDict(PyObject *, PyObject *, PyObject *);
PyAPI_FUNC(int) _PyObject_GenericSetAttrWithDict(PyObject *, PyObject *, PyObject *, PyObject *);
PyAPI_FUNC(int) _Py_fstat(int fd, struct _Py_stat_struct *status);
PyAPI_FUNC(void) _PyEval_FiniThreads(void);

----------
Added file: http://bugs.python.org/file42671/private_limited_api.patch

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

From report at bugs.python.org  Sun May  1 08:04:47 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 May 2016 12:04:47 +0000
Subject: [issue26900] Exclude the private API from the stable API
In-Reply-To: <1462097873.28.0.0706601779139.issue26900@psf.upfronthosting.co.za>
Message-ID: <1462104287.52.0.361674978989.issue26900@psf.upfronthosting.co.za>


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


Removed 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: [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 09:29:11 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 01 May 2016 13:29:11 +0000
Subject: [issue21367] multiprocessing.JoinableQueue requires new kwarg
In-Reply-To: <1398618734.12.0.810845662855.issue21367@psf.upfronthosting.co.za>
Message-ID: <1462109351.34.0.0898074353235.issue21367@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Cryptic error when subclassing multiprocessing classes

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

From report at bugs.python.org  Sun May  1 09:53:50 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 May 2016 13:53:50 +0000
Subject: [issue23867] Argument Clinic: inline parsing code for 1-argument
 functions
In-Reply-To: <1428157476.28.0.0922120616231.issue23867@psf.upfronthosting.co.za>
Message-ID: <1462110830.7.0.863690295228.issue23867@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Synchronized with tip.

----------
versions: +Python 3.6 -Python 3.5
Added file: http://bugs.python.org/file42672/clinic_meth_o_inline.patch

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

From report at bugs.python.org  Sun May  1 09:59:22 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 May 2016 13:59:22 +0000
Subject: [issue26305] Make Argument Clinic to generate PEP 7 conforming code
In-Reply-To: <1454929711.55.0.893733572519.issue26305@psf.upfronthosting.co.za>
Message-ID: <1462111162.42.0.987214527459.issue26305@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The only thing that disturbs me is that some templates need duplicating braces, and others need quadrupling braces.

----------

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

From report at bugs.python.org  Sun May  1 10:24:46 2016
From: report at bugs.python.org (Meador Inge)
Date: Sun, 01 May 2016 14:24:46 +0000
Subject: [issue26305] Make Argument Clinic to generate PEP 7 conforming code
In-Reply-To: <1454929711.55.0.893733572519.issue26305@psf.upfronthosting.co.za>
Message-ID: <1462112686.2.0.957551406476.issue26305@psf.upfronthosting.co.za>


Meador Inge added the comment:

LGTM.  I agree that the extra braces are a little gross, but nothing immediately comes to mind as how to make that better.

----------
nosy: +meador.inge

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

From report at bugs.python.org  Sun May  1 11:36:39 2016
From: report at bugs.python.org (Gabriel Mesquita Cangussu)
Date: Sun, 01 May 2016 15:36:39 +0000
Subject: [issue26832] ProactorEventLoop doesn't support stdin/stdout nor files
 with connect_read_pipe/connect_write_pipe
In-Reply-To: <1461383150.45.0.258316694453.issue26832@psf.upfronthosting.co.za>
Message-ID: <1462116999.4.0.765337419474.issue26832@psf.upfronthosting.co.za>


Gabriel Mesquita Cangussu added the comment:

Terry,

About your question, "Isn't there some other way to asynchronously read/file files, as opposed to sockets and pipes, on Windows?", that is exactly the problem I was trying to overcome, specifically for reading the stdin.

On my research I found both this stackoverflow questions with no valid answers:

http://stackoverflow.com/questions/31510190/aysncio-cannot-read-stdin-on-windows

http://stackoverflow.com/questions/31511563/file-to-socket-adapter-in-python

And I understood that 'pipe' wouldn't mean a 'file', but why can't I use 'sys.stdin' with 'ProactorEventLoop.connect_read_pipe()', can't 'sys.stdin' be a pipe on Windows like it can on Posix?

----------

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

From report at bugs.python.org  Sun May  1 13:05:00 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 01 May 2016 17:05:00 +0000
Subject: [issue26893] ValueError exception raised when using IntEnum with an
 attribute called "name" and @unique decorator
In-Reply-To: <1462019726.06.0.0957572026567.issue26893@psf.upfronthosting.co.za>
Message-ID: <20160501170455.21687.44033.16644642@psf.io>


Roundup Robot added the comment:

New changeset 1b6581bae5a1 by Ethan Furman in branch '3.5':
issue26893: use mro() to examine class heirarchy
https://hg.python.org/cpython/rev/1b6581bae5a1

New changeset 7188de6b50ab by Ethan Furman in branch 'default':
issue26893: use mro() to examine class heirarchy
https://hg.python.org/cpython/rev/7188de6b50ab

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

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

From report at bugs.python.org  Sun May  1 13:34:25 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 01 May 2016 17:34:25 +0000
Subject: [issue26874] Docstring error in divmod function
In-Reply-To: <1461859730.5.0.461826994455.issue26874@psf.upfronthosting.co.za>
Message-ID: <20160501173422.10030.40759.61A1DCB7@psf.io>


Roundup Robot added the comment:

New changeset 84ff79cce41e by Serhiy Storchaka in branch '3.5':
Regenerate Argument Clinic code for issue #26874.
https://hg.python.org/cpython/rev/84ff79cce41e

New changeset 98678738b7e9 by Serhiy Storchaka in branch 'default':
Regenerate Argument Clinic code for issue #26874.
https://hg.python.org/cpython/rev/98678738b7e9

----------

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

From report at bugs.python.org  Sun May  1 13:36:54 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 01 May 2016 17:36:54 +0000
Subject: [issue26858] setting SO_REUSEPORT fails on android
In-Reply-To: <1461677842.81.0.574068471289.issue26858@psf.upfronthosting.co.za>
Message-ID: <1462124214.76.0.530923621629.issue26858@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Where is the patch that adds android_ver()? At the very least that should be listed as a dependency here.

I don't very much like to have changes to asyncio that can only work in Python 3.6; there's still an upstream version (https://github.com/python/asyncio) that is used to do PyPI releases of asyncio for Python 3.3. I try to keep that in sync with the stdlib on all platforms, otherwise figuring out whether any changes need to be packported is a nightmare.

You might also update the comment somewhere that currently states that reuse_port is not supported on Windows.

PS. It amuses me that each platform apparently has a different way to check (there are three different types of platform checks in the lines you change).

----------

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

From report at bugs.python.org  Sun May  1 13:38:13 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 May 2016 17:38:13 +0000
Subject: [issue26305] Make Argument Clinic to generate PEP 7 conforming code
In-Reply-To: <1454929711.55.0.893733572519.issue26305@psf.upfronthosting.co.za>
Message-ID: <1462124293.15.0.603667345378.issue26305@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The problem was that I didn't know wherever all braces repeated correct times. Actually they were not used correctly in NoneType_return_converter, but since this converter is not used in current sources, this error left unnoticed.

New patch escapes generated strings that can contain braces before substituting them in the template for format(). This allows to decrease the braces repetition number to minimal value. Now there is no need to quadruple them.

----------
Added file: http://bugs.python.org/file42673/clinic_pep7_braces2.patch

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

From report at bugs.python.org  Sun May  1 13:54:13 2016
From: report at bugs.python.org (Demur Rumed)
Date: Sun, 01 May 2016 17:54:13 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1462125253.84.0.119732116785.issue26647@psf.upfronthosting.co.za>


Demur Rumed added the comment:

I should mention a change in dis which hasn't come up for the sake of explicit discussion: I modified dis to not print EXTENDED_ARG. Instead one can tell by the byte indices having a hole (since they uniformly count up by 2 otherwise) & the argument value being greater than 255

----------

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

From report at bugs.python.org  Sun May  1 14:18:35 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Sun, 01 May 2016 18:18:35 +0000
Subject: [issue26858] setting SO_REUSEPORT fails on android
In-Reply-To: <1461677842.81.0.574068471289.issue26858@psf.upfronthosting.co.za>
Message-ID: <1462126715.85.0.137901751894.issue26858@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

> Where is the patch that adds android_ver()?

http://bugs.python.org/issue26855

Xavier de Gaye's implementation is buggy while works for most cases.

----------
nosy: +Chi Hsuan Yen

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

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: [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 14:47:29 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 May 2016 18:47:29 +0000
Subject: [issue26902] Argument Clinic incorrectly work with custom converter
 and renamed parameter
In-Reply-To: <1462128328.67.0.613776590116.issue26902@psf.upfronthosting.co.za>
Message-ID: <1462128449.7.0.743044586784.issue26902@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file42674/issue26902_sample.c

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

From report at bugs.python.org  Sun May  1 14:49:00 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 May 2016 18:49:00 +0000
Subject: [issue23867] Argument Clinic: inline parsing code for 1-argument
 functions
In-Reply-To: <1428157476.28.0.0922120616231.issue23867@psf.upfronthosting.co.za>
Message-ID: <1462128540.16.0.115339668559.issue23867@psf.upfronthosting.co.za>


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


----------
dependencies: +Argument Clinic incorrectly work with custom converter and renamed parameter, Make Argument Clinic to generate PEP 7 conforming code

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

From report at bugs.python.org  Sun May  1 14:49:25 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 01 May 2016 18:49:25 +0000
Subject: [issue26902] Argument Clinic incorrectly works with custom converter
 and renamed parameter
In-Reply-To: <1462128328.67.0.613776590116.issue26902@psf.upfronthosting.co.za>
Message-ID: <1462128565.74.0.657783975179.issue26902@psf.upfronthosting.co.za>


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


----------
title: Argument Clinic incorrectly work with custom converter and renamed parameter -> Argument Clinic incorrectly works with custom converter and renamed parameter

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

From report at bugs.python.org  Sun May  1 15:33:26 2016
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 01 May 2016 19:33:26 +0000
Subject: [issue26874] Docstring error in divmod function
In-Reply-To: <1461859730.5.0.461826994455.issue26874@psf.upfronthosting.co.za>
Message-ID: <1462131206.15.0.317706889775.issue26874@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Forgot that step, thanks Serhiy!

----------

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

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: [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  Sun May  1 17:18:25 2016
From: report at bugs.python.org (ppperry)
Date: Sun, 01 May 2016 21:18:25 +0000
Subject: [issue10850] inconsistent behavior concerning
 multiprocessing.manager.BaseManager._Server
In-Reply-To: <1294360374.53.0.588595674921.issue10850@psf.upfronthosting.co.za>
Message-ID: <1462137505.94.0.928677241455.issue10850@psf.upfronthosting.co.za>


ppperry added the comment:

You're working with non-documented internal components of the python standard library with names that start with an underscore. I think that this is not a bug in python, but instead a consequence of mucking with internals that weren't designed to be mucked with.

----------
nosy: +ppperry

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

From report at bugs.python.org  Sun May  1 17:39:28 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 01 May 2016 21:39:28 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1462125253.84.0.119732116785.issue26647@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwY=_b1Navb_D0Kbkrz43mmVRjcLiSV07+fbskLZAAJoyg@mail.gmail.com>


STINNER Victor added the comment:

Oh, I dislike the dis change. Please keep the current behaviour and open an
issue to enhance the dis module.

----------

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

From report at bugs.python.org  Sun May  1 17:48:00 2016
From: report at bugs.python.org (Anthony Sottile)
Date: Sun, 01 May 2016 21:48:00 +0000
Subject: [issue26704] unittest.mock.patch: Double patching instance method:
 AttributeError: Mock object has no attribute '__name__'
In-Reply-To: <1459972886.32.0.234738617564.issue26704@psf.upfronthosting.co.za>
Message-ID: <1462139280.72.0.391749792346.issue26704@psf.upfronthosting.co.za>


Anthony Sottile added the comment:

Seems I've named the patchfile incorrectly -- Hopefully this is correct this time?

----------
keywords: +patch
nosy: +Anthony Sottile
Added file: http://bugs.python.org/file42675/2.patch

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

From report at bugs.python.org  Sun May  1 18:45:25 2016
From: report at bugs.python.org (Nathan Williams)
Date: Sun, 01 May 2016 22:45:25 +0000
Subject: [issue26873] xmlrpclib raises when trying to convert an int to string
 when unicode is available
In-Reply-To: <1461808162.86.0.277160090083.issue26873@psf.upfronthosting.co.za>
Message-ID: <1462142725.08.0.605337618891.issue26873@psf.upfronthosting.co.za>


Nathan Williams added the comment:

Serhiy, that workaround worked for my needs, thanks.

----------

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

From report at bugs.python.org  Sun May  1 22:41:28 2016
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 02 May 2016 02:41:28 +0000
Subject: [issue26900] Exclude the private API from the stable API
In-Reply-To: <1462097873.28.0.0706601779139.issue26900@psf.upfronthosting.co.za>
Message-ID: <1462156888.53.0.85515714324.issue26900@psf.upfronthosting.co.za>


Zachary Ware added the comment:

#23903 is closely related, but I haven't made it back to that one in some time.

----------
nosy: +zach.ware

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

From report at bugs.python.org  Sun May  1 22:42:44 2016
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 02 May 2016 02:42:44 +0000
Subject: [issue23903] Generate PC/python3.def by scraping headers
In-Reply-To: <1428637761.13.0.348463350169.issue23903@psf.upfronthosting.co.za>
Message-ID: <1462156964.36.0.282845493794.issue23903@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Unassigning since I haven't made it anywhere with this in a year; if anybody else would like to pick it up, feel free.  Otherwise I'll get to it some day :)

----------
assignee: zach.ware -> 
versions: +Python 3.6 -Python 3.5

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

From report at bugs.python.org  Sun May  1 23:12:06 2016
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 02 May 2016 03:12:06 +0000
Subject: [issue26901] Argument Clinic test is broken
In-Reply-To: <1462108807.42.0.528462387786.issue26901@psf.upfronthosting.co.za>
Message-ID: <1462158726.86.0.532369592698.issue26901@psf.upfronthosting.co.za>


Zachary Ware added the comment:

The clinic tests should probably be integrated into the regrtest suite, since clinic is integrated into the build process.

----------
nosy: +zach.ware

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

From report at bugs.python.org  Sun May  1 23:15:13 2016
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 02 May 2016 03:15:13 +0000
Subject: [issue26901] Argument Clinic test is broken
In-Reply-To: <1462108807.42.0.528462387786.issue26901@psf.upfronthosting.co.za>
Message-ID: <1462158913.93.0.585552061016.issue26901@psf.upfronthosting.co.za>


Larry Hastings added the comment:

I will admit that even during development I rarely used Clinic's test suite.  My test suite is: make a change, then run Clinic over all of CPython and do a diff.  If nothing changed then Clinic is still working.

----------

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

From report at bugs.python.org  Mon May  2 00:21:20 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 02 May 2016 04:21:20 +0000
Subject: [issue26894] Readline not aborting line edition on sigint
In-Reply-To: <1462027506.98.0.545203031593.issue26894@psf.upfronthosting.co.za>
Message-ID: <1462162880.87.0.269699830548.issue26894@psf.upfronthosting.co.za>


Martin Panter added the comment:

What happens instead of aborting the line at step 3? Is Ctrl+C completely ignored, as if you didn?t press it?

Perhaps matplotlib is interfering with Python?s SIGINT handler and/or PyOS_InputHook().

Can you eliminate ipython from the equation? I.e. does the problem happen with the built-in Python interactive interpreter? Or with a simple script like the following:

import readline
import matplotlib  # Or whatever is needed to trigger it
while True:
    input("PROMPT ")

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

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

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: [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 01:14:00 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 May 2016 05:14:00 +0000
Subject: [issue23903] Generate PC/python3.def by scraping headers
In-Reply-To: <1428637761.13.0.348463350169.issue23903@psf.upfronthosting.co.za>
Message-ID: <1462166040.87.0.593723860762.issue23903@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This tool would be very useful, since new API often accidentally marked as stable API in header files. The script can play just deliberative role, warn if new unstable API is not wrapped with "#ifndef Py_LIMITED_API" or if stable API is not documented. May be we need separate list of public API in more regular format for comparison with header, documentation, python3.def, refcounts.dat, etc.

There is a code for parsing preprocessor instructions in Argument Clinic. May be it can be reused here.

----------

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

From report at bugs.python.org  Mon May  2 01:28:05 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 02 May 2016 05:28:05 +0000
Subject: [issue24225] Idlelib: changing file names
In-Reply-To: <1431934587.56.0.38760352205.issue24225@psf.upfronthosting.co.za>
Message-ID: <1462166885.98.0.417602351503.issue24225@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Since I posted the message above, I have decided that there should be a new version of every currently used idlelib .py file and that all additions, with new names of course, should be done at once, but only to 3.5 and 3.6.  I will soon open a new issue to explain why and post the number here.

To prepare the patch for the new issue, I will try to use file idle_updating_imports.patch after replacing some of the new names with ones I prefer.  The attached @newnames.txt is the list from msg243572 with the addition of the new names I currently favor.  Some notes:

1. idlever.py and ToolTip.py are not currently used, and will be deleted from the patch.

2. help.py is new in 3.5.1 and currently only has the help viewer.  It starts by declaring itself subject to change.  I plan to move all other help menu code into this file and want to keep the name for the new file.  I plan to rename the current file 'helpviewer.py' and change the imports in EditorWindow.py and macosxSupport.py accordingly

3. Most of the changes I made were to delete underscores that Al inserted.  They are not usually used in module names, even when they might be otherwise (example: tkinter.scrolledtext).

4. Other changes should make related files easier to find.

5. Some new names will disappear when files are combined.

Any further discussion here should be limited to the new names.

----------
Added file: http://bugs.python.org/file42677/@newnames.txt

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

From report at bugs.python.org  Mon May  2 01:34:14 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 May 2016 05:34:14 +0000
Subject: [issue26904] Difflib quick_ratio() could use Counter()
In-Reply-To: <1462163353.47.0.300392305122.issue26904@psf.upfronthosting.co.za>
Message-ID: <1462167254.09.0.574855359052.issue26904@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could you provide a script or a data used by you for benchmarking, so we can repeat this?

----------
nosy: +rhettinger, serhiy.storchaka
stage:  -> patch review

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

From report at bugs.python.org  Mon May  2 01:39:23 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 02 May 2016 05:39:23 +0000
Subject: [issue24225] Idlelib: changing file names
In-Reply-To: <1431934587.56.0.38760352205.issue24225@psf.upfronthosting.co.za>
Message-ID: <1462167563.47.0.66096748298.issue24225@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Uploading slightly revised version.

----------
Added file: http://bugs.python.org/file42678/@newnames.txt

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

From report at bugs.python.org  Mon May  2 01:39:35 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 02 May 2016 05:39:35 +0000
Subject: [issue24225] Idlelib: changing file names
In-Reply-To: <1431934587.56.0.38760352205.issue24225@psf.upfronthosting.co.za>
Message-ID: <1462167575.2.0.54614536952.issue24225@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file42677/@newnames.txt

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

From report at bugs.python.org  Mon May  2 01:48:30 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 May 2016 05:48:30 +0000
Subject: [issue24225] Idlelib: changing file names
In-Reply-To: <1431934587.56.0.38760352205.issue24225@psf.upfronthosting.co.za>
Message-ID: <1462168110.64.0.997381746398.issue24225@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I don't think that simple renaming will give us any benefits, but if that will be made, please don't forgot to use the "hg mv" command for this for keeping the history. And please rename 2.7 files too, otherwise the backporting changes will be turned in hell.

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

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

From report at bugs.python.org  Mon May  2 02:09:12 2016
From: report at bugs.python.org (Steve Dower)
Date: Mon, 02 May 2016 06:09:12 +0000
Subject: [issue23903] Generate PC/python3.def by scraping headers
In-Reply-To: <1428637761.13.0.348463350169.issue23903@psf.upfronthosting.co.za>
Message-ID: <1462169352.9.0.712404993977.issue23903@psf.upfronthosting.co.za>


Steve Dower added the comment:

As I recall, the tool is ready to go. The problem is the argument over what to do with all the APIs that currently are incorrect. Zach had a list at PyCon last year, and the consensus seemed to be that "someone" should figure out whether each API should be stable or not. Since Zach understandably doesn't want to be that someone, there's really no way to reliably tool this process when there are a number of existing violations.

(FWIW, I believe we should just add them to the stable list, as that's the only way to guarantee source compatibility. They've already shipped in 3.5 and people can use them on non-Windows OSs.)

----------

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

From report at bugs.python.org  Mon May  2 02:16:47 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 02 May 2016 06:16:47 +0000
Subject: [issue24225] Idlelib: changing file names
In-Reply-To: <1431934587.56.0.38760352205.issue24225@psf.upfronthosting.co.za>
Message-ID: <1462169807.79.0.810454021934.issue24225@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

For back compatibility reasons, I rejected a 'simple renaming', much as I would like to do it for reasons already given, and closed *this* issue in msg250451.  As I said then here and elsewhere, I instead propose to add new files with new names.  As I said above, I will propose a specific, revised plan in a new issue that I will open after some sleep. Please wait for that to discuss anything other than specific new names.

----------

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

From report at bugs.python.org  Mon May  2 02:22:17 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 May 2016 06:22:17 +0000
Subject: [issue23903] Generate PC/python3.def by scraping headers
In-Reply-To: <1428637761.13.0.348463350169.issue23903@psf.upfronthosting.co.za>
Message-ID: <1462170137.32.0.441866811437.issue23903@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See also closely related issue26900.

----------

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

From report at bugs.python.org  Mon May  2 02:39:29 2016
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 02 May 2016 06:39:29 +0000
Subject: [issue26902] Argument Clinic incorrectly works with custom converter
 and renamed parameter
In-Reply-To: <1462128328.67.0.613776590116.issue26902@psf.upfronthosting.co.za>
Message-ID: <1462171169.28.0.268089642433.issue26902@psf.upfronthosting.co.za>


Larry Hastings added the comment:

This is caused by your "meth_o inline" code, which isn't checked in yet.  A clean checkout of CPython trunk generates this correct code:

    if (!PyArg_Parse(arg, "O&:test", PyUnicode_FSConverter, &path))

Maybe you don't need to use bugs.python.org as your personal bug tracker; maybe you don't need to add me to your private bugs.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Mon May  2 02:40:58 2016
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 02 May 2016 06:40:58 +0000
Subject: [issue26305] Make Argument Clinic to generate PEP 7 conforming code
In-Reply-To: <1454929711.55.0.893733572519.issue26305@psf.upfronthosting.co.za>
Message-ID: <1462171258.97.0.0909388553863.issue26305@psf.upfronthosting.co.za>


Larry Hastings added the comment:

I'm not excited by this new addition to PEP 7, so I'm excusing myself from this issue.

----------

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

From report at bugs.python.org  Mon May  2 02:51:20 2016
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 02 May 2016 06:51:20 +0000
Subject: [issue23867] Argument Clinic: inline parsing code for 1-argument
 functions
In-Reply-To: <1428157476.28.0.0922120616231.issue23867@psf.upfronthosting.co.za>
Message-ID: <1462171880.41.0.475301486415.issue23867@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Why is this dependent on #26305?

----------

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

From report at bugs.python.org  Mon May  2 04:33:16 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 May 2016 08:33:16 +0000
Subject: [issue26902] Argument Clinic incorrectly works with custom converter
 and renamed parameter
In-Reply-To: <1462128328.67.0.613776590116.issue26902@psf.upfronthosting.co.za>
Message-ID: <1462177996.69.0.914693975132.issue26902@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

You are right. Sorry for the noise.

----------

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

From report at bugs.python.org  Mon May  2 05:04:09 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 May 2016 09:04:09 +0000
Subject: [issue23867] Argument Clinic: inline parsing code for 1-argument
 functions
In-Reply-To: <1428157476.28.0.0922120616231.issue23867@psf.upfronthosting.co.za>
Message-ID: <1462179849.85.0.438581205494.issue23867@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Because new generated code contains "if" statements and braces (and PEP 7 requires even more braces than current patch adds). The patch for issue26305 allows to repeat braces only twice instead of 4 times.

----------

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

From report at bugs.python.org  Mon May  2 05:08:51 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 May 2016 09:08:51 +0000
Subject: [issue26305] Make Argument Clinic to generate PEP 7 conforming code
In-Reply-To: <1454929711.55.0.893733572519.issue26305@psf.upfronthosting.co.za>
Message-ID: <1462180131.24.0.926038186068.issue26305@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch for 3.5 that allows to not repeat braces too much. This will help to backport new fixes to 3.5.

----------
Added file: http://bugs.python.org/file42679/clinic_escape_braces.patch

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

From report at bugs.python.org  Mon May  2 05:26:00 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 02 May 2016 09:26:00 +0000
Subject: [issue18916] Various out-of-date Lock text in 3.2+
In-Reply-To: <1378255145.39.0.17069692986.issue18916@psf.upfronthosting.co.za>
Message-ID: <20160502092557.3071.53520.A1E1292C@psf.io>


Roundup Robot added the comment:

New changeset 203c9c4ccb2a by Berker Peksag in branch '3.5':
Issue #18916: Update thread module docstrings
https://hg.python.org/cpython/rev/203c9c4ccb2a

New changeset 57a475e0e378 by Berker Peksag in branch 'default':
Issue #18916: Update thread module docstrings
https://hg.python.org/cpython/rev/57a475e0e378

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

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

From report at bugs.python.org  Mon May  2 05:26:51 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 02 May 2016 09:26:51 +0000
Subject: [issue18916] Various out-of-date Lock text in 3.2+
In-Reply-To: <1378255145.39.0.17069692986.issue18916@psf.upfronthosting.co.za>
Message-ID: <1462181211.94.0.00871687476381.issue18916@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the path, Christopher.

----------
assignee:  -> docs at python
components: +Documentation -Interpreter Core
nosy: +berker.peksag, docs at python
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed
versions: +Python 3.5, Python 3.6 -Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon May  2 05:27:06 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 02 May 2016 09:27:06 +0000
Subject: [issue26858] setting SO_REUSEPORT fails on android
In-Reply-To: <1461677842.81.0.574068471289.issue26858@psf.upfronthosting.co.za>
Message-ID: <1462181226.34.0.256274954479.issue26858@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

The patch was not intended to be proposed as a way to fix this problem, but as an indication of what the problem is. This issue is a dependency of issue #26865: Meta-issue: support of the android platform.

I should have posted instead the result of running 'python -m test -v test_asyncio' on an android emulator running an x86 system image at API level 21, which is:

======================================================================
ERROR: test_create_datagram_endpoint_sockopts (test.test_asyncio.test_base_events.BaseEventLoopWithS
electorTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/test_asyncio/test_base_events.py", line 1506,
 in test_create_datagram_endpoint_sockopts
    socket.SOL_SOCKET, socket.SO_REUSEPORT))
OSError: [Errno 92] Protocol not available

======================================================================
ERROR: test_create_server_reuse_port (test.test_asyncio.test_events.EPollEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/test_asyncio/test_events.py", line 830, in te
st_create_server_reuse_port
    socket.SOL_SOCKET, socket.SO_REUSEPORT))
OSError: [Errno 92] Protocol not available

======================================================================
ERROR: test_create_server_reuse_port (test.test_asyncio.test_events.PollEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/test_asyncio/test_events.py", line 830, in te
st_create_server_reuse_port
    socket.SOL_SOCKET, socket.SO_REUSEPORT))
OSError: [Errno 92] Protocol not available

======================================================================
ERROR: test_create_server_reuse_port (test.test_asyncio.test_events.SelectEventLoopTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/test_asyncio/test_events.py", line 830, in te
st_create_server_reuse_port
    socket.SOL_SOCKET, socket.SO_REUSEPORT))
OSError: [Errno 92] Protocol not available

----------------------------------------------------------------------
Ran 991 tests in 16.528s

FAILED (errors=4, skipped=2)
test test_asyncio failed
1 test failed:
    test_asyncio
Total duration: 0:00:18

----------

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

From report at bugs.python.org  Mon May  2 05:28:39 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 02 May 2016 09:28:39 +0000
Subject: [issue26893] ValueError exception raised when using IntEnum with an
 attribute called "name" and @unique decorator
In-Reply-To: <1462019726.06.0.0957572026567.issue26893@psf.upfronthosting.co.za>
Message-ID: <1462181319.37.0.79787864472.issue26893@psf.upfronthosting.co.za>


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


----------
assignee:  -> ethan.furman

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

From report at bugs.python.org  Mon May  2 05:30:35 2016
From: report at bugs.python.org (Wolfgang Maier)
Date: Mon, 02 May 2016 09:30:35 +0000
Subject: [issue26904] Difflib quick_ratio() could use Counter()
In-Reply-To: <1462163353.47.0.300392305122.issue26904@psf.upfronthosting.co.za>
Message-ID: <1462181435.17.0.00731990529364.issue26904@psf.upfronthosting.co.za>


Wolfgang Maier added the comment:

Given your comment about sum((fullacount & fullbcount).values()), why not use its in-place version:

fullacount &= fullbcount
matches = sum(fullacount.values())

?

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

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

From report at bugs.python.org  Mon May  2 05:42:50 2016
From: report at bugs.python.org (SilentGhost)
Date: Mon, 02 May 2016 09:42:50 +0000
Subject: [issue26888] Multiple memory leaks after raw Py_Initialize and
 Py_Finalize.
In-Reply-To: <1461964498.64.0.249239175864.issue26888@psf.upfronthosting.co.za>
Message-ID: <1462182170.79.0.159700408828.issue26888@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
components: +Interpreter Core -Library (Lib)
nosy: +haypo, serhiy.storchaka

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

From report at bugs.python.org  Mon May  2 05:44:34 2016
From: report at bugs.python.org (SilentGhost)
Date: Mon, 02 May 2016 09:44:34 +0000
Subject: [issue26890] inspect.getsource gets source copy on disk even when
 module has not been reloaded
In-Reply-To: <1461987187.54.0.900828586529.issue26890@psf.upfronthosting.co.za>
Message-ID: <1462182274.01.0.409038437388.issue26890@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


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

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

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: [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 07:47:19 2016
From: report at bugs.python.org (Larry Hastings)
Date: Mon, 02 May 2016 11:47:19 +0000
Subject: [issue26905] from multiprocessing.pool import Pool bug on linux
In-Reply-To: <1462182494.66.0.452090779121.issue26905@psf.upfronthosting.co.za>
Message-ID: <1462189639.95.0.691172010716.issue26905@psf.upfronthosting.co.za>


Larry Hastings added the comment:

This has nothing to do with Argument Clinic, which is an internal tool used in the Python 3.x series.

----------
components:  -Argument Clinic
nosy:  -859911096

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

From report at bugs.python.org  Mon May  2 08:20:05 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 May 2016 12:20:05 +0000
Subject: [issue26282] Add support for partial keyword arguments in extension
 functions
In-Reply-To: <1454535856.96.0.444049158428.issue26282@psf.upfronthosting.co.za>
Message-ID: <1462191605.82.0.272130082597.issue26282@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Removed development code from tests (thanks Martin for catching this) and adds support in Argument Clinic. Now the patch is complete and ready for final review.

----------
components: +Argument Clinic, Interpreter Core
stage:  -> patch review
Added file: http://bugs.python.org/file42681/pyarg_parse_positional_only_and_keywords_2.patch

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

From report at bugs.python.org  Mon May  2 08:23:10 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 May 2016 12:23:10 +0000
Subject: [issue26282] Add support for partial keyword arguments in extension
 functions
In-Reply-To: <1454535856.96.0.444049158428.issue26282@psf.upfronthosting.co.za>
Message-ID: <1462191790.89.0.928981931626.issue26282@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

For example here is a patch that partially reverts issue26243 by making "data" positional parameter, but keeping "level" positional-or-keyword parameter.

----------
Added file: http://bugs.python.org/file42682/zlib_compress_positional_only_data.patch

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

From report at bugs.python.org  Mon May  2 08:37:30 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 02 May 2016 12:37:30 +0000
Subject: [issue25757] Subclasses of property lose docstring
In-Reply-To: <1448667832.51.0.334598445629.issue25757@psf.upfronthosting.co.za>
Message-ID: <1462192650.79.0.552623195573.issue25757@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, Torsten. This is a duplicate of issue 24766. Your patch is almost identical (except the behavior change) to the patch in issue 24766. I will adapt your test and attribute your name in commit message.

----------
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed
superseder:  -> Subclass of property doesn't preserve instance __doc__ when using doc= argument

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

From report at bugs.python.org  Mon May  2 08:39:26 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 02 May 2016 12:39:26 +0000
Subject: [issue24766] Subclass of property doesn't preserve instance __doc__
 when using doc= argument
In-Reply-To: <1438362123.61.0.0930515598899.issue24766@psf.upfronthosting.co.za>
Message-ID: <1462192766.75.0.218377947298.issue24766@psf.upfronthosting.co.za>


Berker Peksag added the comment:

test_property_decorator_doc_writable fix has already been committed in cc1aa0e88626.

Here's an updated patch:

* Synced with the default branch
* Adapted the test from duplicate issue 25757 (written by Torsten Landschoff)

----------
nosy: +berker.peksag, torsten
stage: test needed -> patch review
Added file: http://bugs.python.org/file42683/issue24766.diff

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

From report at bugs.python.org  Mon May  2 08:42:08 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 May 2016 12:42:08 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1462192928.66.0.0885719743894.issue26647@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> I should mention a change in dis which hasn't come up for the sake of explicit discussion: I modified dis to not print EXTENDED_ARG.

This may be a problem since jumps can now point on address not output in disassemble.

May be this is good idea (I'm +0), but it deserves separate issue.

----------

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

From report at bugs.python.org  Mon May  2 08:49:14 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 02 May 2016 12:49:14 +0000
Subject: [issue22656] `help` ignores `__doc__` of descriptors
In-Reply-To: <1413551704.24.0.449864930924.issue22656@psf.upfronthosting.co.za>
Message-ID: <1462193354.46.0.0942508195876.issue22656@psf.upfronthosting.co.za>


Berker Peksag added the comment:

The attached patch should solve this. We probably need to add more tests. test_property_subclass depends on issue 24766.

----------
keywords: +patch
nosy: +berker.peksag
stage:  -> patch review
type:  -> behavior
versions: +Python 3.5, Python 3.6 -Python 3.4
Added file: http://bugs.python.org/file42684/issue22656.diff

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

From report at bugs.python.org  Mon May  2 08:50:06 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 May 2016 12:50:06 +0000
Subject: [issue26881] modulefinder should reuse the dis module
In-Reply-To: <1461912649.38.0.754834410981.issue26881@psf.upfronthosting.co.za>
Message-ID: <1462193406.87.0.227997544966.issue26881@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is pretty simple patch and I'm going to push it in short time if there are no objections. This can make the patch for issue26647 simpler since handling extended args is isolated in one function.

Alternative names for _unpack_args() are welcome.

An alternative way is to use public function get_instructions(), but this adds more overhead and don't work for 2.7.

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

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

From report at bugs.python.org  Mon May  2 08:57:26 2016
From: report at bugs.python.org (Erik Bray)
Date: Mon, 02 May 2016 12:57:26 +0000
Subject: [issue24766] Subclass of property doesn't preserve instance __doc__
 when using doc= argument
In-Reply-To: <1438362123.61.0.0930515598899.issue24766@psf.upfronthosting.co.za>
Message-ID: <1462193846.5.0.389796290264.issue24766@psf.upfronthosting.co.za>


Erik Bray added the comment:

Thanks for the updated patch. LGTM.

----------

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

From report at bugs.python.org  Mon May  2 08:58:29 2016
From: report at bugs.python.org (irdb)
Date: Mon, 02 May 2016 12:58:29 +0000
Subject: [issue18766] IDLE: Autocomplete in editor doesn't work for
 un-imported modules
In-Reply-To: <1376703586.47.0.0617094548794.issue18766@psf.upfronthosting.co.za>
Message-ID: <1462193909.7.0.747635215762.issue18766@psf.upfronthosting.co.za>


Changes by irdb <electro.nnn at gmail.com>:


----------
nosy: +irdb

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

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: [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 09:07:24 2016
From: report at bugs.python.org (Antti Haapala)
Date: Mon, 02 May 2016 13:07:24 +0000
Subject: [issue26906] format(object.__reduce__) fails intermittently
Message-ID: <1462194444.45.0.679859267338.issue26906@psf.upfronthosting.co.za>


New submission from Antti Haapala:

This is an annoying heisenbug; it seems that some objects cannot be formatted until you explicitly do obj.__format__. For example `object.__reduce__` behaves like this:

    Python 2.7.10 (default, Oct 14 2015, 16:09:02)
    [GCC 5.2.1 20151010] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> format(object.__reduce__)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: Type method_descriptor doesn't define __format__
    >>> format(object.__reduce__)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: Type method_descriptor doesn't define __format__
    >>> object.__reduce__.__format__
    <built-in method __format__ of method_descriptor object at 0x7f67563ed0e0>
    >>> format(object.__reduce__)
    "<method '__reduce__' of 'object' objects>"

I can replicate this in 2.7.9, .10 and .11 on Ubuntu and Debian, though it works on Windows Python, works in 2.6.6, and Pythons 3 wherever I've tried, but I've heard this also failing on Python 3.

----------
title: __reduce__ format -> format(object.__reduce__) fails intermittently

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

From report at bugs.python.org  Mon May  2 09:09:03 2016
From: report at bugs.python.org (Antti Haapala)
Date: Mon, 02 May 2016 13:09:03 +0000
Subject: [issue26906] format(object.__reduce__) fails intermittently
In-Reply-To: <1462194444.45.0.679859267338.issue26906@psf.upfronthosting.co.za>
Message-ID: <1462194543.52.0.897100796392.issue26906@psf.upfronthosting.co.za>


Antti Haapala added the comment:

s/explicitly do/explicitly access/

----------

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

From report at bugs.python.org  Mon May  2 09:17:30 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 02 May 2016 13:17:30 +0000
Subject: [issue26906] format(object.__reduce__) fails intermittently
In-Reply-To: <1462194444.45.0.679859267338.issue26906@psf.upfronthosting.co.za>
Message-ID: <1462195050.17.0.230836534642.issue26906@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
nosy: +eric.smith
type:  -> behavior

_______________________________________
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: [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 10:31:32 2016
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 02 May 2016 14:31:32 +0000
Subject: [issue18391] socket.fromfd()'s API is difficult or impossible to use
 correctly in general
In-Reply-To: <1373153632.08.0.45299629619.issue18391@psf.upfronthosting.co.za>
Message-ID: <1462199492.2.0.603625532189.issue18391@psf.upfronthosting.co.za>


Christian Heimes added the comment:

fromfd() can be simplified after #26907 has landed.

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

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

From report at bugs.python.org  Mon May  2 10:38:12 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 02 May 2016 14:38:12 +0000
Subject: [issue25392] setup.py --quiet doesn't silence "no previously-included
 directories" warnings from MANIFEST.in
In-Reply-To: <1444736729.8.0.451337139853.issue25392@psf.upfronthosting.co.za>
Message-ID: <1462199892.82.0.125696857808.issue25392@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
components: +Distutils
nosy: +berker.peksag, dstufft, eric.araujo
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.6 -Python 3.3, Python 3.4

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

From report at bugs.python.org  Mon May  2 10:46:31 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 May 2016 14:46:31 +0000
Subject: [issue26906] format(object.__reduce__) fails intermittently
In-Reply-To: <1462194444.45.0.679859267338.issue26906@psf.upfronthosting.co.za>
Message-ID: <1462200391.15.0.365761915265.issue26906@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Proposed patch makes method descriptors types to be explicitly initialized as in 3.x.

----------
components: +Interpreter Core
keywords: +patch
nosy: +serhiy.storchaka
stage:  -> patch review
Added file: http://bugs.python.org/file42685/init_method_descr_types.patch

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

From report at bugs.python.org  Mon May  2 11:03:14 2016
From: report at bugs.python.org (SilentGhost)
Date: Mon, 02 May 2016 15:03:14 +0000
Subject: [issue26905] from multiprocessing.pool import Pool bug on linux
In-Reply-To: <1462182494.66.0.452090779121.issue26905@psf.upfronthosting.co.za>
Message-ID: <1462201394.34.0.328090558904.issue26905@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +jnoller, sbt -larry
type:  -> behavior

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

From report at bugs.python.org  Mon May  2 11:10:39 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 May 2016 15:10:39 +0000
Subject: [issue22656] `help` ignores `__doc__` of descriptors
In-Reply-To: <1413551704.24.0.449864930924.issue22656@psf.upfronthosting.co.za>
Message-ID: <1462201839.63.0.893679331991.issue22656@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon May  2 11:39:46 2016
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 02 May 2016 15:39:46 +0000
Subject: [issue23903] Generate PC/python3.def by scraping headers
In-Reply-To: <1428637761.13.0.348463350169.issue23903@psf.upfronthosting.co.za>
Message-ID: <1462203586.46.0.0991554660604.issue23903@psf.upfronthosting.co.za>


Zachary Ware added the comment:

> There is a code for parsing preprocessor instructions in Argument Clinic.
> May be it can be reused here.

It already is, actually; its availability was a major factor in my thinking this would be possible and starting to work on it.

----------

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

From report at bugs.python.org  Mon May  2 12:29:32 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 02 May 2016 16:29:32 +0000
Subject: [issue26858] setting SO_REUSEPORT fails on android
In-Reply-To: <1461677842.81.0.574068471289.issue26858@psf.upfronthosting.co.za>
Message-ID: <1462206572.14.0.407424414471.issue26858@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

OK, I'll wait until Android support is closer. Do you have a core dev who's mentoring/reviewing here?

----------

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

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: [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: [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:12:25 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 02 May 2016 17:12:25 +0000
Subject: [issue26908] "1and 0" evaluated a zero, instead of SyntaxError
In-Reply-To: <1462208383.05.0.60534121789.issue26908@psf.upfronthosting.co.za>
Message-ID: <1462209145.74.0.800026324088.issue26908@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the report. This is a duplicate of issue 13610. You can read issue 13610 for more information.

----------
nosy: +berker.peksag
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> On Python parsing numbers.

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

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: [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 14:43:41 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 02 May 2016 18:43:41 +0000
Subject: [issue26219] implement per-opcode cache in ceval
In-Reply-To: <1453918500.26.0.0886095278127.issue26219@psf.upfronthosting.co.za>
Message-ID: <1462214621.69.0.68244567926.issue26219@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I'm confused by the relationship between this and issue 26110. That seems to be a much simpler patch (which also doesn't apply cleanly). If 26110 really increases method calls by 20%, what does this add? (By which I mean (a) what additional optimizations does it have, and (b) what additional speedup does it have?)

I'm asking because I'm still trying to look for reasons why I should accept PEP 509, and this is brought up as a reason.

----------

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

From report at bugs.python.org  Mon May  2 14:44:45 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 02 May 2016 18:44:45 +0000
Subject: [issue26110] Speedup method calls 1.2x
In-Reply-To: <1452791347.05.0.923215900831.issue26110@psf.upfronthosting.co.za>
Message-ID: <1462214685.34.0.437104307629.issue26110@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

This patch doesn't apply cleanly any more. Is it easy to update?

----------

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

From report at bugs.python.org  Mon May  2 14:45:35 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 02 May 2016 18:45:35 +0000
Subject: [issue26219] implement per-opcode cache in ceval
In-Reply-To: <1453918500.26.0.0886095278127.issue26219@psf.upfronthosting.co.za>
Message-ID: <1462214735.17.0.321222390414.issue26219@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I'm also looking for some example code that would show clearly the kind of speedup we're talking about.

----------

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

From report at bugs.python.org  Mon May  2 15:00:36 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 02 May 2016 19:00:36 +0000
Subject: [issue26910] dictionary literal should not allow duplicate keys
In-Reply-To: <1462211417.21.0.537077061483.issue26910@psf.upfronthosting.co.za>
Message-ID: <1462215636.35.0.44458539042.issue26910@psf.upfronthosting.co.za>


R. David Murray added the comment:

Since this has been previously rejected, I'm closing this issue as a duplicate.

If you want to reopen the discussion of the merits, the python-ideas mailing list is the appropriate forum.  I encourage you to raise it there.

----------
nosy: +r.david.murray
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> evaluating literal dict with repeated keys gives no warnings/errors

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

From report at bugs.python.org  Mon May  2 15:17:17 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 02 May 2016 19:17:17 +0000
Subject: [issue26858] setting SO_REUSEPORT fails on android
In-Reply-To: <1461677842.81.0.574068471289.issue26858@psf.upfronthosting.co.za>
Message-ID: <1462216637.43.0.233787173549.issue26858@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Stefan has already commited and closed some of the issues listed at issue #26865. Martin has closed issue #22359, a blocker for the cross-compilation of python.

I will enter an issue for all the failures listed at https://bitbucket.org/xdegaye/pyona/wiki/testsuite and add them to the list in the android meta-issue.

----------

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

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: [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 15:46:09 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 02 May 2016 19:46:09 +0000
Subject: [issue26219] implement per-opcode cache in ceval
In-Reply-To: <1453918500.26.0.0886095278127.issue26219@psf.upfronthosting.co.za>
Message-ID: <1462218368.99.0.666324440124.issue26219@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> I'm confused by the relationship between this and issue 26110.


This patch embeds the implementation of 26110.  I'm no longer sure it was a good idea to have two issues instead of one, everybody seems to be confused about that ;)


> That seems to be a much simpler patch (which also doesn't apply cleanly). If 26110 really increases method calls by 20%, what does this add? (By which I mean (a) what additional optimizations does it have, and (b) what additional speedup does it have?)


I'm sorry for the long response, please bare with me.  This issue is complex, and it's very hard to explain it all in a short message.


The patch from 26110 implements LOAD_METHOD/CALL_METHOD pair of opcodes.  The idea is that we can avoid instantiation of BoundMethod objects for code that looks like "something.method(...)'.  I wanted to first get in shape the patch from 26110, commit it, and then, use the patch from this issue to add additional speedups.


This patch implements a generic per-opcode cache.  Using that cache, it speeds up LOAD_GLOBAL, LOAD_ATTR, and LOAD_METHOD (from 26110) opcodes.  The cache works on per-code object basis, only optimizing code objects that were run more than 1,000 times.


* LOAD_GLOBAL uses cache to store pointers for requested names.  Since the cache is per-opcode, the name is always the same for the given LOAD_GLOBAL.  The cache logic uses PEP 509 to invalidate the cache (although the cache is almost never invalidated for real code).

This optimization makes micro optimizations like "def smth(len=len)" obsolete.  LOAD_GLOBAL becomes much faster, almost as fast as LOAD_FAST.


* LOAD_ATTR uses Armin Rigo's clever types cache, and a modified PyDict_GetItem (PyDict_GetItemHint), which accepts a suggested position of the value in the hash table.  Basically, LOAD_ATTR stores in its cache a pointer to the type of the object it works with, its tp_version_tag, and a hint for PyDict_GetItemHint.  When we have a cache hit, LOAD_ATTR becomes super fast, since it only needs to lookup key/value in type's dict by a known offset (the real code is a bit more complex, to handle all edge cases of descriptor protocol etc).

Python programs have a lot of LOAD_ATTRs.  It also seems that dicts of classes are usually stable, and that objects rarely shadow class attributes.


* LOAD_METHOD is optimized very similarly to LOAD_ATTR.  The idea is that if the opcode is optimized, then we simply store a pointer to the function we want to call with CALL_METHOD.  Since 'obj.method' usually implies that 'method' is implemented on 'obj.__class__' this optimization makes LOAD_METHOD even faster.  That's how `s.startswith('abc')` becomes as fast as `s[:3] == 'abc'`.


> If 26110 really increases method calls by 20%, what does this add? 

Speeds up method calls another 15%, speeds up global name lookups and attribute lookups.


> (b) what additional speedup does it have

Here're some benchmark results: https://gist.github.com/1st1/b1978e17ee8b82cc6432

- call_method micro benchmark is 35% faster
- 2to3 is 7-8% faster
- richards - 18% faster
- many other benchmarks are 10-15% faster.  Those that appear slower aren't stable, i.e. one run they are slower, another they are faster.

I'd say each of the above optimizations speeds up macro-benchmarks by 2-4%.  Combined, they speed up CPython 7-15%.


> I'm asking because I'm still trying to look for reasons why I should accept PEP 509, and this is brought up as a reason.

Re PEP 509 and these patches:

1. I want to first find time to finish up and commit 26110.
2. Then I'll do some careful benchmarking for this patch and write another update with results.
3. This patch adds to the complexity of ceval, but if it really speeds up CPython it's well worth it.  PEP 509 will need to be approved if we decide to move forward with this patch.

I'd say that if you aren't sure about PEP 509 right now, then we can wait a couple of months and decide later.

----------

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

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


Ivan Zakhryaschev added the comment:

BTW, this source file seems to be not used anywhere.

----------

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

From report at bugs.python.org  Mon May  2 15:51:12 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 02 May 2016 19:51:12 +0000
Subject: [issue26911] lib2to3/tests/pytree_idempotency.py has a broken import
In-Reply-To: <1462218326.23.0.838867840781.issue26911@psf.upfronthosting.co.za>
Message-ID: <1462218672.58.0.954064296062.issue26911@psf.upfronthosting.co.za>


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


----------
nosy: +benjamin.peterson

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

From report at bugs.python.org  Mon May  2 16:27:12 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 02 May 2016 20:27:12 +0000
Subject: [issue26858] setting SO_REUSEPORT fails on android
In-Reply-To: <1462216637.43.0.233787173549.issue26858@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJKBpPtHk7b84KPMTZBVwTZcZ5oAqrLU-1bqJxMTwRa_vQ@mail.gmail.com>


Guido van Rossum added the comment:

If there are a lot of Android issue maybe you could get a tracker manager
to add a new keyword or category or whatever?

----------

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

From report at bugs.python.org  Mon May  2 16:29:37 2016
From: report at bugs.python.org (Vladimir Rutsky)
Date: Mon, 02 May 2016 20:29:37 +0000
Subject: [issue13610] On Python parsing numbers.
In-Reply-To: <1324020441.52.0.721783432862.issue13610@psf.upfronthosting.co.za>
Message-ID: <1462220977.77.0.723245099825.issue13610@psf.upfronthosting.co.za>


Changes by Vladimir Rutsky <altsysrq at gmail.com>:


----------
nosy: +rutsky

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

From report at bugs.python.org  Mon May  2 16:34:34 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 02 May 2016 20:34:34 +0000
Subject: [issue26858] setting SO_REUSEPORT fails on android
In-Reply-To: <1461677842.81.0.574068471289.issue26858@psf.upfronthosting.co.za>
Message-ID: <1462221274.24.0.848407561958.issue26858@psf.upfronthosting.co.za>


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


----------
nosy:  -pitrou

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

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: [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:45:06 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Mon, 02 May 2016 20:45:06 +0000
Subject: [issue26905] from multiprocessing.pool import Pool bug on linux
In-Reply-To: <1462182494.66.0.452090779121.issue26905@psf.upfronthosting.co.za>
Message-ID: <1462221906.35.0.299734834311.issue26905@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

The Queue module (queue on Py3) is for communication between threads, not processes; what you've written wouldn't behave correctly on any version of Python. You want to use multiprocessing's Queue class, not Queue.Queue, and to avoid possible deadlocks, you want to populate it after the pool workers are running.

In any event, id(q) is expected to match on Linux, which has fork semantics (so the memory space in parent and child is initially identical). On Windows it differs because spawn based multiprocessing means the objects are recreated in the child processes, rather than inherited directly.

This is a problem with your code and understanding on forking, not a problem in Python.

----------
nosy: +josh.r

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

From report at bugs.python.org  Mon May  2 16:57:47 2016
From: report at bugs.python.org (Oren Milman)
Date: Mon, 02 May 2016 20:57:47 +0000
Subject: [issue26896] mix-up with the terms 'importer', 'finder',
 'loader' in the import system and related code
In-Reply-To: <1462046496.61.0.778323150916.issue26896@psf.upfronthosting.co.za>
Message-ID: <1462222667.37.0.221171976878.issue26896@psf.upfronthosting.co.za>


Oren Milman added the comment:

thanks for the review!

I replied to both of your comments, though I am not sure what is expected of me in the rest of the process.
Whatever it is, I would be happy to help as much as I can.

----------

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

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: [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 17:05:49 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 02 May 2016 21:05:49 +0000
Subject: [issue26913] statistics.mean of bools
In-Reply-To: <1462222751.06.0.733276334894.issue26913@psf.upfronthosting.co.za>
Message-ID: <1462223149.12.0.819267078403.issue26913@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +steven.daprano

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

From report at bugs.python.org  Mon May  2 17:13:15 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 02 May 2016 21:13:15 +0000
Subject: [issue26219] implement per-opcode cache in ceval
In-Reply-To: <1453918500.26.0.0886095278127.issue26219@psf.upfronthosting.co.za>
Message-ID: <1462223595.18.0.413749955733.issue26219@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

OK, I get it. I think it would be really helpful if issue 26110 was updated, reviewed and committed -- it sound like a good idea on its own, and it needs some burn-in time due to the introduction of two new opcodes. (That's especially important since there's also a patch introducing wordcode, i.e. issue 26647 and undoubtedly the two patches will conflict.) It also needs to show benchmark results on its own (but I think you've got that).

I am also happy to see the LOAD_GLOBAL optimization, and it alone may be sufficient to save PEP 509 (though I would recommend editing the text of the PEP dramatically to focus on a brief but crisp description of the change itself and the use that LOAD_GLOBAL would make of it and the microbench results; it currently is a pain to read the whole thing).

I have to read up on what you're doing to LOAD_ATTR/LOAD_METHOD. In the mean time I wonder how that would fare in a world where most attr lookups are in namedtuples.

As a general recommendation I would actually prefer more separate patches (even though it's harder on you), just with very clearly stated relationships between them.

A question about the strategy of only optimizing code objects that are called a lot. Doesn't this mean that a "main" function containing a major inner loop doesn't get the optimization it might deserve?

PS. I like you a lot but there's no way I'm going to "bare" with you. :-)

----------

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

From report at bugs.python.org  Mon May  2 17:23:16 2016
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 02 May 2016 21:23:16 +0000
Subject: [issue26912] test/test_email/torture_test.py (and
 test_asian_codecs.py) has a broken import
In-Reply-To: <1462221853.95.0.795708912177.issue26912@psf.upfronthosting.co.za>
Message-ID: <1462224196.84.0.57550417114.issue26912@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
components: +email
nosy: +barry, r.david.murray
versions: +Python 3.6

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

From report at bugs.python.org  Mon May  2 17:24:42 2016
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 02 May 2016 21:24:42 +0000
Subject: [issue26913] statistics.mean of bools
In-Reply-To: <1462222751.06.0.733276334894.issue26913@psf.upfronthosting.co.za>
Message-ID: <1462224282.75.0.671153128856.issue26913@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


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

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

From report at bugs.python.org  Mon May  2 17:28:45 2016
From: report at bugs.python.org (Rohit Jamuar)
Date: Mon, 02 May 2016 21:28:45 +0000
Subject: [issue26876] Extend MSVCCompiler class to respect environment
 variables
In-Reply-To: <1461866719.82.0.2605655084.issue26876@psf.upfronthosting.co.za>
Message-ID: <1462224525.63.0.983931385704.issue26876@psf.upfronthosting.co.za>


Rohit Jamuar added the comment:

Just so that I understand it clearly - Inside MSVCCompiler class (in _msvccompiler.py / msvccompiler.py / msvc9compiler.py ), current implementation of find_exe() finds compiler / linker / ... after parsing PATH. Should the changes be so, that if DISTUTILS_USE_SDK is set to the environment, the values set to CC / AR / LD, etc. are used verbatim? Or did you mean to say, that just as CC, LD and AR are being read from the environment, the same way rc.exe, mc.exe and mt.exe should be read as well, in case DISTUTILS_USE_SDK is set to the environment?

----------

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

From report at bugs.python.org  Mon May  2 17:33:24 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 02 May 2016 21:33:24 +0000
Subject: [issue26912] test/test_email/torture_test.py (and
 test_asian_codecs.py) has a broken import
In-Reply-To: <1462221853.95.0.795708912177.issue26912@psf.upfronthosting.co.za>
Message-ID: <1462224804.46.0.945504857389.issue26912@psf.upfronthosting.co.za>


R. David Murray added the comment:

torture_test is not currently run, and this is intentional (it uses a large external resource).  It is kept for reference and in case anyone wants to run it by hand[*].  The import should be fixed.

test_asian_codecs is run automatically by the unittest load tests protocol.  That import should be fixed as well since it is picking up the class from the wrong location.

[*] At one point I was working on making it run when the largefile resource is asserted, by downloading the resource.  But I'm not convinced it is a good idea, so I abandonded that.

----------

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

From report at bugs.python.org  Mon May  2 17:38:31 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 02 May 2016 21:38:31 +0000
Subject: [issue26219] implement per-opcode cache in ceval
In-Reply-To: <1453918500.26.0.0886095278127.issue26219@psf.upfronthosting.co.za>
Message-ID: <1462225111.84.0.657438088135.issue26219@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> OK, I get it. I think it would be really helpful if issue 26110 was updated, reviewed and committed -- it sound like a good idea on its own, and it needs some burn-in time due to the introduction of two new opcodes. (That's especially important since there's also a patch introducing wordcode, i.e. issue 26647 and undoubtedly the two patches will conflict.) It also needs to show benchmark results on its own (but I think you've got that).

Right.  Victor asked me to review the wordcode patch (and maybe even commit), and I'll try to do that this week.  LOAD_METHOD/CALL_METHOD patch needs some refactoring, right now it's a PoC-quality.  I agree it has to go first.

> I am also happy to see the LOAD_GLOBAL optimization, and it alone may be sufficient to save PEP 509 (though I would recommend editing the text of the PEP dramatically to focus on a brief but crisp description of the change itself and the use that LOAD_GLOBAL would make of it and the microbench results; it currently is a pain to read the whole thing).

Alright.  I'll work on this with Victor.

> I have to read up on what you're doing to LOAD_ATTR/LOAD_METHOD. In the mean time I wonder how that would fare in a world where most attr lookups are in namedtuples.

I think there will be no difference, but I can add a microbenchmark and see.

> As a general recommendation I would actually prefer more separate patches (even though it's harder on you), just with very clearly stated relationships between them.

NP. This is a big change to review, and the last thing I want is to accidentally make CPython slower.

> A question about the strategy of only optimizing code objects that are called a lot. Doesn't this mean that a "main" function containing a major inner loop doesn't get the optimization it might deserve?

Right, the "main" function won't be optimized.  There are two reasons of why I added this threshold of 1000 calls before optimizations:

1. We want to limit the memory overhead.  We, generally, don't want to optimize module code objects, and code objects that are called just a few times over long periods of time.  We can introduce additional heuristic to detect long running loops, but I'm afraid that it will add overhead to the loops that don't need this optimization.

2. We want the environment to become stable -- the builtins and globals namespaces to be fully populated (and, perhaps, mutated), classes fully initialized etc.

> PS. I like you a lot but there's no way I'm going to "bare" with you. :-)

Haha, this is my typo of the month, I guess ;)

----------

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

From report at bugs.python.org  Mon May  2 17:41:14 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 02 May 2016 21:41:14 +0000
Subject: [issue26913] statistics.mean of bools
In-Reply-To: <1462222751.06.0.733276334894.issue26913@psf.upfronthosting.co.za>
Message-ID: <1462225274.35.0.573583396521.issue26913@psf.upfronthosting.co.za>


R. David Murray added the comment:

Already fixed: #24068.

----------
nosy: +r.david.murray
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> statistics module - incorrect results with boolean input

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

From report at bugs.python.org  Mon May  2 17:45:04 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 02 May 2016 21:45:04 +0000
Subject: [issue26219] implement per-opcode cache in ceval
In-Reply-To: <1462225111.84.0.657438088135.issue26219@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJLTu=J_7ATb1BnvFb=zkPt+_DvC7obt4+9=rAV8=WtqZw@mail.gmail.com>


Guido van Rossum added the comment:

All sounds good. Glad the issue of long-running loops is at least on your
radar.

----------

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

From report at bugs.python.org  Mon May  2 18:57:25 2016
From: report at bugs.python.org (Ned Batchelder)
Date: Mon, 02 May 2016 22:57:25 +0000
Subject: [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  Mon May  2 19:05:37 2016
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 02 May 2016 23:05:37 +0000
Subject: [issue21159] configparser.InterpolationMissingOptionError is not very
 intuitive
In-Reply-To: <1396694112.28.0.289974893208.issue21159@psf.upfronthosting.co.za>
Message-ID: <1462230337.35.0.902750512087.issue21159@psf.upfronthosting.co.za>


?ukasz Langa added the comment:

At this point I agree with Robert. It's public API that predates my changes which was inadequately mocked.

I've seen similar problems in the past when we've changed reading file objects to use plain iteration instead of the .readlines() method. I've had people complain that their "file-like object" implementation provided just .readlines() and suddenly stopped working.

I can relate to how this caused painful churn. We do try to minimize it. However, it's hard to evolve any code if we can't touch it based on fear of breaking incompletely duck typed third-party code :(

Barry, would you still like this to be reverted on Python 3.4?

----------

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

From report at bugs.python.org  Mon May  2 19:09:09 2016
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 02 May 2016 23:09:09 +0000
Subject: [issue26537] ConfigParser has optionxform, but not sectionxform
In-Reply-To: <1457678417.52.0.410667040467.issue26537@psf.upfronthosting.co.za>
Message-ID: <1462230549.73.0.507944396672.issue26537@psf.upfronthosting.co.za>


?ukasz Langa added the comment:

I agree sectionxform would be nice. Care to author a patch?

The current workaround is modifying the SECTCRE regular expression.

----------

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

From report at bugs.python.org  Mon May  2 19:09:16 2016
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 02 May 2016 23:09:16 +0000
Subject: [issue26537] ConfigParser has optionxform, but not sectionxform
In-Reply-To: <1457678417.52.0.410667040467.issue26537@psf.upfronthosting.co.za>
Message-ID: <1462230556.37.0.716057656253.issue26537@psf.upfronthosting.co.za>


Changes by ?ukasz Langa <lukasz at langa.pl>:


----------
assignee:  -> lukasz.langa

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

From report at bugs.python.org  Mon May  2 19:11:10 2016
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 02 May 2016 23:11:10 +0000
Subject: [issue20120] Percent-signs (%) in .pypirc should not be interpolated
In-Reply-To: <1388825675.42.0.435893533792.issue20120@psf.upfronthosting.co.za>
Message-ID: <1462230670.24.0.185890142867.issue20120@psf.upfronthosting.co.za>


?ukasz Langa added the comment:

Closing this as setuptools switched to RawConfigParser.

----------
resolution:  -> not a bug
status: open -> closed

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

From report at bugs.python.org  Mon May  2 19:12:30 2016
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 02 May 2016 23:12:30 +0000
Subject: [issue26812] ExtendedInterpolation drops user-defined 'vars' during
 _interpolate_some() recursion
In-Reply-To: <1461212839.44.0.193061483216.issue26812@psf.upfronthosting.co.za>
Message-ID: <1462230750.33.0.406889259326.issue26812@psf.upfronthosting.co.za>


?ukasz Langa added the comment:

This is true. Care to author a patch?

----------
assignee:  -> lukasz.langa

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

From report at bugs.python.org  Mon May  2 19:19:40 2016
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 02 May 2016 23:19:40 +0000
Subject: [issue26710] ConfigParser: Values in DEFAULT section override
 defaults passed to constructor
In-Reply-To: <1460041826.4.0.857287965169.issue26710@psf.upfronthosting.co.za>
Message-ID: <1462231180.93.0.483662927199.issue26710@psf.upfronthosting.co.za>


?ukasz Langa added the comment:

Having both `defaults` and `overrides` would confuse the API, especially given that we already have `fallback` arguments to `get*` methods.

What's the point of having overrides *over* a file? Defaults were thought of as a way to say: "unless the user bothered to modify those, the values are as follows". That's the point of configuration. We have defaults, that the *user* overrides. Why would you want to override what the user specified? I fail to understand the logic behind this.

----------

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

From report at bugs.python.org  Mon May  2 19:40:18 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 02 May 2016 23:40:18 +0000
Subject: [issue16385] evaluating literal dict with repeated keys gives no
 warnings/errors
In-Reply-To: <1351859267.72.0.446639729186.issue16385@psf.upfronthosting.co.za>
Message-ID: <1462232418.54.0.867969527484.issue16385@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

Raising an error on duplicates also has precedent:

>>> dict(a=3, b=4, a=5)
  File "<stdin>", line 1
SyntaxError: keyword argument repeated

----------
nosy: +gregory.p.smith

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

From report at bugs.python.org  Mon May  2 19:41:07 2016
From: report at bugs.python.org (Ned Batchelder)
Date: Mon, 02 May 2016 23:41:07 +0000
Subject: [issue26914] Fix formatting of lists in PEP 420
In-Reply-To: <1462229844.3.0.0802177041097.issue26914@psf.upfronthosting.co.za>
Message-ID: <1462232467.17.0.435750471316.issue26914@psf.upfronthosting.co.za>


Ned Batchelder added the comment:

OK, "rampant" was overly dramatic... :)

These PEPs seem to have the same issue:

pep-0302.html
pep-0327.html
pep-0339.html
pep-0362.html
pep-0364.html
pep-0372.html
pep-0380.html
pep-0382.html
pep-0393.html
pep-0400.html
pep-0403.html
pep-0404.html
pep-0410.html
pep-0416.html
pep-0418.html
pep-0426.html
pep-0432.html
pep-0433.html
pep-0437.html
pep-0446.html
pep-0457.html
pep-0461.html
pep-0472.html
pep-0488.html
pep-0498.html
pep-0628.html
pep-3103.html
pep-3104.html
pep-3108.html
pep-3121.html
pep-3127.html
pep-3131.html
pep-3137.html
pep-3141.html
pep-3147.html
pep-3149.html
pep-3150.html
pep-3156.html

----------

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

From report at bugs.python.org  Mon May  2 19:47:05 2016
From: report at bugs.python.org (Marc Abramowitz)
Date: Mon, 02 May 2016 23:47:05 +0000
Subject: [issue26710] ConfigParser: Values in DEFAULT section override
 defaults passed to constructor
In-Reply-To: <1460041826.4.0.857287965169.issue26710@psf.upfronthosting.co.za>
Message-ID: <1462232825.53.0.168723885352.issue26710@psf.upfronthosting.co.za>


Marc Abramowitz added the comment:

Well my thought is that the configuration file has defaults that a user may want to override at runtime using an environment variable or command-line switch.

I guess as SilentGhost pointed out, maybe this is not the responsibility of the ConfigParser as this behavior is not related to config files per se, though it's curious that the ConfigParser allows the user to pass in values in the constructor.

Since two people are -1 on this, it seems pretty clear that I am on the wrong track with this, so I think we can close this.

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

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

From report at bugs.python.org  Tue May  3 00:10:58 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Tue, 03 May 2016 04:10:58 +0000
Subject: [issue18766] IDLE: Autocomplete in editor doesn't work for
 un-imported modules
In-Reply-To: <1376703586.47.0.0617094548794.issue18766@psf.upfronthosting.co.za>
Message-ID: <1462248658.72.0.187830486471.issue18766@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
nosy:  -BreamoreBoy

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

From report at bugs.python.org  Tue May  3 00:26:56 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 May 2016 04:26:56 +0000
Subject: [issue26914] Fix formatting of lists in PEP 420
In-Reply-To: <1462229844.3.0.0802177041097.issue26914@psf.upfronthosting.co.za>
Message-ID: <1462249616.99.0.655980031932.issue26914@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

For references:

PEP 0302: New Import Hooks
PEP 0327: Decimal Data Type
PEP 0339: Design of the CPython Compiler
PEP 0362: Function Signature Object
PEP 0364: Transitioning to the Py3K Standard Library
PEP 0372: Adding an ordered dictionary to collections
PEP 0380: Syntax for Delegating to a Subgenerator
PEP 0382: Namespace Packages
PEP 0393: Flexible String Representation
PEP 0400: Deprecate codecs.StreamReader and codecs.StreamWriter
PEP 0403: General purpose decorator clause (aka "@in" clause)
PEP 0404: Python 2.8 Un-release Schedule
PEP 0410: Use decimal.Decimal type for timestamps
PEP 0416: Add a frozendict builtin type
PEP 0418: Add monotonic time, performance counter, and process time functions
PEP 0420: Implicit Namespace Packages
PEP 0426: Metadata for Python Software Packages 2.0
PEP 0432: Simplifying the CPython startup sequence
PEP 0433: Easier suppression of file descriptor inheritance
PEP 0437: A DSL for specifying signatures, annotations and argument converters
PEP 0446: Make newly created file descriptors non-inheritable
PEP 0457: Syntax For Positional-Only Parameters
PEP 0461: Adding % formatting to bytes and bytearray
PEP 0472: Support for indexing with keyword arguments
PEP 0488: Elimination of PYO files
PEP 0498: Literal String Interpolation
PEP 0628: Add ``math.tau``
PEP 3103: A Switch/Case Statement
PEP 3104: Access to Names in Outer Scopes
PEP 3108: Standard Library Reorganization
PEP 3121: Extension Module Initialization and Finalization
PEP 3127: Integer Literal Support and Syntax
PEP 3131: Supporting Non-ASCII Identifiers
PEP 3137: Immutable Bytes and Mutable Buffer
PEP 3141: A Type Hierarchy for Numbers
PEP 3147: PYC Repository Directories
PEP 3149: ABI version tagged .so files
PEP 3150: Statement local namespaces (aka "given" clause)
PEP 3156: Asynchronous IO Support Rebooted: the "asyncio" Module

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

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

From report at bugs.python.org  Tue May  3 00:27:41 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 May 2016 04:27:41 +0000
Subject: [issue26914] Fix formatting of lists in PEP 420
In-Reply-To: <1462229844.3.0.0802177041097.issue26914@psf.upfronthosting.co.za>
Message-ID: <1462249661.96.0.855666711863.issue26914@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue May  3 00:35:18 2016
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 03 May 2016 04:35:18 +0000
Subject: [issue26914] Fix formatting of lists in PEP 420
In-Reply-To: <1462229844.3.0.0802177041097.issue26914@psf.upfronthosting.co.za>
Message-ID: <1462250118.75.0.639534162385.issue26914@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Looks pretty rampant to me :)

Anyway, +1 for fixing, you can just do it without review if you have the time.

----------

_______________________________________
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: [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 02:20:37 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 03 May 2016 06:20:37 +0000
Subject: [issue26915] Test identity first in membership operation of ItemsView, 
 ValuesView and Sequence in collections.abc
In-Reply-To: <1462256356.96.0.954300432794.issue26915@psf.upfronthosting.co.za>
Message-ID: <1462256437.46.0.952394936493.issue26915@psf.upfronthosting.co.za>


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


----------
keywords: +patch
Added file: http://bugs.python.org/file42687/issue26915.patch

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

From report at bugs.python.org  Tue May  3 02:23:53 2016
From: report at bugs.python.org (SilentGhost)
Date: Tue, 03 May 2016 06:23:53 +0000
Subject: [issue26915] Test identity first in membership operation of ItemsView, 
 ValuesView and Sequence in collections.abc
In-Reply-To: <1462256356.96.0.954300432794.issue26915@psf.upfronthosting.co.za>
Message-ID: <1462256633.19.0.964791551177.issue26915@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +rhettinger, stutzbach
stage:  -> patch review
type:  -> behavior

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

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


Xiang Zhang added the comment:

Add issue number to test method name.

----------
Added file: http://bugs.python.org/file42688/issue26915_v2.patch

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

From report at bugs.python.org  Tue May  3 02:26:21 2016
From: report at bugs.python.org (SilentGhost)
Date: Tue, 03 May 2016 06:26:21 +0000
Subject: [issue26905] from multiprocessing.pool import Pool bug on linux
In-Reply-To: <1462182494.66.0.452090779121.issue26905@psf.upfronthosting.co.za>
Message-ID: <1462256781.17.0.269564779129.issue26905@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Tue May  3 03:10:54 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 03 May 2016 07:10:54 +0000
Subject: [issue26858] setting SO_REUSEPORT fails on android
In-Reply-To: <1461677842.81.0.574068471289.issue26858@psf.upfronthosting.co.za>
Message-ID: <1462259454.6.0.314916271027.issue26858@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Running the "Search" button on the tracker with "Components" set as "Cross-Build" lists 42 issues (20 in the last year).

I guess using this existing category is fine if the titles' issues are prefixed with "android:".

----------

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

From report at bugs.python.org  Tue May  3 03:11:36 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 03 May 2016 07:11:36 +0000
Subject: [issue26858] android: setting SO_REUSEPORT fails
In-Reply-To: <1461677842.81.0.574068471289.issue26858@psf.upfronthosting.co.za>
Message-ID: <1462259496.91.0.365295181366.issue26858@psf.upfronthosting.co.za>


Changes by Xavier de Gaye <xdegaye at gmail.com>:


----------
title: setting SO_REUSEPORT fails on android -> android: setting SO_REUSEPORT fails

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

From report at bugs.python.org  Tue May  3 03:15:35 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 03 May 2016 07:15:35 +0000
Subject: [issue26856] android does not have pwd.getpwall()
In-Reply-To: <1461677345.21.0.582848799296.issue26856@psf.upfronthosting.co.za>
Message-ID: <1462259735.54.0.788678709049.issue26856@psf.upfronthosting.co.za>


Changes by Xavier de Gaye <xdegaye at gmail.com>:


----------
components: +Cross-Build
nosy: +Alex.Willmer

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

From report at bugs.python.org  Tue May  3 03:18:37 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 03 May 2016 07:18:37 +0000
Subject: [issue26852] android: add a COMPILEALL_FLAGS Makefile variable
In-Reply-To: <1461674611.23.0.732409522866.issue26852@psf.upfronthosting.co.za>
Message-ID: <1462259917.7.0.356882577441.issue26852@psf.upfronthosting.co.za>


Changes by Xavier de Gaye <xdegaye at gmail.com>:


----------
title: add a COMPILEALL_FLAGS Makefile variable -> android: add a COMPILEALL_FLAGS Makefile variable

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

From report at bugs.python.org  Tue May  3 03:19:05 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 03 May 2016 07:19:05 +0000
Subject: [issue26855] android: add platform.android_ver()
In-Reply-To: <1461676711.89.0.563475479331.issue26855@psf.upfronthosting.co.za>
Message-ID: <1462259945.59.0.834710996856.issue26855@psf.upfronthosting.co.za>


Changes by Xavier de Gaye <xdegaye at gmail.com>:


----------
title: add platform.android_ver() for android -> android: add platform.android_ver()

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

From report at bugs.python.org  Tue May  3 03:20:17 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 03 May 2016 07:20:17 +0000
Subject: [issue26862] android: SYS_getdents64 does not need to be defined on
 android API 21
In-Reply-To: <1461678588.46.0.828463582716.issue26862@psf.upfronthosting.co.za>
Message-ID: <1462260017.04.0.0487900606831.issue26862@psf.upfronthosting.co.za>


Changes by Xavier de Gaye <xdegaye at gmail.com>:


----------
title: SYS_getdents64 does not need to be defined on android API 21 -> android: SYS_getdents64 does not need to be defined on android API 21

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

From report at bugs.python.org  Tue May  3 03:20:51 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 03 May 2016 07:20:51 +0000
Subject: [issue26884] android: cross-compilation of extension module links to
 the wrong python library
In-Reply-To: <1461925930.98.0.579147295527.issue26884@psf.upfronthosting.co.za>
Message-ID: <1462260051.95.0.791942712393.issue26884@psf.upfronthosting.co.za>


Changes by Xavier de Gaye <xdegaye at gmail.com>:


----------
title: cross-compilation of extension module links to the wrong python library -> android: cross-compilation of extension module links to the wrong python library

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

From report at bugs.python.org  Tue May  3 03:36:41 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 May 2016 07:36:41 +0000
Subject: [issue26914] Fix formatting of lists in PEP 420
In-Reply-To: <1462229844.3.0.0802177041097.issue26914@psf.upfronthosting.co.za>
Message-ID: <20160503073637.21667.45381.41DC1C55@psf.io>


Roundup Robot added the comment:

New changeset 03a4c21ca991 by Berker Peksag in branch 'default':
Issue #26914: Fix formatting of lists in PEP 420
https://hg.python.org/peps/rev/03a4c21ca991

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

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

From report at bugs.python.org  Tue May  3 03:38:31 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 03 May 2016 07:38:31 +0000
Subject: [issue26914] Fix formatting of lists in PEP 420
In-Reply-To: <1462229844.3.0.0802177041097.issue26914@psf.upfronthosting.co.za>
Message-ID: <1462261111.33.0.13284587079.issue26914@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks, I pushed pep-0420.patch.

----------
keywords: +easy
nosy: +berker.peksag
stage:  -> needs patch

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

From report at bugs.python.org  Tue May  3 03:52:30 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 May 2016 07:52:30 +0000
Subject: [issue26914] Fix formatting of lists in PEP 420
In-Reply-To: <1462229844.3.0.0802177041097.issue26914@psf.upfronthosting.co.za>
Message-ID: <20160503075226.8860.42104.6DA06531@psf.io>


Roundup Robot added the comment:

New changeset d420d6fe349f by Georg Brandl in branch 'default':
Fix lists-in-blockquotes in 3xxx PEPs. Ref: #26914
https://hg.python.org/peps/rev/d420d6fe349f

----------

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

From report at bugs.python.org  Tue May  3 04:35:18 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 May 2016 08:35:18 +0000
Subject: [issue26914] Fix formatting of lists in PEP 420
In-Reply-To: <1462229844.3.0.0802177041097.issue26914@psf.upfronthosting.co.za>
Message-ID: <20160503083514.16687.66468.8809BB14@psf.io>


Roundup Robot added the comment:

New changeset d34c698f63a3 by Georg Brandl in branch 'default':
Fix lists-in-blockquotes in 0xxx PEPs. Ref: #26914
https://hg.python.org/peps/rev/d34c698f63a3

New changeset e7200e32b220 by Georg Brandl in branch 'default':
Fixup some more lists-in-blockquotes. Fixes #26914.
https://hg.python.org/peps/rev/e7200e32b220

----------

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

From report at bugs.python.org  Tue May  3 04:36:46 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 May 2016 08:36:46 +0000
Subject: [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:39:03 2016
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 03 May 2016 08:39:03 +0000
Subject: [issue26914] Fix formatting of lists in PEP 420
In-Reply-To: <1462229844.3.0.0802177041097.issue26914@psf.upfronthosting.co.za>
Message-ID: <1462264743.34.0.853238721078.issue26914@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


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

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

From report at bugs.python.org  Tue May  3 04:40:47 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 03 May 2016 08:40:47 +0000
Subject: [issue26914] Fix formatting of lists in PEP 420
In-Reply-To: <1462229844.3.0.0802177041097.issue26914@psf.upfronthosting.co.za>
Message-ID: <1462264847.36.0.341948794736.issue26914@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


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

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

From report at bugs.python.org  Tue May  3 04:44:50 2016
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 03 May 2016 08:44:50 +0000
Subject: [issue26916] Word duplications in PEPs
In-Reply-To: <1462264605.88.0.73387048167.issue26916@psf.upfronthosting.co.za>
Message-ID: <1462265090.44.0.776688447365.issue26916@psf.upfronthosting.co.za>


Georg Brandl added the comment:

LGTM.

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

_______________________________________
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: [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:01:37 2016
From: report at bugs.python.org (Armin Rigo)
Date: Tue, 03 May 2016 09:01:37 +0000
Subject: [issue26917] Inconsistency in unicodedata.normalize()?
In-Reply-To: <1462265307.72.0.382714967199.issue26917@psf.upfronthosting.co.za>
Message-ID: <1462266097.35.0.872484881573.issue26917@psf.upfronthosting.co.za>


Armin Rigo added the comment:

Note: the examples can also be written in this clearer way on Python 3:

>>> from unicodedata import normalize
>>> print(ascii(normalize("NFC", "---\uafb8\u11a7---")))
'---\uafb8\u11a7---'

>>> print(ascii(normalize("NFC", "---\uafb8\u11a7---\U0002f8a1")))
'---\uafb8---\u393a'

----------

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

From report at bugs.python.org  Tue May  3 05:03:41 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 03 May 2016 09:03:41 +0000
Subject: [issue26852] android: add a COMPILEALL_FLAGS Makefile variable
In-Reply-To: <1461674611.23.0.732409522866.issue26852@psf.upfronthosting.co.za>
Message-ID: <1462266221.72.0.896828784709.issue26852@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

The python '-E' option was needed on 3.4 when this patch was first implemented and is not needed anymore at the current tip (changeset 2ef61a4747eb, Apr 27 2016).

New patch.

----------
Added file: http://bugs.python.org/file42690/compileall-flags_2.patch

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

From report at bugs.python.org  Tue May  3 05:07:10 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 May 2016 09:07:10 +0000
Subject: [issue26916] Word duplications in PEPs
In-Reply-To: <1462264605.88.0.73387048167.issue26916@psf.upfronthosting.co.za>
Message-ID: <20160503090705.100786.38829.1B52C6E9@psf.io>


Roundup Robot added the comment:

New changeset d0b969132758 by Serhiy Storchaka in branch 'default':
Issue #26916: Fixed words duplications.
https://hg.python.org/peps/rev/d0b969132758

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

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

From report at bugs.python.org  Tue May  3 05:11:46 2016
From: report at bugs.python.org (Michael Cuthbert)
Date: Tue, 03 May 2016 09:11:46 +0000
Subject: [issue26904] Difflib quick_ratio() could use Counter()
In-Reply-To: <1462163353.47.0.300392305122.issue26904@psf.upfronthosting.co.za>
Message-ID: <1462266706.02.0.0562781672988.issue26904@psf.upfronthosting.co.za>


Michael Cuthbert added the comment:

@wolma -- you're right, that the inplace __iand__ version of Counter is substantially faster -- it is still slower than the current code (since it is still basically a superset of it).  However, testing shows that it is close enough to the current code as to potentially be worth using it, in order to avoid the same issue that arose here (a small speed tweak in this code prevents it from taking advantage of larger improvements later).

If you think that is worth changing, I can make a new patch that incorporates it.  I don't have formal benchmarks on it, but quick tests show a 10% regression from the current speedups to using &= instead of the custom summation method.

----------

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

From report at bugs.python.org  Tue May  3 05:13:45 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 03 May 2016 09:13:45 +0000
Subject: [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: [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:25:45 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 May 2016 09:25:45 +0000
Subject: [issue26917] Inconsistency in unicodedata.normalize()?
In-Reply-To: <1462265307.72.0.382714967199.issue26917@psf.upfronthosting.co.za>
Message-ID: <1462267545.53.0.914258768336.issue26917@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Extract of unicodedata_UCD_normalize_impl():

    if (strcmp(form, "NFC") == 0) {
        if (is_normalized(self, input, 1, 0)) {
            Py_INCREF(input);
            return input;
        }
        return nfc_nfkc(self, input, 0);
    }

is_normalized() is true for "\uafb8\u11a7" but false for "\U0002f8a1" (and also false for "\uafb8\u11a7\U0002f8a1").

unicodedata.normalize("NFC", "\uafb8\u11a7") returns the string unchanged because is_normalized() is true.

unicodedata.normalize("NFD", "\uafb8\u11a7") returns "\u1101\u116e\u11a7": U+afb8 is decomposed to {U+1101, U+116e}.

unicodedata.normalize("NFC", unicodedata.normalize("NFD", "\uafb8\u11a7")) returns "\uafb8", it's the result of the Hangul Decomposition. {U+1101, U+116e, U+11a7} is composed to {U+afb8}.

It may be an issue in the "quickcheck" property of the Python Unicode database. Format of this field:

    /* The two quickcheck bits at this shift mean 0=Yes, 1=Maybe, 2=No,
       as described in http://unicode.org/reports/tr15/#Annex8. */
    quickcheck_mask = 3 << ((nfc ? 4 : 0) + (k ? 2 : 0));

----------

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

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: [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 05:35:40 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 May 2016 09:35:40 +0000
Subject: [issue26917] Inconsistency in unicodedata.normalize()?
In-Reply-To: <1462265307.72.0.382714967199.issue26917@psf.upfronthosting.co.za>
Message-ID: <1462268140.51.0.974105555681.issue26917@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I tested http://minaret.info/test/normalize.msp

(1)

?? (afb8 11a7) --NFC or NFKC--> ?? (afb8, 11a7) === same than python
?? (afb8 11a7) --NFD or NFKD--> ??? (1101 116e, 11a7) === same than python

(2)

??? (1101 116e 11a7) --NFC or NFKC--> ? (afb8) === same than python
??? (1101 116e 11a7) --NFC or NFKC--> ??? (1101 116e, 11a7) === same than python

(3)

??? (afb8 11a7 2f8a1) --NFC or NFKC--> ??? (afb8, 11a7, 393a) == DIFFERENT than python, python eats the U+11a7 character
??? (afb8 11a7 2f8a1) --NFD or NFKD--> ???? (1101 116e, 11a7, 393a) === same than python

----------

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

From report at bugs.python.org  Tue May  3 05:36:18 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 May 2016 09:36:18 +0000
Subject: [issue26917] unicodedata.normalize(): bug in Hangul Composition
In-Reply-To: <1462265307.72.0.382714967199.issue26917@psf.upfronthosting.co.za>
Message-ID: <1462268178.5.0.53651215878.issue26917@psf.upfronthosting.co.za>


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


----------
title: Inconsistency in unicodedata.normalize()? -> unicodedata.normalize(): bug in Hangul Composition

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

From report at bugs.python.org  Tue May  3 06:01:41 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 May 2016 10:01:41 +0000
Subject: [issue26917] unicodedata.normalize(): bug in Hangul Composition
In-Reply-To: <1462265307.72.0.382714967199.issue26917@psf.upfronthosting.co.za>
Message-ID: <1462269701.85.0.753085346225.issue26917@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Extract of nfc_nfkc():

      /* Hangul Composition. We don't need to check for <LV,T>
         pairs, since we always have decomposed data. */
      code = PyUnicode_READ(kind, data, i);
      if (LBase <= code && code < (LBase+LCount) &&
          i + 1 < len &&
          VBase <= PyUnicode_READ(kind, data, i+1) &&
          PyUnicode_READ(kind, data, i+1) <= (VBase+VCount)) {
          int LIndex, VIndex;
          LIndex = code - LBase;
          VIndex = PyUnicode_READ(kind, data, i+1) - VBase;
          code = SBase + (LIndex*VCount+VIndex)*TCount;
          i+=2;
          if (i < len &&
              TBase <= PyUnicode_READ(kind, data, i) &&
              PyUnicode_READ(kind, data, i) <= (TBase+TCount)) {
              code += PyUnicode_READ(kind, data, i)-TBase;
              i++;
          }
          output[o++] = code;
          continue;
      }

With the input string (1101 116e, 11a7), we get:

* LIndex = 1
* VIndex = 13


code = SBase + (LIndex*VCount+VIndex)*TCount + (ch3 - TBase)
= 0xAC00 + (1 * 21 + 13) * 28 + 0
= 0xafb8

Constants:

* LBase = 0x1100, LCount = 19
* VBase = 0x1161, VCount = 21
* TBase = 0x11A7, TCount = 28
* SBase = 0xAC00

The problem is maybe than we used the 3rd character whereas (ch3 - TBase) is equal to 0.

----------

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

From report at bugs.python.org  Tue May  3 06:02:11 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 May 2016 10:02:11 +0000
Subject: [issue26917] unicodedata.normalize(): bug in Hangul Composition
In-Reply-To: <1462265307.72.0.382714967199.issue26917@psf.upfronthosting.co.za>
Message-ID: <1462269731.68.0.194610629093.issue26917@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Attached patch changes Hangul Composition. I'm not sure that it is correct.

----------
keywords: +patch
Added file: http://bugs.python.org/file42691/hangul_composition.patch

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

From report at bugs.python.org  Tue May  3 06:04:53 2016
From: report at bugs.python.org (Michael Cuthbert)
Date: Tue, 03 May 2016 10:04:53 +0000
Subject: [issue26904] Difflib quick_ratio() could use Counter()
In-Reply-To: <1462163353.47.0.300392305122.issue26904@psf.upfronthosting.co.za>
Message-ID: <1462269893.87.0.276317581652.issue26904@psf.upfronthosting.co.za>


Michael Cuthbert added the comment:

Here are the results I obtained along with the test code I used to get the results.  The test code also has a "hybrid" code which I did not propose, but maybe I should have, which uses the old code for very short (but not degenerate) tests and then the new code for larger tests.  It does add code complexity however.

Results: 

SpeedResult(wordLen=0, tests=1000001, cached=True, oldNew='old', time='1.22 ?sec')
SpeedResult(wordLen=0, tests=1000001, cached=True, oldNew='new', time='525 nsec')
SpeedResult(wordLen=0, tests=1000001, cached=True, oldNew='hybrid', time='522 nsec')
SpeedResult(wordLen=0, tests=1000001, cached=False, oldNew='old', time='1.78 ?sec')
SpeedResult(wordLen=0, tests=1000001, cached=False, oldNew='new', time='605 nsec')
SpeedResult(wordLen=0, tests=1000001, cached=False, oldNew='hybrid', time='617 nsec')
SpeedResult(wordLen=1, tests=500001, cached=True, oldNew='old', time='1.76 ?sec')
SpeedResult(wordLen=1, tests=500001, cached=True, oldNew='new', time='11.4 ?sec')
SpeedResult(wordLen=1, tests=500001, cached=True, oldNew='hybrid', time='2.64 ?sec')
SpeedResult(wordLen=1, tests=500001, cached=False, oldNew='old', time='3.07 ?sec')
SpeedResult(wordLen=1, tests=500001, cached=False, oldNew='new', time='19.6 ?sec')
SpeedResult(wordLen=1, tests=500001, cached=False, oldNew='hybrid', time='3.9 ?sec')
SpeedResult(wordLen=5, tests=166667, cached=True, oldNew='old', time='3.2 ?sec')
SpeedResult(wordLen=5, tests=166667, cached=True, oldNew='new', time='14.4 ?sec')
SpeedResult(wordLen=5, tests=166667, cached=True, oldNew='hybrid', time='3.98 ?sec')
SpeedResult(wordLen=5, tests=166667, cached=False, oldNew='old', time='5.16 ?sec')
SpeedResult(wordLen=5, tests=166667, cached=False, oldNew='new', time='21.8 ?sec')
SpeedResult(wordLen=5, tests=166667, cached=False, oldNew='hybrid', time='6.14 ?sec')
SpeedResult(wordLen=20, tests=47620, cached=True, oldNew='old', time='9.01 ?sec')
SpeedResult(wordLen=20, tests=47620, cached=True, oldNew='new', time='22.4 ?sec')
SpeedResult(wordLen=20, tests=47620, cached=True, oldNew='hybrid', time='9.79 ?sec')
SpeedResult(wordLen=20, tests=47620, cached=False, oldNew='old', time='14.2 ?sec')
SpeedResult(wordLen=20, tests=47620, cached=False, oldNew='new', time='32.2 ?sec')
SpeedResult(wordLen=20, tests=47620, cached=False, oldNew='hybrid', time='15.8 ?sec')
SpeedResult(wordLen=60, tests=16394, cached=True, oldNew='old', time='22.2 ?sec')
SpeedResult(wordLen=60, tests=16394, cached=True, oldNew='new', time='34.9 ?sec')
SpeedResult(wordLen=60, tests=16394, cached=True, oldNew='hybrid', time='35.9 ?sec')
SpeedResult(wordLen=60, tests=16394, cached=False, oldNew='old', time='39.4 ?sec')
SpeedResult(wordLen=60, tests=16394, cached=False, oldNew='new', time='51.9 ?sec')
SpeedResult(wordLen=60, tests=16394, cached=False, oldNew='hybrid', time='50.7 ?sec')
SpeedResult(wordLen=200, tests=4976, cached=True, oldNew='old', time='68.8 ?sec')
SpeedResult(wordLen=200, tests=4976, cached=True, oldNew='new', time='55.8 ?sec')
SpeedResult(wordLen=200, tests=4976, cached=True, oldNew='hybrid', time='54.9 ?sec')
SpeedResult(wordLen=200, tests=4976, cached=False, oldNew='old', time='116 ?sec')
SpeedResult(wordLen=200, tests=4976, cached=False, oldNew='new', time='75.4 ?sec')
SpeedResult(wordLen=200, tests=4976, cached=False, oldNew='hybrid', time='76.6 ?sec')
SpeedResult(wordLen=1000, tests=1000, cached=True, oldNew='old', time='320 ?sec')
SpeedResult(wordLen=1000, tests=1000, cached=True, oldNew='new', time='109 ?sec')
SpeedResult(wordLen=1000, tests=1000, cached=True, oldNew='hybrid', time='111 ?sec')
SpeedResult(wordLen=1000, tests=1000, cached=False, oldNew='old', time='529 ?sec')
SpeedResult(wordLen=1000, tests=1000, cached=False, oldNew='new', time='183 ?sec')
SpeedResult(wordLen=1000, tests=1000, cached=False, oldNew='hybrid', time='175 ?sec')
SpeedResult(wordLen=10000, tests=100, cached=True, oldNew='old', time='3.15 msec')
SpeedResult(wordLen=10000, tests=100, cached=True, oldNew='new', time='651 ?sec')
SpeedResult(wordLen=10000, tests=100, cached=True, oldNew='hybrid', time='673 ?sec')
SpeedResult(wordLen=10000, tests=100, cached=False, oldNew='old', time='5.18 msec')
SpeedResult(wordLen=10000, tests=100, cached=False, oldNew='new', time='1.25 msec')
SpeedResult(wordLen=10000, tests=100, cached=False, oldNew='hybrid', time='1.24 msec')
SpeedResult(wordLen=100000, tests=10, cached=True, oldNew='old', time='33.8 msec')
SpeedResult(wordLen=100000, tests=10, cached=True, oldNew='new', time='8.35 msec')
SpeedResult(wordLen=100000, tests=10, cached=True, oldNew='hybrid', time='8.33 msec')
SpeedResult(wordLen=100000, tests=10, cached=False, oldNew='old', time='53.3 msec')
SpeedResult(wordLen=100000, tests=10, cached=False, oldNew='new', time='15.2 msec')
SpeedResult(wordLen=100000, tests=10, cached=False, oldNew='hybrid', time='15.3 msec')
SpeedResult(wordLen=1000000, tests=1, cached=True, oldNew='old', time='551 msec')
SpeedResult(wordLen=1000000, tests=1, cached=True, oldNew='new', time='168 msec')
SpeedResult(wordLen=1000000, tests=1, cached=True, oldNew='hybrid', time='158 msec')
SpeedResult(wordLen=10000000, tests=1, cached=True, oldNew='old', time='5.48 sec')
SpeedResult(wordLen=10000000, tests=1, cached=True, oldNew='new', time='1.61 sec')
SpeedResult(wordLen=10000000, tests=1, cached=True, oldNew='hybrid', time='1.62 sec')

----------
Added file: http://bugs.python.org/file42692/fasterDifflib.py

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

From report at bugs.python.org  Tue May  3 06:22:19 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 May 2016 10:22:19 +0000
Subject: [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 06:29:22 2016
From: report at bugs.python.org (Armin Rigo)
Date: Tue, 03 May 2016 10:29:22 +0000
Subject: [issue26917] unicodedata.normalize(): bug in Hangul Composition
In-Reply-To: <1462265307.72.0.382714967199.issue26917@psf.upfronthosting.co.za>
Message-ID: <1462271362.88.0.721035930399.issue26917@psf.upfronthosting.co.za>


Armin Rigo added the comment:

See also https://bitbucket.org/pypy/pypy/issues/2289/incorrect-unicode-normalization .  It seems that you reached the same conclusion than the OP in that issue: the problem would really be that normalizing "\uafb8\u11a7" should not drop the second character.  Both Python and PyPy do that, but Python adds the "is_normalized()" check, so in some cases it returns the correct unmodified result.

----------

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

From report at bugs.python.org  Tue May  3 06:42:45 2016
From: report at bugs.python.org (Ned Batchelder)
Date: Tue, 03 May 2016 10:42:45 +0000
Subject: [issue26914] Fix formatting of lists in PEP 420
In-Reply-To: <1462229844.3.0.0802177041097.issue26914@psf.upfronthosting.co.za>
Message-ID: <1462272165.7.0.865567591099.issue26914@psf.upfronthosting.co.za>


Ned Batchelder added the comment:

Unless I have permissions I've never used, I don't think I can just push fixes to the peps repo. Also, it looks like Georg is working away at it!

----------

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

From report at bugs.python.org  Tue May  3 06:46:03 2016
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 03 May 2016 10:46:03 +0000
Subject: [issue26921] Incorrect usage of a/an articles in PEPs
In-Reply-To: <1462270938.38.0.294058819503.issue26921@psf.upfronthosting.co.za>
Message-ID: <1462272363.33.0.584579591795.issue26921@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Also LGTM.  It's easy to spot PEPs written by French people :)

----------

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

From report at bugs.python.org  Tue May  3 06:47:41 2016
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 03 May 2016 10:47:41 +0000
Subject: [issue26914] Fix formatting of lists in PEP 420
In-Reply-To: <1462229844.3.0.0802177041097.issue26914@psf.upfronthosting.co.za>
Message-ID: <1462272461.95.0.598068728657.issue26914@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Yep, they should all be gone. I tried to make sure by running the sources through docutils and finding nested <blockquote><foo_list> nodes.

----------

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

From report at bugs.python.org  Tue May  3 06:52:39 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 May 2016 10:52:39 +0000
Subject: [issue26921] Incorrect usage of a/an articles in PEPs
In-Reply-To: <1462270938.38.0.294058819503.issue26921@psf.upfronthosting.co.za>
Message-ID: <20160503105234.100806.1068.0E7E1C4C@psf.io>


Roundup Robot added the comment:

New changeset d617c7ba4e14 by Serhiy Storchaka in branch 'default':
Issue #26921: Fixed a/an articles.
https://hg.python.org/peps/rev/d617c7ba4e14

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

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

From report at bugs.python.org  Tue May  3 06:53:07 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 May 2016 10:53:07 +0000
Subject: [issue26916] Word duplications in PEPs
In-Reply-To: <1462264605.88.0.73387048167.issue26916@psf.upfronthosting.co.za>
Message-ID: <1462272787.26.0.502820578729.issue26916@psf.upfronthosting.co.za>


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


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

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

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


Serhiy Storchaka added the comment:

Thank you for reviews Georg.

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

_______________________________________
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: [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:21:05 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 May 2016 12:21:05 +0000
Subject: [issue26922] build from fresh checkout fails
In-Reply-To: <1462278034.88.0.00181655793676.issue26922@psf.upfronthosting.co.za>
Message-ID: <1462278065.68.0.449156022442.issue26922@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

$ cat /etc/os-release 
NAME="Ubuntu"
VERSION="15.04 (Vivid Vervet)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 15.04"
VERSION_ID="15.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"

----------

_______________________________________
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: [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:05:56 2016
From: report at bugs.python.org (Thomas Kluyver)
Date: Tue, 03 May 2016 13:05:56 +0000
Subject: [issue26039] More flexibility in zipfile write interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <1462280756.33.0.124616552676.issue26039@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

Any further review comments on this?

----------

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

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: [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:44:21 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 03 May 2016 13:44:21 +0000
Subject: [issue26923] asyncio.gather drops cancellation
In-Reply-To: <1462279806.1.0.880381545595.issue26923@psf.upfronthosting.co.za>
Message-ID: <1462283061.74.0.0815977154142.issue26923@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The doc:
https://docs.python.org/dev/library/asyncio-task.html#asyncio.gather
"Cancellation: if the outer Future is cancelled, all children (that have not completed yet) are also cancelled. If any child is cancelled, this is treated as if it raised CancelledError ? the outer Future is not cancelled in this case. (This is to prevent the cancellation of one child to cause other children to be cancelled.)"

(Sorry, I didn't read your issue yet.)

----------

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

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: [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:49:35 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 03 May 2016 13:49:35 +0000
Subject: [issue26925] android: test_multiprocessing_main_handling fails
In-Reply-To: <1462283212.06.0.365791110432.issue26925@psf.upfronthosting.co.za>
Message-ID: <1462283375.05.0.260879783264.issue26925@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

This seems to be related to issue #26924.

----------

_______________________________________
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: [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: [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:02:54 2016
From: report at bugs.python.org (Johannes Ebke)
Date: Tue, 03 May 2016 14:02:54 +0000
Subject: [issue26923] asyncio.gather drops cancellation
In-Reply-To: <1462279806.1.0.880381545595.issue26923@psf.upfronthosting.co.za>
Message-ID: <1462284174.46.0.233483858699.issue26923@psf.upfronthosting.co.za>


Johannes Ebke added the comment:

Thank you for providing the relevant documentation link.

I just noticed that it should probably be clarified that in case the outer Future is cancelled, and all children that are not already done ignore the cancellation (a.k.a. catch the CancelledError), the cancellation of the outer Future does not continue.

This is different to the behaviour of asyncio.wait_for, which always raises a CancelledError.

----------

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

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: [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: [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:15:53 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 May 2016 14:15:53 +0000
Subject: [issue26906] format(object.__reduce__) fails intermittently
In-Reply-To: <1462194444.45.0.679859267338.issue26906@psf.upfronthosting.co.za>
Message-ID: <1462284953.37.0.912852453483.issue26906@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There is similar issue on 3.x:

>>> import array
>>> it = iter(array.array('i'))
>>> format(it)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Type arrayiterator doesn't define __format__
>>> type(it).__format__
<method '__format__' of 'object' objects>
>>> format(it)
'<arrayiterator object at 0xb703f4ec>'

----------
versions: +Python 3.5, Python 3.6

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

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: [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: [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: [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: [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: [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:21 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 03 May 2016 15:03:21 +0000
Subject: [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: [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: [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:26:15 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 May 2016 15:26:15 +0000
Subject: [issue26933] android: test_posixpath fails
In-Reply-To: <1462287047.8.0.736502543167.issue26933@psf.upfronthosting.co.za>
Message-ID: <1462289175.83.0.717204678952.issue26933@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is a duplicate of issue24950.

----------
nosy: +serhiy.storchaka
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> FAIL: test_expanduser when $HOME=/

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

From report at bugs.python.org  Tue May  3 11:26:28 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 May 2016 15:26:28 +0000
Subject: [issue24950] FAIL: test_expanduser when $HOME=/
In-Reply-To: <1440732506.26.0.0296213798936.issue24950@psf.upfronthosting.co.za>
Message-ID: <1462289188.35.0.610098906964.issue24950@psf.upfronthosting.co.za>


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


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

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

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: [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:33:39 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 03 May 2016 15:33:39 +0000
Subject: [issue26922] build from fresh checkout fails
In-Reply-To: <1462278034.88.0.00181655793676.issue26922@psf.upfronthosting.co.za>
Message-ID: <1462289619.28.0.900334777077.issue26922@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Note this is a data point of how obscure and hard to debug the current early startup phase is :-)

----------
nosy: +ncoghlan

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

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: [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: [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: [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: [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  Tue May  3 12:03:22 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 03 May 2016 16:03:22 +0000
Subject: [issue26537] ConfigParser has optionxform, but not sectionxform
In-Reply-To: <1457678417.52.0.410667040467.issue26537@psf.upfronthosting.co.za>
Message-ID: <1462291402.03.0.215332498835.issue26537@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue May  3 12:04:59 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 03 May 2016 16:04:59 +0000
Subject: [issue26865] Meta-issue: support of the android platform
In-Reply-To: <1461685011.99.0.617135447086.issue26865@psf.upfronthosting.co.za>
Message-ID: <1462291499.6.0.0196355613619.issue26865@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

All the dependencies of this issue are tagged with Components:Cross-Build and a title starting with 'android'.

Tests that fail on an android emulator running an x86 system image at API level 21:

  issue #26918: android: test_pipes fails
  issue #26919: android: test_cmd_line fails
  issue #26920: android: test_sys fails
  issue #26924: android: test_concurrent_futures fails
  issue #26925: android: test_multiprocessing_main_handling fails
  issue #26926: android: test_io fails
  issue #26927: android: test_mmap fails
  issue #26928: android: test_site fails
  issue #26929: android: test_strptime fails
  issue #26931: android: test_distutils fails
  issue #26932: android: test_posix fails
  issue #26933: android: test_posixpath fails
  issue #26934: android: test_faulthandler fails
  issue #26935: android: test_os fails
  issue #26936: android: test_socket fails
  issue #26937: android: test_tarfile fails

Tests that fail on an android emulator running an armv7 system image (but not fail on x86) at API level 21:

  issue #26938: android: test_concurrent_futures hangs on armv7
  issue #26939: android: test_functools hangs on armv7
  issue #26940: android: test_importlib hangs on armv7
  issue #26941: android: test_threading hangs on armv7
  issue #26942: android: test_ctypes crashes on armv7

----------

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

From report at bugs.python.org  Tue May  3 12:09:18 2016
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 03 May 2016 16:09:18 +0000
Subject: [issue26922] build from fresh checkout fails
In-Reply-To: <1462278034.88.0.00181655793676.issue26922@psf.upfronthosting.co.za>
Message-ID: <1462291758.41.0.845692276891.issue26922@psf.upfronthosting.co.za>


Brett Cannon added the comment:

That exception usually stems from when importlib.h has an error in it.

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

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

From report at bugs.python.org  Tue May  3 12:10:45 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 03 May 2016 16:10:45 +0000
Subject: [issue26933] android: test_posixpath fails
In-Reply-To: <1462287047.8.0.736502543167.issue26933@psf.upfronthosting.co.za>
Message-ID: <1462291845.35.0.233452690207.issue26933@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

That was fast!
Thanks Serhiy.

----------

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

From report at bugs.python.org  Tue May  3 12:59:32 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 03 May 2016 16:59:32 +0000
Subject: [issue26696] Document collections.abc.ByteString
In-Reply-To: <1459881544.79.0.834895685887.issue26696@psf.upfronthosting.co.za>
Message-ID: <1462294772.5.0.523905891428.issue26696@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue May  3 13:30:39 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 May 2016 17:30:39 +0000
Subject: [issue26933] android: test_posixpath fails
In-Reply-To: <1462287047.8.0.736502543167.issue26933@psf.upfronthosting.co.za>
Message-ID: <1462296639.29.0.0802655333509.issue26933@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I'll push a patch for issue24950 in short time.

Try to search precedences for other your issues. May be they have patches, additional information or experienced people.

----------

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

From report at bugs.python.org  Tue May  3 13:52:43 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 03 May 2016 17:52:43 +0000
Subject: [issue26933] android: test_posixpath fails
In-Reply-To: <1462287047.8.0.736502543167.issue26933@psf.upfronthosting.co.za>
Message-ID: <1462297963.11.0.830990259.issue26933@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

You are right. I will do that.

----------

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

From report at bugs.python.org  Tue May  3 14:10:46 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 May 2016 18:10:46 +0000
Subject: [issue24950] FAIL: test_expanduser when $HOME=/
In-Reply-To: <1440732506.26.0.0296213798936.issue24950@psf.upfronthosting.co.za>
Message-ID: <1462299046.89.0.288509246288.issue24950@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Yet one corner case is empty HOME value.

----------

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

From report at bugs.python.org  Tue May  3 14:19:06 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 03 May 2016 18:19:06 +0000
Subject: [issue24950] FAIL: test_expanduser when $HOME=/
In-Reply-To: <1440732506.26.0.0296213798936.issue24950@psf.upfronthosting.co.za>
Message-ID: <20160503181900.31605.65206.2C030FC9@psf.io>


Roundup Robot added the comment:

New changeset 194b356c84f5 by Serhiy Storchaka in branch '3.5':
Issue #24950: Fixed expanduser tests when the users home directory in pwd is "/".
https://hg.python.org/cpython/rev/194b356c84f5

New changeset b9b99cb85a5f by Serhiy Storchaka in branch 'default':
Issue #24950: Fixed expanduser tests when the users home directory in pwd is "/".
https://hg.python.org/cpython/rev/b9b99cb85a5f

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

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

From report at bugs.python.org  Tue May  3 14:47:51 2016
From: report at bugs.python.org (Jason R. Coombs)
Date: Tue, 03 May 2016 18:47:51 +0000
Subject: [issue20120] Percent-signs (%) in .pypirc should not be interpolated
In-Reply-To: <1388825675.42.0.435893533792.issue20120@psf.upfronthosting.co.za>
Message-ID: <1462301271.25.0.615856212265.issue20120@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

?ukasz, my proposal was to also update distutils (in all Python versions that get bugfixes) to match the Setuptools behavior and Python 2 behavior. I'd still like to do that to harmonize the implementations.

----------

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

From report at bugs.python.org  Tue May  3 14:50:05 2016
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Tue, 03 May 2016 18:50:05 +0000
Subject: [issue20120] Percent-signs (%) in .pypirc should not be interpolated
In-Reply-To: <1388825675.42.0.435893533792.issue20120@psf.upfronthosting.co.za>
Message-ID: <1462301405.23.0.867401547824.issue20120@psf.upfronthosting.co.za>


?ukasz Langa added the comment:

Oh, my bad. Yeah, that sounds like a worthwhile change.

----------
resolution: not a bug -> 
status: closed -> open

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

From report at bugs.python.org  Tue May  3 14:50:29 2016
From: report at bugs.python.org (Steve Dower)
Date: Tue, 03 May 2016 18:50:29 +0000
Subject: [issue26876] Extend MSVCCompiler class to respect environment
 variables
In-Reply-To: <1461866719.82.0.2605655084.issue26876@psf.upfronthosting.co.za>
Message-ID: <1462301429.76.0.682544432056.issue26876@psf.upfronthosting.co.za>


Steve Dower added the comment:

I was thinking more like this:

if DISTUTILS_USE_SDK:
    assume PATH is configured
    execute os.getenv("CC", "cl.exe") directly
else:
    find VS in the registry
    execute "cl.exe" etc.

The only change here from the current situation is preferring the CC variable in the former case when it is set. When we look up VS in the registry, we know what executable we are going to find and overriding them via the environment is only going to cause issues/vulnerabilities.

----------

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

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


Xavier de Gaye added the comment:

The attached test_output.txt file is the corresponding gdb backtrace[1].

Interestingly, all the tests (issues #26938, #26939, #26940 and #26941) that hang on arm use sys.setswitchinterval() aggressively.


[1] The backtrace is interleaved with:
  * Python Exception <type 'exceptions.UnicodeDecodeError'> 'utf8' codec can't decode byte 0xb8 in posit ion 0: invalid start byte:
    that seem to come from libpython, the python that is embeded in gdb to pretty-print gdb output
  * ---Type <return> to continue, or q <return> to quit---
    sorry, had to resort to copy/paste, gdb 'set logging' does not seem to work

----------
Added file: http://bugs.python.org/file42701/test_output.txt

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

From report at bugs.python.org  Tue May  3 15:08:54 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 May 2016 19:08:54 +0000
Subject: [issue24950] FAIL: test_expanduser when $HOME=/
In-Reply-To: <1440732506.26.0.0296213798936.issue24950@psf.upfronthosting.co.za>
Message-ID: <1462302534.55.0.334413468835.issue24950@psf.upfronthosting.co.za>


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


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

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

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


Xavier de Gaye added the comment:

Interestingly, all the tests (issues #26938, #26939, #26940 and #26941) that hang on arm use sys.setswitchinterval() aggressively.

----------

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

From report at bugs.python.org  Tue May  3 15:10:58 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 03 May 2016 19:10:58 +0000
Subject: [issue26940] android: test_importlib hangs on armv7
In-Reply-To: <1462290134.16.0.615698223309.issue26940@psf.upfronthosting.co.za>
Message-ID: <1462302658.73.0.916378403605.issue26940@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Interestingly, all the tests (issues #26938, #26939, #26940 and #26941) that hang on arm use sys.setswitchinterval() aggressively.

----------

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

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


Xavier de Gaye added the comment:

Interestingly, all the tests (issues #26938, #26939, #26940 and #26941) that hang on arm use sys.setswitchinterval() aggressively.

----------

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

From report at bugs.python.org  Tue May  3 15:41:56 2016
From: report at bugs.python.org (Geoffrey Sneddon)
Date: Tue, 03 May 2016 19:41:56 +0000
Subject: [issue17909] Autodetecting JSON encoding
In-Reply-To: <1367759430.76.0.988181674037.issue17909@psf.upfronthosting.co.za>
Message-ID: <1462304516.41.0.509803077209.issue17909@psf.upfronthosting.co.za>


Changes by Geoffrey Sneddon <geoffers+pythonbugs at gmail.com>:


----------
nosy: +gsnedders

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

From report at bugs.python.org  Tue May  3 15:47:23 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Tue, 03 May 2016 19:47:23 +0000
Subject: [issue26039] More flexibility in zipfile write interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <1462304843.85.0.477602130274.issue26039@psf.upfronthosting.co.za>


Changes by ???? ????????? <socketpair at gmail.com>:


----------
nosy:  -mmarkk

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

From report at bugs.python.org  Tue May  3 15:53:12 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 May 2016 19:53:12 +0000
Subject: [issue26929] android: test_strptime fails
In-Reply-To: <1462284711.76.0.324696843297.issue26929@psf.upfronthosting.co.za>
Message-ID: <1462305192.65.0.171880788906.issue26929@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

What is the output of following code?

import datetime
for i in range(1, 10):
    print(datetime.date(1905, 1, i).strftime('%Y %U %w   %G %V %u'))

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

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

From report at bugs.python.org  Tue May  3 16:02:55 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 03 May 2016 20:02:55 +0000
Subject: [issue26929] android: test_strptime fails
In-Reply-To: <1462284711.76.0.324696843297.issue26929@psf.upfronthosting.co.za>
Message-ID: <1462305775.4.0.647984349223.issue26929@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

root at generic_x86:/data/local/tmp # python
Python 3.6.0a0 (default:f4c6dab59cd8+, May  3 2016, 21:59:47) 
[GCC 4.9 20140827 (prerelease)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import datetime
>>> for i in range(1, 10):
...   print(datetime.date(1905, 1, i).strftime('%Y %U %w   %G %V %u'))
... 
1905 01 0   1904 53 7
1905 01 1   1905 01 1
1905 01 2   1905 01 2
1905 01 3   1905 01 3
1905 01 4   1905 01 4
1905 01 5   1905 01 5
1905 01 6   1905 01 6
1905 02 0   1905 01 7
1905 02 1   1905 02 1
>>>

----------

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

From report at bugs.python.org  Tue May  3 16:13:14 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 May 2016 20:13:14 +0000
Subject: [issue26929] android: test_strptime fails
In-Reply-To: <1462284711.76.0.324696843297.issue26929@psf.upfronthosting.co.za>
Message-ID: <1462306394.88.0.2993788444.issue26929@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thanks. And what is the output of following code?

for i in range(25, 32):
    print(datetime.date(1904, 12, i).strftime('%Y %U %w   %G %V %u'))

----------

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

From report at bugs.python.org  Tue May  3 16:21:15 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 03 May 2016 20:21:15 +0000
Subject: [issue26929] android: test_strptime fails
In-Reply-To: <1462284711.76.0.324696843297.issue26929@psf.upfronthosting.co.za>
Message-ID: <1462306875.55.0.787697969763.issue26929@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

>>> for i in range(25, 32):
...   print(datetime.date(1904, 12, i).strftime('%Y %U %w   %G %V %u'))
... 
1904 52 0   1904 51 7
1904 52 1   1904 52 1
1904 52 2   1904 52 2
1904 52 3   1904 52 3
1904 52 4   1904 52 4
1904 52 5   1904 52 5
1904 52 6   1904 52 6
>>>

----------

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

From report at bugs.python.org  Tue May  3 16:30:22 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Tue, 03 May 2016 20:30:22 +0000
Subject: [issue26915] Test identity first in membership operation of ItemsView, 
 ValuesView and Sequence in collections.abc
In-Reply-To: <1462256356.96.0.954300432794.issue26915@psf.upfronthosting.co.za>
Message-ID: <1462307422.39.0.966758020958.issue26915@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

At some point someone really needs to decide if the C layer behavior of performing an identity test before full equality checking is something that should be emulated at the Python layer or not. The current state seems ridiculous, where C containers check identity first simply by using the easier RichCompareBool function, while Python containers have to have the identity-then-equality check rewritten explicitly, which feels like a DRY violation.

Makes it harder for non-CPython implementations too, since they end up either not matching CPython behavior, or writing extra code to match the CPython quirks.

I have nothing against this patch, but between PyObject_RichCompareBool and the various slightly strange behaviors in the argument parsing format codes (which leads to silly workarounds like _check_int_field in #20858), I feel like the Python code base is getting cluttered with hacks to emulate the hacky C layer.

----------
nosy: +josh.r

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

From report at bugs.python.org  Tue May  3 16:34:23 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 May 2016 20:34:23 +0000
Subject: [issue26929] android: test_strptime fails
In-Reply-To: <1462284711.76.0.324696843297.issue26929@psf.upfronthosting.co.za>
Message-ID: <1462307663.3.0.148192674445.issue26929@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thus there is a gap between 1904-12-31 and 1905-1-1. This is a bug in strftime() on Android.

----------

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

From report at bugs.python.org  Tue May  3 16:40:36 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Tue, 03 May 2016 20:40:36 +0000
Subject: [issue26219] implement per-opcode cache in ceval
In-Reply-To: <1453918500.26.0.0886095278127.issue26219@psf.upfronthosting.co.za>
Message-ID: <1462308036.13.0.300068579991.issue26219@psf.upfronthosting.co.za>


Changes by Josh Rosenberg <shadowranger+python at gmail.com>:


----------
nosy: +josh.r

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

From report at bugs.python.org  Tue May  3 16:40:54 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Tue, 03 May 2016 20:40:54 +0000
Subject: [issue26110] Speedup method calls 1.2x
In-Reply-To: <1452791347.05.0.923215900831.issue26110@psf.upfronthosting.co.za>
Message-ID: <1462308054.24.0.172820562516.issue26110@psf.upfronthosting.co.za>


Changes by Josh Rosenberg <shadowranger+python at gmail.com>:


----------
nosy: +josh.r

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

From report at bugs.python.org  Tue May  3 16:48:39 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 May 2016 20:48:39 +0000
Subject: [issue26915] Test identity first in membership operation of ItemsView, 
 ValuesView and Sequence in collections.abc
In-Reply-To: <1462256356.96.0.954300432794.issue26915@psf.upfronthosting.co.za>
Message-ID: <1462308519.5.0.21317760374.issue26915@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue May  3 16:49:45 2016
From: report at bugs.python.org (Andy Edwards)
Date: Tue, 03 May 2016 20:49:45 +0000
Subject: [issue23003] traceback.{print_exc, print_exception, format_exc,
 format_exception}: Potential AttributeError
In-Reply-To: <1417909047.64.0.652633919593.issue23003@psf.upfronthosting.co.za>
Message-ID: <1462308585.18.0.332928320687.issue23003@psf.upfronthosting.co.za>


Andy Edwards added the comment:

I'm seeing this issue in Python 2.7....

Andys-MacBook-Pro:jcore-api-py andy$ which python
/Library/Frameworks/Python.framework/Versions/2.7/bin/python
Andys-MacBook-Pro:jcore-api-py andy$ python setup.py test
running test
running egg_info
writing requirements to jcore_api.egg-info/requires.txt
writing jcore_api.egg-info/PKG-INFO
writing top-level names to jcore_api.egg-info/top_level.txt
writing dependency_links to jcore_api.egg-info/dependency_links.txt
reading manifest file 'jcore_api.egg-info/SOURCES.txt'
writing manifest file 'jcore_api.egg-info/SOURCES.txt'
running build_ext
.....................
----------------------------------------------------------------------
Ran 21 tests in 3.423s

OK
Andys-MacBook-Pro:jcore-api-py andy$ python setup.py test
running test
running egg_info
writing requirements to jcore_api.egg-info/requires.txt
writing jcore_api.egg-info/PKG-INFO
writing top-level names to jcore_api.egg-info/top_level.txt
writing dependency_links to jcore_api.egg-info/dependency_links.txt
reading manifest file 'jcore_api.egg-info/SOURCES.txt'
writing manifest file 'jcore_api.egg-info/SOURCES.txt'
running build_ext
.....................
----------------------------------------------------------------------
Ran 21 tests in 3.422s

OK
Exception in thread jcore.io receiver:
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 801, in __bootstrap_inner
    self.run()
  File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/threading.py", line 754, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/Users/andy/jcore-api-py/jcore_api/_connection.py", line 104, in _run_recv_thread
    traceback.print_exc()
AttributeError: 'NoneType' object has no attribute 'print_exc'

----------
nosy: +jedwards1211

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

From report at bugs.python.org  Tue May  3 17:05:46 2016
From: report at bugs.python.org (Yih-En Andrew Ban)
Date: Tue, 03 May 2016 21:05:46 +0000
Subject: [issue26812] ExtendedInterpolation drops user-defined 'vars' during
 _interpolate_some() recursion
In-Reply-To: <1461212839.44.0.193061483216.issue26812@psf.upfronthosting.co.za>
Message-ID: <1462309546.48.0.744893316297.issue26812@psf.upfronthosting.co.za>


Yih-En Andrew Ban added the comment:

Sure, patch attached.

----------
keywords: +patch
Added file: http://bugs.python.org/file42702/issue26812.patch

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

From report at bugs.python.org  Tue May  3 17:08:28 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 03 May 2016 21:08:28 +0000
Subject: [issue26929] android: test_strptime fails
In-Reply-To: <1462284711.76.0.324696843297.issue26929@psf.upfronthosting.co.za>
Message-ID: <1462309708.28.0.406831463479.issue26929@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

GNU libc says:

     ?%V?
          The ISO 8601:1988 week number as a decimal number (range ?01?
          through ?53?).  ISO weeks start with Monday and end with
          Sunday.  Week ?01? of a year is the first week which has the
          majority of its days in that year; this is equivalent to the
          week containing the year?s first Thursday, and it is also
          equivalent to the week containing January 4.  Week ?01? of a
          year can contain days from the previous year.  The week before
          week ?01? of a year is the last week (?52? or ?53?) of the
          previous year even if it contains days from the new year.

          This format was first standardized by POSIX.2-1992 and by
          ISO C99.


So on 1905-1-1, %V should be 52 instead of 53 as printed by android; is this the only bug ?

A pretty good test to find such a mistake.

----------

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

From report at bugs.python.org  Tue May  3 17:27:26 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 May 2016 21:27:26 +0000
Subject: [issue26929] android: test_strptime fails
In-Reply-To: <1462284711.76.0.324696843297.issue26929@psf.upfronthosting.co.za>
Message-ID: <1462310846.88.0.430344550009.issue26929@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There is other bug at the last week of a year:

import datetime
for i in range(25, 32):
    print(datetime.date(1906, 12, i).strftime('%Y %U %w   %G %V %u'))

for i in range(1, 10):
    print(datetime.date(1907, 1, i).strftime('%Y %U %w   %G %V %u'))

----------

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

From report at bugs.python.org  Tue May  3 17:32:06 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 May 2016 21:32:06 +0000
Subject: [issue26926] android: test_io fails
In-Reply-To: <1462283737.14.0.888848894928.issue26926@psf.upfronthosting.co.za>
Message-ID: <1462311126.73.0.0104195992183.issue26926@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This looks similar to issue11184.

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

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

From report at bugs.python.org  Tue May  3 17:35:48 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 May 2016 21:35:48 +0000
Subject: [issue26927] android: test_mmap fails
In-Reply-To: <1462284033.57.0.466364918672.issue26927@psf.upfronthosting.co.za>
Message-ID: <1462311348.02.0.830606130676.issue26927@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is other manifestation of issue26926.

----------
nosy: +serhiy.storchaka
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> android: test_io fails

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

From report at bugs.python.org  Tue May  3 17:54:30 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 03 May 2016 21:54:30 +0000
Subject: [issue26932] android: test_posix fails
In-Reply-To: <1462286644.76.0.342167409924.issue26932@psf.upfronthosting.co.za>
Message-ID: <1462312470.98.0.825014907085.issue26932@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

What RTLD_* constants exist on Android?

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

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

From report at bugs.python.org  Tue May  3 22:34:20 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 04 May 2016 02:34:20 +0000
Subject: [issue26915] Test identity first in membership operation of ItemsView, 
 ValuesView and Sequence in collections.abc
In-Reply-To: <1462256356.96.0.954300432794.issue26915@psf.upfronthosting.co.za>
Message-ID: <1462329260.22.0.625333388237.issue26915@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

I agree with you josh. Actually that's what I want to know, consistency. But I don't mention it in my post, so Guido only gives what to do in this case. In this thread, it means does Python code have to keep the invariant mentioned in msg75735?

----------

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

From report at bugs.python.org  Tue May  3 22:54:00 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Wed, 04 May 2016 02:54:00 +0000
Subject: [issue26932] android: test_posix fails
In-Reply-To: <1462286644.76.0.342167409924.issue26932@psf.upfronthosting.co.za>
Message-ID: <1462330440.65.0.809144863752.issue26932@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

On Android RTLD_* constants are not defined via macros but as enum values. I guess CPython needs to check each one in configure.ac. See [1]

[1] https://android.googlesource.com/platform/bionic/+/master/libc/include/dlfcn.h

----------
nosy: +Chi Hsuan Yen

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

From report at bugs.python.org  Tue May  3 23:10:18 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 04 May 2016 03:10:18 +0000
Subject: [issue26922] build from fresh checkout fails
In-Reply-To: <1462278034.88.0.00181655793676.issue26922@psf.upfronthosting.co.za>
Message-ID: <1462331418.85.0.58993964403.issue26922@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Even updating from remote, and then making a fresh clone in a new directory, I can't reproduce this one - "./configure && make -j4" works for me.

Does strace give any potentially useful hints?

For me:

    $ strace -e trace=file ./python -c "pass"

the apparently relevant part of the strace output looks like:

open("/home/ncoghlan/devel/cpython-pristine/pyvenv.cfg", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/home/ncoghlan/devel/pyvenv.cfg", O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/home/ncoghlan/devel/cpython-pristine/Modules/Setup", {st_mode=S_IFREG|0664, st_size=15129, ...}) = 0
stat("/home/ncoghlan/devel/cpython-pristine/Lib/os.py", {st_mode=S_IFREG|0664, st_size=37715, ...}) = 0
stat("/home/ncoghlan/devel/cpython-pristine/pybuilddir.txt", {st_mode=S_IFREG|0664, st_size=26, ...}) = 0
open("/home/ncoghlan/devel/cpython-pristine/pybuilddir.txt", O_RDONLY) = 3
open("/proc/meminfo", O_RDONLY|O_CLOEXEC) = 3
stat("/usr/local/lib/python36.zip", 0x7ffc9a2d15a0) = -1 ENOENT (No such file or directory)
stat("/usr/local/lib", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
stat("/usr/local/lib/python36.zip", 0x7ffc9a2d1120) = -1 ENOENT (No such file or directory)
stat("/home/ncoghlan/devel/cpython-pristine/Lib/", {st_mode=S_IFDIR|0775, st_size=12288, ...}) = 0
stat("/home/ncoghlan/devel/cpython-pristine/Lib/", {st_mode=S_IFDIR|0775, st_size=12288, ...}) = 0
stat("/home/ncoghlan/devel/cpython-pristine/Lib/", {st_mode=S_IFDIR|0775, st_size=12288, ...}) = 0
stat("/home/ncoghlan/devel/cpython-pristine/Lib/", {st_mode=S_IFDIR|0775, st_size=12288, ...}) = 0
open("/home/ncoghlan/devel/cpython-pristine/Lib/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
stat("/home/ncoghlan/devel/cpython-pristine/Lib/encodings/__init__.cpython-36m-x86_64-linux-gnu.so", 0x7ffc9a2d1320) = -1 ENOENT (No such file or directory)
stat("/home/ncoghlan/devel/cpython-pristine/Lib/encodings/__init__.abi3.so", 0x7ffc9a2d1320) = -1 ENOENT (No such file or directory)
stat("/home/ncoghlan/devel/cpython-pristine/Lib/encodings/__init__.so", 0x7ffc9a2d1320) = -1 ENOENT (No such file or directory)
stat("/home/ncoghlan/devel/cpython-pristine/Lib/encodings/__init__.py", {st_mode=S_IFREG|0664, st_size=5067, ...}) = 0
stat("/home/ncoghlan/devel/cpython-pristine/Lib/encodings/__init__.py", {st_mode=S_IFREG|0664, st_size=5067, ...}) = 0
open("/home/ncoghlan/devel/cpython-pristine/Lib/encodings/__pycache__/__init__.cpython-36.pyc", O_RDONLY|O_CLOEXEC) = 3

----------

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

From report at bugs.python.org  Tue May  3 23:31:34 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Wed, 04 May 2016 03:31:34 +0000
Subject: [issue26932] android: test_posix fails
In-Reply-To: <1462286644.76.0.342167409924.issue26932@psf.upfronthosting.co.za>
Message-ID: <1462332694.43.0.568025971431.issue26932@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

Patch attached for improved RTLD_* checking.

----------
keywords: +patch
Added file: http://bugs.python.org/file42703/posixmodule_rtld_constants.patch

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

From report at bugs.python.org  Tue May  3 23:50:44 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Wed, 04 May 2016 03:50:44 +0000
Subject: [issue26932] android: test_posix fails
In-Reply-To: <1462286644.76.0.342167409924.issue26932@psf.upfronthosting.co.za>
Message-ID: <1462333844.65.0.402024326464.issue26932@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

For test_getgroups, in Android 5.1 `id` does not support -G. [1] In Android 6.x `id` seems to support -G. [2] I guess CPython can just skip the test on Android < 6.0.

[1] https://android.googlesource.com/platform/system/core/+/android-5.1.1_r37/toolbox/id.c
[2] https://android.googlesource.com/platform/external/toybox/+/master/toys/posix/id.c

----------

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

From report at bugs.python.org  Wed May  4 00:20:22 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 May 2016 04:20:22 +0000
Subject: [issue26932] android: test_posix fails
In-Reply-To: <1462286644.76.0.342167409924.issue26932@psf.upfronthosting.co.za>
Message-ID: <1462335622.43.0.829521503079.issue26932@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed May  4 00:49:15 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 May 2016 04:49:15 +0000
Subject: [issue26932] android: test_posix fails
In-Reply-To: <1462286644.76.0.342167409924.issue26932@psf.upfronthosting.co.za>
Message-ID: <1462337355.89.0.745425035723.issue26932@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM. But needed to update pyconfig.h.in and configure.

RTLD_* constants are also used in Modules/_ctypes/_ctypes.c and Python/pystate.c (this can be a cause of threading and ctypes issues on Android).

----------

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

From report at bugs.python.org  Wed May  4 00:50:26 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 May 2016 04:50:26 +0000
Subject: [issue26932] android: test_posix fails
In-Reply-To: <1462286644.76.0.342167409924.issue26932@psf.upfronthosting.co.za>
Message-ID: <1462337426.02.0.190625656381.issue26932@psf.upfronthosting.co.za>


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


----------
nosy: +haypo

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

From report at bugs.python.org  Wed May  4 01:24:35 2016
From: report at bugs.python.org (Billy McCulloch)
Date: Wed, 04 May 2016 05:24:35 +0000
Subject: [issue22107] tempfile module misinterprets access denied error on
 Windows
In-Reply-To: <1406724041.52.0.0365391579019.issue22107@psf.upfronthosting.co.za>
Message-ID: <1462339475.28.0.786819131884.issue22107@psf.upfronthosting.co.za>


Billy McCulloch added the comment:

I've also run into this bug on Windows. In my case, the tempdir path includes directories on a network share, which I lack write access permissions to. Python tries to generate a *lot* of files, and never figures out it should move on to another directory. The attached patch for tempdir.py resolves my issue.

In _get_default_tempdir() and _mkstemp_inner(), you want to know if the filename you tried to create already exists as a directory, not whether the parent directory is a directory ? that's handled in _get_default_tempdir().

In mkdtemp(), attempting to create a directory with the same name as an existing directory does not throw a PermissionError, so the code is superfluous.

----------
nosy: +Billy McCulloch
Added file: http://bugs.python.org/file42704/master...bjmcculloch_patch-1.diff

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

From report at bugs.python.org  Wed May  4 02:04:36 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 May 2016 06:04:36 +0000
Subject: [issue26926] Large files are not supported on Android
In-Reply-To: <1462283737.14.0.888848894928.issue26926@psf.upfronthosting.co.za>
Message-ID: <1462341876.72.0.448542143699.issue26926@psf.upfronthosting.co.za>


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


----------
title: android: test_io fails -> Large files are not supported on Android

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

From report at bugs.python.org  Wed May  4 02:06:38 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Wed, 04 May 2016 06:06:38 +0000
Subject: [issue26932] android: test_posix fails
In-Reply-To: <1462286644.76.0.342167409924.issue26932@psf.upfronthosting.co.za>
Message-ID: <1462341998.07.0.822087352231.issue26932@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

Version 2.

----------
Added file: http://bugs.python.org/file42705/rtld_constants.patch

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

From report at bugs.python.org  Wed May  4 02:08:23 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 May 2016 06:08:23 +0000
Subject: [issue26932] RTLD_* macros are not defined on Android
In-Reply-To: <1462286644.76.0.342167409924.issue26932@psf.upfronthosting.co.za>
Message-ID: <1462342103.45.0.703393376674.issue26932@psf.upfronthosting.co.za>


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


----------
nosy: +amaury.forgeotdarc, belopolsky, meador.inge, pitrou
stage:  -> patch review
title: android: test_posix fails -> RTLD_* macros are not defined on Android

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

From report at bugs.python.org  Wed May  4 02:45:21 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 04 May 2016 06:45:21 +0000
Subject: [issue26932] RTLD_* macros are not defined on Android
In-Reply-To: <1462286644.76.0.342167409924.issue26932@psf.upfronthosting.co.za>
Message-ID: <20160504064517.15928.75870.C54BE680@psf.io>


Roundup Robot added the comment:

New changeset 811ccdee6f87 by Serhiy Storchaka in branch 'default':
Issue #26932: Fixed support of RTLD_* constants defined as enum values,
https://hg.python.org/cpython/rev/811ccdee6f87

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

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

From report at bugs.python.org  Wed May  4 02:47:18 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 May 2016 06:47:18 +0000
Subject: [issue26932] RTLD_* macros are not defined on Android
In-Reply-To: <1462286644.76.0.342167409924.issue26932@psf.upfronthosting.co.za>
Message-ID: <1462344438.37.0.0763726819623.issue26932@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Chi Hsuan Yen.

Please open separate issue for "id -G".

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

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

From report at bugs.python.org  Wed May  4 02:58:25 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 May 2016 06:58:25 +0000
Subject: [issue26932] RTLD_* macros are not defined on Android
In-Reply-To: <1462286644.76.0.342167409924.issue26932@psf.upfronthosting.co.za>
Message-ID: <1462345105.76.0.583972225651.issue26932@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Xavier, please check that issues with ctypes and threading are not gone.

----------

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

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: [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 03:21:15 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 May 2016 07:21:15 +0000
Subject: [issue26922] build from fresh checkout fails
In-Reply-To: <1462331418.85.0.58993964403.issue26922@psf.upfronthosting.co.za>
Message-ID: <5729A2E7.4020909@free.fr>


Antoine Pitrou added the comment:

Le 04/05/2016 05:10, Nick Coghlan a ?crit :
> 
> Does strace give any potentially useful hints?
> 
> For me:
> 
>     $ strace -e trace=file ./python -c "pass"

Ah, thanks. It seems this was failing due to a pyvenv.cfg in the parent
directory, which I removed.

----------

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

From report at bugs.python.org  Wed May  4 03:29:30 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 04 May 2016 07:29:30 +0000
Subject: [issue26929] android: test_strptime fails
In-Reply-To: <1462284711.76.0.324696843297.issue26929@psf.upfronthosting.co.za>
Message-ID: <1462346970.84.0.27248017969.issue26929@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Here is the result of running on android:

<script>
import datetime

for y in (1904, 1906, 2008, 1917):
    for i in range(25, 32):
        print(datetime.date(y, 12, i).strftime('%Y %U %w   %G %V %u'))
    print()

    for i in range(1, 10):
          print(datetime.date(y + 1, 1, i).strftime('%Y %U %w   %G %V %u'))
    print('=====================')
<script>


root at generic_x86:/data/local/tmp # python strftime.py
1904 52 0   1904 51 7
1904 52 1   1904 52 1
1904 52 2   1904 52 2
1904 52 3   1904 52 3
1904 52 4   1904 52 4
1904 52 5   1904 52 5
1904 52 6   1904 52 6

1905 01 0   1904 53 7
1905 01 1   1905 01 1
1905 01 2   1905 01 2
1905 01 3   1905 01 3
1905 01 4   1905 01 4
1905 01 5   1905 01 5
1905 01 6   1905 01 6
1905 02 0   1905 01 7
1905 02 1   1905 02 1
=====================
1906 51 2   1906 52 2
1906 51 3   1906 52 3
1906 51 4   1906 52 4
1906 51 5   1906 52 5
1906 51 6   1906 52 6
1906 52 0   1906 52 7
1906 52 1   1907 53 1

1907 00 2   1907 01 2
1907 00 3   1907 01 3
1907 00 4   1907 01 4
1907 00 5   1907 01 5
1907 00 6   1907 01 6
1907 01 0   1907 01 7
1907 01 1   1907 02 1
1907 01 2   1907 02 2
1907 01 3   1907 02 3
=====================
2008 51 4   2008 52 4
2008 51 5   2008 52 5
2008 51 6   2008 52 6
2008 52 0   2008 52 7
2008 52 1   2009 53 1
2008 52 2   2009 53 2
2008 52 3   2009 53 3

2009 00 4   2009 01 4
2009 00 5   2009 01 5
2009 00 6   2009 01 6
2009 01 0   2009 01 7
2009 01 1   2009 02 1
2009 01 2   2009 02 2
2009 01 3   2009 02 3
2009 01 4   2009 02 4
2009 01 5   2009 02 5
=====================
1917 51 2   1917 52 2
1917 51 3   1917 52 3
1917 51 4   1917 52 4
1917 51 5   1917 52 5
1917 51 6   1917 52 6
1917 52 0   1917 52 7
1917 52 1   1918 53 1

1918 00 2   1918 01 2
1918 00 3   1918 01 3
1918 00 4   1918 01 4
1918 00 5   1918 01 5
1918 00 6   1918 01 6
1918 01 0   1918 01 7
1918 01 1   1918 02 1
1918 01 2   1918 02 2
1918 01 3   1918 02 3
=====================

----------

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

From report at bugs.python.org  Wed May  4 03:29:45 2016
From: report at bugs.python.org (Mathias Arens)
Date: Wed, 04 May 2016 07:29:45 +0000
Subject: [issue26923] asyncio.gather drops cancellation
In-Reply-To: <1462279806.1.0.880381545595.issue26923@psf.upfronthosting.co.za>
Message-ID: <1462346985.68.0.899452509325.issue26923@psf.upfronthosting.co.za>


Changes by Mathias Arens <python at arens.ma>:


----------
nosy: +tatellos

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

From report at bugs.python.org  Wed May  4 03:43:50 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 May 2016 07:43:50 +0000
Subject: [issue26881] modulefinder should reuse the dis module
In-Reply-To: <1461912649.38.0.754834410981.issue26881@psf.upfronthosting.co.za>
Message-ID: <1462347830.05.0.514383686885.issue26881@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

modulefinder in 2.7 should be compatible with Python 2.2 (see PEP 291). Thus we can't just add new function in dis and reuse it in modulefinder. We should duplicate this function in modulefinder.

I don't know if there is corresponding rule for 3.x. Should modulefinder keep compatibility with say 3.1?

----------
nosy: +jvr, theller
Added file: http://bugs.python.org/file42707/dis_unpack_args_2.patch

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

From report at bugs.python.org  Wed May  4 03:55:46 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 04 May 2016 07:55:46 +0000
Subject: [issue26932] RTLD_* macros are not defined on Android
In-Reply-To: <1462286644.76.0.342167409924.issue26932@psf.upfronthosting.co.za>
Message-ID: <1462348546.21.0.46485804402.issue26932@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

test_rtld_constants is now ok at the tip of the default branch.
Thanks Chi Hsuan Yen.
I will enter a separate issue for test_getgroups and reference it here as well as in issue #26865.

----------

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

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: [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 04:01:48 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 May 2016 08:01:48 +0000
Subject: [issue26929] android: test_strptime fails
In-Reply-To: <1462284711.76.0.324696843297.issue26929@psf.upfronthosting.co.za>
Message-ID: <1462348908.06.0.314590335075.issue26929@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

1904 52 6   1904 52 6
1905 01 0   1904 53 7
                 ^^

1906 52 0   1906 52 7
1906 52 1   1907 53 1
            ^^^^

strftime() on Android incorrectly formats %V or %G for the last or the first incomplete week in a year.

----------

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

From report at bugs.python.org  Wed May  4 04:03:42 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 04 May 2016 08:03:42 +0000
Subject: [issue26865] Meta-issue: support of the android platform
In-Reply-To: <1461685011.99.0.617135447086.issue26865@psf.upfronthosting.co.za>
Message-ID: <1462349022.86.0.678212943668.issue26865@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Tests that fail on an android emulator running an x86 system image at API level 21:

  issue #26944: android: test_posix fails

----------

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

From report at bugs.python.org  Wed May  4 04:05:08 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 04 May 2016 08:05:08 +0000
Subject: [issue26932] RTLD_* macros are not defined on Android
In-Reply-To: <1462286644.76.0.342167409924.issue26932@psf.upfronthosting.co.za>
Message-ID: <1462349108.36.0.275311099997.issue26932@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

> I will enter a separate issue for test_getgroups and reference it here as well as in issue #26865.
issue #26944: android: test_posix fails.

----------

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

From report at bugs.python.org  Wed May  4 04:07:44 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 04 May 2016 08:07:44 +0000
Subject: [issue26922] build from fresh checkout fails
In-Reply-To: <1462278034.88.0.00181655793676.issue26922@psf.upfronthosting.co.za>
Message-ID: <1462349264.49.0.425451198189.issue26922@psf.upfronthosting.co.za>


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


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Wed May  4 04:08:58 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 May 2016 08:08:58 +0000
Subject: [issue26944] android: test_posix fails
In-Reply-To: <1462348873.26.0.373017977506.issue26944@psf.upfronthosting.co.za>
Message-ID: <1462349338.6.0.988531556011.issue26944@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See more information in comments in issue26932. Since the id tool looks fixed in Android 6.x we should skip the test on Android <6.x.

----------
components: +Tests -Cross-Build, Library (Lib)
dependencies: +android: add platform.android_ver()
nosy: +serhiy.storchaka
type:  -> behavior

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

From report at bugs.python.org  Wed May  4 04:22:38 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 04 May 2016 08:22:38 +0000
Subject: [issue26932] RTLD_* macros are not defined on Android
In-Reply-To: <1462286644.76.0.342167409924.issue26932@psf.upfronthosting.co.za>
Message-ID: <1462350158.71.0.67603780804.issue26932@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

> Xavier, please check that issues with ctypes and threading are not gone.

No ctypes still crashes and threading still hangs.

----------

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

From report at bugs.python.org  Wed May  4 04:28:41 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 04 May 2016 08:28:41 +0000
Subject: [issue26873] xmlrpclib raises when trying to convert an int to string
 when unicode is available
In-Reply-To: <1461808162.86.0.277160090083.issue26873@psf.upfronthosting.co.za>
Message-ID: <20160504082834.46280.4639.94525CF8@psf.io>


Roundup Robot added the comment:

New changeset 0d015f6aba8b by Serhiy Storchaka in branch '3.5':
Issue #26873: xmlrpc now raises ResponseError on unsupported type tags
https://hg.python.org/cpython/rev/0d015f6aba8b

New changeset 8f7cb3b171f3 by Serhiy Storchaka in branch 'default':
Issue #26873: xmlrpc now raises ResponseError on unsupported type tags
https://hg.python.org/cpython/rev/8f7cb3b171f3

New changeset 7050c9fc1f72 by Serhiy Storchaka in branch '2.7':
Issue #26873: xmlrpclib now raises ResponseError on unsupported type tags
https://hg.python.org/cpython/rev/7050c9fc1f72

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

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

From report at bugs.python.org  Wed May  4 04:29:17 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 May 2016 08:29:17 +0000
Subject: [issue26873] xmlrpclib raises when trying to convert an int to string
 when unicode is available
In-Reply-To: <1461808162.86.0.277160090083.issue26873@psf.upfronthosting.co.za>
Message-ID: <1462350557.58.0.180961552155.issue26873@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed May  4 05:06:16 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 04 May 2016 09:06:16 +0000
Subject: [issue26924] android: test_concurrent_futures fails
In-Reply-To: <1462282676.16.0.612748828.issue26924@psf.upfronthosting.co.za>
Message-ID: <1462352776.41.0.0951290324103.issue26924@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

On android:

root at generic_x86:/data/local/tmp # python
Python 3.6.0a0 (default:811ccdee6f87+, May  4 2016, 10:31:14) 
[GCC 4.9 20140827 (prerelease)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from _multiprocessing import sem_unlink
>>> sem_unlink('foo')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 38] Function not implemented
>>>

----------

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

From report at bugs.python.org  Wed May  4 05:12:35 2016
From: report at bugs.python.org (Marcos Dione)
Date: Wed, 04 May 2016 09:12:35 +0000
Subject: [issue26826] Expose new copy_file_range() syscall in os module.
In-Reply-To: <1461325239.41.0.30054024313.issue26826@psf.upfronthosting.co.za>
Message-ID: <1462353155.73.0.75755910719.issue26826@psf.upfronthosting.co.za>


Marcos Dione added the comment:

Sorry for the delay.

Based on suggestions in the mailing list, I changed the *count* handling as if it were a ssize_t, and I added a note about ignored output parameters.

----------
title: Expose new copy_file_range() syscal in os module. -> Expose new copy_file_range() syscall in os module.
Added file: http://bugs.python.org/file42708/copy_file_range.diff

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

From report at bugs.python.org  Wed May  4 05:37:16 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 04 May 2016 09:37:16 +0000
Subject: [issue26926] Large files are not supported on Android
In-Reply-To: <1462283737.14.0.888848894928.issue26926@psf.upfronthosting.co.za>
Message-ID: <1462354636.52.0.498072060656.issue26926@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

The relevant part of the output of configure on x86:

checking size of int... 4
checking size of long... 4
checking size of void *... 4
checking size of short... 2
checking size of float... 4
checking size of double... 8
checking size of fpos_t... 4
checking size of size_t... 4
checking size of pid_t... 4
checking for long long support... yes
checking size of long long... 8
checking for long double support... yes
checking size of long double... 8
checking for _Bool support... yes
checking size of _Bool... 1
checking for uintptr_t... yes
checking size of uintptr_t... 4
checking size of off_t... 4
checking whether to enable large file support... no

And as a consequence in pyconfig.h:
/* Defined to enable large file support when an off_t is bigger than a long
   and long long is available and at least as big as an off_t. You may need to
   add some flags for configuration and compilation to enable this mode. (For
   Solaris and Linux, the necessary defines are already defined.) */
/* #undef HAVE_LARGEFILE_SUPPORT */

----------

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

From report at bugs.python.org  Wed May  4 06:00:09 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 04 May 2016 10:00:09 +0000
Subject: [issue26926] Large files are not supported on Android
In-Reply-To: <1462283737.14.0.888848894928.issue26926@psf.upfronthosting.co.za>
Message-ID: <1462356009.05.0.799165829877.issue26926@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

On android x86:

>>> import resource
>>> resource.setrlimit(resource.RLIMIT_FSIZE, (2**31, 2**31))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: Python int too large to convert to C long
>>> resource.setrlimit(resource.RLIMIT_FSIZE, (2**31-1, 2**31-1))
>>> resource.getrlimit(resource.RLIMIT_FSIZE)
(2147483647, 2147483647)
>>> 


The test_io tests that fail may be skipped by trying first to set this resource limit (if existing) to the max file size tested, in a spawned interpreter.

----------

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

From report at bugs.python.org  Wed May  4 06:07:06 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 04 May 2016 10:07:06 +0000
Subject: [issue26919] android: test_cmd_line fails
In-Reply-To: <1462267115.39.0.594600458307.issue26919@psf.upfronthosting.co.za>
Message-ID: <1462356426.24.0.551303374729.issue26919@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

There is a related issue #4388 although different, and issue #22747 may also be related.

----------
nosy: +haypo

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

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: [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 06:59:48 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 04 May 2016 10:59:48 +0000
Subject: [issue26924] android: test_concurrent_futures fails
In-Reply-To: <1462282676.16.0.612748828.issue26924@psf.upfronthosting.co.za>
Message-ID: <1462359588.91.0.332008326261.issue26924@psf.upfronthosting.co.za>


Berker Peksag added the comment:

It normally should raise an ImportError if sem_unlink is not available. Could you try the attached patch please?

----------
keywords: +patch
nosy: +berker.peksag
Added file: http://bugs.python.org/file42710/sem_unlink.diff

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

From report at bugs.python.org  Wed May  4 07:08:46 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 04 May 2016 11:08:46 +0000
Subject: [issue26696] Document collections.abc.ByteString
In-Reply-To: <1459881544.79.0.834895685887.issue26696@psf.upfronthosting.co.za>
Message-ID: <1462360126.11.0.767145593759.issue26696@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Add collections.abc.ByteString's document.

----------
keywords: +patch
Added file: http://bugs.python.org/file42711/ByteString_doc.patch

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

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: [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: [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:28:13 2016
From: report at bugs.python.org (Michael Felt)
Date: Wed, 04 May 2016 12:28:13 +0000
Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not
 available (e.g., AIX)
In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za>
Message-ID: <1462364893.1.0.316699075205.issue26439@psf.upfronthosting.co.za>


Michael Felt added the comment:

reworked patch. To assist port to Python3 that changes in __init__.py and util.py are minimal. There is a new file: aixutil.py

I have only tested on Python-2.7, so there may be issues for Python3. My goal is to have a single file for both versions.

The main change in util.py is lots of specific (behavior) tests that I have encountered (and initially failed) from projects using ctypes.cdll.

I feel confident that this will work "ASIS" with nearly all existing projects.

Note: normal return is not a full path name. A full path name is only returned when an archive + member could not be found, but a file with the name requested could be found. This "fullpath" is to be compatible with existing code 'demanding' unpacked archives.

----------
Added file: http://bugs.python.org/file42712/python.Lib.ctypes.160504.patch

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

From report at bugs.python.org  Wed May  4 08:30:46 2016
From: report at bugs.python.org (Michael Felt)
Date: Wed, 04 May 2016 12:30:46 +0000
Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not
 available (e.g., AIX)
In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za>
Message-ID: <1462365046.35.0.0665271539313.issue26439@psf.upfronthosting.co.za>


Michael Felt added the comment:

implements ctypes.aixutil.find_library()
In a separate file as both __init__.py as util.py needs it's logic.

----------
Added file: http://bugs.python.org/file42713/aixutil.py

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

From report at bugs.python.org  Wed May  4 08:39:01 2016
From: report at bugs.python.org (Michael Vogt)
Date: Wed, 04 May 2016 12:39:01 +0000
Subject: [issue23228] Crashes when tarfile contains a symlink and unpack
 directory contain it too
In-Reply-To: <1421139302.16.0.710158118765.issue23228@psf.upfronthosting.co.za>
Message-ID: <1462365541.44.0.480929723974.issue23228@psf.upfronthosting.co.za>


Michael Vogt added the comment:

Anything I can do to help moving this issue forward?

----------

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

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: [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: [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 08:51:48 2016
From: report at bugs.python.org (ppperry)
Date: Wed, 04 May 2016 12:51:48 +0000
Subject: [issue26946] os.path.realpath.__name__ is 'abspath'
In-Reply-To: <1462362994.62.0.587690697752.issue26946@psf.upfronthosting.co.za>
Message-ID: <1462366308.54.0.630970473158.issue26946@psf.upfronthosting.co.za>


ppperry added the comment:

Also is true on python 3.4. Why does this matter anyway?

----------
nosy: +ppperry
versions: +Python 3.4

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

From report at bugs.python.org  Wed May  4 08:54:59 2016
From: report at bugs.python.org (ppperry)
Date: Wed, 04 May 2016 12:54:59 +0000
Subject: [issue23228] The tarfile module crashes when tarfile contains a
 symlink and unpack directory contain it too
In-Reply-To: <1421139302.16.0.710158118765.issue23228@psf.upfronthosting.co.za>
Message-ID: <1462366499.4.0.529130524964.issue23228@psf.upfronthosting.co.za>


Changes by ppperry <mapreader at olum.org>:


----------
title: Crashes when tarfile contains a symlink and unpack directory contain it too -> The tarfile module crashes when tarfile contains a symlink and unpack directory contain it too

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

From report at bugs.python.org  Wed May  4 08:57:56 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 04 May 2016 12:57:56 +0000
Subject: [issue23275] Can assign [] = (), but not () = []
In-Reply-To: <1421694347.87.0.147201508367.issue23275@psf.upfronthosting.co.za>
Message-ID: <1462366676.91.0.346402028421.issue23275@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Here is an updated patch. I moved the test into test_unpack and added additional tests. sequence -> iterable changes should probably be applied to 3.5 as well.

Thanks for the review, Martin.

----------
type: behavior -> enhancement
Added file: http://bugs.python.org/file42715/issue23275_v3.diff

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

From report at bugs.python.org  Wed May  4 09:08:18 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 04 May 2016 13:08:18 +0000
Subject: [issue26946] os.path.realpath.__name__ is 'abspath'
In-Reply-To: <1462362994.62.0.587690697752.issue26946@psf.upfronthosting.co.za>
Message-ID: <1462367298.54.0.122848152885.issue26946@psf.upfronthosting.co.za>


Berker Peksag added the comment:

It's because realpath is defined as

    # realpath is a no-op on systems without islink support
    realpath = abspath

under Windows.

----------
nosy: +berker.peksag

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

From report at bugs.python.org  Wed May  4 09:09:28 2016
From: report at bugs.python.org (ppperry)
Date: Wed, 04 May 2016 13:09:28 +0000
Subject: [issue26860] Make os.walk and os.fwalk yield namedtuple instead of
 tuple
In-Reply-To: <1461678306.82.0.694875654943.issue26860@psf.upfronthosting.co.za>
Message-ID: <1462367368.95.0.159854340355.issue26860@psf.upfronthosting.co.za>


Changes by ppperry <mapreader at olum.org>:


----------
title: os.walk and os.fwalk yield namedtuple instead of tuple -> Make os.walk and os.fwalk yield namedtuple instead of tuple

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

From report at bugs.python.org  Wed May  4 09:15:53 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 04 May 2016 13:15:53 +0000
Subject: [issue26947] Documentation improvement needed
In-Reply-To: <1462364495.31.0.190726094652.issue26947@psf.upfronthosting.co.za>
Message-ID: <1462367753.34.0.203744385669.issue26947@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

I think the original is OK. Adding "not" means the opposite.

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

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

From report at bugs.python.org  Wed May  4 09:23:53 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 May 2016 13:23:53 +0000
Subject: [issue26948] Simplify PyImport_ImportModuleLevelObject: avoid
 temporary tuple of str.partition/rpartition
In-Reply-To: <1462366096.99.0.505486204929.issue26948@psf.upfronthosting.co.za>
Message-ID: <1462368233.75.0.528403349765.issue26948@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM, but I left a couple of minor suggestions on Rietveld. I hope they can make the code yet cleaner.

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

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

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: [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 09:49:06 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 May 2016 13:49:06 +0000
Subject: [issue26906] format(object.__reduce__) fails intermittently
In-Reply-To: <1462194444.45.0.679859267338.issue26906@psf.upfronthosting.co.za>
Message-ID: <1462369746.76.0.753553939285.issue26906@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

A number of other types are not initialized until you request an attribute.

Here is larger patch for 2.7 that makes 38 types to be explicitly initialized.

----------
Added file: http://bugs.python.org/file42716/init_types-2.7.patch

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

From report at bugs.python.org  Wed May  4 09:51:54 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 04 May 2016 13:51:54 +0000
Subject: [issue26950] Typo in unittest.mock > Autospeccing documentation
In-Reply-To: <1462369542.26.0.815413375703.issue26950@psf.upfronthosting.co.za>
Message-ID: <1462369914.73.0.757541518714.issue26950@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the report, but the typos are intentional. Quoting from the documentation:

    [...] if you misspell one of these assert methods then your assertion is gone:

    >>> mock = Mock(name='Thing', return_value=None)
    >>> mock(1, 2, 3)
    >>> mock.assret_called_once_with(4, 5, 6)

    Your tests can pass silently and incorrectly because of the typo.

----------
nosy: +berker.peksag
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

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


Joni Bekenstein added the comment:

My bad, didn't see the notice! Makes sense though. Sorry for opening an issue.

----------

_______________________________________
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: [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 10:36:13 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 04 May 2016 14:36:13 +0000
Subject: [issue26947] Documentation improvement needed
In-Reply-To: <1462364495.31.0.190726094652.issue26947@psf.upfronthosting.co.za>
Message-ID: <1462372573.27.0.293655183299.issue26947@psf.upfronthosting.co.za>


Steven D'Aprano added the comment:

Xiang Zhang is correct: the original is technically correct. If you read it like this:

"All of Python?s immutable built-in objects are hashable, while no mutable containers (such as lists or dictionaries) are [hashable]."

it should be clear. But if you have a suggestion for wording which is easier to understand (especially for those whose English is not so good) please say so.

----------
nosy: +steven.daprano

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

From report at bugs.python.org  Wed May  4 11:00:56 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Wed, 04 May 2016 15:00:56 +0000
Subject: [issue26951] Unintuitive error when using generator expression in
 class property
In-Reply-To: <1462372473.02.0.946073615941.issue26951@psf.upfronthosting.co.za>
Message-ID: <1462374056.76.0.0209046636747.issue26951@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

Using a simple metaclass shows that definition order is not at fault here:

>>> class PrintOrder(dict):
...   def __setitem__(self, item, value):
...     print(item, value)
...     super().__setitem__(item, value)
...
>>> class Show(type):
...   def __prepare__(name, bases): return PrintOrder()
...
>>> class A(metaclass=Show):
...   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)
...
__module__ __main__
__qualname__ A
B range(0, 10)
C frozenset({4, 5, 6})
D [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 5, in A
  File "<stdin>", line 5, in <genexpr>
NameError: name 'C' is not defined

However, the following works:

>>> def local_definition():
...   F = frozenset([4, 5, 6])
...   class A(metaclass=Show):
...     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 F)
...   return A
...
>>> local_definition()
__module__ __main__
__qualname__ local_definition.<locals>.A
B range(0, 10)
C frozenset({4, 5, 6})
D [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
E [4, 5, 6]
<class '__main__.local_definition.<locals>.A'>

Sounds like either an inconsistency between 'for' and 'if' parts of generator expressions, or something weird about the way generator expressions work that I'm unaware of.

Furthermore, this isn't documented in the tutorial, the functional programming How-To, the 2.4 release notes or the PEP 289:

https://docs.python.org/3/tutorial/classes.html#generator-expressions
https://docs.python.org/3/howto/functional.html#generator-expressions-and-list-comprehensions
https://docs.python.org/3/whatsnew/2.4.html#pep-289-generator-expressions
https://www.python.org/dev/peps/pep-0289/

----------
nosy: +ebarry
stage:  -> needs patch

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

From report at bugs.python.org  Wed May  4 11:14:20 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 04 May 2016 15:14:20 +0000
Subject: [issue26947] Documentation improvement needed
In-Reply-To: <1462364495.31.0.190726094652.issue26947@psf.upfronthosting.co.za>
Message-ID: <1462374860.54.0.117451696041.issue26947@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

I'm a native speaker, and it's not the greatest sentence. How about:

All of Python?s immutable built-in objects (such as numbers, strings and tuples) are hashable. None of its mutable containers (such as lists or dictionaries) are hashable.

----------
nosy: +eric.smith

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

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: [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:15:36 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 04 May 2016 15:15:36 +0000
Subject: [issue26924] android: test_concurrent_futures fails
In-Reply-To: <1462282676.16.0.612748828.issue26924@psf.upfronthosting.co.za>
Message-ID: <1462374936.94.0.944096248201.issue26924@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Patch tested, it does not fix the problem.
This is because in pyconfig.h:
/* Define to 1 if you have the `sem_unlink' function. */
#define HAVE_SEM_UNLINK 1

Android declares the function but does not implement it. This is not the only case, for example issue #26857.

----------

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

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: [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 11:21:33 2016
From: report at bugs.python.org (Marco)
Date: Wed, 04 May 2016 15:21:33 +0000
Subject: [issue26953] Failed building wheel for greenlet
Message-ID: <1462375293.24.0.0175568770185.issue26953@psf.upfronthosting.co.za>


New submission from Marco:

I have tried to install bpython on Linux with this result

studio at linux:/usr/bin> pip install bpython
...
...
Running setup.py bdist_wheel for greenlet ... error
greenlet.h:8:20: fatal error: Python.h: No such file or directory
   #include <Python.h>
                      ^
  compilation terminated.
  error: command 'gcc' failed with exit status 1

How can I fix this error ?

MC

----------

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

From report at bugs.python.org  Wed May  4 11:26:08 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 04 May 2016 15:26:08 +0000
Subject: [issue26953] Failed building wheel for greenlet
In-Reply-To: <1462375293.24.0.0175568770185.issue26953@psf.upfronthosting.co.za>
Message-ID: <1462375568.94.0.803558892845.issue26953@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Hmm, it's not suitable to report such problems here. You'd better google for it. At least you have to apt-get install python-dev or yum install python-devel.

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

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

From report at bugs.python.org  Wed May  4 11:44:05 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 04 May 2016 15:44:05 +0000
Subject: [issue26953] Failed building wheel for greenlet
In-Reply-To: <1462375293.24.0.0175568770185.issue26953@psf.upfronthosting.co.za>
Message-ID: <1462376645.0.0.890665693479.issue26953@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Please use greenlet's issue tracker: https://github.com/python-greenlet/greenlet/issues You'll probably need to install Python headers by using your distribution's package manager.

----------
nosy: +berker.peksag
resolution:  -> third party
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Wed May  4 11:46:38 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 May 2016 15:46:38 +0000
Subject: [issue26906] format(object.__reduce__) fails intermittently
In-Reply-To: <1462194444.45.0.679859267338.issue26906@psf.upfronthosting.co.za>
Message-ID: <1462376798.59.0.837669169598.issue26906@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

An alternative way is just call PyType_Ready from _PyType_Lookup if type->tp_mro is NULL.

Here is a patch against 2.7 that restores the solution from issue551412, but returns NULL if type->tp_mro is still NULL after calling PyType_Ready. I found one place in tests when this is happened (CIOTest.test_IOBase_finalize in test_io).

----------
assignee:  -> gvanrossum
nosy: +gvanrossum
Added file: http://bugs.python.org/file42717/init_type_in_pytype_lookup.patch

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

From report at bugs.python.org  Wed May  4 11:48:56 2016
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 04 May 2016 15:48:56 +0000
Subject: [issue20120] Percent-signs (%) in .pypirc should not be interpolated
In-Reply-To: <1388825675.42.0.435893533792.issue20120@psf.upfronthosting.co.za>
Message-ID: <1462376936.53.0.734524667797.issue20120@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

I just confirmed only Python 3.5 gets bugfixes, so I'll apply this to 3.5 and default.

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

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

From report at bugs.python.org  Wed May  4 11:54:43 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 04 May 2016 15:54:43 +0000
Subject: [issue26951] Unintuitive error when using generator expression in
 class property
In-Reply-To: <1462372473.02.0.946073615941.issue26951@psf.upfronthosting.co.za>
Message-ID: <1462377283.81.0.818135111294.issue26951@psf.upfronthosting.co.za>


Steven D'Aprano added the comment:

On snap! Nicely found! This seems to have something to do with the way generator expressions are run inside their own scope.

In Python 2.7, a list comprehension in a class sees the locals correctly:

py> class K:
...     a = 2; x = [a+i for i in range(a)]
...
py> K.x
[2, 3]


But change the list comp to a generator expression, and the situation is different:


py> class K:
...     a = 2; x = list(i for i in range(a))  # Okay
...     b = 2; y = list(b+i for i in range(a))  # Raises
...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 3, in K
  File "<stdin>", line 3, in <genexpr>
NameError: global name 'b' is not defined


In Python 3, list comps use the same sort of temporary scope as genexprs, and sure enough, the list comp fails with the same error as the generator expression.

----------
nosy: +steven.daprano

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

From report at bugs.python.org  Wed May  4 12:01:22 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 04 May 2016 16:01:22 +0000
Subject: [issue26952] argparse help formatter crashes
In-Reply-To: <1462374887.67.0.462060112057.issue26952@psf.upfronthosting.co.za>
Message-ID: <1462377682.67.0.935598938507.issue26952@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed May  4 12:01:40 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 04 May 2016 16:01:40 +0000
Subject: [issue20120] Percent-signs (%) in .pypirc should not be interpolated
In-Reply-To: <1388825675.42.0.435893533792.issue20120@psf.upfronthosting.co.za>
Message-ID: <20160504160059.71256.10861.CEB433E5@psf.io>


Roundup Robot added the comment:

New changeset eae59b6bf133 by Jason R. Coombs in branch '3.5':
Issue #20120: Use RawConfigParser for .pypirc parsing, removing support for interpolation unintentionally added with move to Python 3. Behavior no longer does any interpolation in .pypirc files, matching behavior in Python 2.7 and Setuptools 19.0.
https://hg.python.org/cpython/rev/eae59b6bf133

New changeset 89116bd505cb by Jason R. Coombs in branch 'default':
Issue #20120: Merge with 3.5
https://hg.python.org/cpython/rev/89116bd505cb

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

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

From report at bugs.python.org  Wed May  4 12:01:45 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 04 May 2016 16:01:45 +0000
Subject: [issue26951] Unintuitive error when using generator expression in
 class property
In-Reply-To: <1462372473.02.0.946073615941.issue26951@psf.upfronthosting.co.za>
Message-ID: <1462377705.57.0.880714519428.issue26951@psf.upfronthosting.co.za>


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


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

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

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: [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:13:21 2016
From: report at bugs.python.org (Jason R. Coombs)
Date: Wed, 04 May 2016 16:13:21 +0000
Subject: [issue20120] Percent-signs (%) in .pypirc should not be interpolated
In-Reply-To: <1388825675.42.0.435893533792.issue20120@psf.upfronthosting.co.za>
Message-ID: <1462378401.73.0.525868711985.issue20120@psf.upfronthosting.co.za>


Jason R. Coombs added the comment:

Fixed now. I'll watch the buildbots to assure acceptance.

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

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

From report at bugs.python.org  Wed May  4 12:14:41 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 04 May 2016 16:14:41 +0000
Subject: [issue26952] argparse help formatter crashes
In-Reply-To: <1462374887.67.0.462060112057.issue26952@psf.upfronthosting.co.za>
Message-ID: <1462378481.07.0.556544979256.issue26952@psf.upfronthosting.co.za>


Berker Peksag added the comment:

I don't think add_mutually_exclusive_group and add_argument_group are designed to work together. Did this worked with argparse 1.3.0 or stdlib version of argparse before? I'm getting the same traceback in 2.7 and 3.4+.

----------
nosy: +berker.peksag

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

From report at bugs.python.org  Wed May  4 12:15:10 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 04 May 2016 16:15:10 +0000
Subject: [issue26952] argparse help formatter crashes
In-Reply-To: <1462374887.67.0.462060112057.issue26952@psf.upfronthosting.co.za>
Message-ID: <1462378510.44.0.0779849156423.issue26952@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

This error occurs due to there is no action belong to the mutexGroup, the code requires at least one. You can simply add

    mutexGroup.add_argument('--foo', action='store_true')

and you'll see the error disappears. I have no idea that this behaviour is intended or not.

----------

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

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: [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:23:49 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 04 May 2016 16:23:49 +0000
Subject: [issue26952] argparse help formatter crashes
In-Reply-To: <1462374887.67.0.462060112057.issue26952@psf.upfronthosting.co.za>
Message-ID: <1462379029.61.0.0931683686113.issue26952@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

I agree with Berker. Even without any exceptions, the help message given is not what add_argument_group and add_mutually_exclusive_group intend.

You can see

usage: argparse_test.py [-h] [--foo] -u URL -p PROJECT [--dump] --mergeInput
                        MERGEINPUT [--removeDisabled] -c CHECKERS

Sets the checkers of a klocwork project

optional arguments:
  -h, --help            show this help message and exit
  --foo
  -c CHECKERS, --checkers CHECKERS
                        File which lists the checkers to be enabled.

There is not group name and still optional arguments. And the command line does not show exclusive. I believe they are not designed to work like this.

----------

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

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: [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 12:28:41 2016
From: report at bugs.python.org (Endre)
Date: Wed, 04 May 2016 16:28:41 +0000
Subject: [issue26952] argparse help formatter crashes
In-Reply-To: <1462374887.67.0.462060112057.issue26952@psf.upfronthosting.co.za>
Message-ID: <1462379321.14.0.435390681676.issue26952@psf.upfronthosting.co.za>


Endre added the comment:

Hi,

Thanks for taking a look at it.
I have only tried it with argparse-1.4.0.

"I don't think add_mutually_exclusive_group and add_argument_group are designed to work together."

Yes, it really works strange in this case. I guess the framework should raise an exception which states that this use case is not supported, e.g. at the "serverGroup = mutexGroup.add_argument_group('serverGroup')
" line.

----------

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

From report at bugs.python.org  Wed May  4 12:28:52 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 04 May 2016 16:28:52 +0000
Subject: [issue26906] format(object.__reduce__) fails intermittently
In-Reply-To: <1462194444.45.0.679859267338.issue26906@psf.upfronthosting.co.za>
Message-ID: <1462379332.71.0.345863138803.issue26906@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Serhiy, I'm happy to help, but I'm not sure what you're asking me to do. Decide between different patches? I can't even repro the issue.

----------

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

From report at bugs.python.org  Wed May  4 12:30:54 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 04 May 2016 16:30:54 +0000
Subject: [issue26952] argparse help formatter crashes
In-Reply-To: <1462374887.67.0.462060112057.issue26952@psf.upfronthosting.co.za>
Message-ID: <1462379454.39.0.996287456944.issue26952@psf.upfronthosting.co.za>


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


----------
nosy: +bethard

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

From report at bugs.python.org  Wed May  4 12:39:57 2016
From: report at bugs.python.org (SilentGhost)
Date: Wed, 04 May 2016 16:39:57 +0000
Subject: [issue26943] Datetime.strptime crash
In-Reply-To: <1462346227.96.0.56286008604.issue26943@psf.upfronthosting.co.za>
Message-ID: <1462379997.5.0.122468539675.issue26943@psf.upfronthosting.co.za>


SilentGhost added the comment:

Jens, the issue seems to be related to the locale under which your script is operating. You could try to ensure that the locale is suitable for the %b switch. In any case this doesn't look like a datetime bug.

----------
nosy: +SilentGhost
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
type: crash -> behavior

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

From report at bugs.python.org  Wed May  4 12:43:21 2016
From: report at bugs.python.org (SilentGhost)
Date: Wed, 04 May 2016 16:43:21 +0000
Subject: [issue26949] IDLE restarts when one debugs code raising SystemExit
Message-ID: <1462380201.93.0.563918172152.issue26949@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +kbk, roger.serwy, terry.reedy
stage:  -> test needed

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

From report at bugs.python.org  Wed May  4 12:46:20 2016
From: report at bugs.python.org (SilentGhost)
Date: Wed, 04 May 2016 16:46:20 +0000
Subject: [issue26956] About Idle-x  version not updated for  1.13
In-Reply-To: <1462379265.06.0.476376304833.issue26956@psf.upfronthosting.co.za>
Message-ID: <1462380380.69.0.333559978933.issue26956@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +kbk, roger.serwy, terry.reedy
type:  -> behavior

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

From report at bugs.python.org  Wed May  4 12:48:06 2016
From: report at bugs.python.org (SilentGhost)
Date: Wed, 04 May 2016 16:48:06 +0000
Subject: [issue26955] Implement equivalent to `pip.locations.distutils_scheme`
 in distutils
In-Reply-To: <1462378664.68.0.201238634465.issue26955@psf.upfronthosting.co.za>
Message-ID: <1462380486.42.0.0128796068244.issue26955@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
components: +Distutils
nosy: +dstufft, eric.araujo

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

From report at bugs.python.org  Wed May  4 13:00:04 2016
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 04 May 2016 17:00:04 +0000
Subject: [issue26696] Document collections.abc.ByteString
In-Reply-To: <1459881544.79.0.834895685887.issue26696@psf.upfronthosting.co.za>
Message-ID: <1462381204.44.0.551085758648.issue26696@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> brett.cannon

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

From report at bugs.python.org  Wed May  4 13:04:59 2016
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 04 May 2016 17:04:59 +0000
Subject: [issue26943] datetime.datetime.strptime() raises an exception
In-Reply-To: <1462346227.96.0.56286008604.issue26943@psf.upfronthosting.co.za>
Message-ID: <1462381499.28.0.127417033917.issue26943@psf.upfronthosting.co.za>


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


----------
title: Datetime.strptime crash -> datetime.datetime.strptime() raises an exception

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

From report at bugs.python.org  Wed May  4 13:05:58 2016
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 04 May 2016 17:05:58 +0000
Subject: [issue26946] os.path.realpath.__name__ is 'abspath'
In-Reply-To: <1462362994.62.0.587690697752.issue26946@psf.upfronthosting.co.za>
Message-ID: <1462381558.39.0.559094166968.issue26946@psf.upfronthosting.co.za>


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


----------
resolution:  -> not a bug
status: open -> closed

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

From report at bugs.python.org  Wed May  4 13:09:15 2016
From: report at bugs.python.org (SilentGhost)
Date: Wed, 04 May 2016 17:09:15 +0000
Subject: [issue26945] difflib.HtmlDiff().make_file() treat few change as whole
 line change
In-Reply-To: <1462357117.75.0.264226223626.issue26945@psf.upfronthosting.co.za>
Message-ID: <1462381755.73.0.168236408455.issue26945@psf.upfronthosting.co.za>


SilentGhost added the comment:

This seems to do with the percentage of affected characters, the threshold seems to be about a quarter. Not sure this is a bug.

----------
nosy: +SilentGhost

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

From report at bugs.python.org  Wed May  4 13:32:04 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 May 2016 17:32:04 +0000
Subject: [issue26906] format(object.__reduce__) fails intermittently
In-Reply-To: <1462194444.45.0.679859267338.issue26906@psf.upfronthosting.co.za>
Message-ID: <1462383124.63.0.28798366167.issue26906@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file42717/init_type_in_pytype_lookup.patch

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

From report at bugs.python.org  Wed May  4 13:33:04 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 May 2016 17:33:04 +0000
Subject: [issue26906] format(object.__reduce__) fails intermittently
In-Reply-To: <1462194444.45.0.679859267338.issue26906@psf.upfronthosting.co.za>
Message-ID: <1462383184.13.0.14190357163.issue26906@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Added a check for Py_TPFLAGS_READYING to prevent recursive calling.

----------
Added file: http://bugs.python.org/file42718/init_type_in_pytype_lookup.patch

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

From report at bugs.python.org  Wed May  4 13:57:17 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 May 2016 17:57:17 +0000
Subject: [issue26906] format(object.__reduce__) fails intermittently
In-Reply-To: <1462194444.45.0.679859267338.issue26906@psf.upfronthosting.co.za>
Message-ID: <1462384637.01.0.830586541215.issue26906@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The problem is that format() fails for instances of some classes, because the type still is not initialized. The simplest example -- list iterator.

>>> format(iter([]))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Type listiterator doesn't define __format__

After forcing type initialization (for example by getting any type's attribute), format() becomes working.

>>> type(iter([])).foo
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: type object 'listiterator' has no attribute 'foo'
>>> format(iter([]))
'<listiterator object at 0xb708d0ec>'

I afraid that format() is just one example, and there are other functions or operators that don't work or work incorrectly if the type was not initialized.

init_types-2.7.patch adds explicit initialization of 38 types (I didn't check that all of them need this, but I suppose they do). This is large patch, and I'm not sure that it fixes all types.

Other way is to try to initialize the type just in _PyType_Lookup if it is not initialized. This is simple change, but a comment in _PyType_Lookup warns me. I found that this solution was already applied as an attempt to fix issue551412, but then reverted. Since you seem to be the most knowledgeable with this code, I'm asking you what was wrong with this approach and how we can fix this.

Python 3.x also suffers from this bug, but it is reproduced with less types. For example it isn't reproduced for list iterator. I don't know why.

----------

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

From report at bugs.python.org  Wed May  4 14:31:35 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 04 May 2016 18:31:35 +0000
Subject: [issue26951] Unintuitive error when using generator expression in
 class property
In-Reply-To: <1462372473.02.0.946073615941.issue26951@psf.upfronthosting.co.za>
Message-ID: <1462386695.01.0.276122412792.issue26951@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

The outer for loop in a generator expression is evaluated immediately; everything after that is evaluated lazily. This was a deliberate design choice: see https://www.python.org/dev/peps/pep-0289/#early-binding-versus-late-binding for some rationale. This explains why you're able to access "B". The inability to access "C" is due to the usual rule for Python scope resolution: class scopes are skipped when examining nested scopes.

The early evaluation of the outermost for is covered in the docs, here: https://docs.python.org/2/reference/expressions.html#generator-expressions

"""
However, the leftmost for clause is immediately evaluated, so that an error produced by it can be seen before any other possible error in the code that handles the generator expression.
"""

So this behaviour is by design, though there may be a doc issue here. Changing components and versions accordingly.

----------
assignee:  -> docs at python
components: +Documentation -Interpreter Core
nosy: +docs at python, mark.dickinson
versions: +Python 3.6 -Python 3.2, Python 3.3, Python 3.4

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

From report at bugs.python.org  Wed May  4 14:43:53 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 04 May 2016 18:43:53 +0000
Subject: [issue26811] segfault due to null pointer in tuple
In-Reply-To: <1461198016.05.0.40690695807.issue26811@psf.upfronthosting.co.za>
Message-ID: <20160504184335.53109.13869.72443105@psf.io>


Roundup Robot added the comment:

New changeset a98ef122d73d by Serhiy Storchaka in branch '3.5':
Issue #26811: gc.get_objects() no longer contains a broken tuple with NULL
https://hg.python.org/cpython/rev/a98ef122d73d

New changeset 3fe1c7ad3b58 by Serhiy Storchaka in branch 'default':
Issue #26811: gc.get_objects() no longer contains a broken tuple with NULL
https://hg.python.org/cpython/rev/3fe1c7ad3b58

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

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

From report at bugs.python.org  Wed May  4 14:47:25 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 04 May 2016 18:47:25 +0000
Subject: [issue26002] make statistics.median_grouped more efficient
In-Reply-To: <1451830918.88.0.211778162331.issue26002@psf.upfronthosting.co.za>
Message-ID: <20160504184721.15811.28044.8B2E698F@psf.io>


Roundup Robot added the comment:

New changeset 7b2fafd78c1d by Steven D'Aprano in branch 'default':
Issue 26002 and 25974
https://hg.python.org/cpython/rev/7b2fafd78c1d

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

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

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: [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:14:27 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 04 May 2016 19:14:27 +0000
Subject: [issue26926] Large files are not supported on Android
In-Reply-To: <1462283737.14.0.888848894928.issue26926@psf.upfronthosting.co.za>
Message-ID: <1462389267.31.0.471588475749.issue26926@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Here is a patch that uses resource.setrlimit() to check whether large file may not be supported.

----------
keywords: +patch
Added file: http://bugs.python.org/file42720/large_file.patch

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

From report at bugs.python.org  Wed May  4 15:30:07 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 04 May 2016 19:30:07 +0000
Subject: [issue26765] Factor out common bytes and bytearray implementation
In-Reply-To: <1460707559.13.0.709090380773.issue26765@psf.upfronthosting.co.za>
Message-ID: <20160504192353.46266.10034.E7C528D1@psf.io>


Roundup Robot added the comment:

New changeset 41969033eb9d by Serhiy Storchaka in branch 'default':
Issue #26765: Moved common code and docstrings for bytes and bytearray methods
https://hg.python.org/cpython/rev/41969033eb9d

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

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

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: [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 15:47:19 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Wed, 04 May 2016 19:47:19 +0000
Subject: [issue26855] android: add platform.android_ver()
In-Reply-To: <1461676711.89.0.563475479331.issue26855@psf.upfronthosting.co.za>
Message-ID: <1462391239.91.0.0396646991777.issue26855@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

Several questions on implementation:
1. Should Android 4.1 supported? If not pass_fds and logics for deriving it can be removed.
2. I can't find ro.build.version.full on any device/emulator I have access to. Maybe it should be removed due to low popularity?

Some related Android source codes, as my implementation basis:
1. Android 4.1's ANDROID_PROPERTY_WORKSPACE: https://android.googlesource.com/platform/bionic/+/android-4.1.1_r1/libc/bionic/system_properties.c#55
2. The Android Framework assumes property values to be valid UTF-8: https://android.googlesource.com/platform/frameworks/base/+/android-5.1.1_r37/core/jni/android_os_SystemProperties.cpp#49. In fact if I feed a malformed /system/build.prop to DalvikVM, it crashes [1]
3. Google's Android Compatibility Test Suite (CTS) [2] assumes `getprop` binary is in $PATH and can be executed: https://android.googlesource.com/platform/cts/+/android-5.1.1_r37/tests/tests/os/src/android/os/cts/BuildTest.java#110

[1] https://github.com/rave-engine/python3-android/pull/10#issuecomment-159390390
[2] https://source.android.com/compatibility/cts/

----------
Added file: http://bugs.python.org/file42721/android_ver.patch

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

From report at bugs.python.org  Wed May  4 15:47:26 2016
From: report at bugs.python.org (SilentGhost)
Date: Wed, 04 May 2016 19:47:26 +0000
Subject: [issue26958] Suggestion to imporve queue.full reliability
In-Reply-To: <1462390632.09.0.248563716558.issue26958@psf.upfronthosting.co.za>
Message-ID: <1462391246.71.0.392132438446.issue26958@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
components: +Library (Lib)
nosy: +rhettinger

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

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


Sudharsan R added the comment:

Just add on to it..
q=queue.Queue()
with q.not_full:
	q.put_nowait(1)

this will hang. So if we acquire the not_full while computing size, all puts will wait. Same is the case for q.empty() and q.not_empty method and condition respectively.

----------

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

From report at bugs.python.org  Wed May  4 15:59:03 2016
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 04 May 2016 19:59:03 +0000
Subject: [issue26855] android: add platform.android_ver()
In-Reply-To: <1462391239.91.0.0396646991777.issue26855@psf.upfronthosting.co.za>
Message-ID: <572A5481.3020701@egenix.com>


Marc-Andre Lemburg added the comment:

On 04.05.2016 21:47, Chi Hsuan Yen wrote:
> 1. Should Android 4.1 supported? If not pass_fds and logics for deriving it can be removed.

According to http://www.droid-life.com/tag/distribution/ the Jelly
Bean versions (4.1, 4.2 and 4.3) still have a sizable market
share, so if it's not too much trouble, I think supporting 4.1 would
be a plus.

> 2. I can't find ro.build.version.full on any device/emulator I have access to. Maybe it should be removed due to low popularity?

Agreed.

----------

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

From report at bugs.python.org  Wed May  4 16:07:38 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 04 May 2016 20:07:38 +0000
Subject: [issue26918] android: test_pipes fails
In-Reply-To: <1462266824.98.0.209704046857.issue26918@psf.upfronthosting.co.za>
Message-ID: <1462392458.23.0.81910751324.issue26918@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

The attached patch fixes this.

----------
keywords: +patch
Added file: http://bugs.python.org/file42722/no_tr_skipped.patch

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

From report at bugs.python.org  Wed May  4 16:10:43 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Wed, 04 May 2016 20:10:43 +0000
Subject: [issue26855] android: add platform.android_ver()
In-Reply-To: <1461676711.89.0.563475479331.issue26855@psf.upfronthosting.co.za>
Message-ID: <1462392643.03.0.240855244111.issue26855@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

Version 2 attached. Removed ro.build.version.full.

----------
Added file: http://bugs.python.org/file42723/android_ver.patch

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

From report at bugs.python.org  Wed May  4 16:11:22 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 May 2016 20:11:22 +0000
Subject: [issue26765] Factor out common bytes and bytearray implementation
In-Reply-To: <1460707559.13.0.709090380773.issue26765@psf.upfronthosting.co.za>
Message-ID: <1462392682.46.0.634463619233.issue26765@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is the second part of the patch. It moves common code for replace() method to template file Objects/stringlib/transmogrify.h.

----------

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

From report at bugs.python.org  Wed May  4 16:11:45 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 May 2016 20:11:45 +0000
Subject: [issue26765] Factor out common bytes and bytearray implementation
In-Reply-To: <1460707559.13.0.709090380773.issue26765@psf.upfronthosting.co.za>
Message-ID: <1462392705.07.0.145840567272.issue26765@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file42724/bytes_methods_stage2.patch

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

From report at bugs.python.org  Wed May  4 16:25:52 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 04 May 2016 20:25:52 +0000
Subject: [issue26957] Docs: remove duplicate "the" in description of `%z` in
 datetime docs
In-Reply-To: <1462388610.21.0.688244618598.issue26957@psf.upfronthosting.co.za>
Message-ID: <20160504202549.15727.16652.525839EC@psf.io>


Roundup Robot added the comment:

New changeset 580ddeccd689 by Berker Peksag in branch '3.5':
Issue #26957: Remove duplicate 'the' from datetime documentation
https://hg.python.org/cpython/rev/580ddeccd689

New changeset 3a069e5593ef by Berker Peksag in branch 'default':
Issue #26957: Remove duplicate 'the' from datetime documentation
https://hg.python.org/cpython/rev/3a069e5593ef

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

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

From report at bugs.python.org  Wed May  4 16:26:27 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 04 May 2016 20:26:27 +0000
Subject: [issue26957] Docs: remove duplicate "the" in description of `%z` in
 datetime docs
In-Reply-To: <1462388610.21.0.688244618598.issue26957@psf.upfronthosting.co.za>
Message-ID: <1462393587.69.0.891330296544.issue26957@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks!

----------
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type: enhancement -> behavior
versions: +Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed May  4 16:27:04 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 04 May 2016 20:27:04 +0000
Subject: [issue26893] ValueError exception raised when using IntEnum with an
 attribute called "name" and @unique decorator
In-Reply-To: <1462019726.06.0.0957572026567.issue26893@psf.upfronthosting.co.za>
Message-ID: <1462393624.62.0.23170980224.issue26893@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


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

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

From report at bugs.python.org  Wed May  4 16:29:59 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 04 May 2016 20:29:59 +0000
Subject: [issue26918] android: test_pipes fails
In-Reply-To: <1462266824.98.0.209704046857.issue26918@psf.upfronthosting.co.za>
Message-ID: <1462393799.36.0.376007377333.issue26918@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Is tr not available on Android?! I would suggest to use sed instead, but I afraid sed is not available too. What commands are available at all?

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

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

From report at bugs.python.org  Wed May  4 16:51:38 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 04 May 2016 20:51:38 +0000
Subject: [issue26949] IDLE restarts when one debugs code raising SystemExit
Message-ID: <1462395098.97.0.302049116339.issue26949@psf.upfronthosting.co.za>


New submission from Terry J. Reedy:

To be more specific: if one runs a file, the shell is restarted (with the file name).  In the file, raise SystemExit is normally the same as running off the end of the file, and a prompt is printed.  If one runs a file with debugger on, [DEBUG ON] is printed before the prompt.  However, SystemExit while debugging causes a Restart Shell before the [DEBUG ON] and >>> prompt.  The 2nd restart does not normally happen when debugging finishes.  It does not happen when any other exception is raised; instead a traceback is printed as normal.

This is a minor bug, but it does prevent interactive examination of the process after debugging.

There is special code in run.py to catch SystemExit and not print a traceback.  My guess in a bug in RemoteDebugger.py that causes (allows) the execution process to exit or otherwise get detached from the IDLE process.  When the IDLE process loses contact with the current execution process, it starts a new one.

----------

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

From report at bugs.python.org  Wed May  4 16:53:32 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 04 May 2016 20:53:32 +0000
Subject: [issue26956] About Idle-x  version not updated for  1.13
In-Reply-To: <1462379265.06.0.476376304833.issue26956@psf.upfronthosting.co.za>
Message-ID: <1462395212.93.0.310672539333.issue26956@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

This is the wrong tracker for this report.  Idle-X is a 3rd party IDLE extension maintained elsewhere.

----------
resolution:  -> third party
status: open -> closed

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

From report at bugs.python.org  Wed May  4 16:53:44 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 04 May 2016 20:53:44 +0000
Subject: [issue26956] About Idle-x  version not updated for  1.13
In-Reply-To: <1462379265.06.0.476376304833.issue26956@psf.upfronthosting.co.za>
Message-ID: <1462395224.19.0.447140240206.issue26956@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed May  4 16:56:39 2016
From: report at bugs.python.org (ppperry)
Date: Wed, 04 May 2016 20:56:39 +0000
Subject: [issue26949] IDLE restarts when one debugs code raising SystemExit
In-Reply-To: <1462395098.97.0.302049116339.issue26949@psf.upfronthosting.co.za>
Message-ID: <1462395399.59.0.818803469161.issue26949@psf.upfronthosting.co.za>


ppperry added the comment:

Terry, Your `how to reproduce` is more complicated than necessary. This bug can be reproduced by just turning on the debugger in a python shell and typing `raise SystemExit` then pressing step in the debugger.

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

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

From report at bugs.python.org  Wed May  4 17:13:59 2016
From: report at bugs.python.org (Rohit Jamuar)
Date: Wed, 04 May 2016 21:13:59 +0000
Subject: [issue26876] Extend MSVCCompiler class to respect environment
 variables
In-Reply-To: <1461866719.82.0.2605655084.issue26876@psf.upfronthosting.co.za>
Message-ID: <1462396439.16.0.66875999571.issue26876@psf.upfronthosting.co.za>


Changes by Rohit Jamuar <rohit.jamuar at intel.com>:


Removed file: http://bugs.python.org/file42642/msvc_respect_env_flags.patch

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

From report at bugs.python.org  Wed May  4 17:15:28 2016
From: report at bugs.python.org (Rohit Jamuar)
Date: Wed, 04 May 2016 21:15:28 +0000
Subject: [issue26876] Extend MSVCCompiler class to respect environment
 variables
In-Reply-To: <1461866719.82.0.2605655084.issue26876@psf.upfronthosting.co.za>
Message-ID: <1462396528.11.0.924566370347.issue26876@psf.upfronthosting.co.za>


Changes by Rohit Jamuar <rohit.jamuar at intel.com>:


----------
versions: +Python 3.6 -Python 2.7
Added file: http://bugs.python.org/file42725/distutils_patch_master.patch

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

From report at bugs.python.org  Wed May  4 17:15:54 2016
From: report at bugs.python.org (Rohit Jamuar)
Date: Wed, 04 May 2016 21:15:54 +0000
Subject: [issue26876] Extend MSVCCompiler class to respect environment
 variables
In-Reply-To: <1461866719.82.0.2605655084.issue26876@psf.upfronthosting.co.za>
Message-ID: <1462396554.07.0.624458144836.issue26876@psf.upfronthosting.co.za>


Changes by Rohit Jamuar <rohit.jamuar at intel.com>:


----------
versions: +Python 2.7 -Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42726/distutils_patch_27.patch

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

From report at bugs.python.org  Wed May  4 17:21:19 2016
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 04 May 2016 21:21:19 +0000
Subject: [issue26876] Extend MSVCCompiler class to respect environment
 variables
In-Reply-To: <1461866719.82.0.2605655084.issue26876@psf.upfronthosting.co.za>
Message-ID: <1462396879.73.0.531402394737.issue26876@psf.upfronthosting.co.za>


Zachary Ware added the comment:

(The version field is for the whole issue, not per patch.)

----------
versions: +Python 3.5, Python 3.6

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

From report at bugs.python.org  Wed May  4 19:48:23 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 04 May 2016 23:48:23 +0000
Subject: [issue26958] Suggestion to imporve queue.full reliability
In-Reply-To: <1462390632.09.0.248563716558.issue26958@psf.upfronthosting.co.za>
Message-ID: <1462405703.78.0.0981202529077.issue26958@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

The reliability issue for qsize(), empty(), and full() has nothing to do with their implementations.  The problem is that any information obtained by those methods is potentially out-of-date by the time you try to use it (the LBYL problem).  This is why multi-threaded programmers prefer (try: os.remove(fn) except OSError: pass) over (if os.path.exists(fn): os.remove(fn)) where the latter has an intrinsic race condition regardless of the implementation of os.path.exists().

One other note, self.not_full uses self.mutex internally.  There is only one underlying lock for the whole queue implementation.

Lastly, despite not having an underscore prefix in its name, q.not_full() is not part of the public API.  Your "it hangs" example is part of the reason why ;-)

In general, don't use full and empty tests to decide whether or not to do a put or get.  Instead, just try the put or get directly and catch the exception if queue turns out to be full or empty.

----------
resolution:  -> not a bug
status: open -> closed

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

From report at bugs.python.org  Wed May  4 20:13:49 2016
From: report at bugs.python.org (Vsevolod Velichko)
Date: Thu, 05 May 2016 00:13:49 +0000
Subject: [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:16:03 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 05 May 2016 00:16:03 +0000
Subject: [issue26949] IDLE restarts when one debugs code raising SystemExit
In-Reply-To: <1462395098.97.0.302049116339.issue26949@psf.upfronthosting.co.za>
Message-ID: <1462407363.16.0.194748463311.issue26949@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Thanks, that may make debugging this (and creating a test) easier.  I have only seriously used debugger with files, and often with breakpoints in the file.

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

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

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: [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 20:28:01 2016
From: report at bugs.python.org (Chris Beaumont)
Date: Thu, 05 May 2016 00:28:01 +0000
Subject: [issue26960] urllib hangs when closing connection
In-Reply-To: <1462407954.17.0.565805320206.issue26960@psf.upfronthosting.co.za>
Message-ID: <1462408081.68.0.716649063173.issue26960@psf.upfronthosting.co.za>


Changes by Chris Beaumont <chrisnbeaumont at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file42728/urllib.patch

_______________________________________
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: [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  Wed May  4 21:43:49 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 05 May 2016 01:43:49 +0000
Subject: [issue26961] Add operator.get_providing_type
In-Reply-To: <1462412614.49.0.691089118164.issue26961@psf.upfronthosting.co.za>
Message-ID: <1462412629.74.0.904956577187.issue26961@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


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

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

From report at bugs.python.org  Wed May  4 21:50:21 2016
From: report at bugs.python.org (Meador Inge)
Date: Thu, 05 May 2016 01:50:21 +0000
Subject: [issue26881] modulefinder should reuse the dis module
In-Reply-To: <1461912649.38.0.754834410981.issue26881@psf.upfronthosting.co.za>
Message-ID: <1462413021.88.0.397487267787.issue26881@psf.upfronthosting.co.za>


Meador Inge added the comment:

Overall, this patch LGTM.  Some new tests would be nice.  Especially since the NEWS entry claims that we now support extended args.

As for for the compatibility concerns, I don't know.

----------
nosy: +meador.inge

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

From report at bugs.python.org  Wed May  4 21:54:07 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 05 May 2016 01:54:07 +0000
Subject: [issue26948] Simplify PyImport_ImportModuleLevelObject: avoid
 temporary tuple of str.partition/rpartition
In-Reply-To: <1462366096.99.0.505486204929.issue26948@psf.upfronthosting.co.za>
Message-ID: <1462413247.22.0.87671799817.issue26948@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

No objections from me (and I don't have anything to add to Serhiy's comments on the code review)

----------

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

From report at bugs.python.org  Wed May  4 21:54:13 2016
From: report at bugs.python.org (Meador Inge)
Date: Thu, 05 May 2016 01:54:13 +0000
Subject: [issue26765] Factor out common bytes and bytearray implementation
In-Reply-To: <1460707559.13.0.709090380773.issue26765@psf.upfronthosting.co.za>
Message-ID: <1462413253.91.0.970513540715.issue26765@psf.upfronthosting.co.za>


Meador Inge added the comment:

LGTM.

----------

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

From report at bugs.python.org  Wed May  4 22:04:52 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 05 May 2016 02:04:52 +0000
Subject: [issue26002] make statistics.median_grouped more efficient
In-Reply-To: <1451830918.88.0.211778162331.issue26002@psf.upfronthosting.co.za>
Message-ID: <1462413892.77.0.16761548466.issue26002@psf.upfronthosting.co.za>


Changes by Steven D'Aprano <steve+python at pearwood.info>:


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

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

From report at bugs.python.org  Wed May  4 22:43:27 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 05 May 2016 02:43:27 +0000
Subject: [issue25724] SSLv3 test failure on Ubuntu 16.04 LTS
In-Reply-To: <1448379899.26.0.590688499284.issue25724@psf.upfronthosting.co.za>
Message-ID: <1462416207.85.0.373038968576.issue25724@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Ubuntu 16.04 has came out and test_ssl fails. I already opened a issue about it. See issue26867.

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

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

From report at bugs.python.org  Wed May  4 23:42:04 2016
From: report at bugs.python.org (Joe Jevnik)
Date: Thu, 05 May 2016 03:42:04 +0000
Subject: [issue25770] expose name, args, and kwargs from methodcaller
In-Reply-To: <1448935631.22.0.209196895729.issue25770@psf.upfronthosting.co.za>
Message-ID: <1462419724.88.0.186536441696.issue25770@psf.upfronthosting.co.za>


Joe Jevnik added the comment:

people have had some time to think about this, whats should the name be so we can merge this?

----------

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

From report at bugs.python.org  Thu May  5 00:43:15 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 May 2016 04:43:15 +0000
Subject: [issue26961] Add operator.get_providing_type
In-Reply-To: <1462412614.49.0.691089118164.issue26961@psf.upfronthosting.co.za>
Message-ID: <1462423395.02.0.94489849307.issue26961@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could you please provide an example of using get_providing_type? If this is intended primarily as a debugging aid, I think the inspect module is better place than the operator module. I don't know wherever this functionality is already provided by the inspect module.

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

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

From report at bugs.python.org  Thu May  5 01:31:52 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 05 May 2016 05:31:52 +0000
Subject: [issue26947] Documentation improvement needed
In-Reply-To: <1462364495.31.0.190726094652.issue26947@psf.upfronthosting.co.za>
Message-ID: <1462426312.42.0.130728377821.issue26947@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

As a non-native speaker, actually I prefer the original one. But both versions lead to no confusion for me.

----------

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

From report at bugs.python.org  Thu May  5 01:41:16 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 05 May 2016 05:41:16 +0000
Subject: [issue26961] Provide an API to help debug super().__getattribute__
 results
In-Reply-To: <1462412614.49.0.691089118164.issue26961@psf.upfronthosting.co.za>
Message-ID: <1462426876.22.0.684928596744.issue26961@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

The main reason for suggesting operator is that it needs to be in an extension module if it's going to share the underlying lookup algorithm used by super().__getattribute__ rather than reimplementing it.

I'm not particularly concerned about the exact API name though, so I changed the title of the issue to explain the problem to be solved, rather than to propose a particular solution.

Doug, could you provide a specific example of the cryptic traceback that started the discussion?

----------
title: Add operator.get_providing_type -> Provide an API to help debug super().__getattribute__ results

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

From report at bugs.python.org  Thu May  5 02:26:30 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 05 May 2016 06:26:30 +0000
Subject: [issue26765] Factor out common bytes and bytearray implementation
In-Reply-To: <1460707559.13.0.709090380773.issue26765@psf.upfronthosting.co.za>
Message-ID: <20160505062627.42367.76594.7DC55537@psf.io>


Roundup Robot added the comment:

New changeset f4406d746d27 by Serhiy Storchaka in branch 'default':
Issue #26765: Moved common code for the replace() method of bytes and bytearray
https://hg.python.org/cpython/rev/f4406d746d27

----------

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

From report at bugs.python.org  Thu May  5 02:38:24 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 May 2016 06:38:24 +0000
Subject: [issue26765] Factor out common bytes and bytearray implementation
In-Reply-To: <1460707559.13.0.709090380773.issue26765@psf.upfronthosting.co.za>
Message-ID: <1462430304.46.0.146029711325.issue26765@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Meador.

Stage 3 patch is simple. It just adds guards in bytes-specific and unicode-specific template files to be sure that they are not used with wrong type.

----------
Added file: http://bugs.python.org/file42729/bytes_methods_stage3.patch

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

From report at bugs.python.org  Thu May  5 02:42:31 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 05 May 2016 06:42:31 +0000
Subject: [issue26961] Provide an API to help debug super().__getattribute__
 results
In-Reply-To: <1462412614.49.0.691089118164.issue26961@psf.upfronthosting.co.za>
Message-ID: <1462430551.24.0.420531983998.issue26961@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Actually, since this is intended primarily for debugging:

Doug, do you actually need the type information? Or would combining inspect.getsourcefile() and inspect.getlines() with super().__init__ to locate the source code for the offending method implementation be sufficient?

If that's the case, then the only benefit of this API would be to extend such debugging to extension module types in addition to regular Python classes.

----------

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

From report at bugs.python.org  Thu May  5 02:57:36 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 May 2016 06:57:36 +0000
Subject: [issue26765] Factor out common bytes and bytearray implementation
In-Reply-To: <1460707559.13.0.709090380773.issue26765@psf.upfronthosting.co.za>
Message-ID: <1462431456.7.0.00424874848193.issue26765@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Stage 4 patch moves thin wrappers around functions from bytes_methods.c to Objects/stringlib/transmogrify.h. The _method_ suffix is added to some names to distinguish them from existing stringlib names.

I'm not sure this is a good place. It may be better to add separate file (I'm going to move more simple wrappers here), but I don't have good name for it (bytes_methods.h is already used). Any ideas?

----------
Added file: http://bugs.python.org/file42730/bytes_methods_stage4.patch

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

From report at bugs.python.org  Thu May  5 03:12:30 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 05 May 2016 07:12:30 +0000
Subject: [issue26918] android: test_pipes fails
In-Reply-To: <1462266824.98.0.209704046857.issue26918@psf.upfronthosting.co.za>
Message-ID: <1462432350.74.0.760982782991.issue26918@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Here is the list of commands at /system/bin on the emulator.

----------
Added file: http://bugs.python.org/file42731/emulator_system_bin.txt

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

From report at bugs.python.org  Thu May  5 03:15:00 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 05 May 2016 07:15:00 +0000
Subject: [issue26918] android: test_pipes fails
In-Reply-To: <1462266824.98.0.209704046857.issue26918@psf.upfronthosting.co.za>
Message-ID: <1462432500.19.0.742882845008.issue26918@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Thanks for the review Serhiy. New patch attached.

----------
Added file: http://bugs.python.org/file42732/no_tr_skipped_2.patch

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

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: [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 03:56:14 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 05 May 2016 07:56:14 +0000
Subject: [issue26962] curses documenation- keys for Page Up and Page Down are
 reversed
In-Reply-To: <1462434806.76.0.440361178857.issue26962@psf.upfronthosting.co.za>
Message-ID: <1462434974.12.0.451048008512.issue26962@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Good catch, I forgot to update 2.7 (3.2, 3.3 and 3.4 are in security-fix-only mode so they don't get documentation updates anymore).

----------
nosy: +berker.peksag
versions:  -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 03:56:27 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 05 May 2016 07:56:27 +0000
Subject: [issue26918] android: test_pipes fails
In-Reply-To: <1462266824.98.0.209704046857.issue26918@psf.upfronthosting.co.za>
Message-ID: <20160505075623.21003.29009.9E581ABF@psf.io>


Roundup Robot added the comment:

New changeset 3bad4b0f7612 by Serhiy Storchaka in branch 'default':
Issue #26918: Skipped some tests in test_pipes on Android.
https://hg.python.org/cpython/rev/3bad4b0f7612

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

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

From report at bugs.python.org  Thu May  5 04:00:25 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 May 2016 08:00:25 +0000
Subject: [issue26918] android: test_pipes fails
In-Reply-To: <1462266824.98.0.209704046857.issue26918@psf.upfronthosting.co.za>
Message-ID: <1462435225.79.0.991619942548.issue26918@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM. Thanks Xavier.

It looks to me that there are no useful commands that can be used for testing on Android. We could use md5 or grep, but this would require rewriting tests too much for small benefit. It is better to skip tests.

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

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

From report at bugs.python.org  Thu May  5 04:04:42 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 05 May 2016 08:04:42 +0000
Subject: [issue26918] android: test_pipes fails
In-Reply-To: <1462266824.98.0.209704046857.issue26918@psf.upfronthosting.co.za>
Message-ID: <1462435482.11.0.424502008526.issue26918@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Ooops too late. Here is a new patch that replaces the tr command and allows all the tests of test_pipes to run successfully on android.

----------
Added file: http://bugs.python.org/file42733/replace_tr.patch

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

From report at bugs.python.org  Thu May  5 04:05:41 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 05 May 2016 08:05:41 +0000
Subject: [issue26962] curses documenation- keys for Page Up and Page Down are
 reversed
In-Reply-To: <1462434806.76.0.440361178857.issue26962@psf.upfronthosting.co.za>
Message-ID: <20160505080532.21003.90248.D74AFC09@psf.io>


Roundup Robot added the comment:

New changeset 4462e193f089 by Berker Peksag in branch '2.7':
Issue #26962: Backport 23d986228c6b to 2.7
https://hg.python.org/cpython/rev/4462e193f089

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

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

From report at bugs.python.org  Thu May  5 04:06:10 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 05 May 2016 08:06:10 +0000
Subject: [issue26962] curses documenation- keys for Page Up and Page Down are
 reversed
In-Reply-To: <1462434806.76.0.440361178857.issue26962@psf.upfronthosting.co.za>
Message-ID: <1462435570.12.0.919244233774.issue26962@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks!

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

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

From report at bugs.python.org  Thu May  5 04:14:17 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 05 May 2016 08:14:17 +0000
Subject: [issue26915] Test identity first in membership operation of ItemsView, 
 ValuesView and Sequence in collections.abc
In-Reply-To: <1462256356.96.0.954300432794.issue26915@psf.upfronthosting.co.za>
Message-ID: <20160505081412.9349.21514.CB26AAC7@psf.io>


Roundup Robot added the comment:

New changeset 1c6cf4010df3 by Raymond Hettinger in branch 'default':
Issue 26915:  Add identity checks to the collections ABC __contains__ methods.
https://hg.python.org/cpython/rev/1c6cf4010df3

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

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

From report at bugs.python.org  Thu May  5 04:17:31 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 05 May 2016 08:17:31 +0000
Subject: [issue26915] Test identity first in membership operation of ItemsView, 
 ValuesView and Sequence in collections.abc
In-Reply-To: <1462256356.96.0.954300432794.issue26915@psf.upfronthosting.co.za>
Message-ID: <1462436251.67.0.60504828372.issue26915@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Xiang, hanks for the patch and for the link to Guido's opinion.

Josh, I concur with your sentiments.  In this case the burden is light and is likely to prevent future difficulties by keeping the container invariants intact.

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

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

From report at bugs.python.org  Thu May  5 04:18:23 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 May 2016 08:18:23 +0000
Subject: [issue26926] Large files are not supported on Android
In-Reply-To: <1462283737.14.0.888848894928.issue26926@psf.upfronthosting.co.za>
Message-ID: <1462436303.24.0.99620716388.issue26926@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The resource module is not always available. And resource.setrlimit() itself can fail.

May be check HAVE_LARGEFILE_SUPPORT directly using sysconfig.get_config_vars()?

test_mmap needs similar fix.

----------

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

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: [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 04:21:34 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 May 2016 08:21:34 +0000
Subject: [issue26926] Large files are not supported on Android
In-Reply-To: <1462283737.14.0.888848894928.issue26926@psf.upfronthosting.co.za>
Message-ID: <1462436494.48.0.633811652255.issue26926@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Skipping test is the one way.

Other way is to enable large files support on Android (like it was done in issue11184 for AIX). It is hard to believe that Android's libc doesn't support files larger 2GiB. Should be an option to enable this support in a program.

----------

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

From report at bugs.python.org  Thu May  5 04:25:07 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 May 2016 08:25:07 +0000
Subject: [issue26915] Test identity first in membership operation of ItemsView, 
 ValuesView and Sequence in collections.abc
In-Reply-To: <1462256356.96.0.954300432794.issue26915@psf.upfronthosting.co.za>
Message-ID: <1462436707.92.0.153416907201.issue26915@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Is it worth to add a function in the operator module that tests arguments for identity or equality?

----------

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

From report at bugs.python.org  Thu May  5 04:40:41 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 May 2016 08:40:41 +0000
Subject: [issue26963] compile() expected string without null bytes
In-Reply-To: <1462436390.77.0.0191019210095.issue26963@psf.upfronthosting.co.za>
Message-ID: <1462437641.2.0.289952926809.issue26963@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

compile() always required a string without null bytes. If it accepted a string with null bytes in 2.7.10 (I don't see the confirmation on this in the source code), it was a bug and is fixed.

----------
nosy: +serhiy.storchaka
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Thu May  5 04:50:24 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 05 May 2016 08:50:24 +0000
Subject: [issue26915] Test identity first in membership operation of ItemsView, 
 ValuesView and Sequence in collections.abc
In-Reply-To: <1462256356.96.0.954300432794.issue26915@psf.upfronthosting.co.za>
Message-ID: <1462438224.12.0.571554444865.issue26915@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

In my opinion it's not worth. If there is such an operator in stdlib, I would expect more, exposing PyObject_RichCompareBool in Python level, providing a new operator like `===`.

----------

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

From report at bugs.python.org  Thu May  5 05:10:22 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 05 May 2016 09:10:22 +0000
Subject: [issue26926] Large files are not supported on Android
In-Reply-To: <1462283737.14.0.888848894928.issue26926@psf.upfronthosting.co.za>
Message-ID: <1462439422.97.0.518236550955.issue26926@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Using the glibc compilation flags recommended for large file support '-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE=1 -D_LARGEFILE64_SOURCE=1' does not enable large file support. See Suse's 'Large File Support in Linux' document [1].

In the android issue 64613 [2] one of the last comment said, only few days ago,  "fixed in the platform. (partially in L, mostly in M, completely in N.)", L standing for Lollipop (API 21 or 22) and M for Marshmallow (API 23). So it seems these tests should be skipped until platform N is available.

[1] http://users.suse.com/~aj/linux_lfs.html
[2] https://code.google.com/p/android/issues/detail?id=64613

----------

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

From report at bugs.python.org  Thu May  5 05:16:50 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 May 2016 09:16:50 +0000
Subject: [issue26915] Test identity first in membership operation of ItemsView, 
 ValuesView and Sequence in collections.abc
In-Reply-To: <1462256356.96.0.954300432794.issue26915@psf.upfronthosting.co.za>
Message-ID: <1462439810.72.0.254158904734.issue26915@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

What about Sequence.index and Sequence.count?

----------

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

From report at bugs.python.org  Thu May  5 06:08:06 2016
From: report at bugs.python.org (mPython)
Date: Thu, 05 May 2016 10:08:06 +0000
Subject: [issue26947] Documentation improvement needed
In-Reply-To: <1462364495.31.0.190726094652.issue26947@psf.upfronthosting.co.za>
Message-ID: <1462442886.91.0.753919377535.issue26947@psf.upfronthosting.co.za>


mPython added the comment:

Just to mention that I'm not native speaker, and I'm Django (Python) beginner. I'm very good in C++, Java and in last 12 years read a lot IT documentation. Mentioned sentence was not clear enough for me so I created this ticket.

----------

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

From report at bugs.python.org  Thu May  5 06:29:16 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 05 May 2016 10:29:16 +0000
Subject: [issue26915] Test identity first in membership operation of ItemsView, 
 ValuesView and Sequence in collections.abc
In-Reply-To: <1462256356.96.0.954300432794.issue26915@psf.upfronthosting.co.za>
Message-ID: <1462444156.41.0.0408946428638.issue26915@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Oops, I forgot about them. I think they should. Raymond mentioned count in msg75735. Attach patch to take them in.

----------
Added file: http://bugs.python.org/file42734/issue26915_s2.patch

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

From report at bugs.python.org  Thu May  5 06:44:40 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 05 May 2016 10:44:40 +0000
Subject: [issue26928] android: test_site fails
In-Reply-To: <1462284365.5.0.819379627022.issue26928@psf.upfronthosting.co.za>
Message-ID: <1462445080.44.0.201210369439.issue26928@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

The problem is caused by the fact that android does not have HAVE_LANGINFO_H and CODESET set, hence in the _bootlocale module, the statement '_locale.CODESET' raises AttributeError and the locale module is imported upon interpreter startup. The locale module imports re.

See issue #19205 for why we would rather not import re and locale on startup.

This seems difficult to fix without either skipping most part of the test as it is done with Mac OS X, or having a specific sys.platform for android to handle the AttributeError in _bootlocale by having the getpreferredencoding() fuction returning 'UTF-8' ('UTF-8' is the file system encoding on android).

----------

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

From report at bugs.python.org  Thu May  5 06:48:07 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 05 May 2016 10:48:07 +0000
Subject: [issue26928] android: test_site fails
In-Reply-To: <1462284365.5.0.819379627022.issue26928@psf.upfronthosting.co.za>
Message-ID: <1462445287.92.0.393737257982.issue26928@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

BTW the test runs fine on android when the AttributeError in _bootlocale is hard-coded with a getpreferredencoding() fuction returning 'UTF-8' and not importing locale.

----------

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

From report at bugs.python.org  Thu May  5 07:53:43 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 May 2016 11:53:43 +0000
Subject: [issue26881] modulefinder should reuse the dis module
In-Reply-To: <1461912649.38.0.754834410981.issue26881@psf.upfronthosting.co.za>
Message-ID: <1462449223.71.0.104648671684.issue26881@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Added test.

But this test is fragile. Clever optimizer can made it passing even with modulefinder not supporting extended args (I'm going to provide such optimization).

----------
Added file: http://bugs.python.org/file42735/dis_unpack_args_3.patch

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

From report at bugs.python.org  Thu May  5 08:40:02 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 May 2016 12:40:02 +0000
Subject: [issue26918] android: test_pipes fails
In-Reply-To: <1462266824.98.0.209704046857.issue26918@psf.upfronthosting.co.za>
Message-ID: <1462452002.32.0.96838623763.issue26918@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The equivalent of used "tr" command is .upper(), not .swapcase().

Instead of the loop

    for s in sys.stdin.read(): sys.stdout.write(s.upper())

you can write just

    sys.stdout.write(sys.stdin.read().upper())

But actually the loop is needed for testing purpose.

    while True:
        b = sys.stdin.buffer.read(1)
        if not b:
            break
        sys.stdout.buffer.write(b.upper())

And sys.executable should be escaped for the case of spaces or other special symbols in the path.

All this complicates tests too much. I prefer to skip some tests on Android.

----------

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

From report at bugs.python.org  Thu May  5 09:22:36 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 May 2016 13:22:36 +0000
Subject: [issue26811] segfault due to null pointer in tuple
In-Reply-To: <1461198016.05.0.40690695807.issue26811@psf.upfronthosting.co.za>
Message-ID: <1462454556.75.0.310941132888.issue26811@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu May  5 09:41:35 2016
From: report at bugs.python.org (Doug Hellmann)
Date: Thu, 05 May 2016 13:41:35 +0000
Subject: [issue26961] Provide an API to help debug super().__getattribute__
 results
In-Reply-To: <1462412614.49.0.691089118164.issue26961@psf.upfronthosting.co.za>
Message-ID: <1462455695.62.0.724870098786.issue26961@psf.upfronthosting.co.za>


Doug Hellmann added the comment:

The specific case I have right now is with a large code base written by someone else who is seeing a TypeError when they call super(their-local-class, self).__init__() because whatever class super() is returning is expecting arguments to __init__(). The TypeError thrown doesn't say what is being called (that's a separate issue) so I was trying to debug. The __init__() method of super() is a special wrapper, so there isn't any way using only super() to access the class it has decided to use. I'm currently walking the MRO by hand to find the class that's causing the problem. I expected to be able to do something like super(their-local-class, self).give_me_the_type_with('__init__') and get back a class.

----------

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

From report at bugs.python.org  Thu May  5 11:22:48 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Thu, 05 May 2016 15:22:48 +0000
Subject: [issue26918] android: test_pipes fails
In-Reply-To: <1462266824.98.0.209704046857.issue26918@psf.upfronthosting.co.za>
Message-ID: <1462461768.22.0.109321569058.issue26918@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

I agree with not complicating tests too much.

For the record, the pipes test suite coverage is very low and the code paths that lead to invocations of os.popen() in the pipes module are not tested when those three tests are skipped.

----------

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

From report at bugs.python.org  Thu May  5 11:24:51 2016
From: report at bugs.python.org (Doug Hellmann)
Date: Thu, 05 May 2016 15:24:51 +0000
Subject: [issue26961] Provide an API to help debug super().__getattribute__
 results
In-Reply-To: <1462412614.49.0.691089118164.issue26961@psf.upfronthosting.co.za>
Message-ID: <1462461891.5.0.297933851151.issue26961@psf.upfronthosting.co.za>


Doug Hellmann added the comment:

@Nick - Being able to get to the source is ok, but if I can get the actual type I can always get the source from that. I don't need the actual type object except to know what it is, and it seems more flexible to return the class object than a name or other reference to it that I then have to turn into the class object if I really did need it.

----------

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

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: [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 13:46:22 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 05 May 2016 17:46:22 +0000
Subject: [issue26961] Provide an API to help debug super().__getattribute__
 results
In-Reply-To: <1462412614.49.0.691089118164.issue26961@psf.upfronthosting.co.za>
Message-ID: <1462470382.45.0.781586352122.issue26961@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu May  5 13:51:59 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 05 May 2016 17:51:59 +0000
Subject: [issue19072] classmethod doesn't honour descriptor protocol of
 wrapped callable
In-Reply-To: <1379856164.11.0.6368818134.issue19072@psf.upfronthosting.co.za>
Message-ID: <1462470719.23.0.461321636073.issue19072@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Here is an updated patch with a test (adapted from msg198274.)

----------
nosy: +berker.peksag
stage:  -> patch review
versions: +Python 3.6 -Python 3.4
Added file: http://bugs.python.org/file42737/issue19072.diff

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

From report at bugs.python.org  Thu May  5 14:44:42 2016
From: report at bugs.python.org (Antti Haapala)
Date: Thu, 05 May 2016 18:44:42 +0000
Subject: [issue26906] format(object.__reduce__) fails intermittently
In-Reply-To: <1462194444.45.0.679859267338.issue26906@psf.upfronthosting.co.za>
Message-ID: <1462473882.52.0.27650880016.issue26906@psf.upfronthosting.co.za>


Antti Haapala added the comment:

I can reproduce the bug in 3.5.0+ Ubuntu with list iterator, if I execute python with -S:

    % python3.5 -S
    Python 3.5.0+ (default, Oct 11 2015, 09:05:38) 
    [GCC 5.2.1 20151010] on linux
    >>> format(iter([]))
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: Type list_iterator doesn't define __format__

Thus here it depends on the stuff that site does or doesn't do. Iterating over a list iterator does *not* trigger the initialization. Printing it doesn't help either, or anything else that does not touch the non-magic attributes. I am not even sure what the site.py and such are doing to the list iterator class to trigger the initialization.

----------

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

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: [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:51:41 2016
From: report at bugs.python.org (Ned Deily)
Date: Thu, 05 May 2016 18:51:41 +0000
Subject: [issue26965] spam
In-Reply-To: <1462474206.86.0.381535493708.issue26965@psf.upfronthosting.co.za>
Message-ID: <1462474301.93.0.791211301548.issue26965@psf.upfronthosting.co.za>


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


----------
resolution:  -> rejected
status: open -> closed
title: Turbotax Tech Support Mumber 1!!888!!226!!1422 turbotax Usa Canada -> spam
type: security -> 
versions:  -Python 3.6

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

From report at bugs.python.org  Thu May  5 14:52:15 2016
From: report at bugs.python.org (Ned Deily)
Date: Thu, 05 May 2016 18:52:15 +0000
Subject: [issue26965] spam
Message-ID: <1462474335.65.0.407433478561.issue26965@psf.upfronthosting.co.za>


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


----------
Removed message: http://bugs.python.org/msg264913

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

From report at bugs.python.org  Thu May  5 14:52:26 2016
From: report at bugs.python.org (Ned Deily)
Date: Thu, 05 May 2016 18:52:26 +0000
Subject: [issue26965] spam
Message-ID: <1462474346.16.0.705318442712.issue26965@psf.upfronthosting.co.za>


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


----------
nosy:  -Karan Rawat, larry

_______________________________________
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: [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 14:57:12 2016
From: report at bugs.python.org (Ned Deily)
Date: Thu, 05 May 2016 18:57:12 +0000
Subject: [issue26965] spam
Message-ID: <1462474632.64.0.815970746386.issue26965@psf.upfronthosting.co.za>


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


Removed 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:57:43 2016
From: report at bugs.python.org (Ned Deily)
Date: Thu, 05 May 2016 18:57:43 +0000
Subject: [issue26965] spam
Message-ID: <1462474663.33.0.294864459464.issue26965@psf.upfronthosting.co.za>


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


----------
components:  -Argument Clinic

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

From report at bugs.python.org  Thu May  5 14:58:30 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 05 May 2016 18:58:30 +0000
Subject: [issue26966] Spam
In-Reply-To: <1462474471.08.0.192781449816.issue26966@psf.upfronthosting.co.za>
Message-ID: <1462474710.13.0.324258825205.issue26966@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy:  -Karan Rawat, larry
resolution:  -> rejected
status: open -> closed
title: turbotax phone number 1**888**226**1422 support, turbotax tech support phone number 1**888**226**1422 -> Spam

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

From report at bugs.python.org  Thu May  5 14:58:54 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 05 May 2016 18:58:54 +0000
Subject: [issue26966] Spam
Message-ID: <1462474734.92.0.917848941508.issue26966@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
Removed message: http://bugs.python.org/msg264914

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

From report at bugs.python.org  Thu May  5 14:59:05 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 05 May 2016 18:59:05 +0000
Subject: [issue26966] Spam
Message-ID: <1462474745.32.0.410356681391.issue26966@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


Removed 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 14:59:51 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 05 May 2016 18:59:51 +0000
Subject: [issue26966] Spam
Message-ID: <1462474791.17.0.644431600762.issue26966@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
components:  -Argument Clinic
versions:  -Python 3.5

_______________________________________
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: [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:16:04 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 05 May 2016 19:16:04 +0000
Subject: [issue26967] argparse: allow_abbrev=False stops -vv from working
In-Reply-To: <1462475086.65.0.670765920247.issue26967@psf.upfronthosting.co.za>
Message-ID: <1462475764.5.0.84709704487.issue26967@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
keywords: +3.5regression
nosy: +berker.peksag
stage:  -> needs patch
versions: +Python 3.6

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

From report at bugs.python.org  Thu May  5 15:23:25 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 05 May 2016 19:23:25 +0000
Subject: [issue25177] OverflowError in statistics.mean when summing large
 floats
In-Reply-To: <1442662840.23.0.781753910755.issue25177@psf.upfronthosting.co.za>
Message-ID: <1462476205.88.0.38513825464.issue25177@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


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

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

From report at bugs.python.org  Thu May  5 15:28:39 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 May 2016 19:28:39 +0000
Subject: [issue19072] classmethod doesn't honour descriptor protocol of
 wrapped callable
In-Reply-To: <1379856164.11.0.6368818134.issue19072@psf.upfronthosting.co.za>
Message-ID: <1462476519.34.0.981097624863.issue19072@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

With the patch class properties work:

>>> class A:
...     @classmethod
...     @property
...     def __doc__(cls):
...         return 'A doc for %r' % cls.__name__
... 
>>> A.__doc__
"A doc for 'A'"

This is worth to be explicitly documented.

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

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

From report at bugs.python.org  Thu May  5 15:38:32 2016
From: report at bugs.python.org (Krzysztof Warzecha)
Date: Thu, 05 May 2016 19:38:32 +0000
Subject: [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  Thu May  5 15:55:32 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 05 May 2016 19:55:32 +0000
Subject: [issue26968] glob.glob incorrect results under windows when pathname
 exists but interpreter does not have access permissions to pathname
In-Reply-To: <1462477111.96.0.426689886808.issue26968@psf.upfronthosting.co.za>
Message-ID: <1462478132.58.0.825976444556.issue26968@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

What returns os.lstat('c:\\PerfLogs')?

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

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

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


Krzysztof Warzecha added the comment:

>>> os.lstat('c:\\PerfLogs')
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    PermissionError: [WinError 5] Odmowa dost?pu: 'c:\\PerfLogs'

(thats "Permission denied")

----------

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

From report at bugs.python.org  Thu May  5 16:10:12 2016
From: report at bugs.python.org (Antti Haapala)
Date: Thu, 05 May 2016 20:10:12 +0000
Subject: [issue26906] format(object.__reduce__) fails intermittently
In-Reply-To: <1462194444.45.0.679859267338.issue26906@psf.upfronthosting.co.za>
Message-ID: <1462479012.59.0.509030882852.issue26906@psf.upfronthosting.co.za>


Antti Haapala added the comment:

And to the other things failing, I was trying to find out which of the magic method ops fail, and for that tried to find out the `dir` of list iterator. Well...

    % python3.5 -S          
    Python 3.5.0+ (default, Oct 11 2015, 09:05:38) 
    [GCC 5.2.1 20151010] on linux
    >>> dir(iter([]))
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: object does not provide __dir__

----------

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

From report at bugs.python.org  Thu May  5 17:08:56 2016
From: report at bugs.python.org (paul czyzewski)
Date: Thu, 05 May 2016 21:08:56 +0000
Subject: [issue15786] IDLE code completion window can hang or misbehave with
 mouse
In-Reply-To: <1346027701.33.0.908436854594.issue15786@psf.upfronthosting.co.za>
Message-ID: <1462482536.0.0.772384454295.issue15786@psf.upfronthosting.co.za>


paul czyzewski added the comment:

I'm new to IDLE.  I just upgraded to Mac El Capitan from Snow Leopard, and installed Python 3.5.1 (v3.5.1:37a07cee5969, Dec  5 2015, 21:12:44).

I have had the IDLE window freeze so many times (when clicking on something in the autocomplete window as described by Ned Deily) that I consider IDLE unusable.  I'm not familiar with Python bug practices but I would consider this a serious bug because, as a product manager would probably put it, this is going to drive away a significant percentage of new users (i.e., unexplained freezing of the product when doing something which seems natural -- clicking on the item that I want to select).

BTW, looks like I'm on tcl 8.5:
>>> tkinter.TclVersion
8.5

Unrelated question:  which can't Mac Spotlight find tkinter.py?  is it in some compressed file or something, so I can't find a standalone py file?

----------
nosy: +paulsfo

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

From report at bugs.python.org  Thu May  5 17:28:32 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 05 May 2016 21:28:32 +0000
Subject: [issue26939] android: test_functools hangs on armv7
In-Reply-To: <1462289866.52.0.349587333392.issue26939@psf.upfronthosting.co.za>
Message-ID: <1462483712.67.0.588545971043.issue26939@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Can you post the backtraces of all threads (at least the innermost frames)?
Also, can you reproduce on an actual armv7 machine? Just wondering if there may be something peculiar in the emulator.

----------
nosy: +pitrou

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

From report at bugs.python.org  Thu May  5 17:37:46 2016
From: report at bugs.python.org (Eryk Sun)
Date: Thu, 05 May 2016 21:37:46 +0000
Subject: [issue26968] glob.glob incorrect results under windows when pathname
 exists but interpreter does not have access permissions to pathname
In-Reply-To: <1462477111.96.0.426689886808.issue26968@psf.upfronthosting.co.za>
Message-ID: <1462484266.84.0.768558176371.issue26968@psf.upfronthosting.co.za>


Eryk Sun added the comment:

The access control list of a file may not grant or may deny the current user the right to read file attributes (i.e. lstat). Generally you don't have to worry about granted access to parent directories when attempting to stat the file or directory, since even standard users have SeChangeNotifyPrivilege to bypass path traversal access checks. In this case, ISTM that we at least know the file exists if lstat raises PermissionError instead of FileNotFoundError. Currently os.path.lexists returns False for any OSError, without distinguishing between these two cases.

You may also come across a similar issue when a file's delete disposition is set, since Windows doesn't allow opening a deleted file, even to read its attributes, and it doesn't actually unlink the file or directory until all references are closed. 

For example, create a directory, opened with delete sharing:

    >>> h = _winapi.CreateFile('testglob', 0x40000000, 7, 0, 1,
    ...                        0x2000000|0x1000000|0x80|0x10, 0)
    >>> os.path.isdir('testglob')
    True

Before removing the directory, it can be globbed directly:

    >>> glob.glob('testglob')
    ['testglob']

After removing the directory, it can only be globbed indirectly by listing its parent directory:

    >>> os.rmdir('testglob')
    >>> os.lstat('testglob')
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    PermissionError: [WinError 5] Access is denied: 'testglob'

    >>> glob.glob('testglob')
    []
    >>> glob.glob('testglob*')
    ['testglob']

Once the handle is closed, the directory is unlinked:

    >>> _winapi.CloseHandle(h)
    >>> os.lstat('testglob')
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    FileNotFoundError: [WinError 2] The system cannot find the file specified: 'testglob'
    >>> glob.glob('testglob*')
    []

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

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

From report at bugs.python.org  Thu May  5 17:47:44 2016
From: report at bugs.python.org (Robert Jordens)
Date: Thu, 05 May 2016 21:47:44 +0000
Subject: [issue26156] Bad name into power operator syntax
In-Reply-To: <1453214486.32.0.13836493656.issue26156@psf.upfronthosting.co.za>
Message-ID: <1462484864.19.0.115802555056.issue26156@psf.upfronthosting.co.za>


Robert Jordens added the comment:

The original bug report is (apart from spelling) correct. This is a bug and it should be closed.

Please reopen.

This patch reverts the erroneous change in:

changeset:   96185:548d5704fcb3
user:        Yury Selivanov <yselivanov at sprymix.com>
date:        Thu May 21 11:50:30 2015 -0400
summary:     Issue 24180: Documentation for PEP 492 changes.

----------
keywords: +patch
nosy: +Robert.Jordens
Added file: http://bugs.python.org/file42740/issue26156_power.patch

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

From report at bugs.python.org  Thu May  5 17:51:43 2016
From: report at bugs.python.org (Robert Jordens)
Date: Thu, 05 May 2016 21:51:43 +0000
Subject: [issue26156] Bad name into power operator syntax
In-Reply-To: <1453214486.32.0.13836493656.issue26156@psf.upfronthosting.co.za>
Message-ID: <1462485103.43.0.723251234855.issue26156@psf.upfronthosting.co.za>


Robert Jordens added the comment:

That should have read "... should _not_ be closed."

----------

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

From report at bugs.python.org  Thu May  5 17:59:14 2016
From: report at bugs.python.org (R. David Murray)
Date: Thu, 05 May 2016 21:59:14 +0000
Subject: [issue26156] Bad name into power operator syntax
In-Reply-To: <1453214486.32.0.13836493656.issue26156@psf.upfronthosting.co.za>
Message-ID: <1462485554.94.0.918721522019.issue26156@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution: not a bug -> 
stage: resolved -> commit review
status: closed -> open

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

From report at bugs.python.org  Thu May  5 19:07:57 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 05 May 2016 23:07:57 +0000
Subject: [issue15786] IDLE code completion window can hang or misbehave with
 mouse
In-Reply-To: <1346027701.33.0.908436854594.issue15786@psf.upfronthosting.co.za>
Message-ID: <1462489677.83.0.943948083827.issue15786@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

As far as I know, freezing is limited to Macs.  In msg220751, Ned said "Further, then pressing "Return", "a", and "Tab" to try a new code completion results in the code completion window momentarily appearing then disappearing." The disappearance , and hence the later reappearance Ned describes, does not happen for me on Windows.

In my view, AutoComplete.py and AutoCompleteWindow.py need to be combined, refactored, re-written, and tested on all systems with a much more complete test suite.

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

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

From report at bugs.python.org  Thu May  5 19:15:28 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 05 May 2016 23:15:28 +0000
Subject: [issue25770] expose name, args, and kwargs from methodcaller
In-Reply-To: <1448935631.22.0.209196895729.issue25770@psf.upfronthosting.co.za>
Message-ID: <1462490128.53.0.585732300613.issue25770@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

To me, the best rhythm has always been (*args, **kwds).

----------

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

From report at bugs.python.org  Thu May  5 21:47:37 2016
From: report at bugs.python.org (Ned Deily)
Date: Fri, 06 May 2016 01:47:37 +0000
Subject: [issue15786] IDLE code completion window can hang or misbehave with
 mouse
In-Reply-To: <1346027701.33.0.908436854594.issue15786@psf.upfronthosting.co.za>
Message-ID: <1462499257.22.0.340649234567.issue15786@psf.upfronthosting.co.za>


Ned Deily added the comment:

Paul, also check to make sure you have installed the latest ActiveTcl Tcl/Tk 8.5.x (not 8.6.x) as described here:  https://www.python.org/download/mac/tcltk/.  One way to tell exactly which minor release of Tcl/Tk (the "x" in "8.5.x") is in use is to click on the "About IDLE" menu item in the "IDLE" menu or, depending on how you launched IDLE, "About Python" in the "Python" menu.  It should be 8.5.18 or higher and not 8.5.9 (the Apple-supplied version).

----------

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

From report at bugs.python.org  Thu May  5 22:55:10 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 06 May 2016 02:55:10 +0000
Subject: [issue26967] argparse: allow_abbrev=False stops -vv from working
In-Reply-To: <1462475086.65.0.670765920247.issue26967@psf.upfronthosting.co.za>
Message-ID: <1462503310.18.0.453705558853.issue26967@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu May  5 23:06:42 2016
From: report at bugs.python.org (paul czyzewski)
Date: Fri, 06 May 2016 03:06:42 +0000
Subject: [issue15786] IDLE code completion window can hang or misbehave with
 mouse
In-Reply-To: <1346027701.33.0.908436854594.issue15786@psf.upfronthosting.co.za>
Message-ID: <1462504002.33.0.487504257296.issue15786@psf.upfronthosting.co.za>


paul czyzewski added the comment:

Thanks, Terry and Ned.

Ned, I checked (nice clear instructions, btw) and I had Tk 8.5.10.  So I followed the link and installed 8.5.18.  -- The freeze on mac still occurs but I understand that this will avoid some other bugs.

BTW, I don't know how testing works for IDLE and Python, but that's what I do for a living, so maybe I'll try to get involved.

----------

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

From report at bugs.python.org  Thu May  5 23:19:37 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 06 May 2016 03:19:37 +0000
Subject: [issue26967] argparse: allow_abbrev=False stops -vv from working
In-Reply-To: <1462475086.65.0.670765920247.issue26967@psf.upfronthosting.co.za>
Message-ID: <1462504777.23.0.573297053512.issue26967@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

This is a side effect introduced by 99302634d756. You have to set allow_abbrev to True to make such match succeed. I think this is a bug.

----------

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

From report at bugs.python.org  Fri May  6 00:14:59 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 06 May 2016 04:14:59 +0000
Subject: [issue26967] argparse: allow_abbrev=False stops -vv from working
In-Reply-To: <1462475086.65.0.670765920247.issue26967@psf.upfronthosting.co.za>
Message-ID: <1462508099.27.0.0593307484084.issue26967@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

After some research I suggest to document this behaviour that allow_abbrev=False will suspend option prefix matching. Simply fixing the count action behaviour is not enough since it also prevents you from creating custom actions that want to use option prefix matching. What's your advice berker?

----------
nosy: +bethard

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

From report at bugs.python.org  Fri May  6 00:30:30 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 May 2016 04:30:30 +0000
Subject: [issue26156] Bad name into power operator syntax
In-Reply-To: <1453214486.32.0.13836493656.issue26156@psf.upfronthosting.co.za>
Message-ID: <1462509030.66.0.59703116191.issue26156@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The docs looks correct to me. It reflects the fact that the "await" keyword has higher priority than the power operator. "await a ** b" is identical to "(await a) ** b", not "await (a ** b)".

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

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

From report at bugs.python.org  Fri May  6 00:32:13 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 06 May 2016 04:32:13 +0000
Subject: [issue26156] Bad name into power operator syntax
In-Reply-To: <1462509030.66.0.59703116191.issue26156@psf.upfronthosting.co.za>
Message-ID: <F07DA0DFF279E4B6.9677DFB0-DA4C-45A9-B28A-8DE4FA07C5AD@mail.outlook.com>


Yury Selivanov added the comment:

Fwiw, I'm -1 on changing this. I think that the current names are correct.

----------
nosy: +Yury.Selivanov

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

From report at bugs.python.org  Fri May  6 00:41:23 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 May 2016 04:41:23 +0000
Subject: [issue26156] Bad name into power operator syntax
In-Reply-To: <1453214486.32.0.13836493656.issue26156@psf.upfronthosting.co.za>
Message-ID: <1462509683.44.0.312262232847.issue26156@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

But to avoid confusion I propose following patch. This may be more correct, since it is strange to name the expression without "await" "await expression".

----------
Added file: http://bugs.python.org/file42741/issue26156_await_power.patch

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

From report at bugs.python.org  Fri May  6 00:45:44 2016
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 06 May 2016 04:45:44 +0000
Subject: [issue26156] Bad name into power operator syntax
In-Reply-To: <1453214486.32.0.13836493656.issue26156@psf.upfronthosting.co.za>
Message-ID: <1462509944.3.0.95226144861.issue26156@psf.upfronthosting.co.za>


Zachary Ware added the comment:

I agree that what is currently in the docs is technically correct.  The section on the power operator:

   power ::=  await ["**" u_expr]

should be read as:

   power ::=  (["await"] primary) ["**" u_expr]

just as the definition of 'u_expr' below should be read as:

   u_expr ::=  (await ["**" u_expr]) | "-" u_expr | "+" u_expr | "~" u_expr

and 'await' should be read as:

   await ::= ["await"] (atom | attributeref | subscription | slicing | call)

Each definition builds upon previous ones.

However, it is confusing.  Could a name other than "await" be used, since "await" is easily confused with the keyword await?

----------
nosy: +zach.ware

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

From report at bugs.python.org  Fri May  6 00:49:03 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 May 2016 04:49:03 +0000
Subject: [issue26156] Bad name into power operator syntax
In-Reply-To: <1453214486.32.0.13836493656.issue26156@psf.upfronthosting.co.za>
Message-ID: <1462510143.93.0.0778430480049.issue26156@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

May be "w_expr"? ("a_expr" is already used for addition level).

----------

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

From report at bugs.python.org  Fri May  6 00:50:30 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 06 May 2016 04:50:30 +0000
Subject: [issue26156] Bad name into power operator syntax
In-Reply-To: <1453214486.32.0.13836493656.issue26156@psf.upfronthosting.co.za>
Message-ID: <1462510230.05.0.705361872637.issue26156@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Let's call it "await_expr"

----------

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

From report at bugs.python.org  Fri May  6 00:59:55 2016
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 06 May 2016 04:59:55 +0000
Subject: [issue26156] Bad name into power operator syntax
In-Reply-To: <1462510230.05.0.705361872637.issue26156@psf.upfronthosting.co.za>
Message-ID: <CAKJDb-MKvSK4upB3d2vcWfVgdOy1cYOak4CEEbfin4=shq8zCw@mail.gmail.com>


Zachary Ware added the comment:

+1 for await_expr

----------

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

From report at bugs.python.org  Fri May  6 02:10:41 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 May 2016 06:10:41 +0000
Subject: [issue26156] Bad name into power operator syntax
In-Reply-To: <1453214486.32.0.13836493656.issue26156@psf.upfronthosting.co.za>
Message-ID: <1462515041.44.0.881249064933.issue26156@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The confusion is in the definition of await expression with optional "await". Without "await" the expression doesn't suspend the execution of coroutine. And await expression can only be used inside a coroutine function, but the power operator can be used outside.

----------

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

From report at bugs.python.org  Fri May  6 02:45:17 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 May 2016 06:45:17 +0000
Subject: [issue26702] A better assert statement
In-Reply-To: <1459953817.06.0.108745447257.issue26702@psf.upfronthosting.co.za>
Message-ID: <1462517117.16.0.440450407269.issue26702@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I'm -1 for changing syntax of assert.

But I think that it may be useful to change semantic of assert so that all intermediate results of subexpressions are saved and included in the assert report (or at least their shortened reprs). I'm +0 for this.

----------

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

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: [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 02:57:22 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 May 2016 06:57:22 +0000
Subject: [issue25628] Make namedtuple "verbose" and "rename" parameters into
 keyword only arguments
In-Reply-To: <1447615273.45.0.0364929463097.issue25628@psf.upfronthosting.co.za>
Message-ID: <1462517842.86.0.515244621277.issue25628@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Ping.

If the keyword-only changes can be made without deprecation, I would want to make such changes for json functions (issue18726). json.dump() takes 11 positional parameters!

Guido, what you say about this?

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

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

From report at bugs.python.org  Fri May  6 03:14:41 2016
From: report at bugs.python.org (SilentGhost)
Date: Fri, 06 May 2016 07:14:41 +0000
Subject: [issue26959] pickle: respect dispatch for functions again
In-Reply-To: <1462407226.68.0.381104260984.issue26959@psf.upfronthosting.co.za>
Message-ID: <1462518881.8.0.468616796868.issue26959@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +alexandre.vassalotti, pitrou
stage:  -> patch review

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

From report at bugs.python.org  Fri May  6 03:40:09 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 May 2016 07:40:09 +0000
Subject: [issue18531] Undocumented different between METH_KEYWORDS and **kws
In-Reply-To: <1374519103.74.0.277776306074.issue18531@psf.upfronthosting.co.za>
Message-ID: <1462520409.09.0.437184323867.issue18531@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Yet one difference is that kwargs can be NULL in C function if no keyword arguments are supplied.

Here is a patch that adds tests for exact types of args and kwargs arguments in C functions.

I think that we should keep passing NULL as kwargs for performance reasons. But shouldn't we convert dict subclass to exact dict? I think there are good reasons to do this. Some functions can save kwargs for latter use. And this makes the implementation more consistent with PyPy.

If defaultdict behavior is needed for formatting, there is format_map().

----------
keywords: +patch
nosy: +serhiy.storchaka
type:  -> behavior
versions: +Python 3.5, Python 3.6 -Python 3.3, Python 3.4
Added file: http://bugs.python.org/file42742/test_args_kwargs_types.patch

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

From report at bugs.python.org  Fri May  6 03:51:07 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 May 2016 07:51:07 +0000
Subject: [issue18531] Undocumented different between METH_KEYWORDS and **kws
In-Reply-To: <1374519103.74.0.277776306074.issue18531@psf.upfronthosting.co.za>
Message-ID: <1462521067.4.0.655435241355.issue18531@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file42742/test_args_kwargs_types.patch

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

From report at bugs.python.org  Fri May  6 03:51:20 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 May 2016 07:51:20 +0000
Subject: [issue18531] Undocumented different between METH_KEYWORDS and **kws
In-Reply-To: <1374519103.74.0.277776306074.issue18531@psf.upfronthosting.co.za>
Message-ID: <1462521080.66.0.788231087326.issue18531@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file42743/test_args_kwargs_types.patch

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

From report at bugs.python.org  Fri May  6 04:05:00 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 06 May 2016 08:05:00 +0000
Subject: [issue26931] android: test_distutils fails
In-Reply-To: <1462285501.44.0.0195995288955.issue26931@psf.upfronthosting.co.za>
Message-ID: <1462521900.94.0.835492000214.issue26931@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

The last two failed tests:
    test_sysconfig_compiler_vars
    test_sysconfig_module

are caused by LDFLAGS being set in the environment both when configure is run and when make is run.

Removing LDFLAGS from the environment when running make fixes these tests.

----------

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

From report at bugs.python.org  Fri May  6 04:08:19 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 06 May 2016 08:08:19 +0000
Subject: [issue26931] android: test_distutils fails
In-Reply-To: <1462285501.44.0.0195995288955.issue26931@psf.upfronthosting.co.za>
Message-ID: <1462522099.44.0.030660738414.issue26931@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

The attached patch skips some tests when the interpreter was cross-compiled. When the interpreter has been cross-compiled, there is probably no compiler on the host system.

----------
keywords: +patch
Added file: http://bugs.python.org/file42744/cross-compiled-skip.patch

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

From report at bugs.python.org  Fri May  6 04:15:10 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 06 May 2016 08:15:10 +0000
Subject: [issue26931] android: test_distutils fails
In-Reply-To: <1462285501.44.0.0195995288955.issue26931@psf.upfronthosting.co.za>
Message-ID: <1462522510.19.0.711479710346.issue26931@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

On android, the shell path is /system/bin/sh. The attached patch fixes this, assuming that there is a platform.android_ver() as per issue #26855: add platform.android_ver() for android. This could be changed for a test on sys.platform if there was a specific sys.platform value for android.

With both patches and the LDFLAGS change on the cross-build system, test_distutils runs fine.

----------
Added file: http://bugs.python.org/file42745/android-sh-path.patch

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

From report at bugs.python.org  Fri May  6 04:30:46 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 May 2016 08:30:46 +0000
Subject: [issue18531] Undocumented different between METH_KEYWORDS and **kws
In-Reply-To: <1374519103.74.0.277776306074.issue18531@psf.upfronthosting.co.za>
Message-ID: <1462523446.15.0.323221716366.issue18531@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Proposed patch converts var-keyword arguments to exact dict. Since it changes the behavior of str.format() it can be pushed only in 3.6.

----------
Added file: http://bugs.python.org/file42746/ceval_kwargs_exact_dict.patch

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

From report at bugs.python.org  Fri May  6 04:33:35 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 May 2016 08:33:35 +0000
Subject: [issue15753] No-argument super in method with variable arguments
 raises SystemError
In-Reply-To: <1345549960.82.0.102703520127.issue15753@psf.upfronthosting.co.za>
Message-ID: <1462523615.49.0.999022650309.issue15753@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri May  6 05:10:28 2016
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 06 May 2016 09:10:28 +0000
Subject: [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  Fri May  6 05:13:09 2016
From: report at bugs.python.org (Cory Benfield)
Date: Fri, 06 May 2016 09:13:09 +0000
Subject: [issue26970] Replace OpenSSL's CPRNG with system entropy source
In-Reply-To: <1462525827.05.0.33480267606.issue26970@psf.upfronthosting.co.za>
Message-ID: <1462525989.14.0.14005969831.issue26970@psf.upfronthosting.co.za>


Changes by Cory Benfield <cory at lukasa.co.uk>:


----------
nosy: +Lukasa

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

From report at bugs.python.org  Fri May  6 05:14:56 2016
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 06 May 2016 09:14:56 +0000
Subject: [issue15071] TLS get keys and randoms
In-Reply-To: <1339706412.94.0.740645043785.issue15071@psf.upfronthosting.co.za>
Message-ID: <1462526096.78.0.834940866696.issue15071@psf.upfronthosting.co.za>


Christian Heimes added the comment:

This request is an advanced use case. I'd rather keep the Python _ssl module simple and suggest PyOpenSSL + PyCA/cryptography for advanced features.

----------
status: open -> languishing
versions: +Python 3.6 -Python 3.4

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

From report at bugs.python.org  Fri May  6 05:22:40 2016
From: report at bugs.python.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=)
Date: Fri, 06 May 2016 09:22:40 +0000
Subject: [issue26959] pickle: respect dispatch for functions again
In-Reply-To: <1462407226.68.0.381104260984.issue26959@psf.upfronthosting.co.za>
Message-ID: <1462526560.08.0.716107085721.issue26959@psf.upfronthosting.co.za>


Hrvoje Nik?i? added the comment:

You can simplify pickle_lambda in the test by using marshal.dumps(code_obj) and marshal.loads(code_obj) to dump and load the code object without going through its entire guts. It would be a shame to have to change a pickle test just because some detail of the code object implementation changes.

----------
nosy: +hniksic

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

From report at bugs.python.org  Fri May  6 05:24:36 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 May 2016 09:24:36 +0000
Subject: [issue26756] fileinput handling of unicode errors from standard input
In-Reply-To: <1460644347.16.0.552330506095.issue26756@psf.upfronthosting.co.za>
Message-ID: <1462526676.49.0.451823311745.issue26756@psf.upfronthosting.co.za>


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


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri May  6 05:24:58 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 May 2016 09:24:58 +0000
Subject: [issue26970] Replace OpenSSL's CPRNG with system entropy source
In-Reply-To: <1462525827.05.0.33480267606.issue26970@psf.upfronthosting.co.za>
Message-ID: <1462526698.18.0.546379230611.issue26970@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

What are the helper methods good for? I don't think we want to expose them for now.

----------

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

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


Christian Heimes added the comment:

I have used the helper methods during development. They are also used in unit tests.

----------

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

From report at bugs.python.org  Fri May  6 05:30:46 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 May 2016 09:30:46 +0000
Subject: [issue26970] Replace OpenSSL's CPRNG with system entropy source
In-Reply-To: <1462525827.05.0.33480267606.issue26970@psf.upfronthosting.co.za>
Message-ID: <1462527046.66.0.509092594041.issue26970@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Then I'd say just keep them private.

----------

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

From report at bugs.python.org  Fri May  6 05:40:28 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 May 2016 09:40:28 +0000
Subject: [issue17765] weakref.ref ignores a 'callback' keyword argument
In-Reply-To: <1366139470.36.0.39573405184.issue17765@psf.upfronthosting.co.za>
Message-ID: <1462527628.98.0.867090855954.issue17765@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

no_weakref_kwargs_2.patch LGTM.

----------
components: +Extension Modules
nosy: +serhiy.storchaka
stage: needs patch -> commit review
type: enhancement -> behavior
versions: +Python 3.5, Python 3.6 -Python 3.3, Python 3.4

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

From report at bugs.python.org  Fri May  6 05:41:54 2016
From: report at bugs.python.org (Tyler Crompton)
Date: Fri, 06 May 2016 09:41:54 +0000
Subject: [issue26870] Unexpected call to readline's add_history in
 call_readline
In-Reply-To: <1461743534.82.0.668302064476.issue26870@psf.upfronthosting.co.za>
Message-ID: <1462527714.54.0.698329356221.issue26870@psf.upfronthosting.co.za>


Changes by Tyler Crompton <tyler at tylercrompton.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file42748/set_auto_history.patch

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

From report at bugs.python.org  Fri May  6 05:45:48 2016
From: report at bugs.python.org (Tyler Crompton)
Date: Fri, 06 May 2016 09:45:48 +0000
Subject: [issue26870] Unexpected call to readline's add_history in
 call_readline
In-Reply-To: <1461743534.82.0.668302064476.issue26870@psf.upfronthosting.co.za>
Message-ID: <1462527948.91.0.604156650473.issue26870@psf.upfronthosting.co.za>


Tyler Crompton added the comment:

I couldn't think of a way to test input() with the unittest module without bypassing readline or requesting the input from the user. With that said, this informal script verifies proper behavior.

----------
status: open -> pending
Added file: http://bugs.python.org/file42749/test_set_auto_history.py

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

From report at bugs.python.org  Fri May  6 05:46:46 2016
From: report at bugs.python.org (Tyler Crompton)
Date: Fri, 06 May 2016 09:46:46 +0000
Subject: [issue26870] Unexpected call to readline's add_history in
 call_readline
In-Reply-To: <1461743534.82.0.668302064476.issue26870@psf.upfronthosting.co.za>
Message-ID: <1462528006.7.0.401640854333.issue26870@psf.upfronthosting.co.za>


Changes by Tyler Crompton <tyler at tylercrompton.com>:


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

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

From report at bugs.python.org  Fri May  6 05:57:50 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 May 2016 09:57:50 +0000
Subject: [issue1528167] Tweak to make string.Templates more customizable
Message-ID: <1462528670.4.0.866494109414.issue1528167@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I seconded Raymond. Now the approach is argued against twice. And the patch itself is outdated. I suggest to close this issue. If somebody want to implement Raymond's idea, his can reopen this issue or open new issue.

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

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

From report at bugs.python.org  Fri May  6 06:02:23 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 May 2016 10:02:23 +0000
Subject: [issue13173] Default values for string.Template
In-Reply-To: <1318540565.49.0.753035083637.issue13173@psf.upfronthosting.co.za>
Message-ID: <1462528943.79.0.648415840555.issue13173@psf.upfronthosting.co.za>


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


----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri May  6 06:20:55 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Fri, 06 May 2016 10:20:55 +0000
Subject: [issue26939] android: test_functools hangs on armv7
In-Reply-To: <1462289866.52.0.349587333392.issue26939@psf.upfronthosting.co.za>
Message-ID: <1462530055.73.0.293584416305.issue26939@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

FWIW, test_functools passes on ASUS Zenfone 2 Laser ZE500KL with stock ROM (rooted) and my patchset. [1] The CPU is ARM64 and the Python is built as 32-bit ARM binaries. test_threading (#26941) and test_importlib (#26940) pass, too. test_concurrent_futures (#26938) fails with 27 errors, all with "OSError: [Errno 38] Function not implemented", which seems the same as #26924.

The attached file contains logs of the four tests mentioned here.

[1] https://github.com/yan12125/python3-android

----------
nosy: +Chi Hsuan Yen
Added file: http://bugs.python.org/file42750/python_tests_on_arm.txt

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

From report at bugs.python.org  Fri May  6 06:21:04 2016
From: report at bugs.python.org (Vsevolod Velichko)
Date: Fri, 06 May 2016 10:21:04 +0000
Subject: [issue26959] pickle: respect dispatch for functions again
In-Reply-To: <1462407226.68.0.381104260984.issue26959@psf.upfronthosting.co.za>
Message-ID: <1462530064.29.0.993606935924.issue26959@psf.upfronthosting.co.za>


Vsevolod Velichko added the comment:

I was trying to avoid additional imports in the test.
But your point of view seems more reasonable, so I reupload the fixed patch.

----------
Added file: http://bugs.python.org/file42751/function_pickle.patch

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

From report at bugs.python.org  Fri May  6 06:24:38 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 May 2016 10:24:38 +0000
Subject: [issue20291] Argument Clinic should understand *args and **kwargs
 parameters
In-Reply-To: <1390010125.91.0.58212727704.issue20291@psf.upfronthosting.co.za>
Message-ID: <1462530278.62.0.449716452404.issue20291@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think at first step we can support var-positional parameter only when there are no other positional parameters, and var-keyword parameter only when there are no other keyword parameters. So print, max and dict.update will be supported, but __build_class__, map and functools.partial are not.

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

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

From report at bugs.python.org  Fri May  6 06:31:22 2016
From: report at bugs.python.org (Robert Jordens)
Date: Fri, 06 May 2016 10:31:22 +0000
Subject: [issue26156] Bad name into power operator syntax
In-Reply-To: <1453214486.32.0.13836493656.issue26156@psf.upfronthosting.co.za>
Message-ID: <1462530682.4.0.378788589104.issue26156@psf.upfronthosting.co.za>


Robert Jordens added the comment:

Ack to the new patch. It is semantically confusing that the await expression also served as the power base without any await.

----------

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

From report at bugs.python.org  Fri May  6 06:40:04 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 06 May 2016 10:40:04 +0000
Subject: [issue26537] ConfigParser has optionxform, but not sectionxform
In-Reply-To: <1457678417.52.0.410667040467.issue26537@psf.upfronthosting.co.za>
Message-ID: <1462531204.27.0.00746837953557.issue26537@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

I write a patch to add sectionxform. It wraps necessary section name operation I think. Hope to have some feedback.

----------
keywords: +patch
Added file: http://bugs.python.org/file42752/add_sectionxform.patch

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

From report at bugs.python.org  Fri May  6 06:53:50 2016
From: report at bugs.python.org (suddha sourav)
Date: Fri, 06 May 2016 10:53:50 +0000
Subject: [issue15786] IDLE code completion window can hang or misbehave with
 mouse
In-Reply-To: <1462504002.33.0.487504257296.issue15786@psf.upfronthosting.co.za>
Message-ID: <CAP1JSm-LpQMThoAYwbsOGyWNDieY+VQtr8e2Sz_p9FDOtQiNJw@mail.gmail.com>


suddha sourav added the comment:

I reported the issue in 2012, and it's not nice to see that in four years
the flagship editor of Python in all platforms I know is still something I
have to avoid. I am not writing this mail to vent; I'm asking: what can we
do, and through which channels we can go, for a quick solution? I am
unfamiliar with the structure of issue resolving in Python, maybe Ned can
help?

Thank you all

On Fri, May 6, 2016 at 8:36 AM, paul czyzewski <report at bugs.python.org>
wrote:

>
> paul czyzewski added the comment:
>
> Thanks, Terry and Ned.
>
> Ned, I checked (nice clear instructions, btw) and I had Tk 8.5.10.  So I
> followed the link and installed 8.5.18.  -- The freeze on mac still occurs
> but I understand that this will avoid some other bugs.
>
> BTW, I don't know how testing works for IDLE and Python, but that's what I
> do for a living, so maybe I'll try to get involved.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue15786>
> _______________________________________
>

----------

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

From report at bugs.python.org  Fri May  6 07:11:51 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 May 2016 11:11:51 +0000
Subject: [issue26939] android: test_functools hangs on armv7
In-Reply-To: <1462289866.52.0.349587333392.issue26939@psf.upfronthosting.co.za>
Message-ID: <1462533111.91.0.514063297905.issue26939@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I suspect this bug is caused by memory ordering differences between x86 and ARM (see https://en.wikipedia.org/wiki/Memory_ordering#Runtime_memory_ordering ), which is why it may not reproduce easily (may depend on the particular CPU implementation and/or various timing subtleties in the tests themselves).

Xavier / Chi, can you tell if Android has stdatomic.h? See Include/pyatomic.h for the difference it makes.

----------

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

From report at bugs.python.org  Fri May  6 07:12:00 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 May 2016 11:12:00 +0000
Subject: [issue26939] android: test_functools hangs on armv7
In-Reply-To: <1462289866.52.0.349587333392.issue26939@psf.upfronthosting.co.za>
Message-ID: <1462533120.29.0.338385896612.issue26939@psf.upfronthosting.co.za>


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


----------
nosy: +neologix

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

From report at bugs.python.org  Fri May  6 07:27:02 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 06 May 2016 11:27:02 +0000
Subject: [issue25745] Reference leaks in test_curses
In-Reply-To: <1448647482.06.0.750956111756.issue25745@psf.upfronthosting.co.za>
Message-ID: <1462534022.27.0.392673545389.issue25745@psf.upfronthosting.co.za>


Berker Peksag added the comment:

In case someone wants to work on this, the suspicious tests are test_userptr_memory_leak and test_userptr_segfault. See also issue 18113.

----------
nosy: +berker.peksag
stage:  -> needs patch
versions: +Python 3.5

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

From report at bugs.python.org  Fri May  6 07:30:24 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 May 2016 11:30:24 +0000
Subject: [issue26939] android: test_functools hangs on armv7
In-Reply-To: <1462289866.52.0.349587333392.issue26939@psf.upfronthosting.co.za>
Message-ID: <1462534224.08.0.915907731138.issue26939@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Xavier, as a strating point, can you try the following patch? (atomic_explicit.patch)
If it solves the issue, can you also measure the performance drop compared to unpatched (on a non-debug build)? `python -m test.pystone` should be sufficient.

----------
keywords: +patch
Added file: http://bugs.python.org/file42753/atomic_explicit.patch

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

From report at bugs.python.org  Fri May  6 07:45:50 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 06 May 2016 11:45:50 +0000
Subject: [issue21890] wsgiref.simple_server sends headers on empty bytes
In-Reply-To: <1404184510.5.0.84615415722.issue21890@psf.upfronthosting.co.za>
Message-ID: <1462535150.66.0.788119727921.issue21890@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag
stage:  -> patch review
versions: +Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri May  6 07:50:41 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 06 May 2016 11:50:41 +0000
Subject: [issue17888] docs: more information on documentation team
In-Reply-To: <1367412914.06.0.588625037016.issue17888@psf.upfronthosting.co.za>
Message-ID: <1462535441.78.0.699078646026.issue17888@psf.upfronthosting.co.za>


Berker Peksag added the comment:

issue17888.patch looks good to me. I'd probably remove the "necessary skills" part.

----------
nosy: +berker.peksag
stage: needs patch -> patch review
versions: +Python 3.5, Python 3.6

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

From report at bugs.python.org  Fri May  6 07:57:05 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 06 May 2016 11:57:05 +0000
Subject: [issue20971] HTML output of difflib
In-Reply-To: <1395163142.65.0.134532339762.issue20971@psf.upfronthosting.co.za>
Message-ID: <1462535825.43.0.887397913447.issue20971@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder:  -> Modernize HTML output of difflib.HtmlDiff.make_file()

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

From report at bugs.python.org  Fri May  6 08:00:48 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 May 2016 12:00:48 +0000
Subject: [issue25745] Reference leaks in test_curses
In-Reply-To: <1448647482.06.0.750956111756.issue25745@psf.upfronthosting.co.za>
Message-ID: <1462536048.75.0.930669569228.issue25745@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for the tip Berker. Now I see how to fix the leak.

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

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

From report at bugs.python.org  Fri May  6 08:02:09 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 06 May 2016 12:02:09 +0000
Subject: [issue25974] Fix statistics.py after the Decimal.as_integer_ratio()
 change
In-Reply-To: <1451393371.35.0.476117922354.issue25974@psf.upfronthosting.co.za>
Message-ID: <1462536129.08.0.0144746108702.issue25974@psf.upfronthosting.co.za>


Berker Peksag added the comment:

statistics_as_integer_ratio.diff has been committed in 7b2fafd78c1d.

----------
nosy: +berker.peksag
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri May  6 08:04:27 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 06 May 2016 12:04:27 +0000
Subject: [issue26002] make statistics.median_grouped more efficient
In-Reply-To: <1451830918.88.0.211778162331.issue26002@psf.upfronthosting.co.za>
Message-ID: <1462536267.39.0.168704829819.issue26002@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


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

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

From report at bugs.python.org  Fri May  6 08:10:07 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 06 May 2016 12:10:07 +0000
Subject: [issue20554] Use specific asserts in optparse test
In-Reply-To: <1391808859.25.0.0531028969207.issue20554@psf.upfronthosting.co.za>
Message-ID: <1462536607.26.0.595902249783.issue20554@psf.upfronthosting.co.za>


Berker Peksag added the comment:

The patch looks simple, but I don't see much gain to apply it since optparse is a deprecated module. I'm in favor of closing this as 'wont fix'.

----------
priority: normal -> low

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

From report at bugs.python.org  Fri May  6 08:14:36 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 May 2016 12:14:36 +0000
Subject: [issue25745] Reference leaks in test_curses
In-Reply-To: <1448647482.06.0.750956111756.issue25745@psf.upfronthosting.co.za>
Message-ID: <1462536876.87.0.822991550073.issue25745@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is simple patch that fixes a leak.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file42754/curses_panel_dealloc_userptr.patch

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

From report at bugs.python.org  Fri May  6 08:16:44 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 May 2016 12:16:44 +0000
Subject: [issue20554] Use specific asserts in optparse test
In-Reply-To: <1391808859.25.0.0531028969207.issue20554@psf.upfronthosting.co.za>
Message-ID: <1462537004.86.0.941679288468.issue20554@psf.upfronthosting.co.za>


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


----------
resolution:  -> wont fix
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri May  6 08:33:50 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 06 May 2016 12:33:50 +0000
Subject: [issue12135] The spawn function should return stderr.
In-Reply-To: <1305987963.54.0.668824633518.issue12135@psf.upfronthosting.co.za>
Message-ID: <1462538030.67.0.212211611091.issue12135@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


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

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

From report at bugs.python.org  Fri May  6 08:35:27 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 06 May 2016 12:35:27 +0000
Subject: [issue18841] math.isfinite fails with Decimal sNAN
In-Reply-To: <1377531520.63.0.106544243675.issue18841@psf.upfronthosting.co.za>
Message-ID: <1462538127.09.0.835308768202.issue18841@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
resolution:  -> wont fix
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri May  6 08:40:01 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 06 May 2016 12:40:01 +0000
Subject: [issue17888] docs: more information on documentation team
In-Reply-To: <1367412914.06.0.588625037016.issue17888@psf.upfronthosting.co.za>
Message-ID: <1462538401.03.0.842398860177.issue17888@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
nosy:  -BreamoreBoy

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

From report at bugs.python.org  Fri May  6 08:45:25 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 May 2016 12:45:25 +0000
Subject: [issue22107] tempfile module misinterprets access denied error on
 Windows
In-Reply-To: <1406724041.52.0.0365391579019.issue22107@psf.upfronthosting.co.za>
Message-ID: <1462538725.83.0.696305070049.issue22107@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Billy, no, the parent directory is tested intentionally. If it isn't a directory, we should fail.

May be there is a way to distinguish a failure because the name is already used for a subdirectory from a failure because we don't have permission to create a file, but I haven't access to Windows and can't experiment. Someone motivated and experienced should to do this work.

----------

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

From report at bugs.python.org  Fri May  6 08:48:13 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 May 2016 12:48:13 +0000
Subject: [issue26282] Add support for partial keyword arguments in extension
 functions
In-Reply-To: <1454535856.96.0.444049158428.issue26282@psf.upfronthosting.co.za>
Message-ID: <1462538893.07.0.563091267538.issue26282@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

If there are no objections I'm inclined to commit pyarg_parse_positional_only_and_keywords_2.patch in short time.

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

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

From report at bugs.python.org  Fri May  6 09:04:57 2016
From: report at bugs.python.org (R. David Murray)
Date: Fri, 06 May 2016 13:04:57 +0000
Subject: [issue26156] Bad name into power operator syntax
In-Reply-To: <1453214486.32.0.13836493656.issue26156@psf.upfronthosting.co.za>
Message-ID: <1462539897.75.0.406419074119.issue26156@psf.upfronthosting.co.za>


R. David Murray added the comment:

Sounds like it is a bit more than just confusion: given that power can be used outside a coroutine but await can't, Serhiy's formulation would seem to me to be more semantically correct, even if syntactically it is the same as the current.

I think it would regardless be better to replace 'await' with 'await_expr', so +1 on that from me as well.

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

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

From report at bugs.python.org  Fri May  6 10:53:04 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 06 May 2016 14:53:04 +0000
Subject: [issue26939] android: test_functools hangs on armv7
In-Reply-To: <1462289866.52.0.349587333392.issue26939@psf.upfronthosting.co.za>
Message-ID: <1462546384.17.0.976401855601.issue26939@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Android has stdatomic.h and HAVE_STD_ATOMIC is defined.

The build fails with the patch, see the errors in the attached file. This is the native compilation of python, the patches in my build system are also applied to the native build so that they can be checked. I can prevent that if needed.

----------
Added file: http://bugs.python.org/file42755/build-failure.txt

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

From report at bugs.python.org  Fri May  6 10:53:26 2016
From: report at bugs.python.org (Michael Kruse)
Date: Fri, 06 May 2016 14:53:26 +0000
Subject: [issue26967] argparse: allow_abbrev=False stops -vv from working
In-Reply-To: <1462475086.65.0.670765920247.issue26967@psf.upfronthosting.co.za>
Message-ID: <1462546406.84.0.0214191693196.issue26967@psf.upfronthosting.co.za>


Michael Kruse added the comment:

I think the allow_abbrev option should be orthogonal on how short options are parsed. I am using parse_known_args() to forward the unrecognized args to another program, therefore allow_abbrev=False is essential.

There is a special handling for short options in the consume_optional and _get_option_tuples to allow them being concatenated with one dash, as commonly done with short options (eg. "tar -czf file"). I interpret allow_abbrev as an option to avoid matching non-exiting options that should be forwarded to the other program; '-vv' is an existing option with the same meaning as '-v -v'.

This would also mean that parse_known_args(['-vz']) (where '-v' is a registered argument, but '-z' is not) matches '-v' and returns '-z' as unknown argument; but I don't know whether you want to go that far. It is difficult to interpret whether '-verify' should mean '-v -e -r -i -f -y' or '--verify' (but this is why there are double-dash options), especially when the first letter is not a registered short option.

----------

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

From report at bugs.python.org  Fri May  6 10:58:38 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 May 2016 14:58:38 +0000
Subject: [issue26939] android: test_functools hangs on armv7
In-Reply-To: <1462289866.52.0.349587333392.issue26939@psf.upfronthosting.co.za>
Message-ID: <1462546718.14.0.139176789931.issue26939@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Oops, sorry, hadn't seen the patch didn't compile. Can you tried with this new patch? (atomic_explicit2.patch)

----------
Added file: http://bugs.python.org/file42756/atomic_explicit2.patch

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

From report at bugs.python.org  Fri May  6 11:06:45 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 06 May 2016 15:06:45 +0000
Subject: [issue26632] __all__ decorator
In-Reply-To: <1458786797.31.0.0749407715279.issue26632@psf.upfronthosting.co.za>
Message-ID: <1462547205.76.0.277720221505.issue26632@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

Here's a C implementation.  I'm a bit under the weather so please do double check my refcounting logic. ;)

No tests or docs yet, but those would be easy to add.  Here's an example:

@public
class Foo:
    pass

public(qux=3)

print(qux)

@public
def zzz():
    pass

public(jix=1, jox=2, jrx=3)

print(__all__)
print(jix, jox, jrx)

You could also try to add an explicit __all__ in the module and those names will get appended to it.

----------
keywords: +patch
Added file: http://bugs.python.org/file42757/26632-in-c.diff

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

From report at bugs.python.org  Fri May  6 11:19:22 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 06 May 2016 15:19:22 +0000
Subject: [issue1528167] Tweak to make string.Templates more customizable
Message-ID: <1462547962.39.0.327604664041.issue1528167@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

Agreed with Serhiy.  Raymond's approach is nicer, but I'm still not convinced about the use case.  Closing.

If someone wants to run with this again, an updated patch would be needed, and the issue could be reopened, but I also suggest following through with Raymond's idea.

----------
resolution:  -> wont fix
status: open -> closed

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

From report at bugs.python.org  Fri May  6 11:20:45 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 06 May 2016 15:20:45 +0000
Subject: [issue18531] Undocumented different between METH_KEYWORDS and **kws
In-Reply-To: <1374519103.74.0.277776306074.issue18531@psf.upfronthosting.co.za>
Message-ID: <1462548045.37.0.574930126357.issue18531@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
nosy: +eric.smith

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

From report at bugs.python.org  Fri May  6 11:21:26 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 06 May 2016 15:21:26 +0000
Subject: [issue18531] Undocumented different between METH_KEYWORDS and **kws
In-Reply-To: <1374519103.74.0.277776306074.issue18531@psf.upfronthosting.co.za>
Message-ID: <1462548086.3.0.93761099268.issue18531@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

Eric should chime in on the str.format() implications.

----------

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

From report at bugs.python.org  Fri May  6 11:26:35 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 06 May 2016 15:26:35 +0000
Subject: [issue26632] __all__ decorator
In-Reply-To: <1458786797.31.0.0749407715279.issue26632@psf.upfronthosting.co.za>
Message-ID: <1462548395.34.0.174349260869.issue26632@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

I think I missed a decref.  New diff.

----------
Added file: http://bugs.python.org/file42758/26632-in-c-2.diff

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

From report at bugs.python.org  Fri May  6 11:28:15 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 06 May 2016 15:28:15 +0000
Subject: [issue26939] android: test_functools hangs on armv7
In-Reply-To: <1462289866.52.0.349587333392.issue26939@psf.upfronthosting.co.za>
Message-ID: <1462548495.73.0.247057360499.issue26939@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Still hangs at test_lru_cache_threaded with this last patch :(

----------

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

From report at bugs.python.org  Fri May  6 11:41:16 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 06 May 2016 15:41:16 +0000
Subject: [issue18531] Undocumented different between METH_KEYWORDS and **kws
In-Reply-To: <1374519103.74.0.277776306074.issue18531@psf.upfronthosting.co.za>
Message-ID: <1462549276.26.0.577648619085.issue18531@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

I think it's okay to change this as far as str.format() goes.

Interestingly enough, the motivating case to add str.format_map() in issue 6081 was exactly this kind of code. Although I notice that the example in that issue, which it shows as failing, works in both 2.7 and 3.4 (the only versions I have handy). So I'm not sure what changed after 2009 to cause that code to start working, but I'd be okay with it breaking again. But maybe we should track it down, in case it was deliberately changed and is important to someone.

In any event, since str.format_map() is well-known (to me, at least!), and is the approved way of getting the behavior of passing a specific map in to the format machinery, I'm okay with changing **dict to create an exact new dict, at least as far as str.format() goes. I can't speak to the overall implications (such as other APIs and performance).

I agree it would be a 3.6 only change (and I've change the versions to reflect that).

----------
versions:  -Python 2.7, Python 3.5

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

From report at bugs.python.org  Fri May  6 11:43:30 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 06 May 2016 15:43:30 +0000
Subject: [issue26969] ascynio should provide a policy to address
 pass-loop-everywhere problem
In-Reply-To: <1462517538.3.0.176027238089.issue26969@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJKiswvpybx2C+3YkrCPLUfHjQKskXU1oVcHg5A6dRV4iA@mail.gmail.com>


Guido van Rossum added the comment:

Can't you easily write such a policy yourself? Why does it have to be a
standard part of asyncio?

----------

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

From report at bugs.python.org  Fri May  6 11:45:30 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 06 May 2016 15:45:30 +0000
Subject: [issue25628] Make namedtuple "verbose" and "rename" parameters into
 keyword only arguments
In-Reply-To: <1447615273.45.0.0364929463097.issue25628@psf.upfronthosting.co.za>
Message-ID: <1462549530.58.0.96203109676.issue25628@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I think such a change can be safely made in a feature release (say 3.6) without further deprecation. But not in a bugfix release (say 3.5.2).

----------

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

From report at bugs.python.org  Fri May  6 11:46:32 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 06 May 2016 15:46:32 +0000
Subject: [issue18531] Undocumented different between METH_KEYWORDS and **kws
In-Reply-To: <1462549276.26.0.577648619085.issue18531@psf.upfronthosting.co.za>
Message-ID: <20160506104627.1e7e1ddc@python.org>


Barry A. Warsaw added the comment:

On May 06, 2016, at 03:41 PM, Eric V. Smith wrote:

>I agree it would be a 3.6 only change (and I've change the versions to
>reflect that).

The reason the other versions were included was because this was originally
reported as a documentation bug.  It should probably still be documented in
those older releases.

----------

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

From report at bugs.python.org  Fri May  6 11:47:39 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 06 May 2016 15:47:39 +0000
Subject: [issue25628] Make namedtuple "verbose" and "rename" parameters into
 keyword only arguments
In-Reply-To: <1447615273.45.0.0364929463097.issue25628@psf.upfronthosting.co.za>
Message-ID: <1462549659.16.0.797454242097.issue25628@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

And by "safely" I mean that I don't mind if some code breaks when they upgrade to a new feature release.

FWIW the code most likely to break is code that wraps these functions with an identical interface.

----------

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

From report at bugs.python.org  Fri May  6 11:53:31 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 May 2016 15:53:31 +0000
Subject: [issue26632] __all__ decorator
In-Reply-To: <1458786797.31.0.0749407715279.issue26632@psf.upfronthosting.co.za>
Message-ID: <1462550011.48.0.51316025754.issue26632@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Added a couple of comments on Rietveld.

But sorry, the overall idea looks unpythonic to me. I'm strong -1.

----------

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

From report at bugs.python.org  Fri May  6 11:55:47 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 06 May 2016 15:55:47 +0000
Subject: [issue26939] android: test_functools hangs on armv7
In-Reply-To: <1462289866.52.0.349587333392.issue26939@psf.upfronthosting.co.za>
Message-ID: <1462550147.49.0.195759011199.issue26939@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

> Can you post the backtraces of all threads (at least the innermost frames)?

There are two threads, gdb does not print the backtrace of the other thread. My current gdb setup with a connection to a gdb-server misses some stuff (access to the loader or some libraries I guess) and needs to be completed with the same setup as the one used by the ndk-gdb script (released by google for android applications).

> Also, can you reproduce on an actual armv7 machine? Just wondering if there may be something peculiar in the emulator.

I don't have an armv7 device that can be used for testing.

----------

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

From report at bugs.python.org  Fri May  6 12:01:04 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 May 2016 16:01:04 +0000
Subject: [issue25628] Make namedtuple "verbose" and "rename" parameters into
 keyword only arguments
In-Reply-To: <1447615273.45.0.0364929463097.issue25628@psf.upfronthosting.co.za>
Message-ID: <1462550464.7.0.0871331731221.issue25628@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Then namedtuple_keywords.diff LGTM. But please document changes.

----------
assignee:  -> rhettinger
stage: patch review -> commit review

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

From report at bugs.python.org  Fri May  6 12:38:54 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 06 May 2016 16:38:54 +0000
Subject: [issue26906] format(object.__reduce__) fails intermittently
In-Reply-To: <1462479012.59.0.509030882852.issue26906@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJJs7_Mwad_uduaV7Qqe4kjHmc7PLm3fu=XYsaPVnFhVVQ@mail.gmail.com>


Guido van Rossum added the comment:

Sadly it's been a very long time since I wrote that code and I don't recall
much about it. I presume there was a good reason for not to do it in
_PyType_Lookup(), but who knows -- maybe the oroginal approach was just too
naive and nobody cared? I'm not excited by a patch that does this for 38
types -- invariably there will be another type that still surfaces the same
bug.

----------

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

From report at bugs.python.org  Fri May  6 12:43:57 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 May 2016 16:43:57 +0000
Subject: [issue18726] json functions have too many positional parameters
In-Reply-To: <1376392694.75.0.457946059126.issue18726@psf.upfronthosting.co.za>
Message-ID: <1462553037.3.0.967038452041.issue18726@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Guido's decision on similar issue25628 is that changing keyword-or-positional parameters to keyword-only is safe and can be made without deprecation.

If we started the deprecation period in 3.4, we could finish it in 3.6.

Proposed simple patch changes all optional parameters in functions and constructors that takes too much parameters in the json module to keyword-only without deprecation.

----------
keywords: +patch
nosy: +gvanrossum
stage:  -> patch review
versions: +Python 3.6 -Python 3.4
Added file: http://bugs.python.org/file42759/json_keyword_only.patch

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

From report at bugs.python.org  Fri May  6 12:45:22 2016
From: report at bugs.python.org (Guido Treutwein)
Date: Fri, 06 May 2016 16:45:22 +0000
Subject: [issue26156] Bad name into power operator syntax
In-Reply-To: <1462539897.75.0.406419074119.issue26156@psf.upfronthosting.co.za>
Message-ID: <CADE0f3xgd-K4qU=VO-pMFLwBf1NM2VXNghwjAGP-A8NtEzmBMA@mail.gmail.com>


Guido Treutwein added the comment:

I'm with David here, in that a change would improve ease of comprehension:
I still find it strange, that the grammar symbol has the same name as the
keyword (or in the proposed version keyword+'expr'), which is never done on
more widely used levels. I would have expected something like
'coroutine_suspension', which reflects what it is and not which keyword is
required to state it.

2016-05-06 15:04 GMT+02:00 R. David Murray <report at bugs.python.org>:

>
> R. David Murray added the comment:
>
> Sounds like it is a bit more than just confusion: given that power can be
> used outside a coroutine but await can't, Serhiy's formulation would seem
> to me to be more semantically correct, even if syntactically it is the same
> as the current.
>
> I think it would regardless be better to replace 'await' with
> 'await_expr', so +1 on that from me as well.
>
> ----------
> nosy: +r.david.murray
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue26156>
> _______________________________________
>

----------

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

From report at bugs.python.org  Fri May  6 12:51:39 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 06 May 2016 16:51:39 +0000
Subject: [issue18726] json functions have too many positional parameters
In-Reply-To: <1376392694.75.0.457946059126.issue18726@psf.upfronthosting.co.za>
Message-ID: <1462553499.53.0.285532255867.issue18726@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

> Guido's decision on similar issue25628 is that changing keyword-or-positional parameters to keyword-only is safe and can be made without deprecation.

> If we started the deprecation period in 3.4, we could finish it in 3.6.

That makes little sense. You can't start deprecation in 3.4 or in 3.5 since these have been released already.

But what I said implies that you can make these things mandatory in 3.6 without having to worry about deprecating them, so the start of the deprecation period is meaningless.

However I do encourage you to be conservative, and add a warning about this and similar cases when the alphas and betas go out; and if you get much pushback during beta consider changing your mind.

----------

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

From report at bugs.python.org  Fri May  6 12:52:37 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 06 May 2016 16:52:37 +0000
Subject: [issue18531] Undocumented different between METH_KEYWORDS and **kws
In-Reply-To: <1374519103.74.0.277776306074.issue18531@psf.upfronthosting.co.za>
Message-ID: <1462553557.33.0.190050847831.issue18531@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Okay. Adding back 3.5 and 2.7, in case someone wants to document the behavior there. I'm not sure if we fix docs in 3.4 still.

----------
versions: +Python 2.7, Python 3.5

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

From report at bugs.python.org  Fri May  6 12:55:47 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 06 May 2016 16:55:47 +0000
Subject: [issue26939] android: test_functools hangs on armv7
In-Reply-To: <1462289866.52.0.349587333392.issue26939@psf.upfronthosting.co.za>
Message-ID: <1462553747.74.0.220389135321.issue26939@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

The strace of test_lru_cache_threaded:

...
gettimeofday({1462553238, 580860}, NULL) = 0
clock_gettime(CLOCK_REALTIME, {1462553238, 581276772}) = 0
gettimeofday({1462553238, 581672}, NULL) = 0
clock_gettime(CLOCK_REALTIME, {1462553238, 582078767}) = 0
gettimeofday({1462553238, 583956}, NULL) = 0
clock_gettime(CLOCK_REALTIME, {1462553238, 585865959}) = 0
gettimeofday({1462553238, 587597}, NULL) = 0
clock_gettime(CLOCK_REALTIME, {1462553238, 589381724}) = 0
gettimeofday({1462553238, 589973}, NULL) = 0
clock_gettime(CLOCK_REALTIME, {1462553238, 591858839}) = 0
gettimeofday({1462553238, 593003}, NULL) = 0
clock_gettime(CLOCK_REALTIME, {1462553238, 593452750}) = 0
gettimeofday({1462553238, 593886}, NULL) = 0
clock_gettime(CLOCK_REALTIME, {1462553238, 594364345}) = 0
gettimeofday({1462553238, 594764}, NULL) = 0
clock_gettime(CLOCK_REALTIME, {1462553238, 595227771}) = 0
gettimeofday({1462553238, 595626}, NULL) = 0
clock_gettime(CLOCK_REALTIME, {1462553238, 596027590}) = 0
gettimeofday({1462553238, 596448}, NULL) = 0
clock_gettime(CLOCK_REALTIME, {1462553238, 596848736}) = 0
gettimeofday({1462553238, 597259}, NULL) = 0
clock_gettime(CLOCK_REALTIME, {1462553238, 597665484}) = 0
gettimeofday({1462553238, 598060}, NULL) = 0
clock_gettime(CLOCK_REALTIME, {1462553238, 598869963}) = 0
gettimeofday({1462553238, 599547}, NULL) = 0
clock_gettime(CLOCK_REALTIME, {1462553238, 601053152}) = 0
gettimeofday({1462553238, 601593}, NULL) = 0
clock_gettime(CLOCK_REALTIME, ^CProcess 908 detached
 <detached ...>

----------

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

From report at bugs.python.org  Fri May  6 12:58:48 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 May 2016 16:58:48 +0000
Subject: [issue18726] json functions have too many positional parameters
In-Reply-To: <1376392694.75.0.457946059126.issue18726@psf.upfronthosting.co.za>
Message-ID: <1462553928.65.0.00360636461008.issue18726@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

My remark was just about that I proposed to start a deprecation period at the time of developing Python 3.4. If this did accepted, the deprecation period would already finished and we would come up to the same code in 3.6.

It doesn't matter now.

----------

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

From report at bugs.python.org  Fri May  6 13:04:07 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 06 May 2016 17:04:07 +0000
Subject: [issue26632] __all__ decorator
In-Reply-To: <1458786797.31.0.0749407715279.issue26632@psf.upfronthosting.co.za>
Message-ID: <1462554247.63.0.0998644309003.issue26632@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

Updated.

----------
Added file: http://bugs.python.org/file42760/26632-in-c-3.diff

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

From report at bugs.python.org  Fri May  6 13:10:37 2016
From: report at bugs.python.org (Michael Felt)
Date: Fri, 06 May 2016 17:10:37 +0000
Subject: [issue11063] uuid.py module import has heavy side effects
In-Reply-To: <1296321060.32.0.846037411239.issue11063@psf.upfronthosting.co.za>
Message-ID: <1462554637.88.0.234726454658.issue11063@psf.upfronthosting.co.za>


Michael Felt added the comment:

I cannot comment on uuid directly, but for me, this is yet another example of how assumptions can break things.

imho - if you know the exact version of s shared library that you want, calling cdll directly should be find. Maybe find_library is historic.

However, an advantage to calling find_library is that it should lead to an OSError if it cannot be loaded. But trapping OSError on a call to ctypes.cdll or testing for None (NULL) from find_library() is the option of a developer using the ctypes interface.

As far as libFOO.so.N - do you always want to assume it is going to be version N, or are you expecting to be able to work work version N+X?
Again, find_library() can give you the library name it would load - but a programmer must be aware of the platform differences (e.g., AIX returns not a filename, but a libFOO.a(libFOO.so.N) - as just one example.
p.s. as far as ldconfig being part of the problem on AIX (as it does not exist and can lead to OSError or just long delays, I have worked out a (pending) patch for ctypes/util (and ctypes/cdll) that may address the issues with uuid import on AIX. (see issue26439 for the patch)

----------
nosy: +Michael.Felt

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

From report at bugs.python.org  Fri May  6 13:11:07 2016
From: report at bugs.python.org (R. David Murray)
Date: Fri, 06 May 2016 17:11:07 +0000
Subject: [issue26969] ascynio should provide a policy to address
 pass-loop-everywhere problem
In-Reply-To: <1462517538.3.0.176027238089.issue26969@psf.upfronthosting.co.za>
Message-ID: <1462554667.91.0.223564724094.issue26969@psf.upfronthosting.co.za>


R. David Murray added the comment:

Can we at least make it part of the documentation?  It's not obvious to me, at least, how to do it.  (Maybe I just haven't thought about it carefully enough.)  For that matter, it wasn't obvious to me it could even be done, so I've been passing loop everywhere in my code rather than thinking about how to avoid it; which is another argument for documenting it at least.

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

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

From report at bugs.python.org  Fri May  6 13:18:31 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 06 May 2016 17:18:31 +0000
Subject: [issue26969] ascynio should provide a policy to address
 pass-loop-everywhere problem
In-Reply-To: <1462517538.3.0.176027238089.issue26969@psf.upfronthosting.co.za>
Message-ID: <1462555111.63.0.290174237524.issue26969@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> 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. 

Why don't you just use 'loop = asyncio.get_event_loop()' in places where you need the loop?

----------

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

From report at bugs.python.org  Fri May  6 13:23:22 2016
From: report at bugs.python.org (R. David Murray)
Date: Fri, 06 May 2016 17:23:22 +0000
Subject: [issue26632] __all__ decorator
In-Reply-To: <1458786797.31.0.0749407715279.issue26632@psf.upfronthosting.co.za>
Message-ID: <1462555402.05.0.0568043530607.issue26632@psf.upfronthosting.co.za>


R. David Murray added the comment:

"This will cause more problems than it solves" and "this looks unpythonic" are, IMO, not strong arguments against it without butressing discussion.  If we can have some examples of problems it will cause, or a concrete explanation of wy something that makes code easier to understand and update (by putting the __all__ declaration next to the object being made public) is unpythonic, that would also help.

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

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

From report at bugs.python.org  Fri May  6 13:36:10 2016
From: report at bugs.python.org (R. David Murray)
Date: Fri, 06 May 2016 17:36:10 +0000
Subject: [issue26969] ascynio should provide a policy to address
 pass-loop-everywhere problem
In-Reply-To: <1462517538.3.0.176027238089.issue26969@psf.upfronthosting.co.za>
Message-ID: <1462556170.75.0.491428126069.issue26969@psf.upfronthosting.co.za>


R. David Murray added the comment:

Because, as indicated by the OP, I'm not using the default event loop of the thread.

Thinking about my code, I now remember that the reason I went down this path was because I wanted to make sure that my functions, like asyncio functions, accepted the optional loop parameter, and that it worked. For it to work my code pretty much has to pass loop everywhere, because that was a design decision I made early on.  So maybe there's nothing interesting for me here after all.

----------

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

From report at bugs.python.org  Fri May  6 13:40:20 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 06 May 2016 17:40:20 +0000
Subject: [issue26939] android: test_functools hangs on armv7
In-Reply-To: <1462289866.52.0.349587333392.issue26939@psf.upfronthosting.co.za>
Message-ID: <1462556420.71.0.994559808128.issue26939@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> Still hangs at test_lru_cache_threaded with this last patch :(

What about the other tests (test_importlib, test_threading)?

Do you know in which precise test it hangs? (use "-v" to print test names)

> There are two threads, gdb does not print the backtrace of the other thread.

Even with "thread apply all backtrace" (Google tells me this is the incantation)?

----------

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

From report at bugs.python.org  Fri May  6 13:51:41 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 06 May 2016 17:51:41 +0000
Subject: [issue26967] argparse: allow_abbrev=False stops -vv from working
In-Reply-To: <1462475086.65.0.670765920247.issue26967@psf.upfronthosting.co.za>
Message-ID: <1462557101.21.0.209768229311.issue26967@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

I agree with you. But right now, it seems parsing short options and allow_abbrev both rely on the same logic. If you turn off allow_abbrev, short options parsing also disabled. Separating them seems nontrivial.

----------

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

From report at bugs.python.org  Fri May  6 13:54:11 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 May 2016 17:54:11 +0000
Subject: [issue26163] FAIL: test_hash_effectiveness
 (test.test_set.TestFrozenSet)
In-Reply-To: <1453293464.25.0.570690037157.issue26163@psf.upfronthosting.co.za>
Message-ID: <1462557251.27.0.864372688461.issue26163@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I can stably reproduce this. 

PYTHONHASHSEED=36 ./python -m test.regrtest -vm test_hash_effectiveness test_set

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

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

From report at bugs.python.org  Fri May  6 14:43:09 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 06 May 2016 18:43:09 +0000
Subject: [issue26889] Improve Doc/library/xmlrpc.client.rst
In-Reply-To: <1461965955.82.0.756722302068.issue26889@psf.upfronthosting.co.za>
Message-ID: <1462560189.4.0.317009490977.issue26889@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

This is my first reading of this doc.  The formatting improvements look good.  A definite enhancement.

Review contains a few comments.  My main difficulty is separating creation of a proxy instance from use of a proxy instance.  Some of the creation parameters govern the use, and hence do not make must sense until one reads the instance description a few paragraphs further on.  
Perhaps the initial sentence "A :class:`ServerProxy` instance is an object that manages communication with aremote XML-RPC server." should be expanded into a paragraph with some of the description given later.

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

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

From report at bugs.python.org  Fri May  6 15:11:20 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 06 May 2016 19:11:20 +0000
Subject: [issue26903] ProcessPoolExecutor(max_workers=64) crashes on Windows
In-Reply-To: <1462135538.41.0.857077084248.issue26903@psf.upfronthosting.co.za>
Message-ID: <1462561880.5.0.0226952369883.issue26903@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The example runs fine, in about 1 second, on my 6 core (which I guess is 12 logical cores) Pentium.  I am guessing that the default number of workers needs to be changed, at least on Windows, to min(#logical_cores, 60)

----------
nosy: +bquinlan, terry.reedy

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

From report at bugs.python.org  Fri May  6 15:20:24 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 06 May 2016 19:20:24 +0000
Subject: [issue26941] android: test_threading hangs on armv7
In-Reply-To: <1462290426.09.0.613967464154.issue26941@psf.upfronthosting.co.za>
Message-ID: <1462562424.87.0.61771202832.issue26941@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Adding the back trace.

----------
Added file: http://bugs.python.org/file42761/test_threading_gdb_bt.txt

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

From report at bugs.python.org  Fri May  6 15:23:32 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 06 May 2016 19:23:32 +0000
Subject: [issue26906] format(object.__reduce__) fails intermittently
In-Reply-To: <1462194444.45.0.679859267338.issue26906@psf.upfronthosting.co.za>
Message-ID: <1462562612.3.0.0385806531671.issue26906@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Is there a way to have format() try to force the initialization, by explicitly doing the equivalent of obj.__format__, at least for types, instead of raising the TypeError?

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

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

From report at bugs.python.org  Fri May  6 15:30:04 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 06 May 2016 19:30:04 +0000
Subject: [issue26906] format(object.__reduce__) fails intermittently
In-Reply-To: <1462562612.3.0.0385806531671.issue26906@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJJ1c3Z+PMVy1ooD9a-V98PGciaVu0MH+Aadpj8PN4XtSg@mail.gmail.com>


Guido van Rossum added the comment:

But the problem isn't limited to format()... Why would format() be special?

----------

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

From report at bugs.python.org  Fri May  6 15:34:06 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 06 May 2016 19:34:06 +0000
Subject: [issue26940] android: test_importlib hangs on armv7
In-Reply-To: <1462290134.16.0.615698223309.issue26940@psf.upfronthosting.co.za>
Message-ID: <1462563246.6.0.00323036164232.issue26940@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Adding gdb backtrace.

----------
Added file: http://bugs.python.org/file42762/test_importlib_gdb_bt.txt

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

From report at bugs.python.org  Fri May  6 15:43:51 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 06 May 2016 19:43:51 +0000
Subject: [issue26938] android: test_concurrent_futures hangs on armv7
In-Reply-To: <1462289530.91.0.204802241019.issue26938@psf.upfronthosting.co.za>
Message-ID: <1462563831.74.0.219990437959.issue26938@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

The strace output, the process is blocked in a futex system call:

root at generic:/ # strace -p 1304
Process 1304 attached
futex(0xb6f24880, FUTEX_WAIT_PRIVATE, 2, NULL

----------

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

From report at bugs.python.org  Fri May  6 15:46:52 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 May 2016 19:46:52 +0000
Subject: [issue26889] Improve Doc/library/xmlrpc.client.rst
In-Reply-To: <1461965955.82.0.756722302068.issue26889@psf.upfronthosting.co.za>
Message-ID: <1462564012.74.0.0678017319739.issue26889@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your review Terry. Updated patch addresses most of your comments. But I'm unable to expand ServerProxy description as you suggest. May you can do this? My purpose was modest. Just fix some incorrect and outdated sentences. Then I fixed some formatting. I was not going and is not able to do anything besides this. I will take all that you offer.

----------
Added file: http://bugs.python.org/file42763/docs_xmlrpc_client_2.patch

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

From report at bugs.python.org  Fri May  6 15:58:12 2016
From: report at bugs.python.org (Ilya Kulakov)
Date: Fri, 06 May 2016 19:58:12 +0000
Subject: [issue26969] ascynio should provide a policy to address
 pass-loop-everywhere problem
In-Reply-To: <1462517538.3.0.176027238089.issue26969@psf.upfronthosting.co.za>
Message-ID: <1462564692.26.0.224104952002.issue26969@psf.upfronthosting.co.za>


Ilya Kulakov added the comment:

> Why does it have to be a standard part of asyncio?

I've only seen few libraries that deal with asyncio so far (aiohttp, pyzmq), but my general impression is that this is a generic problem.

With asyncio code should be (ideally) written as a set of coroutines which schedule each other or are called in response to monitored events. That means (and asyncio very implementation shows that) loop has to be "self" for all coroutines it executes.

Thread-local default event loop is a good solution to get an entry point into the event loop from an out-of-event-loop execution location. But (ideally) there will be exactly one place in code where this behavior is convenient: when you "instantiate" and run event loop. After that the event loop becomes "self" for each coroutine it may run and therefore it's now convenient for get_event_loop to return currently running event loop.

Probably it would make sense to modify behavior of the default policy to make get_event_loop to return Thread-local event loop when called from out-of-event-loop and return currently running event loop when called from within a coroutine.

> Why don't you just use 'loop = asyncio.get_event_loop()' in places where you need the loop?

As David pointed out, I'm not using thread-local event loop.

----------

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

From report at bugs.python.org  Fri May  6 15:58:37 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 May 2016 19:58:37 +0000
Subject: [issue26911] lib2to3/tests/pytree_idempotency.py has a broken import
In-Reply-To: <1462218326.23.0.838867840781.issue26911@psf.upfronthosting.co.za>
Message-ID: <20160506195827.42369.46332.9240F7CC@psf.io>


Roundup Robot added the comment:

New changeset 3279c910d0e0 by Terry Jan Reedy in branch '3.5':
Issue 26911: fix import (other problems remain).
https://hg.python.org/cpython/rev/3279c910d0e0

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

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

From report at bugs.python.org  Fri May  6 16:02:39 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 06 May 2016 20:02:39 +0000
Subject: [issue26969] ascynio should provide a policy to address
 pass-loop-everywhere problem
In-Reply-To: <1462517538.3.0.176027238089.issue26969@psf.upfronthosting.co.za>
Message-ID: <1462564959.15.0.0110223721599.issue26969@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> Probably it would make sense to modify behavior of the default policy to make get_event_loop to return Thread-local event loop when called from out-of-event-loop and return currently running event loop when called from within a coroutine.

The problem with this approach is that you're relying on the presence of GIL.  If, let's say, PyPy releases tomorrow with 3.5 and STM, this won't work.

----------

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

From report at bugs.python.org  Fri May  6 16:05:35 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 06 May 2016 20:05:35 +0000
Subject: [issue26969] ascynio should provide a policy to address
 pass-loop-everywhere problem
In-Reply-To: <1462517538.3.0.176027238089.issue26969@psf.upfronthosting.co.za>
Message-ID: <1462565135.76.0.52670589771.issue26969@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

To clarify: the problem lies in "return currently running event loop when called from within a coroutine" -- what if there is no GIL and we have a few event loops running?  You'd need to use a threadlocal storage.  In this case I'm not sure how this is different from the current "get_event_loop".

----------

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

From report at bugs.python.org  Fri May  6 16:09:08 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 May 2016 20:09:08 +0000
Subject: [issue26906] format(object.__reduce__) fails intermittently
In-Reply-To: <1462194444.45.0.679859267338.issue26906@psf.upfronthosting.co.za>
Message-ID: <1462565348.96.0.1013750194.issue26906@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There is one test (ClassPropertiesAndMethods.test_mutable_bases_with_failing_mro in test_descr) that crashes with the code from issue551412 because _PyType_Lookup() is recursive called from PyType_Ready(). Is this the reason? My patch prevents recursive calls.

Here is minimal example (for Python 3):

class M(type):
    def mro(self):
        hasattr(self, 'foo')
        return type.mro(self)

class C(metaclass=M):
    pass

When class C is created, C.mro() is called while C still is not ready. Resolving an attribute calls _PyType_Lookup() which calls PyType_Ready() which calls mro() etc.

----------
keywords:  -patch

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

From report at bugs.python.org  Fri May  6 16:09:48 2016
From: report at bugs.python.org (Ilya Kulakov)
Date: Fri, 06 May 2016 20:09:48 +0000
Subject: [issue26969] ascynio should provide a policy to address
 pass-loop-everywhere problem
In-Reply-To: <1462517538.3.0.176027238089.issue26969@psf.upfronthosting.co.za>
Message-ID: <1462565388.81.0.677673641248.issue26969@psf.upfronthosting.co.za>


Ilya Kulakov added the comment:

> In this case I'm not sure how this is different from the current "get_event_loop"

Thread may have multiple event loops, but only one, explicitly associated, is default. And it's not necessary one which is currently running.

I think what I propose here can be expressed in Python terms as an implicit context manager that replaces Thread's default event loop once while it "runs" particular event loop then switches it back (possible to None) once loop is stopped.

----------

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

From report at bugs.python.org  Fri May  6 16:11:19 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 06 May 2016 20:11:19 +0000
Subject: [issue26939] android: test_functools hangs on armv7
In-Reply-To: <1462289866.52.0.349587333392.issue26939@psf.upfronthosting.co.za>
Message-ID: <1462565479.6.0.00931559841103.issue26939@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

> Do you know in which precise test it hangs?

They are named in the first msg of each issue, the issues are:
    issue #26938: android: test_concurrent_futures hangs on armv7
    issue #26939: android: test_functools hangs on armv7
    issue #26940: android: test_importlib hangs on armv7
    issue #26941: android: test_threading hangs on armv7

The test_threading and test_importlib issues have also now a gdb backtrace, so we know not only the test name but also the full python frame stack with line numbers thanks to python-gdb.py magic. It seems that test_functools, test_threading and test_importlib all hang within take_gil().

test_concurrent_futures is different and hangs in a futex().

With "thread apply all backtrace",  nothing changes and gdb still prints:
    Cannot access memory at address 0x0
    #0  0xb6efae6c in ?? ()
    #1  0xb6efd830 in ?? ()
    Backtrace stopped: previous frame identical to this frame (corrupt stack?)

The problem seems to be that gdb does not have enough information to unwind the stack for the other threads and for thread #1 it only works after an interrupted continue command, and not on gdb startup.

----------

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

From report at bugs.python.org  Fri May  6 16:18:10 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 06 May 2016 20:18:10 +0000
Subject: [issue26969] ascynio should provide a policy to address
 pass-loop-everywhere problem
In-Reply-To: <1462517538.3.0.176027238089.issue26969@psf.upfronthosting.co.za>
Message-ID: <1462565890.45.0.731828882448.issue26969@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> Thread may have multiple event loops, but only one, explicitly associated, is default. And it's not necessary one which is currently running.

Ah, I got it.  You know what, this actually is starting to make sense.

Guido, what do you think about this?  Essentially, (Ilya, feel free to correct me if I'm wrong), we can implement the following:

1. Add a new thread-local storage, say "_running_loop"

2. Add another method "asyncio.get_running_loop()"

3. Update some places in asyncio where we currently use "get_event_loop()", such as Future constructor, Task.current_task, etc.

This might actually solve an awkwardness of get_event_loop(), which when called, instantiates an event loop if it doesn't find one, which makes it difficult to know if an event loop was running before the call.

----------

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

From report at bugs.python.org  Fri May  6 16:22:59 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 06 May 2016 20:22:59 +0000
Subject: [issue26969] ascynio should provide a policy to address
 pass-loop-everywhere problem
In-Reply-To: <1462565890.45.0.731828882448.issue26969@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJ+apo5KC9dhuTNGi5o_eenY84dZvaHwNhUiqqevW6VqUA@mail.gmail.com>


Guido van Rossum added the comment:

Honestly I think it's pretty crazy and out there to have multiple event
loops in the same thread. That feels like an anti-pattern inspired by some
other event loop APIs (in other languages) that encourage this. But asyncio
was not designed for that.

----------

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

From report at bugs.python.org  Fri May  6 16:25:34 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 06 May 2016 20:25:34 +0000
Subject: [issue26906] format(object.__reduce__) fails intermittently
In-Reply-To: <1462565348.96.0.1013750194.issue26906@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJJGKp8hhOwh+gj7=sc4=AX+5HA9kD9EWYJ7z3JqU-WUow@mail.gmail.com>


Guido van Rossum added the comment:

Probably.

----------

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

From report at bugs.python.org  Fri May  6 16:29:52 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 06 May 2016 20:29:52 +0000
Subject: [issue26969] ascynio should provide a policy to address
 pass-loop-everywhere problem
In-Reply-To: <1462517538.3.0.176027238089.issue26969@psf.upfronthosting.co.za>
Message-ID: <1462566592.56.0.446416543988.issue26969@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> Honestly I think it's pretty crazy and out there to have multiple event
loops in the same thread. That feels like an anti-pattern inspired by some
other event loop APIs (in other languages) that encourage this. But asyncio
was not designed for that.

I agree.

OTOH, if you're designing a library for asyncio, you want it to be as foolproof as possible, so many people simply pass an event loop everywhere.  It's especially annoying when you have a huge chunk of code that didn't need the loop, and then when something needs it you have to refactor everything or use "get_event_loop".

In terms of performance, I don't think this is gonna affect anything, it's just a couple of additional thread-local sets in the Loop.run method.

And we can design "get_running_loop" to raise a clear exception if no loop is currently running.

----------

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

From report at bugs.python.org  Fri May  6 16:36:09 2016
From: report at bugs.python.org (Ilya Kulakov)
Date: Fri, 06 May 2016 20:36:09 +0000
Subject: [issue26969] ascynio should provide a policy to address
 pass-loop-everywhere problem
In-Reply-To: <1462517538.3.0.176027238089.issue26969@psf.upfronthosting.co.za>
Message-ID: <1462566969.8.0.0756519495778.issue26969@psf.upfronthosting.co.za>


Ilya Kulakov added the comment:

Yury, that would do it.

Guido, that's indeed might be an anti-pattern. But it looks like passing event loop around is just a worse version of it.

----------

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

From report at bugs.python.org  Fri May  6 16:38:16 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 06 May 2016 20:38:16 +0000
Subject: [issue26911] lib2to3/tests/pytree_idempotency.py does not run
In-Reply-To: <1462218326.23.0.838867840781.issue26911@psf.upfronthosting.co.za>
Message-ID: <1462567096.12.0.644351489115.issue26911@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

(Import errors are runtime errors, not compile errors.)

After 'import lib2to3.pgen2', 'pgen2' in the code would not be valid.  A 'from' import is needed instead.  I fixed the import for 3.5/6 (but not 2.7), but the file still does not run.

  File "F:\Python\dev\35\lib\lib2to3\tests\pytree_idempotency.py", line 27, in main
    gr = driver.load_grammar("Grammar.txt")
 ,,,
FileNotFoundError: [Errno 2] No such file or directory: 'Grammar.txt'

After fixing this with

 def main():
-    gr = driver.load_grammar("Grammar.txt")
+    gfile = os.path.dirname(os.path.dirname(__file__)) + "/Grammar.txt"
+    gr = driver.load_grammar(gfile)
     dr = driver.Driver(gr, convert=pytree.convert)
 
the file fails with

FileNotFoundError: [Errno 2] No such file or directory: 'example.py'

There is no 'example.py in lib2to3.  The closest is lib2to3/tests/data/fixers/parrot_example.py.  At this point, I leave it Benjamin to fix the file so it runs or delete it.

The file is not used anywhere since it is not part of the regular test suite (that would require the name to begin with 'test_').  It was meant to be run as a test by itself -- see the doc string.  Perhaps the completion of 2to3 and the test suite made it obsolete.

----------
nosy: +terry.reedy
stage:  -> needs patch
title: lib2to3/tests/pytree_idempotency.py has a broken import -> lib2to3/tests/pytree_idempotency.py does not run
type: compile error -> behavior
versions: +Python 2.7, Python 3.6

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

From report at bugs.python.org  Fri May  6 16:45:56 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 06 May 2016 20:45:56 +0000
Subject: [issue26939] android: test_functools hangs on armv7
In-Reply-To: <1462289866.52.0.349587333392.issue26939@psf.upfronthosting.co.za>
Message-ID: <1462567556.68.0.469963801215.issue26939@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Forgot to say that the backtraces for test_threading and test_importlib were obtained with the patch applied while they were hanging.

----------

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

From report at bugs.python.org  Fri May  6 16:50:10 2016
From: report at bugs.python.org (Ilya Kulakov)
Date: Fri, 06 May 2016 20:50:10 +0000
Subject: [issue26969] ascynio should provide a policy to address
 pass-loop-everywhere problem
In-Reply-To: <1462517538.3.0.176027238089.issue26969@psf.upfronthosting.co.za>
Message-ID: <1462567810.33.0.347657320251.issue26969@psf.upfronthosting.co.za>


Ilya Kulakov added the comment:

> Update some places in asyncio where we currently use "get_event_loop()", such as Future constructor, Task.current_task, etc.

Yury, do you have an idea how it could be done?

----------

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

From report at bugs.python.org  Fri May  6 16:51:14 2016
From: report at bugs.python.org (R. David Murray)
Date: Fri, 06 May 2016 20:51:14 +0000
Subject: [issue26969] ascynio should provide a policy to address
 pass-loop-everywhere problem
In-Reply-To: <1462517538.3.0.176027238089.issue26969@psf.upfronthosting.co.za>
Message-ID: <1462567874.65.0.723408436583.issue26969@psf.upfronthosting.co.za>


R. David Murray added the comment:

The way I avoid the errors of failing to always pass the loop through in my application library, currently, is to run my tests in a thread with no event loop set up, so that get_event_loop will raise an error.  Take that for what it is worth, since I don't claim to know what best practices are in asyncio programming.

----------

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

From report at bugs.python.org  Fri May  6 16:52:39 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 06 May 2016 20:52:39 +0000
Subject: [issue22234] urllib.parse.urlparse accepts any falsy value as an url
In-Reply-To: <1408538391.97.0.53072227801.issue22234@psf.upfronthosting.co.za>
Message-ID: <1462567959.24.0.232116413135.issue22234@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Luiz for your testing.

> __main__:1: DeprecationWarning: Use of '' is deprecated

It is bad that a warning is emitted for default value.

> Will bytes be deprecated if used as a default_schema?

No, only using empty bytes schema with string url is deprecated (because it works now). Using non-empty bytes schema with string url just causes an error.

> Shouldn't it complain that the types are different?

This special case is left for compatibility with wrappers.

> __main__:1: DeprecationWarning: Use of [] is deprecated

The warning should not be emitted for the value that the user did not provide.

If go by the way of strong deprecation, the patch needs reworking. But this is a way of overcomplication.

Since as pointed Antti, only using str, bytes and bytearray is documented, I think we can ignore the breakage for other types.

----------

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

From report at bugs.python.org  Fri May  6 17:00:56 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 06 May 2016 21:00:56 +0000
Subject: [issue26969] ascynio should provide a policy to address
 pass-loop-everywhere problem
In-Reply-To: <1462517538.3.0.176027238089.issue26969@psf.upfronthosting.co.za>
Message-ID: <1462568456.34.0.0993207365605.issue26969@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

>> Update some places in asyncio where we currently use "get_event_loop()", such as Future constructor, Task.current_task, etc.

> Yury, do you have an idea how it could be done?

I think I do.  To keep the backwards compatibility, we'll need to update the "get_event_loop()" function as follows:

  def get_event_loop():
     loop = _running_loop.loop
     if loop is None:
         loop = get_event_loop_old_impl()
     return loop

No need to actually update Future or Task or any other asyncio code.

The get_running_loop() would look like this:

  def get_running_loop():
     loop = _running_loop.loop
     if loop is None:
         raise RuntimeError('no running event loop')
     return loop

----------

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

From report at bugs.python.org  Fri May  6 17:08:50 2016
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 06 May 2016 21:08:50 +0000
Subject: [issue16113] Add SHA-3 and SHAKE (Keccak) support
In-Reply-To: <1349233804.79.0.00772371618682.issue16113@psf.upfronthosting.co.za>
Message-ID: <1462568930.98.0.56094437353.issue16113@psf.upfronthosting.co.za>


Changes by Christian Heimes <lists at cheimes.de>:


----------
hgrepos:  -152

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

From report at bugs.python.org  Fri May  6 17:09:21 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 06 May 2016 21:09:21 +0000
Subject: [issue26912] Broken imports in test/test_email/torture_test.py,
 test_asian_codecs.py) has a broken import
In-Reply-To: <1462221853.95.0.795708912177.issue26912@psf.upfronthosting.co.za>
Message-ID: <1462568961.42.0.322396272259.issue26912@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

As with #26911, no 'test_' prefix means 'run by hand'.  I will make the two simple fixes, as well as delete 'from types import ListType' (ListType is list, and removed in 3.x).  But I will not try to run the torture test, hence no guarantee that it will run after import.

----------
nosy: +terry.reedy
stage:  -> needs patch
title: test/test_email/torture_test.py (and test_asian_codecs.py) has a broken import -> Broken imports in test/test_email/torture_test.py, test_asian_codecs.py) has a broken import
type: compile error -> behavior

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

From report at bugs.python.org  Fri May  6 17:12:14 2016
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 06 May 2016 21:12:14 +0000
Subject: [issue16113] Add SHA-3 and SHAKE (Keccak) support
In-Reply-To: <1349233804.79.0.00772371618682.issue16113@psf.upfronthosting.co.za>
Message-ID: <1462569134.66.0.129894227986.issue16113@psf.upfronthosting.co.za>


Christian Heimes added the comment:

This patch implements SHA-3 and SHAKE for Python 3.6. The algorithm is provided by a slightly modified copy of the Keccak Code Package. I had to replace C++ comments and perform some minor cleanups.

----------
stage: needs patch -> patch review
Added file: http://bugs.python.org/file42764/SHA3-and-SHAKE-support-for-Python.patch

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

From report at bugs.python.org  Fri May  6 17:35:38 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 06 May 2016 21:35:38 +0000
Subject: [issue26912] Broken imports in test/test_email/torture_test.py,
 test_asian_codecs.py) has a broken import
In-Reply-To: <1462221853.95.0.795708912177.issue26912@psf.upfronthosting.co.za>
Message-ID: <20160506213535.9357.1482.B5CCF092@psf.io>


Roundup Robot added the comment:

New changeset e7da216ba17c by Terry Jan Reedy in branch '3.5':
Issue 26912: fix broken imports in test_email package.
https://hg.python.org/cpython/rev/e7da216ba17c

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

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

From report at bugs.python.org  Fri May  6 17:54:25 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 06 May 2016 21:54:25 +0000
Subject: [issue26912] Broken imports in test/test_email/torture_test.py,
 test_asian_codecs.py) has a broken import
In-Reply-To: <1462221853.95.0.795708912177.issue26912@psf.upfronthosting.co.za>
Message-ID: <1462571665.32.0.452040935656.issue26912@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I also removed try to import the deleted support.TestSkipped.  I temporarily commented out the SkipTest replacement so the module would run, create the test class, run it, and fail.

I believe the import of run_unittest and the associated test_main, etc, can be deleted, but that is another issue.

----------
assignee:  -> terry.reedy
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

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

From report at bugs.python.org  Fri May  6 17:56:13 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 06 May 2016 21:56:13 +0000
Subject: [issue26911] lib2to3/tests/pytree_idempotency.py has broken imports
In-Reply-To: <1462218326.23.0.838867840781.issue26911@psf.upfronthosting.co.za>
Message-ID: <1462571773.0.0.79328592421.issue26911@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I decided that I should leave the scope of this issue as it was and close it as fixed.

----------
assignee:  -> terry.reedy
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed
title: lib2to3/tests/pytree_idempotency.py does not run -> lib2to3/tests/pytree_idempotency.py has broken imports
versions:  -Python 2.7

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

From report at bugs.python.org  Fri May  6 17:58:50 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 06 May 2016 21:58:50 +0000
Subject: [issue26969] ascynio should provide a policy to address
 pass-loop-everywhere problem
In-Reply-To: <1462568456.34.0.0993207365605.issue26969@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJL3wsDEAVwecj8tdkWJrTVLghnZpcWm5i4nJLopVj54=w@mail.gmail.com>


Guido van Rossum added the comment:

FWIW asyncio's own test suite makes sure that the loop is indeed passed
everywhere by setting the default loop to None. If a library chooses to
pass the loop around like this it should structure its tests the same way.

----------

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

From report at bugs.python.org  Fri May  6 18:14:13 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 06 May 2016 22:14:13 +0000
Subject: [issue26934] android: test_faulthandler fails
In-Reply-To: <1462287504.69.0.311102051296.issue26934@psf.upfronthosting.co.za>
Message-ID: <1462572853.65.0.13398638981.issue26934@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The 8 failures are all because exitcode is 0 when it should not be.

    self.assertNotEqual(exitcode, 0)
AssertionError: 0 == 0

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

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

From report at bugs.python.org  Fri May  6 18:26:39 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 06 May 2016 22:26:39 +0000
Subject: [issue26889] Improve Doc/library/xmlrpc.client.rst
In-Reply-To: <1461965955.82.0.756722302068.issue26889@psf.upfronthosting.co.za>
Message-ID: <1462573599.42.0.414436803477.issue26889@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The corrected link works.  I agree with deleting a bad sentence if you cannot fix it.  I think you can go ahead and apply as is.

----------

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

From report at bugs.python.org  Fri May  6 23:50:01 2016
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 07 May 2016 03:50:01 +0000
Subject: [issue22107] tempfile module misinterprets access denied error on
 Windows
In-Reply-To: <1406724041.52.0.0365391579019.issue22107@psf.upfronthosting.co.za>
Message-ID: <1462593001.64.0.130303022272.issue22107@psf.upfronthosting.co.za>


Eryk Sun added the comment:

The Windows API loses information when mapping kernel status values to Windows error codes. For example, the following status values are all mapped to ERROR_ACCESS_DENIED:

    STATUS_INVALID_LOCK_SEQUENCE   0xc000001e
    STATUS_INVALID_VIEW_SIZE       0xc000001f
    STATUS_ALREADY_COMMITTED       0xc0000021
    STATUS_ACCESS_DENIED           0xc0000022
    STATUS_PORT_CONNECTION_REFUSED 0xc0000041
    STATUS_THREAD_IS_TERMINATING   0xc000004b
    STATUS_DELETE_PENDING          0xc0000056
    STATUS_FILE_IS_A_DIRECTORY     0xc00000ba
    STATUS_FILE_RENAMED            0xc00000d5
    STATUS_PROCESS_IS_TERMINATING  0xc000010a
    STATUS_CANNOT_DELETE           0xc0000121
    STATUS_FILE_DELETED            0xc0000123

    Encrypting File System
    STATUS_ENCRYPTION_FAILED       0xc000028a
    STATUS_DECRYPTION_FAILED       0xc000028b
    STATUS_NO_RECOVERY_POLICY      0xc000028d
    STATUS_NO_EFS                  0xc000028e
    STATUS_WRONG_EFS               0xc000028f
    STATUS_NO_USER_KEYS            0xc0000290

STATUS_ACCESS_DENIED is from a failed NtAccessCheck. STATUS_FILE_IS_A_DIRECTORY is from trying to open a directory as a file, because NT doesn't allow accessing the anonymous data stream of a directory, such as "dirname::$DATA", which is the same as trying to open "dirname" as a file. It only allows creating a named data stream for a directory, such as "dirname:streamname:$DATA".

The original status value may still be available, but only by calling the undocumented runtime library function, RtlGetLastNtStatus, which was added in XP (NT 5.1). After a failed system call, the Windows base API calls BaseSetLastNTError, which calls RtlNtStatusToDosError to get the Win32/DOS error code for a given NT status value. This in turn caches the last NT status in the LastStatusValue field of the thread environment block (TEB). RtlGetLastNtStatus gets this value from the TEB.

Possibly PyErr_SetExcFromWindowsErrWithFilenameObjects could capture the most recent kernel status value from RtlGetLastNtStatus(), to add this as a new "ntstatus" attribute of OSError. This wouldn't always be meaningful, since the thread's LastErrorValue (returned by GetLastError) isn't always related to a failed system call, but it can help in cases such as this, to distinguish a genuine denial of access from some other failure, and without suffering from race conditions. 

For example, I added a "testdir" subdirectory to a directory and then modified the DACL of the parent directory to deny write/append access for all users. The following experiment checks the NT status using ctypes:

    STATUS_ACCESS_DENIED = ctypes.c_long(0xC0000022).value
    STATUS_FILE_IS_A_DIRECTORY = ctypes.c_long(0xC00000BA).value

    ntdll = ctypes.WinDLL('ntdll')

    try: open('testdir', 'w')
    except: status_dir = ntdll.RtlGetLastNtStatus()

    try: open('test', 'w')
    except: status_access = ntdll.RtlGetLastNtStatus()

    >>> status_dir == STATUS_FILE_IS_A_DIRECTORY
    True
    >>> status_access == STATUS_ACCESS_DENIED
    True

Obviously using ctypes isn't recommended, since the status value needs to be captured ASAP after the call fails, so here's an example in C:

    #define UNICODE
    #include <Windows.h>
    #include <fcntl.h>
    #include <stdio.h>

    typedef NTSTATUS (NTAPI *RTLGETLASTNTSTATUS)(VOID);

    int main()
    {
        HMODULE hNtdll = GetModuleHandle(L"ntdll");
        RTLGETLASTNTSTATUS RtlGetLastNtStatus = (RTLGETLASTNTSTATUS)
            GetProcAddress(hNtdll, "RtlGetLastNtStatus");

        if (_open("testdir", _O_CREAT | _O_EXCL) == -1)
            printf("status_dir: %#08x\n", RtlGetLastNtStatus());

        if (_open("test", _O_CREAT | _O_EXCL) == -1)
            printf("status_access: %#08x\n", RtlGetLastNtStatus());
     
       return 0;
    }

output:

    status_dir: 0xc00000ba
    status_access: 0xc0000022

----------

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

From report at bugs.python.org  Sat May  7 01:45:36 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 May 2016 05:45:36 +0000
Subject: [issue26889] Improve Doc/library/xmlrpc.client.rst
In-Reply-To: <1461965955.82.0.756722302068.issue26889@psf.upfronthosting.co.za>
Message-ID: <20160507054533.22581.4847.2516F85C@psf.io>


Roundup Robot added the comment:

New changeset 04250fc723e6 by Serhiy Storchaka in branch '3.5':
Issue #26889: Tweaked xmlrpc.client documentation.
https://hg.python.org/cpython/rev/04250fc723e6

New changeset 9bdec549bad3 by Serhiy Storchaka in branch 'default':
Issue #26889: Tweaked xmlrpc.client documentation.
https://hg.python.org/cpython/rev/9bdec549bad3

New changeset fb5bd513751f by Serhiy Storchaka in branch '2.7':
Issue #26889: Tweaked xmlrpclib documentation.
https://hg.python.org/cpython/rev/fb5bd513751f

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

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

From report at bugs.python.org  Sat May  7 01:46:29 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 May 2016 05:46:29 +0000
Subject: [issue26889] Improve Doc/library/xmlrpc.client.rst
In-Reply-To: <1461965955.82.0.756722302068.issue26889@psf.upfronthosting.co.za>
Message-ID: <1462599989.44.0.475062525149.issue26889@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Terry.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 2.7

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

From report at bugs.python.org  Sat May  7 01:51:24 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 May 2016 05:51:24 +0000
Subject: [issue17765] weakref.ref ignores a 'callback' keyword argument
In-Reply-To: <1366139470.36.0.39573405184.issue17765@psf.upfronthosting.co.za>
Message-ID: <1462600284.75.0.879067515218.issue17765@psf.upfronthosting.co.za>


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


----------
assignee:  -> georg.brandl

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

From report at bugs.python.org  Sat May  7 03:07:28 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 May 2016 07:07:28 +0000
Subject: [issue26889] Improve Doc/library/xmlrpc.client.rst
In-Reply-To: <1461965955.82.0.756722302068.issue26889@psf.upfronthosting.co.za>
Message-ID: <20160507070724.15120.42780.9D9D3727@psf.io>


Roundup Robot added the comment:

New changeset 52924d962027 by Serhiy Storchaka in branch '3.5':
Issue #26889: Fixed hyperlinks formatting.
https://hg.python.org/cpython/rev/52924d962027

New changeset ea9d69a4d0fe by Serhiy Storchaka in branch 'default':
Issue #26889: Fixed hyperlinks formatting.
https://hg.python.org/cpython/rev/ea9d69a4d0fe

New changeset 29a927c524cb by Serhiy Storchaka in branch '2.7':
Issue #26889: Fixed hyperlinks formatting.
https://hg.python.org/cpython/rev/29a927c524cb

----------

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

From report at bugs.python.org  Sat May  7 03:09:56 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 07 May 2016 07:09:56 +0000
Subject: [issue26934] android: test_faulthandler fails
In-Reply-To: <1462287504.69.0.311102051296.issue26934@psf.upfronthosting.co.za>
Message-ID: <1462604996.81.0.406899110803.issue26934@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Reproducing the code that is executed on the first failure (test_disable) gives:

On linux:
$ python
Python 3.6.0a0 (default:47fa003aa9f1, Feb 24 2016, 13:09:02) 
[GCC 5.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import faulthandler
>>> faulthandler.enable()
>>> faulthandler.disable()
True
>>> faulthandler._sigsegv()
Segmentation fault (core dumped)


On the android emulator:
root at generic_x86:/data/local/tmp # python
Python 3.6.0a0 (default:811ccdee6f87+, May  7 2016, 09:02:21) 
[GCC 4.9 20140827 (prerelease)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import faulthandler
>>> faulthandler.enable()
>>> faulthandler.disable()
True
>>> faulthandler._sigsegv()
>>>

----------

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

From report at bugs.python.org  Sat May  7 03:17:36 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 May 2016 07:17:36 +0000
Subject: [issue26885] Add parsing support for more types in xmlrpc
In-Reply-To: <1461943983.79.0.576979457392.issue26885@psf.upfronthosting.co.za>
Message-ID: <1462605456.18.0.554741959596.issue26885@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Updated documentation.

Terry, could you please look at the documentation. Is it good English or needed a correction?

----------
nosy: +terry.reedy
Added file: http://bugs.python.org/file42765/xmlrpc_extensions2.patch

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

From report at bugs.python.org  Sat May  7 03:19:31 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 May 2016 07:19:31 +0000
Subject: [issue26736] Use HTTPS protocol in links
In-Reply-To: <1460399300.6.0.985736947814.issue26736@psf.upfronthosting.co.za>
Message-ID: <1462605571.95.0.507494430834.issue26736@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> serhiy.storchaka

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

From report at bugs.python.org  Sat May  7 03:28:28 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 07 May 2016 07:28:28 +0000
Subject: [issue26934] android: test_faulthandler fails
In-Reply-To: <1462287504.69.0.311102051296.issue26934@psf.upfronthosting.co.za>
Message-ID: <1462606108.04.0.0575766378529.issue26934@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

The gdb backtrace of running interactively 'faulthandler._sigsegv()'. After the SIGSEGV and the last gdb 'continue', python is still alive with a '>>>' prompt and ready for the next user input:


(gdb) b faulthandler_sigsegv
Breakpoint 1 at 0xb752159f: file /home/xavier/src/packages/android/cpython/Modules/faulthandler.c, line 964.
(gdb) c
Continuing.

Breakpoint 1, faulthandler_sigsegv (self=self at entry=<module at remote 0xb6d85cf4>, 
    args=args at entry=()) at /home/xavier/src/packages/android/cpython/Modules/faulthandler.c:964
964     {
(gdb) next
965         int release_gil = 0;
(gdb) 
966         if (!PyArg_ParseTuple(args, "|i:_sigsegv", &release_gil))
(gdb) 
969         if (release_gil) {
(gdb) 
974             faulthandler_raise_sigsegv();
(gdb) step
faulthandler_raise_sigsegv ()
    at /home/xavier/src/packages/android/cpython/Modules/faulthandler.c:941
941     {
(gdb) next
942         faulthandler_suppress_crash_report();
(gdb) 
958         raise(SIGSEGV);
(gdb) 

Program received signal SIGSEGV, Segmentation fault.
0xb76ec126 in ?? ()
(gdb) c
Continuing.

----------

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

From report at bugs.python.org  Sat May  7 03:50:43 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 May 2016 07:50:43 +0000
Subject: [issue26736] Use HTTPS protocol in links
In-Reply-To: <1460399300.6.0.985736947814.issue26736@psf.upfronthosting.co.za>
Message-ID: <20160507075040.15124.39200.5C34A6C2@psf.io>


Roundup Robot added the comment:

New changeset 211a9f32dfb9 by Serhiy Storchaka in branch '3.5':
Issue #26736: Used HTTPS for external links in the documentation if possible.
https://hg.python.org/cpython/rev/211a9f32dfb9

New changeset 3ceb54a49387 by Serhiy Storchaka in branch 'default':
Issue #26736: Used HTTPS for external links in the documentation if possible.
https://hg.python.org/cpython/rev/3ceb54a49387

New changeset e3af25d70976 by Serhiy Storchaka in branch '2.7':
Issue #26736: Used HTTPS for external links in the documentation if possible.
https://hg.python.org/cpython/rev/e3af25d70976

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

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

From report at bugs.python.org  Sat May  7 04:06:05 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 May 2016 08:06:05 +0000
Subject: [issue26736] Use HTTPS protocol in links
In-Reply-To: <1460399300.6.0.985736947814.issue26736@psf.upfronthosting.co.za>
Message-ID: <1462608365.59.0.360114844167.issue26736@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The :rfc: and :pep: roles are defined in Sphinx. I don't know if they can be configured to use HTTPS.

----------

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

From report at bugs.python.org  Sat May  7 04:09:26 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 May 2016 08:09:26 +0000
Subject: [issue26708] Constify C string pointers in the posix module
In-Reply-To: <1460009897.32.0.801268253531.issue26708@psf.upfronthosting.co.za>
Message-ID: <1462608566.04.0.101177493418.issue26708@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could anyone please try to compile with the patch on Windows and report if there are complile errors?

----------
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

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

From report at bugs.python.org  Sat May  7 04:13:57 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 07 May 2016 08:13:57 +0000
Subject: [issue19444] mmap.mmap() allocates a file descriptor that isn't
 CLOEXEC
In-Reply-To: <1383110349.25.0.857290073089.issue19444@psf.upfronthosting.co.za>
Message-ID: <1462608837.09.0.666868297286.issue19444@psf.upfronthosting.co.za>


Martin Panter added the comment:

Closing because Victor has proposed a patch in Issue 26769.

----------
nosy: +martin.panter
resolution:  -> duplicate
status: open -> closed
superseder:  -> Python 2.7: make private file descriptors non inheritable

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

From report at bugs.python.org  Sat May  7 04:21:25 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 May 2016 08:21:25 +0000
Subject: [issue25747] test_idle failure in leaks searching mode
In-Reply-To: <1448647986.99.0.712792565134.issue25747@psf.upfronthosting.co.za>
Message-ID: <1462609285.33.0.857206458202.issue25747@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

import_fresh_module() emits the deprecation warning twice.

>>> from test.support import import_fresh_module
>>> import_fresh_module('idlelib.idlever')
/home/serhiy/py/cpython-debug/Lib/test/support/__init__.py:166: DeprecationWarning: 
The separate Idle version was eliminated years ago;
idlelib.idlever is no longer used by Idle
and will be removed in 3.6 or later.  Use
    from sys import version
    IDLE_VERSION = version[:version.index(' ')]

  __import__(name)
/home/serhiy/py/cpython-debug/Lib/importlib/__init__.py:126: DeprecationWarning: 
The separate Idle version was eliminated years ago;
idlelib.idlever is no longer used by Idle
and will be removed in 3.6 or later.  Use
    from sys import version
    IDLE_VERSION = version[:version.index(' ')]

  return _bootstrap._gcd_import(name[level:], package, level)
<module 'idlelib.idlever' from '/home/serhiy/py/cpython-debug/Lib/idlelib/idlever.py'>

----------

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

From report at bugs.python.org  Sat May  7 04:51:45 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 07 May 2016 08:51:45 +0000
Subject: [issue26897] Clarify Popen stdin, stdout, stderr
In-Reply-To: <1462077137.11.0.0338937138998.issue26897@psf.upfronthosting.co.za>
Message-ID: <1462611105.44.0.128884284231.issue26897@psf.upfronthosting.co.za>


Martin Panter added the comment:

Yes, in all cases I understand it is just the file descriptor that matters. Perhaps any documentation update could also take Issue 24358 into account, which points out that compressed and buffered file object wrappers also cause inconsistencies in the data at the high-level file object and the OS-level file descriptor.

----------
nosy: +martin.panter
stage:  -> needs patch
versions: +Python 2.7, Python 3.5

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

From report at bugs.python.org  Sat May  7 05:27:18 2016
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 07 May 2016 09:27:18 +0000
Subject: [issue26736] Use HTTPS protocol in links
In-Reply-To: <1460399300.6.0.985736947814.issue26736@psf.upfronthosting.co.za>
Message-ID: <1462613238.02.0.956363092039.issue26736@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Newer Sphinx versions already redefine docutils' RFC and PEP URLs to use https.

----------

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

From report at bugs.python.org  Sat May  7 05:40:46 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 07 May 2016 09:40:46 +0000
Subject: [issue26352] getpass incorrectly displays password prompt on stderr
 on fallback
In-Reply-To: <1455311450.52.0.299309264077.issue26352@psf.upfronthosting.co.za>
Message-ID: <1462614046.48.0.722313044946.issue26352@psf.upfronthosting.co.za>


Martin Panter added the comment:

Why do you think using stderr is bad behaviour, or that a user would want the prompt and warning on different streams? As far as I can tell, the documentation already says that stderr is used by default, and there are other unpatched references to sys.stderr left.

See also Issue 1927, where Serhiy wants to change input() to always prompt to stderr rather than stdout.

----------
nosy: +martin.panter
stage:  -> patch review

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

From report at bugs.python.org  Sat May  7 05:41:05 2016
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 07 May 2016 09:41:05 +0000
Subject: [issue17765] weakref.ref ignores a 'callback' keyword argument
In-Reply-To: <1366139470.36.0.39573405184.issue17765@psf.upfronthosting.co.za>
Message-ID: <1462614065.25.0.0779814131672.issue17765@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Serhiy, feel free to go ahead and commit, I don't have my keys with me ATM.

----------

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

From report at bugs.python.org  Sat May  7 06:05:30 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Sat, 07 May 2016 10:05:30 +0000
Subject: [issue26934] android: test_faulthandler fails
In-Reply-To: <1462287504.69.0.311102051296.issue26934@psf.upfronthosting.co.za>
Message-ID: <1462615530.79.0.111545442167.issue26934@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

This is due to something mysterious in Android's bionic & kernel. For the following C program:

#include <stdlib.h>
#include <signal.h>
#include <stdio.h>

int main()
{
    sigaction(SIGSEGV, NULL, NULL);
    raise(SIGSEGV);
    printf("Good evening!\n");
    return 0;
}

Compiled with: /opt/android-ndk/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-gcc test_sigsegv.c --sysroot /opt/android-ndk/platforms/android-21/arch-arm -fPIE -Wl,-pie
(Replace /opt/android-ndk to the path of NDK)

On ASUS ZE500KL:
shell at ASUS_Z00E_2:/data/local/tmp $ ./a.out
Good evening!

On Linux: (Compiled with gcc test_sigsegv.c)
$ ./a.out 
[2]    23434 segmentation fault (core dumped)  ./a.out

Seems the sigaction() call in Python occurs in Modules/signalmodule.c.

----------
nosy: +Chi Hsuan Yen

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

From report at bugs.python.org  Sat May  7 06:37:27 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 May 2016 10:37:27 +0000
Subject: [issue26352] getpass incorrectly displays password prompt on stderr
 on fallback
In-Reply-To: <1455311450.52.0.299309264077.issue26352@psf.upfronthosting.co.za>
Message-ID: <1462617447.94.0.155107253793.issue26352@psf.upfronthosting.co.za>


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


----------
nosy: +serhiy.storchaka
status: open -> pending

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

From report at bugs.python.org  Sat May  7 07:14:09 2016
From: report at bugs.python.org (Antti Haapala)
Date: Sat, 07 May 2016 11:14:09 +0000
Subject: [issue26906] format(object.__reduce__) fails intermittently
In-Reply-To: <1462194444.45.0.679859267338.issue26906@psf.upfronthosting.co.za>
Message-ID: <1462619649.41.0.325736485273.issue26906@psf.upfronthosting.co.za>


Antti Haapala added the comment:

I am not an expert on PyType internals, so I am wondering why is the PyType_Ready'ing done implicitly at all?

----------

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

From report at bugs.python.org  Sat May  7 07:17:08 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 May 2016 11:17:08 +0000
Subject: [issue16113] Add SHA-3 and SHAKE (Keccak) support
In-Reply-To: <1349233804.79.0.00772371618682.issue16113@psf.upfronthosting.co.za>
Message-ID: <1462619828.49.0.783274134767.issue16113@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Is there any guidance or recommendation on how to use the SHAKE variants?

----------

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

From report at bugs.python.org  Sat May  7 07:19:53 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 07 May 2016 11:19:53 +0000
Subject: [issue26903] ProcessPoolExecutor(max_workers=64) crashes on Windows
In-Reply-To: <1462135538.41.0.857077084248.issue26903@psf.upfronthosting.co.za>
Message-ID: <1462619993.09.0.175655549874.issue26903@psf.upfronthosting.co.za>


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


----------
nosy: +sbt

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

From report at bugs.python.org  Sat May  7 07:47:39 2016
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 07 May 2016 11:47:39 +0000
Subject: [issue26708] Constify C string pointers in the posix module
In-Reply-To: <1460009897.32.0.801268253531.issue26708@psf.upfronthosting.co.za>
Message-ID: <1462621659.76.0.795336987926.issue26708@psf.upfronthosting.co.za>


Eryk Sun added the comment:

I get the following warnings:

..\Modules\posixmodule.c(7422): warning C4090: 'function': different 'const' qualifiers [...]
..\Modules\posixmodule.c(7423): warning C4090: 'function': different 'const' qualifiers [...]

        target_is_directory |= _check_dirW(src->wide, dst->wide);
        result = Py_CreateSymbolicLinkW(dst->wide, src->wide,
                                        target_is_directory);

..\Modules\posixmodule.c(7429): warning C4090: 'function': different 'const' qualifiers [...]

        result = Py_CreateSymbolicLinkA(dst->narrow, src->narrow,
                                        target_is_directory);

You can change _check_dirW to use LPCWSTR parameters, or const wchar_t * to be consistent with _check_dirA. In this context I prefer the Windows typedefs:

    _check_dirW(LPCWSTR src, LPCWSTR dest)
    _check_dirA(LPCSTR src, LPCSTR dest)

Change Py_CreateSymbolicLink[W|A] to use LPC[W]STR, which is how it's declared in Winbase.h:

    static DWORD (CALLBACK *Py_CreateSymbolicLinkW)(LPCWSTR, LPCWSTR, DWORD) = NULL;
    static DWORD (CALLBACK *Py_CreateSymbolicLinkA)(LPCSTR, LPCSTR, DWORD) = NULL;

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

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

From report at bugs.python.org  Sat May  7 07:52:32 2016
From: report at bugs.python.org (John Hagen)
Date: Sat, 07 May 2016 11:52:32 +0000
Subject: [issue25521] optparse module does not emit DeprecationWarning
In-Reply-To: <1446247354.16.0.386152814173.issue25521@psf.upfronthosting.co.za>
Message-ID: <1462621952.74.0.823033755777.issue25521@psf.upfronthosting.co.za>


John Hagen added the comment:

With 3.6.0a1 scheduled just around the corner, is there consensus about how to begin this?  I just signed the contributor agreement, so I should be able to try to help if we have a plan on how to divide the work.

----------

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

From report at bugs.python.org  Sat May  7 08:20:25 2016
From: report at bugs.python.org (ppperry)
Date: Sat, 07 May 2016 12:20:25 +0000
Subject: [issue26859] unittest fails with "Start directory is not importable"
 when trying to run sourceless tests
In-Reply-To: <1461678137.48.0.743276761028.issue26859@psf.upfronthosting.co.za>
Message-ID: <1462623625.33.0.572120790422.issue26859@psf.upfronthosting.co.za>


Changes by ppperry <mapreader at olum.org>:


----------
title: unittest fails with "Start directory is not importable" -> unittest fails with "Start directory is not importable" when trying to run sourceless tests

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

From report at bugs.python.org  Sat May  7 08:32:05 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 07 May 2016 12:32:05 +0000
Subject: [issue18726] json functions have too many positional parameters
In-Reply-To: <1376392694.75.0.457946059126.issue18726@psf.upfronthosting.co.za>
Message-ID: <1462624325.37.0.657901699805.issue18726@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat May  7 08:44:33 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 May 2016 12:44:33 +0000
Subject: [issue17765] weakref.ref ignores a 'callback' keyword argument
In-Reply-To: <1366139470.36.0.39573405184.issue17765@psf.upfronthosting.co.za>
Message-ID: <20160507124429.67133.8723.0D6C3D78@psf.io>


Roundup Robot added the comment:

New changeset ee17a83feabc by Serhiy Storchaka in branch '3.5':
Issue #17765: weakref.ref() no longer silently ignores keyword arguments.
https://hg.python.org/cpython/rev/ee17a83feabc

New changeset 60de9c6188cc by Serhiy Storchaka in branch '2.7':
Issue #17765: weakref.ref() no longer silently ignores keyword arguments.
https://hg.python.org/cpython/rev/60de9c6188cc

New changeset ef55fa8c4b82 by Serhiy Storchaka in branch 'default':
Issue #17765: weakref.ref() no longer silently ignores keyword arguments.
https://hg.python.org/cpython/rev/ef55fa8c4b82

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

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

From report at bugs.python.org  Sat May  7 08:48:00 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 May 2016 12:48:00 +0000
Subject: [issue17765] weakref.ref ignores a 'callback' keyword argument
In-Reply-To: <1366139470.36.0.39573405184.issue17765@psf.upfronthosting.co.za>
Message-ID: <1462625280.12.0.0050290148099.issue17765@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Done. This issue is similar to recently closed issue26822.

Please give me know if you have other ready to review patches.

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

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

From report at bugs.python.org  Sat May  7 08:56:22 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 May 2016 12:56:22 +0000
Subject: [issue19253] PyArg_ParseTuple: wrong use of seterror() clips helpful
 type error annotation
In-Reply-To: <1381698493.04.0.861687446453.issue19253@psf.upfronthosting.co.za>
Message-ID: <1462625782.77.0.0643574412364.issue19253@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Error message was fixed in issue26198.

>>> format(None, 1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: format() argument 2 must be str, not int

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

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

From report at bugs.python.org  Sat May  7 08:57:34 2016
From: report at bugs.python.org (R. David Murray)
Date: Sat, 07 May 2016 12:57:34 +0000
Subject: [issue26352] getpass incorrectly displays password prompt on stderr
 on fallback
In-Reply-To: <1455311450.52.0.299309264077.issue26352@psf.upfronthosting.co.za>
Message-ID: <1462625854.27.0.31840137775.issue26352@psf.upfronthosting.co.za>


R. David Murray added the comment:

stdout is much more likely to be redirected than stderr, so falling back to stderr makes more sense than falling back to stdout.  In the normal case, the prompt is shown regardless of whether stdout is redirected, and we're trying our best to replicate that in the fallback.

----------
nosy: +r.david.murray
resolution:  -> rejected
stage: patch review -> resolved
status: pending -> closed

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

From report at bugs.python.org  Sat May  7 09:15:42 2016
From: report at bugs.python.org (Larry Hastings)
Date: Sat, 07 May 2016 13:15:42 +0000
Subject: [issue16113] Add SHA-3 and SHAKE (Keccak) support
In-Reply-To: <1349233804.79.0.00772371618682.issue16113@psf.upfronthosting.co.za>
Message-ID: <1462626942.07.0.2557020375.issue16113@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Christian: any interest in proposing this for 2.7?  We could ask Benjamin.  It could still make 2.7.11--rc1 should be tagged in about a month.

----------

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

From report at bugs.python.org  Sat May  7 09:17:42 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 May 2016 13:17:42 +0000
Subject: [issue26708] Constify C string pointers in the posix module
In-Reply-To: <1460009897.32.0.801268253531.issue26708@psf.upfronthosting.co.za>
Message-ID: <1462627062.76.0.0354860059022.issue26708@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Eryk. Here is updated patch. Is it correct?

----------
Added file: http://bugs.python.org/file42766/posixmodule_constify2.patch

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

From report at bugs.python.org  Sat May  7 09:36:58 2016
From: report at bugs.python.org (Eryk Sun)
Date: Sat, 07 May 2016 13:36:58 +0000
Subject: [issue26708] Constify C string pointers in the posix module
In-Reply-To: <1460009897.32.0.801268253531.issue26708@psf.upfronthosting.co.za>
Message-ID: <1462628218.29.0.756223024822.issue26708@psf.upfronthosting.co.za>


Eryk Sun added the comment:

It looks good to me. There are no errors or warnings.

----------

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

From report at bugs.python.org  Sat May  7 09:41:24 2016
From: report at bugs.python.org (Jaroslav Urban)
Date: Sat, 07 May 2016 13:41:24 +0000
Subject: [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 09:45:45 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 May 2016 13:45:45 +0000
Subject: [issue26708] Constify C string pointers in the posix module
In-Reply-To: <1460009897.32.0.801268253531.issue26708@psf.upfronthosting.co.za>
Message-ID: <20160507134537.21021.94559.0FAFA01B@psf.io>


Roundup Robot added the comment:

New changeset 7edf74098c76 by Serhiy Storchaka in branch 'default':
Issue #26708: Use the "const" qualifier for immutable strings.
https://hg.python.org/cpython/rev/7edf74098c76

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

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

From report at bugs.python.org  Sat May  7 09:46:53 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 May 2016 13:46:53 +0000
Subject: [issue26708] Constify C string pointers in the posix module
In-Reply-To: <1460009897.32.0.801268253531.issue26708@psf.upfronthosting.co.za>
Message-ID: <1462628813.1.0.515185202356.issue26708@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat May  7 10:25:01 2016
From: report at bugs.python.org (Jaroslav Urban)
Date: Sat, 07 May 2016 14:25:01 +0000
Subject: [issue26971] python v3.5.1: sys.paths not respecting DESTDIRS and
 DESTSHARED
In-Reply-To: <1462628482.0.0.926875224828.issue26971@psf.upfronthosting.co.za>
Message-ID: <1462631101.16.0.91509185978.issue26971@psf.upfronthosting.co.za>


Jaroslav Urban added the comment:

just a remark, my system is

$uname -r
4.4.5-200.fc22.x86_64

and these python-related rpm archives are installed:

$rpm -qa | grep python
python-IPy-0.81-12.fc22.noarch
python-urllib3-1.13.1-3.fc22.noarch
libselinux-python-2.3-10.fc22.x86_64
python-kitchen-1.2.1-2.fc22.noarch
python-backports-1.0-5.fc22.x86_64
python3-gobject-3.16.2-1.fc22.x86_64
python3-slip-dbus-0.6.4-1.fc22.noarch
python-meh-0.40-1.fc22.noarch
python3-dbus-1.2.0-7.fc22.x86_64
python3-PyXB-1.2.4-2.fc22.noarch
python-augeas-0.5.0-2.fc22.noarch
python-libcomps-0.1.6-14.fc22.x86_64
python-libs-2.7.10-8.fc22.x86_64
python-pwquality-1.2.4-3.fc22.x86_64
libsemanage-python-2.3-6.fc22.x86_64
python-di-0.3-4.fc21.noarch
python3-requests-2.9.1-1.fc22.noarch
libxml2-python-2.9.3-1.fc22.x86_64
audit-libs-python-2.4.5-1.fc22.x86_64
python-dnf-langpacks-0.15.1-1.fc22.noarch
python-talloc-2.1.5-2.fc22.x86_64
python-pexpect-3.1-3.fc21.noarch
python-pip-6.0.8-1.fc22.noarch
python3-libs-3.4.2-6.fc22.x86_64
python3-cups-1.9.72-1.fc22.x86_64
python3-pycurl-7.19.5.1-3.fc22.x86_64
python-dnf-1.1.6-2.fc22.noarch
python3-humanize-0.5.1-1.fc22.noarch
python3-pip-6.0.8-1.fc22.noarch
python3-cairo-1.10.0-11.fc22.x86_64
python-blivet-1.0.10-1.fc22.noarch
python3-lxml-3.3.6-1.fc22.x86_64
python-pyudev-0.16.1-3.fc22.noarch
python-iniparse-0.4-15.fc22.noarch
python3-enchant-1.6.6-1.fc22.noarch
python3-systemd-231-4.fc22.x86_64
python3-urllib3-1.13.1-3.fc22.noarch
python-2.7.10-8.fc22.x86_64
python-coverage-4.0.3-1.fc22.x86_64
python-slip-0.6.4-1.fc22.noarch
python3-firewall-0.3.14.2-4.fc22.noarch
python3-sssdconfig-1.13.3-5.fc22.noarch
python-hawkey-0.6.2-2.fc22.x86_64
python2-pyparsing-2.1.0-2.fc22.noarch
python-xpyb-1.3.1-4.fc22.x86_64
python-setuptools-17.1.1-3.fc22.noarch
python3-setuptools-17.1.1-3.fc22.noarch
python-pycurl-7.19.5.1-3.fc22.x86_64
python-six-1.9.0-1.fc22.noarch
python-decorator-3.4.0-5.fc21.noarch
python-dmidecode-3.10.13-12.fc22.x86_64
python2-systemd-231-4.fc22.x86_64
python-requests-2.9.1-1.fc22.noarch
python-backports-ssl_match_hostname-3.5.0.1-1.fc22.noarch
policycoreutils-python-2.3-18.fc22.x86_64
python-slip-dbus-0.6.4-1.fc22.noarch
python-librepo-1.7.16-1.fc22.x86_64
langtable-python-0.0.34-1.fc22.noarch
python-firewall-0.3.14.2-4.fc22.noarch
python-chardet-2.2.1-2.fc22.noarch
python3-six-1.9.0-1.fc22.noarch
python3-chardet-2.2.1-2.fc22.noarch
python-meh-gui-0.40-1.fc22.noarch
libuser-python-0.62-1.fc22.x86_64
libselinux-python3-2.3-10.fc22.x86_64
libreport-python3-2.6.4-1.fc22.x86_64
python-urlgrabber-3.10.1-6.fc22.noarch
python-dnf-plugins-extras-common-0.0.11-1.fc22.noarch
python3-inotify-0.9.6-1.fc22.noarch
python3-slip-0.6.4-1.fc22.noarch
newt-python-0.52.18-1.fc22.x86_64
python-ntplib-0.3.2-3.fc21.noarch
dbus-python-1.2.0-7.fc22.x86_64
python3-decorator-3.4.0-5.fc21.noarch
rpm-python-4.12.0.1-14.fc22.x86_64
libreport-python-2.6.4-1.fc22.x86_64
python3-javapackages-4.3.2-6.fc22.noarch
python-sssdconfig-1.13.3-5.fc22.noarch
python3-3.4.2-6.fc22.x86_64
python-dnf-plugins-core-0.1.16-1.fc22.noarch
python-dnf-plugins-extras-migrate-0.0.11-1.fc22.noarch
python3-cssselect-0.9.1-5.fc22.noarch

----------

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

From report at bugs.python.org  Sat May  7 10:25:20 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 May 2016 14:25:20 +0000
Subject: [issue11643] Use |version| instead of X.Y in the doc
In-Reply-To: <1300838111.66.0.617899175478.issue11643@psf.upfronthosting.co.za>
Message-ID: <1462631120.89.0.0216256185406.issue11643@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Agree with ?ric.

----------
nosy: +serhiy.storchaka
resolution:  -> rejected
stage: needs patch -> resolved
status: open -> closed

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

From report at bugs.python.org  Sat May  7 10:41:28 2016
From: report at bugs.python.org (ppperry)
Date: Sat, 07 May 2016 14:41:28 +0000
Subject: [issue4260] Document that ctypes.xFUNCTYPE are decorators.
In-Reply-To: <1225864263.85.0.365773038706.issue4260@psf.upfronthosting.co.za>
Message-ID: <1462632088.63.0.348693322722.issue4260@psf.upfronthosting.co.za>


Changes by ppperry <mapreader at olum.org>:


----------
title: ctypes.xFUNCTYPE are decorators. -> Document that ctypes.xFUNCTYPE are decorators.

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

From report at bugs.python.org  Sat May  7 10:47:00 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 May 2016 14:47:00 +0000
Subject: [issue18730] suffix parameter in NamedTemporaryFile silently fails
 when not prepending with a period
In-Reply-To: <1376427240.14.0.584954211651.issue18730@psf.upfronthosting.co.za>
Message-ID: <1462632420.97.0.636793613482.issue18730@psf.upfronthosting.co.za>


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


----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python
stage: needs patch -> patch review
type: behavior -> enhancement
versions: +Python 3.5, Python 3.6 -Python 3.3, Python 3.4

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

From report at bugs.python.org  Sat May  7 10:51:26 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 07 May 2016 14:51:26 +0000
Subject: [issue26906] format(object.__reduce__) fails intermittently
In-Reply-To: <1462619649.41.0.325736485273.issue26906@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJJy=yoPaXRkqqSiSQrVYMKmwMRf3LNNU0Omoz=xofwiKg@mail.gmail.com>


Guido van Rossum added the comment:

Because the data structure that defines a type is just data, and at some
point PyType_Ready() must be called. The question is how to do this, given
that nobody can (or needs to) produce a definitive list of all types.

----------

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

From report at bugs.python.org  Sat May  7 12:02:44 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 07 May 2016 16:02:44 +0000
Subject: [issue26935] android: test_os fails
In-Reply-To: <1462287800.22.0.0769666286965.issue26935@psf.upfronthosting.co.za>
Message-ID: <1462636964.31.0.384006651227.issue26935@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

On android dup2() returns with an error when both fds are the same:

root at generic_x86:/data/local/tmp # python
Python 3.6.0a0 (default:811ccdee6f87+, May  7 2016, 12:44:06) 
[GCC 4.9 20140827 (prerelease)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.dup2(1, 1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 22] Invalid argument


The attached patch fixes this in test_urandom_fd_reopened.

----------
keywords: +patch
Added file: http://bugs.python.org/file42768/test_urandom_fd_reopened.patch

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

From report at bugs.python.org  Sat May  7 12:11:18 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 07 May 2016 16:11:18 +0000
Subject: [issue26924] android: test_concurrent_futures fails
In-Reply-To: <1462282676.16.0.612748828.issue26924@psf.upfronthosting.co.za>
Message-ID: <1462637478.47.0.811336698484.issue26924@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for testing. Here is a new patch.

----------
stage:  -> patch review
Added file: http://bugs.python.org/file42769/sem_unlink_v2.diff

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

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: [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  Sat May  7 12:16:50 2016
From: report at bugs.python.org (Oren Milman)
Date: Sat, 07 May 2016 16:16:50 +0000
Subject: [issue26972] mistakes in docstrings in the import machinery
In-Reply-To: <1462637766.06.0.0379757360626.issue26972@psf.upfronthosting.co.za>
Message-ID: <1462637810.66.0.634802627615.issue26972@psf.upfronthosting.co.za>


Changes by Oren Milman <orenmn at gmail.com>:


Added file: http://bugs.python.org/file42771/CPythonTestOutput.txt

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

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


Changes by Oren Milman <orenmn at gmail.com>:


Added file: http://bugs.python.org/file42772/patchedCPythonTestOutput.txt

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

From report at bugs.python.org  Sat May  7 12:26:44 2016
From: report at bugs.python.org (SilentGhost)
Date: Sat, 07 May 2016 16:26:44 +0000
Subject: [issue26972] mistakes in docstrings in the import machinery
In-Reply-To: <1462637766.06.0.0379757360626.issue26972@psf.upfronthosting.co.za>
Message-ID: <1462638404.77.0.126079732029.issue26972@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +brett.cannon
stage:  -> patch review
type:  -> behavior

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

From report at bugs.python.org  Sat May  7 12:34:22 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 07 May 2016 16:34:22 +0000
Subject: [issue26972] mistakes in docstrings in the import machinery
In-Reply-To: <1462637766.06.0.0379757360626.issue26972@psf.upfronthosting.co.za>
Message-ID: <1462638862.71.0.0759966318315.issue26972@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Thanks for the thorough review, Oren! I'll have a look at the patch when I get a chance.

----------
assignee:  -> brett.cannon
priority: normal -> low

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

From report at bugs.python.org  Sat May  7 12:47:13 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 07 May 2016 16:47:13 +0000
Subject: [issue26936] android: test_socket fails
In-Reply-To: <1462288246.37.0.495121419926.issue26936@psf.upfronthosting.co.za>
Message-ID: <1462639633.35.0.426596704206.issue26936@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

On android getservbyname(const char *NAME, const char *PROTO) returns NULL when PROTO is NULL:

root at generic_x86:/data/local/tmp # python
Python 3.6.0a0 (default:811ccdee6f87+, May  7 2016, 17:56:37) 
[GCC 4.9 20140827 (prerelease)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> socket.getservbyname('daytime', 'tcp')
13
>>> socket.getservbyname('daytime', 'udp')
13
>>> socket.getservbyname('daytime')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: service/proto not found
>>> 


On android socket.getaddrinfo() raises an exception when port is not a number:

>>> socket.getaddrinfo('127.0.0.1', 80)
[(<AddressFamily.AF_INET: 2>, <SocketKind.SOCK_DGRAM: 2>, 17, '', ('127.0.0.1', 80)), (<AddressFamily.AF_INET: 2>, <SocketKind.SOCK_STREAM: 1>, 6, '', ('127.0.0.1', 80))]
>>> socket.getaddrinfo('127.0.0.1', 'http')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  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
>>>

----------

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

From report at bugs.python.org  Sat May  7 13:00:08 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 07 May 2016 17:00:08 +0000
Subject: [issue26924] android: test_concurrent_futures fails
In-Reply-To: <1462282676.16.0.612748828.issue26924@psf.upfronthosting.co.za>
Message-ID: <1462640408.46.0.944461168463.issue26924@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Here is the result of the test:

root at generic_x86:/data/local/tmp # python -m test -v test_concurrent_futures
== CPython 3.6.0a0 (default:811ccdee6f87+, May 7 2016, 18:51:28) [GCC 4.9 20140827 (prerelease)]
==   Linux-3.4.67+-i686-with-libc little-endian
==   hash algorithm: fnv 32bit
==   /data/local/tmp/test_python_2024
Testing with flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0)
Run tests sequentially
0:00:00 [1/1] test_concurrent_futures
test_concurrent_futures skipped -- This platform lacks a functioning sem_open implementation, therefore, the required synchronization primitives needed will not function, see issue 3770.
1 test skipped:
    test_concurrent_futures
Total duration: 0:00:01

----------

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

From report at bugs.python.org  Sat May  7 13:01:53 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 07 May 2016 17:01:53 +0000
Subject: [issue26924] android: test_concurrent_futures fails
In-Reply-To: <1462282676.16.0.612748828.issue26924@psf.upfronthosting.co.za>
Message-ID: <1462640513.47.0.0950696605636.issue26924@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

> Here is the result of the test:

I meant, results with the new patch.

----------

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

From report at bugs.python.org  Sat May  7 13:10:24 2016
From: report at bugs.python.org (Antti Haapala)
Date: Sat, 07 May 2016 17:10:24 +0000
Subject: [issue26906] format(object.__reduce__) fails intermittently
In-Reply-To: <1462194444.45.0.679859267338.issue26906@psf.upfronthosting.co.za>
Message-ID: <1462641024.43.0.202264405485.issue26906@psf.upfronthosting.co.za>


Antti Haapala added the comment:

Could it be possible to to make the debug build absolutely abort on any usage of PyType's that are not readied, usage including instantiating them. Then, instead of changing all `static` linkages to `extern`s (as in Serhiy's first patch) one could rather make per-compilation unit initialization functions that are called from objects.c; that way it would be easier to use preprocessor to turn on and off the very existence of certain types in a compilation unit based on a preprocessor flag.

Likewise the C-API docs for PyType_Ready should perhaps say "This must be called on all type objects to finish their initialization." instead of "should"

----------

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

From report at bugs.python.org  Sat May  7 13:38:54 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 May 2016 17:38:54 +0000
Subject: [issue26924] android: test_concurrent_futures fails
In-Reply-To: <1462282676.16.0.612748828.issue26924@psf.upfronthosting.co.za>
Message-ID: <20160507173851.130799.78438.F135227F@psf.io>


Roundup Robot added the comment:

New changeset 1030aa8357a7 by Berker Peksag in branch 'default':
Issue #26924: Do not define _multiprocessing.sem_unlink under Android
https://hg.python.org/cpython/rev/1030aa8357a7

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

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

From report at bugs.python.org  Sat May  7 13:39:21 2016
From: report at bugs.python.org (Eric Fahlgren)
Date: Sat, 07 May 2016 17:39:21 +0000
Subject: [issue22893] Idle: __future__ does not work in startup code.
In-Reply-To: <1416261777.24.0.465929106454.issue22893@psf.upfronthosting.co.za>
Message-ID: <1462642761.38.0.960898843877.issue22893@psf.upfronthosting.co.za>


Changes by Eric Fahlgren <ericfahlgren at gmail.com>:


----------
nosy: +eric.fahlgren

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

From report at bugs.python.org  Sat May  7 13:39:40 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 07 May 2016 17:39:40 +0000
Subject: [issue26924] android: test_concurrent_futures fails
In-Reply-To: <1462282676.16.0.612748828.issue26924@psf.upfronthosting.co.za>
Message-ID: <1462642780.66.0.870377246726.issue26924@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks, Xavier.

----------
components: +Extension Modules -Cross-Build, Library (Lib)
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Sat May  7 14:13:25 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 07 May 2016 18:13:25 +0000
Subject: [issue26924] android: test_concurrent_futures fails
In-Reply-To: <1462282676.16.0.612748828.issue26924@psf.upfronthosting.co.za>
Message-ID: <20160507181321.67129.4925.5F24520B@psf.io>


Roundup Robot added the comment:

New changeset eee959fee5f5 by Berker Peksag in branch 'default':
Issue #26924: Fix Windows buildbots
https://hg.python.org/cpython/rev/eee959fee5f5

----------

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

From report at bugs.python.org  Sat May  7 14:17:30 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 07 May 2016 18:17:30 +0000
Subject: [issue26924] android: test_concurrent_futures fails
In-Reply-To: <1462282676.16.0.612748828.issue26924@psf.upfronthosting.co.za>
Message-ID: <1462645050.97.0.313081305118.issue26924@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Xavier, could you try this alternative patch?

----------
Added file: http://bugs.python.org/file42773/sem_unlink_alt.diff

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

From report at bugs.python.org  Sat May  7 14:23:03 2016
From: report at bugs.python.org (Tim Peters)
Date: Sat, 07 May 2016 18:23:03 +0000
Subject: [issue26903] ProcessPoolExecutor(max_workers=64) crashes on Windows
In-Reply-To: <1462135538.41.0.857077084248.issue26903@psf.upfronthosting.co.za>
Message-ID: <1462645383.19.0.137793545849.issue26903@psf.upfronthosting.co.za>


Tim Peters added the comment:

Just noting that the `multiprocessing` module can be used instead.  In the example, add

    import multiprocessing as mp

and change

        with concurrent.futures.ProcessPoolExecutor() as executor:

to

        with mp.Pool() as executor:

That's all it takes.  On my 4-core Win10 box (8 logical cores), that continued to work fine even when passing 1024 to mp.Pool() (although it obviously burned time and RAM to create over a thousand processes).

Some quick Googling strongly suggests there's no reasonably general way to overcome the Windows-defined MAXIMUM_WAIT_OBJECTS=64 for implementations that call the Windows WaitForMultipleObjects().

----------
nosy: +tim.peters

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

From report at bugs.python.org  Sat May  7 15:02:41 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 May 2016 19:02:41 +0000
Subject: [issue12290] __setstate__ is called for false values
In-Reply-To: <1307586060.34.0.652262251036.issue12290@psf.upfronthosting.co.za>
Message-ID: <1462647761.59.0.692613008726.issue12290@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Actually this wording is not quite correct. __setstate__() is called for any pickled state. It is not called only if the state is not pickled. The state is not pickled if reducing method (__reduce_ex__ or __reduce__) doesn't return state or returns None as a state. Default reducing method for protocol 0 and 1 doesn't return a state if __getstate__() returns false value.

There are many other details of pickle protocol that are not correctly documented in the documentation of the pickle module. PEP 307 documents pickle protocol more correctly.

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

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

From report at bugs.python.org  Sat May  7 15:05:19 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 07 May 2016 19:05:19 +0000
Subject: [issue16113] Add SHA-3 and SHAKE (Keccak) support
In-Reply-To: <1462626942.07.0.2557020375.issue16113@psf.upfronthosting.co.za>
Message-ID: <CAGE7PNK_K+9mjLw=HqAhc4CCKoowHD1-s7=r7fi4qs7CZxBb5Q@mail.gmail.com>


Gregory P. Smith added the comment:

I'd there any good reason 2.7 needs this? They are available via pypi as
extensions. (Read: I vote no)

On Sat, May 7, 2016, 3:15 AM Larry Hastings <report at bugs.python.org> wrote:

>
> Larry Hastings added the comment:
>
> Christian: any interest in proposing this for 2.7?  We could ask
> Benjamin.  It could still make 2.7.11--rc1 should be tagged in about a
> month.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue16113>
> _______________________________________
>

----------

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

From report at bugs.python.org  Sat May  7 15:13:14 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 May 2016 19:13:14 +0000
Subject: [issue6827] deepcopy erroneously doesn't call __setstate__ if
 __getstate__ returns empty dict
In-Reply-To: <1251926992.64.0.823425954467.issue6827@psf.upfronthosting.co.za>
Message-ID: <1462648394.7.0.336307130977.issue6827@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The documentation of the pickle module doesn't match PEP 307 and the implementation. The copy module was changed in issue25718 to match the implementation of the pickle module. This fixed this issue.

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

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

From report at bugs.python.org  Sat May  7 15:19:48 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 07 May 2016 19:19:48 +0000
Subject: [issue26924] android: test_concurrent_futures fails
In-Reply-To: <1462282676.16.0.612748828.issue26924@psf.upfronthosting.co.za>
Message-ID: <1462648788.88.0.752132109061.issue26924@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Attached the results with sem_unlink_alt.diff.

----------
Added file: http://bugs.python.org/file42774/sem_unlink_alt_output.txt

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

From report at bugs.python.org  Sat May  7 15:52:46 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 07 May 2016 19:52:46 +0000
Subject: [issue26924] android: test_concurrent_futures fails
In-Reply-To: <1462282676.16.0.612748828.issue26924@psf.upfronthosting.co.za>
Message-ID: <1462650766.96.0.407678411093.issue26924@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

There is a typo in sem_unlink_alt.diff, not in the patch itself but in the neighbouring lines. In Modules/_multiprocessing/semaphore.c, it should be, I think, after one does 's/define sem_unlink(name)/define SEM_UNLINK(name)/':

@@ -194,8 +194,8 @@
 #  define SEM_FAILED ((sem_t *)-1)
 #endif
 
-#ifndef HAVE_SEM_UNLINK
-#  define sem_unlink(name) 0
+#if !defined(HAVE_SEM_UNLINK) || defined(__ANDROID__)
+#  define SEM_UNLINK(name) 0
 #endif
 
 #ifndef HAVE_SEM_TIMEDWAIT


But applying this new patch, gives exactly the same results. Maybe it is not just sem_unlink() that is not implemented. I will run a gdb session to find out.

----------

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

From report at bugs.python.org  Sat May  7 16:31:24 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 07 May 2016 20:31:24 +0000
Subject: [issue26924] android: test_concurrent_futures fails
In-Reply-To: <1462282676.16.0.612748828.issue26924@psf.upfronthosting.co.za>
Message-ID: <1462653084.71.0.49837262016.issue26924@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

sem_open() is not implemented as well. Here is a gdb session with a breakpoint set at semlock_new() (SEM_FAILED is NULL on android):

Breakpoint 1, semlock_new (type=0xb6d070c0 <_PyMp_SemLockType>, 
    args=(1, 1, 1, '/mp-dkzrq4ed', True), kwds=0x0)
    at /home/xavier/src/packages/android/cpython/Modules/_multiprocessing/semaphore.c:420
420     {
(gdb) next
428         if (!PyArg_ParseTupleAndKeywords(args, kwds, "iiisi", kwlist,
(gdb) 
432         if (kind != RECURSIVE_MUTEX && kind != SEMAPHORE) {
(gdb) 
437         if (!unlink) {
(gdb) 
424         char *name, *name_copy = NULL;
(gdb) 
445         handle = SEM_CREATE(name, value, maxvalue);
(gdb) 
447         if (handle == SEM_FAILED || SEM_GET_LAST_ERROR() != 0)
(gdb) print handle
$5 = (SEM_HANDLE) 0x0
(gdb) next
460         if (handle != SEM_FAILED)
(gdb) 
462         PyMem_Free(name_copy);
(gdb) 
463         _PyMp_SetError(NULL, MP_STANDARD_ERROR);
(gdb) 
464         return NULL;
(gdb) 


This is run with sem_unlink_alt.diff modified to include the change to 'define SEM_UNLINK(name) 0' although I guess this does not change anything.

Sorry for misleading you about sem_unlink().

----------

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

From report at bugs.python.org  Sat May  7 16:59:06 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 07 May 2016 20:59:06 +0000
Subject: [issue26924] android: test_concurrent_futures fails
In-Reply-To: <1462282676.16.0.612748828.issue26924@psf.upfronthosting.co.za>
Message-ID: <1462654746.32.0.210994391186.issue26924@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks! Perhaps we should not set HAVE_SEM_* to 1 if we are on Android in the configure step.

----------

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

From report at bugs.python.org  Sat May  7 17:23:38 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 May 2016 21:23:38 +0000
Subject: [issue23815] Segmentation fault when create _tkinter objects
In-Reply-To: <1427745415.01.0.962782500028.issue23815@psf.upfronthosting.co.za>
Message-ID: <1462656218.22.0.947437759567.issue23815@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There is special exception -- 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). After converting them to heap types they became inherit tp_new from object.

Proposed patch adds workarounds for types in _tkinter and curses.panel modules.

----------
assignee:  -> serhiy.storchaka
keywords: +patch
stage:  -> patch review
versions:  -Python 3.4
Added file: http://bugs.python.org/file42775/tp_new_workaround.patch

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

From report at bugs.python.org  Sat May  7 18:04:31 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 07 May 2016 22:04:31 +0000
Subject: [issue24500] provide context manager to redirect C output
In-Reply-To: <1435161782.93.0.989546707262.issue24500@psf.upfronthosting.co.za>
Message-ID: <1462658671.17.0.304700333649.issue24500@psf.upfronthosting.co.za>


Martin Panter added the comment:

Is it really common to have a C wrapper with undesirable output? I suspect there is not much demand for this feature. Maybe this would be better outside of Python?s standard library.

----------
nosy: +martin.panter
status: open -> languishing

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

From report at bugs.python.org  Sat May  7 18:42:11 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 07 May 2016 22:42:11 +0000
Subject: [issue23815] Segmentation fault when create _tkinter objects
In-Reply-To: <1427745415.01.0.962782500028.issue23815@psf.upfronthosting.co.za>
Message-ID: <1462660931.02.0.0988095201973.issue23815@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The news part of the patch did not apply  -- best not to include such in posted patches.

After recompiliing 3.5 on Windows 10, the two tkinter test cases give the 3.3 TypeErrors instead of crashing.  test_tcl also runs.  curses does not run on Windows.

I do not know enough internals to really understand #15721 or why you call the fix a workaround, but I do understand 'exception' (OK) versus 'crash' (forbidden).  Unless you think restoring the previous situation (tp_new = NUll) can cause a worse problem, I would apply this soon, within a week, so not forgotten before the June update releases.  The tcl test addition is correct.  The fix can be improved later if you think of something better.

I initially wondered why _tkinter has classes that cannot be instantiated (from Python).  Then I discovered that this is normal, and that the exception is standard.

>>> type(iter([]))()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: cannot create 'list_iterator' instances

Is list_iterator.tp_new NULL?  Or does it raise instead of crash by other means?

----------

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

From report at bugs.python.org  Sat May  7 18:43:09 2016
From: report at bugs.python.org (ppperry)
Date: Sat, 07 May 2016 22:43:09 +0000
Subject: [issue26949] IDLE restarts when one debugs code raising SystemExit
In-Reply-To: <1462395098.97.0.302049116339.issue26949@psf.upfronthosting.co.za>
Message-ID: <1462660989.44.0.516549129612.issue26949@psf.upfronthosting.co.za>


ppperry added the comment:

This issue has worse consequences than I previously thought. It also affects `KeyboardInterrupt` with worse consequences.

If you run a program raising `KeyboardInterrupt` in the debugger, the shell will hang. Restarting the shell fixes this problem.

----------

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

From report at bugs.python.org  Sat May  7 18:44:46 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 07 May 2016 22:44:46 +0000
Subject: [issue18730] suffix parameter in NamedTemporaryFile silently fails
 when not prepending with a period
In-Reply-To: <1376427240.14.0.584954211651.issue18730@psf.upfronthosting.co.za>
Message-ID: <1462661086.29.0.382611825108.issue18730@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think Terry may have had the mkstemp() doc string in mind. The NamedTemporaryFile() doc string already points to that function, and it doesn?t make sense to single NamedTemporaryFile() out above other functions.

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

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

From report at bugs.python.org  Sat May  7 18:52:37 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 07 May 2016 22:52:37 +0000
Subject: [issue26935] android: test_os fails
In-Reply-To: <1462287800.22.0.0769666286965.issue26935@psf.upfronthosting.co.za>
Message-ID: <1462661557.65.0.349725137185.issue26935@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think this is an Android bug. See specification <http://pubs.opengroup.org/onlinepubs/9699919799/functions/dup2.html>, fix <https://android.googlesource.com/platform/bionic/+/be52e658171edf6651895c40d1563289bafa52f7%5E!/>.

If the change is to go into Python, it would be good to include a comment admitting it is an Android workaround, rather than a general deficiency.

----------
nosy: +martin.panter
stage:  -> patch review

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

From report at bugs.python.org  Sat May  7 18:56:25 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 07 May 2016 22:56:25 +0000
Subject: [issue14111] IDLE Debugger should handle interrupts
In-Reply-To: <1330112839.68.0.0096879566667.issue14111@psf.upfronthosting.co.za>
Message-ID: <1462661785.11.0.615467180085.issue14111@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

'raise KeyboardInterrupt' in code causes shell to hang until Restart Shell Cntl-F6 in invoked.

>>> 
[DEBUG ON]
>>> raise KeyboardInterrupt
<debug window activates.  Hit [step].  Window deactivates.  No prompt, even in response to Enter.  Shell unresponsive.>
<Restart Shell>
=============================== RESTART: Shell ===============================
[DEBUG ON]
>>> 

The behavior was noted by pperry on #26949, which is about SystemExit behavior.  I currently think it part of this issue.

----------
stage:  -> patch review
type: enhancement -> behavior
versions: +Python 3.6 -Python 3.4

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

From report at bugs.python.org  Sat May  7 18:57:59 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 07 May 2016 22:57:59 +0000
Subject: [issue26949] IDLE restarts when one debugs code raising SystemExit
In-Reply-To: <1462395098.97.0.302049116339.issue26949@psf.upfronthosting.co.za>
Message-ID: <1462661879.56.0.595850710286.issue26949@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

#14111 is about handling ^C while debugging.  So for now I will assume that handling 'raise KeyboardInterrupt' is part of that issue.

----------

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

From report at bugs.python.org  Sat May  7 19:02:44 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 07 May 2016 23:02:44 +0000
Subject: [issue23815] Segmentation fault when create _tkinter objects
In-Reply-To: <1427745415.01.0.962782500028.issue23815@psf.upfronthosting.co.za>
Message-ID: <1462662164.13.0.431474424175.issue23815@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I called the fix a workaround because other solution may be to make PyType_FromSpec() not setting tp_new in such cases. I expect that this is common mistake when convert a static class to a heap class with PyType_FromSpec(). At least we should add warnings in C API documentation and PEP 384. Or change the behavior of PyType_FromSpec() if it is appropriate. But this is different issue. If PyType_FromSpec() will be changed, proposed fix can be reverted.

----------

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

From report at bugs.python.org  Sat May  7 19:13:58 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 07 May 2016 23:13:58 +0000
Subject: [issue14111] IDLE Debugger should handle interrupts
In-Reply-To: <1330112839.68.0.0096879566667.issue14111@psf.upfronthosting.co.za>
Message-ID: <1462662838.55.0.222348459425.issue14111@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

More info: Even though the debug window looks inactive, it is not.  After the restart, debugger cannot be turned off because it is 'active'.  It must be stuck on the raise statement.  The window can be closed, but after that, it cannot be brought back because something is still going.  It takes another Restart to restart debugger.

----------

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

From report at bugs.python.org  Sat May  7 19:18:48 2016
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 07 May 2016 23:18:48 +0000
Subject: [issue23640] int.from_bytes() is broken for subclasses
In-Reply-To: <1426080876.51.0.657090719237.issue23640@psf.upfronthosting.co.za>
Message-ID: <1462663128.94.0.600036754078.issue23640@psf.upfronthosting.co.za>


Ethan Furman added the comment:

Not sure what I was thinking at the time, but several of my comments were supportive of `classmethod`s not calling subclass' __new__; I actually do not think that, and am +1 on the patch.

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

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

From report at bugs.python.org  Sat May  7 19:19:47 2016
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 07 May 2016 23:19:47 +0000
Subject: [issue23640] int.from_bytes() is broken for subclasses
In-Reply-To: <1426080876.51.0.657090719237.issue23640@psf.upfronthosting.co.za>
Message-ID: <1462663187.69.0.939940539221.issue23640@psf.upfronthosting.co.za>


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


----------
Removed message: http://bugs.python.org/msg237891

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

From report at bugs.python.org  Sat May  7 19:20:48 2016
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 07 May 2016 23:20:48 +0000
Subject: [issue23640] int.from_bytes() is broken for subclasses
In-Reply-To: <1426080876.51.0.657090719237.issue23640@psf.upfronthosting.co.za>
Message-ID: <1462663248.19.0.161544961262.issue23640@psf.upfronthosting.co.za>


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


----------
Removed message: http://bugs.python.org/msg239619

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

From report at bugs.python.org  Sat May  7 19:21:08 2016
From: report at bugs.python.org (Ethan Furman)
Date: Sat, 07 May 2016 23:21:08 +0000
Subject: [issue23640] int.from_bytes() is broken for subclasses
In-Reply-To: <1426080876.51.0.657090719237.issue23640@psf.upfronthosting.co.za>
Message-ID: <1462663268.92.0.885336867682.issue23640@psf.upfronthosting.co.za>


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


----------
Removed message: http://bugs.python.org/msg240053

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

From report at bugs.python.org  Sat May  7 19:37:16 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 07 May 2016 23:37:16 +0000
Subject: [issue18730] suffix parameter in NamedTemporaryFile silently fails
 when not prepending with a period
In-Reply-To: <1376427240.14.0.584954211651.issue18730@psf.upfronthosting.co.za>
Message-ID: <1462664235.99.0.962404915598.issue18730@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Correct.  The doc I quoted was for the unlying mkstemp function.  I should have said so even though this fact was easily discovered. So by docstring, I meant the one for mkstemp also, which is currently 27 lines.  The docstring for the high level functions should not change.

I proposed to shorten the docstring by combining the sentences for prefix and suffix, while adding a bit of info.  I decided to withdraw this suggestion and close this issue.

----------
assignee: docs at python -> terry.reedy
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

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

From report at bugs.python.org  Sat May  7 20:12:51 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 08 May 2016 00:12:51 +0000
Subject: [issue23815] Segmentation fault when create _tkinter objects
In-Reply-To: <1427745415.01.0.962782500028.issue23815@psf.upfronthosting.co.za>
Message-ID: <1462666371.41.0.439442920274.issue23815@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I noticed that you reported the crash and asked for a fix or reversion on #15721 6 months ago, with no response.  Hence, lets not wait longer.

Looking again, I see that there were 3 rounds of patches in 2012/2013.  If you want to follow up, I suggest closing that issue and open a fresh issue with with alternatives and your recommendation.

----------

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

From report at bugs.python.org  Sat May  7 20:42:03 2016
From: report at bugs.python.org (Ilya Kulakov)
Date: Sun, 08 May 2016 00:42:03 +0000
Subject: [issue26969] ascynio should provide a policy to address
 pass-loop-everywhere problem
In-Reply-To: <1462517538.3.0.176027238089.issue26969@psf.upfronthosting.co.za>
Message-ID: <1462668123.42.0.17372814033.issue26969@psf.upfronthosting.co.za>


Ilya Kulakov added the comment:

Guido, Probably a legitimate example of having multiple event loops in a single thread: you want to run certain coroutine synchronously without running thread's own event loop.

----------

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

From report at bugs.python.org  Sat May  7 23:10:30 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 08 May 2016 03:10:30 +0000
Subject: [issue23275] Can assign [] = (), but not () = []
In-Reply-To: <1421694347.87.0.147201508367.issue23275@psf.upfronthosting.co.za>
Message-ID: <1462677030.04.0.014991309755.issue23275@psf.upfronthosting.co.za>


Martin Panter added the comment:

Erm, I think you went overboard with the sequence ? iterable changes and subscripting; see the review. Also, I think target_list should be made optional in the grammar description.

----------

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

From report at bugs.python.org  Sat May  7 23:24:54 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 08 May 2016 03:24:54 +0000
Subject: [issue11063] uuid.py module import has heavy side effects
In-Reply-To: <1296321060.32.0.846037411239.issue11063@psf.upfronthosting.co.za>
Message-ID: <1462677894.34.0.849473945862.issue11063@psf.upfronthosting.co.za>


Martin Panter added the comment:

The versioning problem with libFOO.so.N already occurs with compiled programs. A C program compiled against libuuid.so.1 will fail to load if you only have libuuid.so.2. On the other hand, a Python program using find_library() will find either version. My point about robustness is that if a version 2 is invented, it might have different semantics or function signatures, and Python would then be assuming the wrong semantics.

----------

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

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: [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 00:43:28 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 08 May 2016 04:43:28 +0000
Subject: [issue22636] avoid using a shell in ctypes.util: replace os.popen
 with subprocess
In-Reply-To: <1413325975.89.0.175884398711.issue22636@psf.upfronthosting.co.za>
Message-ID: <1462682608.12.0.694349215764.issue22636@psf.upfronthosting.co.za>


Martin Panter added the comment:

There are a few review comments that probably need addressing.

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

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

From report at bugs.python.org  Sun May  8 00:52:59 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 08 May 2016 04:52:59 +0000
Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not
 available (e.g., AIX)
In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za>
Message-ID: <1462683179.24.0.865050001848.issue26439@psf.upfronthosting.co.za>


Martin Panter added the comment:

'''
call find_library("foo")
libc:  libc.a
libc.a:  libc.a
libc.so.6:  libc.a
libcrypto.so:  libcrypto.a
'''

The above don?t seem right to me, unless compiling with ?cc -llibc.so.6? etc works on AIX.

'''
call cdll.LoadLibrary("foo")
m:  <CDLL 'None', handle d at 700000000216860>
libm.so:  <CDLL 'None', handle e at 700000000216860>
'''

These doesn?t look right. What happened to the library name?

With your new aixutil.py file, it might be good to give it an underscore (_) prefix, to indicate it is an internal module rather than part of the ctypes API. So your code would do

import ctypes._aixutil as aix

----------
Added file: http://bugs.python.org/file42776/python.Lib.ctypes.160504.patch

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

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: [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:00:36 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 08 May 2016 06:00:36 +0000
Subject: [issue26973] Dict View binops permit non-set types
In-Reply-To: <1462681499.01.0.123702812837.issue26973@psf.upfronthosting.co.za>
Message-ID: <20160508060030.GT12028@ando.pearwood.info>


Steven D'Aprano added the comment:

On Sun, May 08, 2016 at 04:24:59AM +0000, Joshua Morton wrote:

> Following the comments in python ideas [1] [...]
> 
> [1] https://mail.python.org/pipermail/python-ideas/2016-April/039469.html

Am I missing something? I don't see anything resembling a consensus that 
the behaviour of dict views is a bug in that thread, in fact I hardly 
see any discussion about this specific behaviour. (Other related topics 
are discussed in more depth.)

I don't think it is a bug for views to permit non-set arguments with 
binops:

py> {'a': 1, 'b': 2}.keys() & ['a', 'c']
{'a'}

I think it is a matter of taste. My own taste tells me that sets should 
be more restrictive, only accepting other [frozen]sets or subclasses, 
but views should be less restrictive, and perform more duck-typing of 
"set-like" objects, including lists. No, I can't justify it, except by 
an appeal to status quo: that's how it is now, and I don't think that 
changing it is worth breaking backwards compatibility.

----------
nosy: +steven.daprano

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

From report at bugs.python.org  Sun May  8 02:29:33 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 08 May 2016 06:29:33 +0000
Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not
 available (e.g., AIX)
In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za>
Message-ID: <1462688973.52.0.610199997209.issue26439@psf.upfronthosting.co.za>


Martin Panter added the comment:

Your new patch calls find_library() internally in CDLL(); why? My understanding is CDLL() is a fairly lightweight wrapper around the dlopen() call. On Linux, you either pass a full library file name, or an SO-name. Both these strings can be discovered for compiled objects using e.g.:

$ ldd build/lib.linux-x86_64-2.7-pydebug/_ssl.so
	linux-vdso.so.1 (0x00007fff567fe000)
	libssl.so.1.0.0 => /usr/lib/libssl.so.1.0.0 (0x00007f598474c000)
	libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0x00007f59842d4000)
	. . .

So in Python, the SO-name or full path can be used, but not the compile-time name, unless you first pass it through find_library():

>>> CDLL("libcrypto.so.1.0.0")  # soname
<CDLL 'libcrypto.so.1.0.0', handle 7f1665e1eb90 at 7f16658f34d0>
>>> CDLL("/usr/lib/libcrypto.so.1.0.0")  # Full path
<CDLL '/usr/lib/libcrypto.so.1.0.0', handle 7f1665e1eb90 at 7f1663cddcd0>
>>> CDLL("crypto")  # Compile-time name
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/ctypes/__init__.py", line 365, in __init__
    self._handle = _dlopen(self._name, mode)
OSError: crypto: cannot open shared object file: No such file or directory
>>> find_library("crypto")  # Some people pass the result of this to CDLL()
'libcrypto.so.1.0.0'

----------

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

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: [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 03:08:07 2016
From: report at bugs.python.org (Joshua Morton)
Date: Sun, 08 May 2016 07:08:07 +0000
Subject: [issue26973] Dict View binops permit non-set types
In-Reply-To: <1462681499.01.0.123702812837.issue26973@psf.upfronthosting.co.za>
Message-ID: <1462691287.04.0.375326630748.issue26973@psf.upfronthosting.co.za>


Joshua Morton added the comment:

There (seemed to be) consensus between the one or two on topic commenters that something was off, although much of the discussion was on a tangent. Although on looking back, there was even less discussion than I originally thought. Heh.

My response was going to be very different, however I did some additional digging: the `collections.abc.Set` class can be used as a mixin for implementing set-likes. In its default implementations of the various binops, they will attempt to convert the right hand argument of an operator to the correct type, via _from_iterable. This in effect makes the set the special case that is more permissive than Set is. 

This strikes me as strange, I'd expect set and Set to be 'the same', or in other words a Set to act like a set and vice versa. But it seems that python swings toward your intuition and not mine. And the opposite, making set *more* permissive also doesn't sit well, nor does it feel necessary.

----------

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

From report at bugs.python.org  Sun May  8 03:33:26 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 08 May 2016 07:33:26 +0000
Subject: [issue26975] Decimal.from_float works incorrectly for non-binary
 floats
In-Reply-To: <1462689945.43.0.203317585545.issue26975@psf.upfronthosting.co.za>
Message-ID: <1462692806.89.0.848894967736.issue26975@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

True. Though having a subclass of float that overrides as_integer_ratio seems a fairly unlikely use-case. We could add a check for subclasses of float that the denominator is a power of 2 (using the usual trick: a positive integer n is a power of 2 if and only if `n & (n-1)` is zero) and raise a suitable error otherwise.

I doubt it's worth trying to support arbitrary return values from as_integer_ratio. Note that by overriding as_integer_ratio, you're breaking its "contract": the docs say

> Return a pair of integers, whose ratio is exactly equal to the original
> float and with a positive denominator.

and you've lost that "exactly equal". I think it's reasonably to get wrong results or an exception in that case.

----------

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

From report at bugs.python.org  Sun May  8 04:56:34 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 08 May 2016 08:56:34 +0000
Subject: [issue26870] Unexpected call to readline's add_history in
 call_readline
In-Reply-To: <1461743534.82.0.668302064476.issue26870@psf.upfronthosting.co.za>
Message-ID: <1462697794.42.0.938598337478.issue26870@psf.upfronthosting.co.za>


Martin Panter added the comment:

I left a few minor comments in the code review.

I agree automated testing would be awkward for Readline. It should be possible using a pseudoterminal (pty). In fact there is already very basic testing that does this in /Lib/test/test_builtin.py, class PtyTests. It only tests the input() prompt.

I could have a go at writing a test. I guess pseudocode for a test would look a bit like:

def run_pty(script):
    [master, slave] = pty.openpty()
    with subprocess.Popen(script, stdin=slave, stdout=slave, stderr=slave)
        # Read and write concurrently like proc.communicate()
        master.write(b"dummy input\r")
        return slave.read()

template = """\
import readline
readline.set_auto_history({})
input()
print("History length:", readline.get_current_history_length())
"""

def test_auto_history_enabled(self):
    output = run_session(template.format(True))
    self.assertIn(b"History length: 1\n", output)

def test_auto_history_disabled(self):
    output = run_session(template.format(False))
    self.assertIn(b"History length: 0\n", output)

----------
stage:  -> patch review
versions:  -Python 2.7, Python 3.5

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

From report at bugs.python.org  Sun May  8 05:35:53 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 08 May 2016 09:35:53 +0000
Subject: [issue26282] Add support for partial keyword arguments in extension
 functions
In-Reply-To: <1454535856.96.0.444049158428.issue26282@psf.upfronthosting.co.za>
Message-ID: <1462700153.58.0.140862099828.issue26282@psf.upfronthosting.co.za>


Martin Panter added the comment:

I made some suggestions in the documentation. I only skimmed over the C and arg clinic code, but there is nothing obviously wrong.

----------

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

From report at bugs.python.org  Sun May  8 06:24:56 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 08 May 2016 10:24:56 +0000
Subject: [issue26826] Expose new copy_file_range() syscall in os module.
In-Reply-To: <1461325239.41.0.30054024313.issue26826@psf.upfronthosting.co.za>
Message-ID: <1462703096.17.0.74579253201.issue26826@psf.upfronthosting.co.za>


Martin Panter added the comment:

There?s still something funny about your patches: the last one has a bit of configure script at the end of the posixmodule.c diff.

One other thing I thought of: ?in? is not a practical keyword argument name in Python, because it is a reserved word. Yes, sendfile(**{"in": ...}) is already there, but I think we should find some other name for copy_file_range() before it is too late. Some ideas:

copy_file_range(input, output, count, offset_in, offset_out, flags)  # Spell them out
copy_file_range(fd_in, fd_out, len, off_in, off_out, flags)  # Direct from man page
copy_file_range(src, dst, count, offset_src, offset_dst, flags)  # Like os.replace(), shutil.copyfile(), etc
copy_file_range(fsrc, fdst, count, offset_src, offset_dst, flags)  # Like shutil.copyfileobj()

My favourites are probably ?input?, or ?src?.

----------

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

From report at bugs.python.org  Sun May  8 06:34:40 2016
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 08 May 2016 10:34:40 +0000
Subject: [issue11063] uuid.py module import has heavy side effects
In-Reply-To: <1296321060.32.0.846037411239.issue11063@psf.upfronthosting.co.za>
Message-ID: <1462703680.09.0.440650240781.issue11063@psf.upfronthosting.co.za>


Christian Heimes added the comment:

It sounds like ctypes is causing you some headache. How about we get rid of ctypes for uuid and replace it with a simple implementation in C instead? Autoconf (configure) can take care of the library detection easily.

----------

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

From report at bugs.python.org  Sun May  8 06:37:40 2016
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 08 May 2016 10:37:40 +0000
Subject: [issue26975] Decimal.from_float works incorrectly for non-binary
 floats
In-Reply-To: <1462689945.43.0.203317585545.issue26975@psf.upfronthosting.co.za>
Message-ID: <1462703860.71.0.205297482607.issue26975@psf.upfronthosting.co.za>


Stefan Krah added the comment:

It seems to work correctly here for non-binary floats:

>>> from _pydecimal import Decimal
>>> Decimal.from_float(Decimal("1.2"))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.6/_pydecimal.py", line 739, in from_float
    raise TypeError("argument must be int or float.")
TypeError: argument must be int or float.


I think we should not support strange inheritance hierarchies that
break the expected return values of parent class methods.

----------

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

From report at bugs.python.org  Sun May  8 06:45:19 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 08 May 2016 10:45:19 +0000
Subject: [issue26935] android: test_os fails
In-Reply-To: <1462287800.22.0.0769666286965.issue26935@psf.upfronthosting.co.za>
Message-ID: <1462704319.48.0.0692558971381.issue26935@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Since this seems to be fixed in a version of android that is more recent that API 21, maybe use the value of 'sdk.release' when platform.android_ver() is available after issue #26855 is fixed, with for example, if this is fixed at API 23:

    sdk_release = platform.android_ver()[1]
    if new_fd != fd or not sdk_release or sdk_release >= 23:

----------

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

From report at bugs.python.org  Sun May  8 06:49:02 2016
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 08 May 2016 10:49:02 +0000
Subject: [issue16113] Add SHA-3 and SHAKE (Keccak) support
In-Reply-To: <1349233804.79.0.00772371618682.issue16113@psf.upfronthosting.co.za>
Message-ID: <1462704542.5.0.230908553557.issue16113@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Larry,
I'm with Gregory. There is no good reason to add SHA3 to Python 2.7. The SHA-2 family is still safe. Besides I'd rather add BLAKE2 to Python 2.7. It's much faster and more versatile than SHA3.

Antoine,
SHAKEs are XOF (extensible output function). NIST has standardized the XOFs but not yet approved them as replacement for other constructs. They are useful for signatures or as a simple stream cipher. The SHAKEs were low hanging fruits to implement, so I included them.

----------

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

From report at bugs.python.org  Sun May  8 06:58:37 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 08 May 2016 10:58:37 +0000
Subject: [issue11063] uuid.py module import has heavy side effects
In-Reply-To: <1296321060.32.0.846037411239.issue11063@psf.upfronthosting.co.za>
Message-ID: <1462705117.66.0.588490522428.issue11063@psf.upfronthosting.co.za>


Martin Panter added the comment:

There is already Issue 20519 for that, although it looks like the proposed patch keeps ctypes as a fall-back. (My interest here is only theoretical.)

----------

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

From report at bugs.python.org  Sun May  8 07:05:21 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 08 May 2016 11:05:21 +0000
Subject: [issue26935] android: test_os fails
In-Reply-To: <1462287800.22.0.0769666286965.issue26935@psf.upfronthosting.co.za>
Message-ID: <1462705521.35.0.0189193127848.issue26935@psf.upfronthosting.co.za>


Martin Panter added the comment:

Yes something like that should do the trick

----------
components: +Tests -Cross-Build, Library (Lib)
dependencies: +android: add platform.android_ver()

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

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: [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:16:20 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 08 May 2016 11:16:20 +0000
Subject: [issue26924] android: test_concurrent_futures fails
In-Reply-To: <1462282676.16.0.612748828.issue26924@psf.upfronthosting.co.za>
Message-ID: <1462706180.77.0.870715089915.issue26924@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Undefining the SEM_* macros in multiprocessing.h when __ANDROID__ is set, would allow for an easier update when those functions become implemented at a future API level. The __ANDROID_API__ macro can be used for that purpose. For example, if this happens at API 24, this could be a changed to:

#if defined(__ANDROID__)
# include <android/api-level.h>
# if __ANDROID_API__ < 24
#  undef sem_open
#  ...
# endif
#endif

----------

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

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


Changes by Davide Rizzo <sorcio at gmail.com>:


----------
type:  -> enhancement

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

From report at bugs.python.org  Sun May  8 07:19:09 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 08 May 2016 11:19:09 +0000
Subject: [issue26924] android: test_concurrent_futures fails
In-Reply-To: <1462282676.16.0.612748828.issue26924@psf.upfronthosting.co.za>
Message-ID: <1462706349.25.0.818995020152.issue26924@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

> #  undef sem_open

I meant of course:

#  undef HAVE_SEM_OPEN

----------

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

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: [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 07:59:32 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 May 2016 11:59:32 +0000
Subject: [issue26512] Vocabulary: Using "integral" in library/stdtypes.html
In-Reply-To: <1457472244.72.0.113699245831.issue26512@psf.upfronthosting.co.za>
Message-ID: <20160508115928.5176.5708.FF7D1360@psf.io>


Roundup Robot added the comment:

New changeset 9e29034a41fa by Martin Panter in branch '3.5':
Issue #26512: Clarify Integral; tidy up table of rounding functions
https://hg.python.org/cpython/rev/9e29034a41fa

New changeset a8883951b2ff by Martin Panter in branch 'default':
Issue #26512: Merge rounding doc from 3.5
https://hg.python.org/cpython/rev/a8883951b2ff

New changeset a69805edfadd by Martin Panter in branch '2.7':
Issue #26512: Clarify Integral; tidy up table of rounding functions
https://hg.python.org/cpython/rev/a69805edfadd

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

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

From report at bugs.python.org  Sun May  8 08:14:57 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 May 2016 12:14:57 +0000
Subject: [issue26977] Unnecessary line in statistics.pvariance
In-Reply-To: <1462708569.69.0.176390210867.issue26977@psf.upfronthosting.co.za>
Message-ID: <20160508121454.22561.30568.F58D2929@psf.io>


Roundup Robot added the comment:

New changeset 2bf4a02f3570 by Steven D'Aprano in branch 'default':
Issue 26977, remove unneeded line in pvariance (duplicate call to _ss).
https://hg.python.org/cpython/rev/2bf4a02f3570

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

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

From report at bugs.python.org  Sun May  8 08:16:50 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 08 May 2016 12:16:50 +0000
Subject: [issue26977] Unnecessary line in statistics.pvariance
In-Reply-To: <1462708569.69.0.176390210867.issue26977@psf.upfronthosting.co.za>
Message-ID: <1462709810.13.0.0810520211903.issue26977@psf.upfronthosting.co.za>


Steven D'Aprano added the comment:

Thanks Ian! I can't believe I looked at that function earlier today and couldn't see that!

----------
nosy: +steven.daprano
stage:  -> resolved
status: open -> closed

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

From report at bugs.python.org  Sun May  8 08:29:11 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 08 May 2016 12:29:11 +0000
Subject: [issue26977] Unnecessary line in statistics.pvariance
In-Reply-To: <1462708569.69.0.176390210867.issue26977@psf.upfronthosting.co.za>
Message-ID: <1462710551.54.0.0423023512139.issue26977@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
resolution:  -> fixed

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

From report at bugs.python.org  Sun May  8 08:37:54 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 May 2016 12:37:54 +0000
Subject: [issue26976] pathlib equivalent for os.path.realpath()
In-Reply-To: <1462706148.1.0.443359172953.issue26976@psf.upfronthosting.co.za>
Message-ID: <1462711074.8.0.671421847771.issue26976@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is a duplicate of issue19717.

----------
nosy: +serhiy.storchaka
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> resolve() fails when the path doesn't exist

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

From report at bugs.python.org  Sun May  8 08:46:34 2016
From: report at bugs.python.org (Akira Li)
Date: Sun, 08 May 2016 12:46:34 +0000
Subject: [issue22274] subprocess.Popen(stderr=STDOUT) fails to redirect
 subprocess stderr to stdout
In-Reply-To: <1409003162.0.0.312391949761.issue22274@psf.upfronthosting.co.za>
Message-ID: <1462711594.67.0.203993917312.issue22274@psf.upfronthosting.co.za>


Akira Li added the comment:

Updated the patch to address vadmium's review comments.

----------
versions:  -Python 3.4
Added file: http://bugs.python.org/file42777/subprocess-stderr_redirect_with_no_stdout_redirect-2.diff

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

From report at bugs.python.org  Sun May  8 09:10:49 2016
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 08 May 2016 13:10:49 +0000
Subject: [issue26798] add BLAKE2 to hashlib
In-Reply-To: <1461004812.44.0.872226457841.issue26798@psf.upfronthosting.co.za>
Message-ID: <1462713049.78.0.516263810244.issue26798@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Here is my first patch. I have tested it on X86_64 (m64 and m32) and ARMv7. It should compile on Windows but I don't have a working Windows box on my box. 

Dmitry, I have copied your documentation. Are you fine with that?

TODO:

- set BLAKE2_USE_SSE on win32 X86_64
- more test vectorss for advanced use cases (salt, personal, tree hashing)

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file42778/BLAKE2-hash-algorithm-for-CPython.patch

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

From report at bugs.python.org  Sun May  8 09:25:20 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 May 2016 13:25:20 +0000
Subject: [issue26975] Decimal.from_float works incorrectly for non-binary
 floats
In-Reply-To: <1462689945.43.0.203317585545.issue26975@psf.upfronthosting.co.za>
Message-ID: <1462713920.63.0.352938009266.issue26975@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Once I was going to propose to make as_integer_ratio() returning a pair (n, d) with minimal positive d that n/d (as float) is exactly equal to the original float. I think this is legitimate implementation and doesn't contradict the documentation.

I see following ways to resolve this issue:

1. Ignore it.

2. Ignore methods overriding:
2a) either convert float subclass to exact float with known behavior;
2b) or directly call static float.__abs__() and float.as_integer_ratio() instead of resolving dynamic methods.

3. Check that the denominator is a power of 2 and raise error otherwise.

4. Implement different different algorithm. Returns decimal n / 10**k with minimal k that after converting to float is exactly equal to the original float.

Most of these solutions will automatically fix issue26974, so it doesn't need special fix.

----------

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

From report at bugs.python.org  Sun May  8 09:27:17 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 08 May 2016 13:27:17 +0000
Subject: [issue22274] subprocess.Popen(stderr=STDOUT) fails to redirect
 subprocess stderr to stdout
In-Reply-To: <1409003162.0.0.312391949761.issue22274@psf.upfronthosting.co.za>
Message-ID: <1462714037.96.0.344238624013.issue22274@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think this patch is pretty good. I will try to commit it in the next few days.

----------
nosy: +martin.panter
versions: +Python 2.7, Python 3.5, Python 3.6

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

From report at bugs.python.org  Sun May  8 09:39:06 2016
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 08 May 2016 13:39:06 +0000
Subject: [issue26975] Decimal.from_float works incorrectly for non-binary
 floats
In-Reply-To: <1462689945.43.0.203317585545.issue26975@psf.upfronthosting.co.za>
Message-ID: <1462714746.77.0.0972625488253.issue26975@psf.upfronthosting.co.za>


Stefan Krah added the comment:

As Mark hinted at, many people would say there is no issue at all.
Subclassing like that often breaks the Liskov Substitution Principle.

For more information, see e.g.:

  http://okmij.org/ftp/Computation/Subtyping/


"Alas, LSP when considered from an OOP point of view is undecidable. You cannot count on a compiler for help in pointing out an error. You cannot rely on regression tests either. It's manual work -- you have to see the problem"

----------

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

From report at bugs.python.org  Sun May  8 10:02:25 2016
From: report at bugs.python.org (Dmitry Chestnykh)
Date: Sun, 08 May 2016 14:02:25 +0000
Subject: [issue26798] add BLAKE2 to hashlib
In-Reply-To: <1461004812.44.0.872226457841.issue26798@psf.upfronthosting.co.za>
Message-ID: <1462716144.98.0.409119664298.issue26798@psf.upfronthosting.co.za>


Dmitry Chestnykh added the comment:

Christian: yes, and I'm also happy that you kept the drawing of hash tree, as it helps a lot with understanding of terminology.

I had a quick look at the patch and it looks good to me.

Some comments, which you can ignore:

In keyed hashing example there's:

+    >>> def verify(cookie, sig):
+    ...     good_sig = sign(cookie)
+    ...     if len(sig) != len(good_sig):
+    ...          return False
+    ...     # Use constant-time comparison to avoid timing attacks.
+    ...     result = 0
+    ...     for x, y in zip(sig, good_sig):
+    ...         result |= ord(x) ^ ord(y)
+    ...     return result == 0

Perhaps, you can replace comparison with hmac.compare_digest(sig, goodsig) now that we have it in Python.

+    *Salted hashing* (or just hashing) with BLAKE2 or any other general-purpose
+    cryptographic hash function, such as SHA-256, is not suitable for hashing
+    passwords.  See `BLAKE2 FAQ <https://blake2.net/#qa>`_ for more
+    information.

Maybe also point readers to hashlib.html#key-derivation


+On platforms with support for 64bit integer types (some 32bit platforms,
+all 64bit platforms), blake2b and blake2s are supported.

Theoretically, blake2s shouldn't require 64bit int, reference code only uses it for sizes -- is this something worth fixing? Are there platforms that have uint32_t, but not uint64_t?


@@ -162,7 +192,7 @@ class HashLibTestCase(unittest.TestCase):
         for cons in self.hash_constructors:
             h = cons()
             self.assertIsInstance(h.name, str)
-            self.assertIn(h.name, self.supported_hash_names)
+            #self.assertIn(h.name, self.supported_hash_names)
             self.assertEqual(h.name, hashlib.new(h.name).name)


Was this commented-out on purpose? Also, in setup.py:

+            #if os.uname().machine == "x86_64":
+                # Every x86_64 machine has at least SSE2.
+                #blake2_macros.append(('BLAKE2_USE_SSE', '1'))

----------
nosy: +dchest

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

From report at bugs.python.org  Sun May  8 10:32:12 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 08 May 2016 14:32:12 +0000
Subject: [issue26975] Decimal.from_float works incorrectly for non-binary
 floats
In-Reply-To: <1462689945.43.0.203317585545.issue26975@psf.upfronthosting.co.za>
Message-ID: <1462717932.61.0.37693437452.issue26975@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> I see following ways to resolve this issue:

I don't think 4. is an option: for input of exact type float, from_float should continue to produce the exact value of the float, rather than an approximation to that exact value. There's code out there that depends on this behaviour. Options 1 through 3 all seem reasonable to me.

----------

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

From report at bugs.python.org  Sun May  8 10:58:35 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 May 2016 14:58:35 +0000
Subject: [issue26282] Add support for partial keyword arguments in extension
 functions
In-Reply-To: <1454535856.96.0.444049158428.issue26282@psf.upfronthosting.co.za>
Message-ID: <1462719515.44.0.291333648238.issue26282@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

On new patch applied Martin's suggestions, added entities in What's New and NEWS, added a reference to the glossary, and improved error message.

----------
Added file: http://bugs.python.org/file42779/pyarg_parse_positional_only_and_keywords_3.patch

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

From report at bugs.python.org  Sun May  8 11:06:14 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Sun, 08 May 2016 15:06:14 +0000
Subject: [issue26935] android: test_os fails
In-Reply-To: <1462287800.22.0.0769666286965.issue26935@psf.upfronthosting.co.za>
Message-ID: <1462719974.79.0.228437496583.issue26935@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

My implementation at #26855 returns a tuple of strings like other funcitons, including java_ver() and mac_ver(). Maybe it requires a change.

----------
nosy: +Chi Hsuan Yen

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

From report at bugs.python.org  Sun May  8 11:11:36 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Sun, 08 May 2016 15:11:36 +0000
Subject: [issue26855] android: add platform.android_ver()
In-Reply-To: <1461676711.89.0.563475479331.issue26855@psf.upfronthosting.co.za>
Message-ID: <1462720296.92.0.741861589625.issue26855@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

Android framework provides an SDK_INT field [1], which parses the value of `ro.build.version.sdk` and defaults to 0 if failed [2]. Should android_ver() return an integer for the `sdk` field, too? It simplifies the usage in #26935 and similar ones.

[1] https://android.googlesource.com/platform/frameworks/base/+/e8579b12a3c5be5fef25fc5a1c8c2c9d43e49347/core/java/android/os/Build.java#183
[2] https://android.googlesource.com/platform/frameworks/base/+/e8579b12a3c5be5fef25fc5a1c8c2c9d43e49347/core/jni/android_os_SystemProperties.cpp#66

----------

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

From report at bugs.python.org  Sun May  8 11:16:30 2016
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Sun, 08 May 2016 15:16:30 +0000
Subject: [issue23228] The tarfile module crashes when tarfile contains a
 symlink and unpack directory contain it too
In-Reply-To: <1421139302.16.0.710158118765.issue23228@psf.upfronthosting.co.za>
Message-ID: <1462720590.74.0.945080665162.issue23228@psf.upfronthosting.co.za>


Lars Gust?bel added the comment:

TarFile.makelink() has a fallback mode in case the platform does not support links. Instead of a symlink or a hardlink it extracts the file it points to as long as it exists in the current archive.

More precisely, makelink() calls os.symlink() and if one of the exceptions in the symlink_exception tuple is raised, it goes into fallback mode. r80944 introduced a regression because it replaced the WindowsError in symlink_exception with an OSError which is much less specific than a WindowsError. Since that change, the fallback is used everytime an OSError occurs, in Michael's case it is a FileExistsError, because the symlink is already there.

The attached patch restores the old behavior. This might not be what you wanted, Michael, but at least, tarfile no longer crashes.

----------
Added file: http://bugs.python.org/file42780/windowserror.diff

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

From report at bugs.python.org  Sun May  8 11:27:16 2016
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Sun, 08 May 2016 15:27:16 +0000
Subject: [issue23228] The tarfile module crashes when tarfile contains a
 symlink and unpack directory contain it too
In-Reply-To: <1421139302.16.0.710158118765.issue23228@psf.upfronthosting.co.za>
Message-ID: <1462721236.69.0.0105679053092.issue23228@psf.upfronthosting.co.za>


Lars Gust?bel added the comment:

I suck :-) It is hg revision bb94f6222fef.

----------

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

From report at bugs.python.org  Sun May  8 11:46:46 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 May 2016 15:46:46 +0000
Subject: [issue26974] Crash in Decimal.from_float
In-Reply-To: <1462684427.76.0.86950702335.issue26974@psf.upfronthosting.co.za>
Message-ID: <1462722406.01.0.980363729312.issue26974@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here are two alternative patches that fix the crash.

The first patch adds checks for as_integer_ratio() result. The only disadvantage is that error messages are quite arbitrary and differ from error messages in Python version.

----------
keywords: +patch
Added file: http://bugs.python.org/file42781/decimal_from_float_check_result.patch

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

From report at bugs.python.org  Sun May  8 11:50:02 2016
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 08 May 2016 15:50:02 +0000
Subject: [issue23640] int.from_bytes() is broken for subclasses
In-Reply-To: <1426080876.51.0.657090719237.issue23640@psf.upfronthosting.co.za>
Message-ID: <1426094762.6.0.607507382027.issue23640@psf.upfronthosting.co.za>


Ethan Furman added the comment:

I think the classmethod-as-constructor behavior is correct, so it's up to IntEnum (or EnumMeta, or foo, or ...), to work around the issue.

----------

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

From report at bugs.python.org  Sun May  8 11:50:12 2016
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 08 May 2016 15:50:12 +0000
Subject: [issue23640] int.from_bytes() is broken for subclasses
In-Reply-To: <1426080876.51.0.657090719237.issue23640@psf.upfronthosting.co.za>
Message-ID: <1427731321.63.0.606134497138.issue23640@psf.upfronthosting.co.za>


Ethan Furman added the comment:

'from_bytes' is a classmethod.  As such, it should return the same type as the class it is called on.  If that wasn't the intent it would be a staticmethod instead.

It is the responsibility of the subclass to override base class behavior, not the other way around.

----------

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

From report at bugs.python.org  Sun May  8 11:50:22 2016
From: report at bugs.python.org (Ethan Furman)
Date: Sun, 08 May 2016 15:50:22 +0000
Subject: [issue23640] int.from_bytes() is broken for subclasses
In-Reply-To: <1426080876.51.0.657090719237.issue23640@psf.upfronthosting.co.za>
Message-ID: <1428138490.56.0.797061084185.issue23640@psf.upfronthosting.co.za>


Ethan Furman added the comment:

With the patch:

  --> import enum
  --> class Huh(enum.IntEnum):
  ...   blah = 2
  ...
  --> Huh.blah.from_bytes(b'\04', 'big')
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    File "/home/ethan/source/python/issue23640/Lib/enum.py", line 222, in __call__
      return cls.__new__(cls, value)
    File "/home/ethan/source/python/issue23640/Lib/enum.py", line 457, in __new__
      raise ValueError("%r is not a valid %s" % (value, cls.__name__))
  ValueError: 4 is not a valid Huh

This is not the correct behavior.  An IntEnum should act like an int, and in cases where it can't and still be an IntEnum, it becomes an int.  But this behavior is Enum specific, and I would not expect other int subclasses to need or want that behavior.

Also, in cases where class methods are alternate constructors there is no requirement that they go through the main __new__/__init__ constructors to do their job.

In other words, if IntEnum.from_bytes (which is inherited) is not behaving correctly, it is up to IntEnum to fix it -- it is not the job of int, and this is not a bug in int.

----------

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

From report at bugs.python.org  Sun May  8 11:52:14 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 May 2016 15:52:14 +0000
Subject: [issue26974] Crash in Decimal.from_float
In-Reply-To: <1462684427.76.0.86950702335.issue26974@psf.upfronthosting.co.za>
Message-ID: <1462722734.98.0.0983414928421.issue26974@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The second patch converts an instance of float subclass to exact float. Disadvantages are that this changes behavior ignoring overriding as_integer_ratio() and __abs__() and slightly slows down Python implementation. Advantages are that this fixes also issue26975 and slightly speeds up C implementation.

----------
stage:  -> patch review
Added file: http://bugs.python.org/file42782/decimal_from_float_exact_float.patch

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

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: [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 12:41:20 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 08 May 2016 16:41:20 +0000
Subject: [issue26978] Implement pathlib.Path.link (Using os.link)
Message-ID: <1462725680.13.0.850280189796.issue26978@psf.upfronthosting.co.za>


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


----------
nosy: +pitrou
type:  -> enhancement

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

From report at bugs.python.org  Sun May  8 12:41:59 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 08 May 2016 16:41:59 +0000
Subject: [issue26976] pathlib equivalent for os.path.realpath()
In-Reply-To: <1462706148.1.0.443359172953.issue26976@psf.upfronthosting.co.za>
Message-ID: <1462725719.6.0.340131214115.issue26976@psf.upfronthosting.co.za>


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


----------
nosy: +pitrou

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

From report at bugs.python.org  Sun May  8 13:47:18 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 May 2016 17:47:18 +0000
Subject: [issue23815] Segmentation fault when create _tkinter objects
In-Reply-To: <1427745415.01.0.962782500028.issue23815@psf.upfronthosting.co.za>
Message-ID: <20160508174716.22581.30455.A9967169@psf.io>


Roundup Robot added the comment:

New changeset cd25508c62fc by Serhiy Storchaka in branch '3.5':
Issue #23815: Fixed crashes related to directly created instances of types in
https://hg.python.org/cpython/rev/cd25508c62fc

New changeset 1c6326e81c33 by Serhiy Storchaka in branch 'default':
Issue #23815: Fixed crashes related to directly created instances of types in
https://hg.python.org/cpython/rev/1c6326e81c33

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23815>
_______________________________________

From report at bugs.python.org  Sun May  8 14:04:23 2016
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 08 May 2016 18:04:23 +0000
Subject: [issue26798] add BLAKE2 to hashlib
In-Reply-To: <1461004812.44.0.872226457841.issue26798@psf.upfronthosting.co.za>
Message-ID: <1462730663.22.0.54609877693.issue26798@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Thanks for your review, Dmitry.

I have replaced verify() with compare_digest().

Python requires a C89 compatible compiler and 32bit architecture. C89 doesn't mandate 64bit integers. As far as I remember there is (or was) one buildbot with a compiler, that doesn't have 64 ints on an old SPARC system. All major platforms have 64bit ints. I might modify the implementation when the patch has landed.

#self.assertIn(h.name, self.supported_hash_names)
I now check for guaranteed and eventually supported hashes.

SSE is enabled on X64_86. I forgot to remove the comments.


The test suite is missing tests for salt, personal and tree hashing. I have asked Zooko and JPA for vectors.

----------
Added file: http://bugs.python.org/file42783/BLAKE2-hash-algorithm-for-CPython-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26798>
_______________________________________

From report at bugs.python.org  Sun May  8 14:13:10 2016
From: report at bugs.python.org (Davide Rizzo)
Date: Sun, 08 May 2016 18:13:10 +0000
Subject: [issue19717] resolve() fails when the path doesn't exist
In-Reply-To: <1385142353.37.0.842056066182.issue19717@psf.upfronthosting.co.za>
Message-ID: <1462731190.34.0.0310054718706.issue19717@psf.upfronthosting.co.za>


Changes by Davide Rizzo <sorcio at gmail.com>:


----------
nosy: +davide.rizzo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19717>
_______________________________________

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: [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 14:29:33 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 May 2016 18:29:33 +0000
Subject: [issue23815] Segmentation fault when create _tkinter objects
In-Reply-To: <1427745415.01.0.962782500028.issue23815@psf.upfronthosting.co.za>
Message-ID: <1462732173.3.0.0698658230699.issue23815@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

After looking closer I found that making PyType_FromSpec() not inheriting tp_new for static types whose base class is 'object' is not an option, because this breaks examples in the documentation, and likely break some third-party code. Opened new issue26979 for documenting the catch.

Thank you for your review Terry.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23815>
_______________________________________

From report at bugs.python.org  Sun May  8 14:31:21 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 May 2016 18:31:21 +0000
Subject: [issue15721] PEP 3121, 384 Refactoring applied to tkinter module
In-Reply-To: <1345287224.98.0.204885883161.issue15721@psf.upfronthosting.co.za>
Message-ID: <1462732281.23.0.103375000557.issue15721@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Fixed in issue23815. Opened issue26979 for documenting the catch.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15721>
_______________________________________

From report at bugs.python.org  Sun May  8 14:35:43 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 May 2016 18:35:43 +0000
Subject: [issue14936] PEP 3121, 384 refactoring applied to curses_panel module
In-Reply-To: <1338223470.25.0.655210931272.issue14936@psf.upfronthosting.co.za>
Message-ID: <1462732543.56.0.789271593953.issue14936@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This patch made the "_curses_panel.curses panel" type callable. Created objects were in inconsistent state and using them caused a crash.

This bug is fixed in issue23815. Opened issue26979 for documenting the catch.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14936>
_______________________________________

From report at bugs.python.org  Sun May  8 14:35:54 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 May 2016 18:35:54 +0000
Subject: [issue14936] PEP 3121, 384 refactoring applied to curses_panel module
In-Reply-To: <1338223470.25.0.655210931272.issue14936@psf.upfronthosting.co.za>
Message-ID: <1462732554.42.0.103924954902.issue14936@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
stage:  -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14936>
_______________________________________

From report at bugs.python.org  Sun May  8 14:50:47 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 May 2016 18:50:47 +0000
Subject: [issue26156] Bad name into power operator syntax
In-Reply-To: <1453214486.32.0.13836493656.issue26156@psf.upfronthosting.co.za>
Message-ID: <1462733447.36.0.100146659124.issue26156@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think "await_expr" is good. It is not new that the keyword is a part of the grammar symbol name (yield_expression, comp_for, and_expr, or_test, lambda_expr).

----------
assignee: docs at python -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26156>
_______________________________________

From report at bugs.python.org  Sun May  8 14:51:15 2016
From: report at bugs.python.org (Camilla Montonen)
Date: Sun, 08 May 2016 18:51:15 +0000
Subject: [issue26732] multiprocessing sentinel resource leak
In-Reply-To: <1460325501.58.0.225914662536.issue26732@psf.upfronthosting.co.za>
Message-ID: <1462733475.54.0.779986156747.issue26732@psf.upfronthosting.co.za>


Changes by Camilla Montonen <camillamon at gmail.com>:


----------
nosy: +Winterflower

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26732>
_______________________________________

From report at bugs.python.org  Sun May  8 15:00:33 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 May 2016 19:00:33 +0000
Subject: [issue26156] Bad name into power operator syntax
In-Reply-To: <1453214486.32.0.13836493656.issue26156@psf.upfronthosting.co.za>
Message-ID: <20160508190025.42555.10022.6A197E19@psf.io>


Roundup Robot added the comment:

New changeset e876ff4e9e95 by Serhiy Storchaka in branch '3.5':
Issue #26156: Make expressions grammar description more semantically correct.
https://hg.python.org/cpython/rev/e876ff4e9e95

New changeset 61e3160310ae by Serhiy Storchaka in branch 'default':
Issue #26156: Make expressions grammar description more semantically correct.
https://hg.python.org/cpython/rev/61e3160310ae

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26156>
_______________________________________

From report at bugs.python.org  Sun May  8 15:01:01 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 May 2016 19:01:01 +0000
Subject: [issue26156] Bad name into power operator syntax
In-Reply-To: <1453214486.32.0.13836493656.issue26156@psf.upfronthosting.co.za>
Message-ID: <1462734061.0.0.720502653032.issue26156@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26156>
_______________________________________

From report at bugs.python.org  Sun May  8 15:06:04 2016
From: report at bugs.python.org (R. David Murray)
Date: Sun, 08 May 2016 19:06:04 +0000
Subject: [issue26973] Dict View binops permit non-set types
In-Reply-To: <1462681499.01.0.123702812837.issue26973@psf.upfronthosting.co.za>
Message-ID: <1462734364.68.0.582140955918.issue26973@psf.upfronthosting.co.za>


R. David Murray added the comment:

In any case I think the backward compatibility argument torpedoes making the views more restrictive.

Since you agree there's no real consensus on python-ideas, I'm going to close this.  If there is some other consistency change that seems to make sense and gains consensus on python-ideas, you can open another issue.

----------
nosy: +r.david.murray
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26973>
_______________________________________

From report at bugs.python.org  Sun May  8 15:08:32 2016
From: report at bugs.python.org (Dmitry Chestnykh)
Date: Sun, 08 May 2016 19:08:32 +0000
Subject: [issue26798] add BLAKE2 to hashlib
In-Reply-To: <1461004812.44.0.872226457841.issue26798@psf.upfronthosting.co.za>
Message-ID: <1462734512.21.0.432751314264.issue26798@psf.upfronthosting.co.za>


Dmitry Chestnykh added the comment:

> I have replaced verify() with compare_digest().

+    >>> compare_digesty(cookie, '0102030405060708090a0b0c0d0e0f00')

Typo here. Also, this doesn't look like it compares the digest. Maybe you can keep the verify() function, but make it use compare_digest() -- this looks more clear to me:

>>> def verify(cookie, sig):
...     good_sig = sign(cookie)
...     return compare_digest(goodsig, sig)


> Python requires a C89 compatible compiler and 32bit architecture. C89 doesn't mandate 64bit integers. As far as I remember there is (or was) one buildbot with a compiler, that doesn't have 64 ints on an old SPARC system. All major platforms have 64bit ints. I might modify the implementation when the patch has landed.

Oh, I see. Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26798>
_______________________________________

From report at bugs.python.org  Sun May  8 15:44:43 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 May 2016 19:44:43 +0000
Subject: [issue18531] Undocumented different between METH_KEYWORDS and **kws
In-Reply-To: <1374519103.74.0.277776306074.issue18531@psf.upfronthosting.co.za>
Message-ID: <1462736683.58.0.818607854714.issue18531@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

str.format() uses PyDict_GetItem() in 2.7, but PyObject_GetItem() in 3.x. A comment before:

        /* Use PyObject_GetItem instead of PyDict_GetItem because this
           code is no longer just used with kwargs. It might be passed
           a non-dict when called through format_map. */

Thus the behavior of str.format() was changed by accident.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18531>
_______________________________________

From report at bugs.python.org  Sun May  8 15:47:36 2016
From: report at bugs.python.org (paul j3)
Date: Sun, 08 May 2016 19:47:36 +0000
Subject: [issue26967] argparse: allow_abbrev=False stops -vv from working
In-Reply-To: <1462475086.65.0.670765920247.issue26967@psf.upfronthosting.co.za>
Message-ID: <1462736856.3.0.0643179146344.issue26967@psf.upfronthosting.co.za>


paul j3 added the comment:

It's been 2 years since I worked on this patch.  In the issue discussion http://bugs.python.org/issue14910 there was no mention of short v long options.  The unit tests only look at longs.

The result is that with the abbrev off, it disables all use of combined shorts, not just the count.  Not only if '-vv' disabled, so is '-vz', '-vz1', '-v -z1'.

We should have discussed that issue.

I can imagine modifying the 

    if self.allow_abbrev:

to something like

    if self.allow_abbrev or <argstring has only one dash>:
        <search for abbreviations>

But even if we don't go that far, we should add a documentation note.

----------
nosy: +paul.j3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26967>
_______________________________________

From report at bugs.python.org  Sun May  8 15:47:53 2016
From: report at bugs.python.org (paul j3)
Date: Sun, 08 May 2016 19:47:53 +0000
Subject: [issue26967] argparse: allow_abbrev=False stops -vv from working
In-Reply-To: <1462475086.65.0.670765920247.issue26967@psf.upfronthosting.co.za>
Message-ID: <1462736873.29.0.315435029769.issue26967@psf.upfronthosting.co.za>


Changes by paul j3 <ajipanca at gmail.com>:


----------
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26967>
_______________________________________

From report at bugs.python.org  Sun May  8 16:08:29 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 08 May 2016 20:08:29 +0000
Subject: [issue23721] Set up a daily test coverage run
In-Reply-To: <1426858130.98.0.810512379451.issue23721@psf.upfronthosting.co.za>
Message-ID: <1462738109.15.0.061905588765.issue23721@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Devinabox now lives at https://github.com/python/devinabox

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23721>
_______________________________________

From report at bugs.python.org  Sun May  8 16:11:22 2016
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 08 May 2016 20:11:22 +0000
Subject: [issue21012] Figure out how to best leverage pip in devinabox
In-Reply-To: <1395421162.45.0.220152918386.issue21012@psf.upfronthosting.co.za>
Message-ID: <1462738282.29.0.810786594793.issue21012@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Devinabox has moved to its own project at https://github.com/python/devinabox/issues/3

----------
resolution:  -> third party
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21012>
_______________________________________

From report at bugs.python.org  Sun May  8 16:22:45 2016
From: report at bugs.python.org (paul j3)
Date: Sun, 08 May 2016 20:22:45 +0000
Subject: [issue26952] argparse help formatter crashes
In-Reply-To: <1462374887.67.0.462060112057.issue26952@psf.upfronthosting.co.za>
Message-ID: <1462738965.89.0.59190949772.issue26952@psf.upfronthosting.co.za>


paul j3 added the comment:

Argument Groups are not designed for nesting, and despite their names and subclassing, Mutually exclusive groups and Argument Groups are not meant to be used together (with one exception).

I agree that the error is obscure, but it occurs in a particularly fragile function in the formatter, '_format_actions_usage'.  That function needs a major rewrite (that's in another bug/issue).

Argument Groups serve only as a way of grouping help lines.  Mutually exclusive groups test arguments during parsing, and add some markings to the usage line.  So they have very different purposes.

I have seen questions on Stackoverflow where people try to use Argument Groups as a way of adding some sort of subgroup to the Mutually Exclusive one, one for example that implements a 'allow any of this group' logic.  There is a bug/issue asking for 'inclusive' nesting groups, but production patch of that sort is long ways off.  http://bugs.python.org/issue11588

This usage line

    (--url URL --project Prj [--dump]) | (--mergeInput input.txt [--removeDisabled])

suggests that this what you are trying do - allow any of -u,-p,-d, but disallow one of these with -m or -r.  That logic is beyond the current group testing mechanism, and beyond the usage formatting code.  You'll have to do your own tests, and write a custom usage line.

Mutually exclusive groups can be nested in other mutual groups, but the effect isn't what you might hope.  It just forms a larger mutually exclusive group; there's no subgrouping.

It is possible to nest a mutually exclusive group in an Argument group; the effect is to give the mutually exclusive group a title.

----------
nosy: +paul.j3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26952>
_______________________________________

From report at bugs.python.org  Sun May  8 16:27:21 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 08 May 2016 20:27:21 +0000
Subject: [issue26632] __all__ decorator
In-Reply-To: <1458786797.31.0.0749407715279.issue26632@psf.upfronthosting.co.za>
Message-ID: <1462739241.92.0.117974079947.issue26632@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

One more diff.  As I was working on tests, I realized that the decorator version wasn't returning the thing it was decorating.  Changing this also allowed me to simplify the exit path.

I should be putting up a PyPI package soon which implements this for earlier Pythons (Python 3 only for now though).

----------
Added file: http://bugs.python.org/file42784/26632-in-c-4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26632>
_______________________________________

From report at bugs.python.org  Sun May  8 16:37:07 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 May 2016 20:37:07 +0000
Subject: [issue18531] Undocumented different between METH_KEYWORDS and **kws
In-Reply-To: <1374519103.74.0.277776306074.issue18531@psf.upfronthosting.co.za>
Message-ID: <20160508203704.22565.70437.B34AF344@psf.io>


Roundup Robot added the comment:

New changeset e4835b1ed7b1 by Serhiy Storchaka in branch 'default':
Issue #18531: Single var-keyword argument of dict subtype was passed
https://hg.python.org/cpython/rev/e4835b1ed7b1

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18531>
_______________________________________

From report at bugs.python.org  Sun May  8 16:55:03 2016
From: report at bugs.python.org (paul j3)
Date: Sun, 08 May 2016 20:55:03 +0000
Subject: [issue26967] argparse: allow_abbrev=False stops -vv from working
In-Reply-To: <1462475086.65.0.670765920247.issue26967@psf.upfronthosting.co.za>
Message-ID: <1462740903.92.0.892687793763.issue26967@psf.upfronthosting.co.za>


paul j3 added the comment:

Someone needs to take the current argparse.py, set the default value of this parameter to False, and run the unittest file.  This should turn up this case, and possibly others that fail when abbreviations are turned off.  Then we have to debate whether such failures are acceptable or not.

When we say 'disable abbreviations' do we mean, all abbreviations, or just a subset?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26967>
_______________________________________

From report at bugs.python.org  Sun May  8 17:02:33 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 May 2016 21:02:33 +0000
Subject: [issue26881] modulefinder should reuse the dis module
In-Reply-To: <1461912649.38.0.754834410981.issue26881@psf.upfronthosting.co.za>
Message-ID: <20160508210230.31183.91690.75CE3E75@psf.io>


Roundup Robot added the comment:

New changeset 3579cdaf56d9 by Serhiy Storchaka in branch '3.5':
Issue #26881: The modulefinder module now supports extended opcode arguments.
https://hg.python.org/cpython/rev/3579cdaf56d9

New changeset c27e3773d0f9 by Serhiy Storchaka in branch 'default':
Issue #26881: The modulefinder module now supports extended opcode arguments.
https://hg.python.org/cpython/rev/c27e3773d0f9

New changeset f06baed1bb0c by Serhiy Storchaka in branch '2.7':
Issue #26881: modulefinder now works with bytecode with extended args.
https://hg.python.org/cpython/rev/f06baed1bb0c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26881>
_______________________________________

From report at bugs.python.org  Sun May  8 17:03:49 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 May 2016 21:03:49 +0000
Subject: [issue26881] modulefinder should reuse the dis module
In-Reply-To: <1461912649.38.0.754834410981.issue26881@psf.upfronthosting.co.za>
Message-ID: <1462741429.21.0.644794358127.issue26881@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26881>
_______________________________________

From report at bugs.python.org  Sun May  8 17:06:13 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 May 2016 21:06:13 +0000
Subject: [issue26736] Use HTTPS protocol in links
In-Reply-To: <1460399300.6.0.985736947814.issue26736@psf.upfronthosting.co.za>
Message-ID: <1462741573.91.0.257383406159.issue26736@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26736>
_______________________________________

From report at bugs.python.org  Sun May  8 17:14:49 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 08 May 2016 21:14:49 +0000
Subject: [issue25745] Reference leaks in test_curses
In-Reply-To: <1448647482.06.0.750956111756.issue25745@psf.upfronthosting.co.za>
Message-ID: <20160508211446.67125.3598.E4E50051@psf.io>


Roundup Robot added the comment:

New changeset afed12943ddd by Serhiy Storchaka in branch '3.5':
Issue #25745: Fixed leaking a userptr in curses panel destructor.
https://hg.python.org/cpython/rev/afed12943ddd

New changeset 1662b41e1663 by Serhiy Storchaka in branch '2.7':
Issue #25745: Fixed leaking a userptr in curses panel destructor.
https://hg.python.org/cpython/rev/1662b41e1663

New changeset 50a94e1cabe0 by Serhiy Storchaka in branch 'default':
Issue #25745: Fixed leaking a userptr in curses panel destructor.
https://hg.python.org/cpython/rev/50a94e1cabe0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25745>
_______________________________________

From report at bugs.python.org  Sun May  8 17:15:22 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 08 May 2016 21:15:22 +0000
Subject: [issue25745] Reference leaks in test_curses
In-Reply-To: <1448647482.06.0.750956111756.issue25745@psf.upfronthosting.co.za>
Message-ID: <1462742122.57.0.410773330804.issue25745@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25745>
_______________________________________

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: [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 18:45:51 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 08 May 2016 22:45:51 +0000
Subject: [issue26512] Vocabulary: Using "integral" in library/stdtypes.html
In-Reply-To: <1457472244.72.0.113699245831.issue26512@psf.upfronthosting.co.za>
Message-ID: <1462747551.42.0.631581735031.issue26512@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26512>
_______________________________________

From report at bugs.python.org  Sun May  8 18:59:31 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 08 May 2016 22:59:31 +0000
Subject: [issue18531] Undocumented different between METH_KEYWORDS and **kws
In-Reply-To: <1374519103.74.0.277776306074.issue18531@psf.upfronthosting.co.za>
Message-ID: <1462748371.54.0.509713333656.issue18531@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

I'm not sure PyObject_GetItem instead of PyDict_GetItem in 3.x completely explains things, because the code in issue 6081 also works in 2.7.

But I don't think it's terribly important in any event, as long as we understand the 3.x difference. Thanks for researching!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18531>
_______________________________________

From report at bugs.python.org  Sun May  8 19:30:48 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 08 May 2016 23:30:48 +0000
Subject: [issue26969] ascynio should provide a policy to address
 pass-loop-everywhere problem
In-Reply-To: <1462668123.42.0.17372814033.issue26969@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJJepd+C1BBRYMenX2YXinVSz90TEYx81M2+nwyQwizJ+w@mail.gmail.com>


Guido van Rossum added the comment:

No, that specifically sounds like asking for trouble to me. You don't know
what else that coroutine is waiting for, and it may be waiting for some I/O
whose socket is registered with the other event loop. Since the other event
loop won't make progress, you'd be deadlocked.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26969>
_______________________________________

From report at bugs.python.org  Sun May  8 19:31:34 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 08 May 2016 23:31:34 +0000
Subject: [issue26969] ascynio should provide a policy to address
 pass-loop-everywhere problem
In-Reply-To: <CAP7+vJJepd+C1BBRYMenX2YXinVSz90TEYx81M2+nwyQwizJ+w@mail.gmail.com>
Message-ID: <CAP7+vJK2=eKo+Zpa3MyLbdgXBft1a2yfv4f7M8sdvbioEbVwDA@mail.gmail.com>


Guido van Rossum added the comment:

PS. If you have something you sometimes want to run synchronously and
sometimes as a coroutine, you probably need to refactor it somehow.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26969>
_______________________________________

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: [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 20:26:38 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 09 May 2016 00:26:38 +0000
Subject: [issue26981] add compatibility shim for enum34 backport
In-Reply-To: <1462751121.21.0.925705458571.issue26981@psf.upfronthosting.co.za>
Message-ID: <1462753598.34.0.720536474666.issue26981@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Doesn't namedtuple use _fields (as opposed to _fields_) for a similar purpose? Would Enum using _order be more consistent with that?

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26981>
_______________________________________

From report at bugs.python.org  Sun May  8 20:49:20 2016
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 09 May 2016 00:49:20 +0000
Subject: [issue26981] add compatibility shim for enum34 backport
In-Reply-To: <1462751121.21.0.925705458571.issue26981@psf.upfronthosting.co.za>
Message-ID: <1462754960.38.0.732172343326.issue26981@psf.upfronthosting.co.za>


Ethan Furman added the comment:

It would, but that's not what we did.

Currently we have _name_ and _value_; the backport uses __order__ because I didn't want the stdlib version having a hairball when someone tried to use a 2.7 Enum in 3.4 and it didn't occur to me at the time to just add and ignore _order_.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26981>
_______________________________________

From report at bugs.python.org  Sun May  8 20:56:38 2016
From: report at bugs.python.org (ppperry)
Date: Mon, 09 May 2016 00:56:38 +0000
Subject: [issue25901] `make test` crashes in test_httpservers
In-Reply-To: <1450431596.39.0.127057535.issue25901@psf.upfronthosting.co.za>
Message-ID: <1462755398.43.0.718725103123.issue25901@psf.upfronthosting.co.za>


Changes by ppperry <mapreader at olum.org>:


----------
title: make test crash in test_httpservers -> `make test` crashes in test_httpservers

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25901>
_______________________________________

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: [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  Sun May  8 21:15:37 2016
From: report at bugs.python.org (James Tatum)
Date: Mon, 09 May 2016 01:15:37 +0000
Subject: [issue26982] Clarify forward annotations in PEP 484
In-Reply-To: <1462756311.8.0.304204398387.issue26982@psf.upfronthosting.co.za>
Message-ID: <1462756537.58.0.140714789156.issue26982@psf.upfronthosting.co.za>


Changes by James Tatum <jtatum at gmail.com>:


Removed 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  Sun May  8 21:15:53 2016
From: report at bugs.python.org (James Tatum)
Date: Mon, 09 May 2016 01:15:53 +0000
Subject: [issue26982] Clarify forward annotations in PEP 484
In-Reply-To: <1462756311.8.0.304204398387.issue26982@psf.upfronthosting.co.za>
Message-ID: <1462756553.28.0.35523366685.issue26982@psf.upfronthosting.co.za>


Changes by James Tatum <jtatum at gmail.com>:


Added file: http://bugs.python.org/file42786/forward_references.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26982>
_______________________________________

From report at bugs.python.org  Sun May  8 21:16:25 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 09 May 2016 01:16:25 +0000
Subject: [issue25901] `make test` crashes in test_httpservers
In-Reply-To: <1450431596.39.0.127057535.issue25901@psf.upfronthosting.co.za>
Message-ID: <1462756585.27.0.0797752833714.issue25901@psf.upfronthosting.co.za>


Martin Panter added the comment:

It is not clear what compiler options you changed (you just gave the entire link command lines).

Does the crash occur every time, or only once? Does it occur if you run test_httpservers alone, without the other tests:

./python Tools/scripts/run_tests.py test_httpservers

It seems the crash happened inside a socket.bind() call. Ideally, it would be nice to investigate with GDB exactly where it crashes.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25901>
_______________________________________

From report at bugs.python.org  Sun May  8 21:26:15 2016
From: report at bugs.python.org (James Tatum)
Date: Mon, 09 May 2016 01:26:15 +0000
Subject: [issue26982] Clarify forward annotations in PEP 484
In-Reply-To: <1462756311.8.0.304204398387.issue26982@psf.upfronthosting.co.za>
Message-ID: <1462757175.48.0.657394853823.issue26982@psf.upfronthosting.co.za>


Changes by James Tatum <jtatum at gmail.com>:


Removed file: http://bugs.python.org/file42786/forward_references.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26982>
_______________________________________

From report at bugs.python.org  Sun May  8 21:26:23 2016
From: report at bugs.python.org (James Tatum)
Date: Mon, 09 May 2016 01:26:23 +0000
Subject: [issue26982] Clarify forward annotations in PEP 484
In-Reply-To: <1462756311.8.0.304204398387.issue26982@psf.upfronthosting.co.za>
Message-ID: <1462757183.15.0.0817640479564.issue26982@psf.upfronthosting.co.za>


Changes by James Tatum <jtatum at gmail.com>:


Added file: http://bugs.python.org/file42787/forward_references.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26982>
_______________________________________

From report at bugs.python.org  Sun May  8 23:28:45 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 09 May 2016 03:28:45 +0000
Subject: [issue6445] Add check parameter to subprocess.Popen.communicate
In-Reply-To: <1247131793.49.0.582429022768.issue6445@psf.upfronthosting.co.za>
Message-ID: <1462764525.17.0.527083935187.issue6445@psf.upfronthosting.co.za>


Martin Panter added the comment:

According to PEP 375, 3.1 was out on 27 June 2009, just before this report was opened (9 July). So perhaps OG7 wasn?t aware of check_output() at the time. But it sounds like they did want CalledProcessError to be raised.

I suggest to close this, unless there is demand for some new feature.

----------
resolution:  -> out of date
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6445>
_______________________________________

From report at bugs.python.org  Sun May  8 23:44:05 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 09 May 2016 03:44:05 +0000
Subject: [issue23213] subprocess communicate() hangs when stderr isn't closed
In-Reply-To: <1420848131.85.0.905282247977.issue23213@psf.upfronthosting.co.za>
Message-ID: <1462765445.73.0.785722045127.issue23213@psf.upfronthosting.co.za>


Martin Panter added the comment:

I suggest closing this. Depending on what the daemons are supposed to do, I think this is either a bug with ?systemd? and PHP holding onto stderr when they become daemons, or a bug/misunderstanding with how Thomas was using the subprocess module and communicate().

----------
resolution:  -> third party
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23213>
_______________________________________

From report at bugs.python.org  Sun May  8 23:53:21 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 May 2016 03:53:21 +0000
Subject: [issue18531] Undocumented different between METH_KEYWORDS and **kws
In-Reply-To: <1462748371.54.0.509713333656.issue18531@psf.upfronthosting.co.za>
Message-ID: <2274620.McyHzD0X0O@raxxla>


Serhiy Storchaka added the comment:

> I'm not sure PyObject_GetItem instead of PyDict_GetItem in 3.x completely
> explains things, because the code in issue 6081 also works in 2.7.

It doesn't work to me in current develop 2.7.11+. What version did you test?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18531>
_______________________________________

From report at bugs.python.org  Mon May  9 00:07:03 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 May 2016 04:07:03 +0000
Subject: [issue18531] Undocumented different between METH_KEYWORDS and **kws
In-Reply-To: <1374519103.74.0.277776306074.issue18531@psf.upfronthosting.co.za>
Message-ID: <1462766823.45.0.0918771119535.issue18531@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Now this is just the documentation issue. I think the change of the behavior in 3.6 should be documented too, but I even don't know where.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18531>
_______________________________________

From report at bugs.python.org  Mon May  9 00:08:37 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 09 May 2016 04:08:37 +0000
Subject: [issue26982] Clarify forward annotations in PEP 484
In-Reply-To: <1462756311.8.0.304204398387.issue26982@psf.upfronthosting.co.za>
Message-ID: <1462766917.2.0.948462854767.issue26982@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
assignee: docs at python -> gvanrossum
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26982>
_______________________________________

From report at bugs.python.org  Mon May  9 00:21:38 2016
From: report at bugs.python.org (James Tatum)
Date: Mon, 09 May 2016 04:21:38 +0000
Subject: [issue26689] Add `has_flag` method to `distutils.CCompiler`
In-Reply-To: <1459643481.74.0.720699620632.issue26689@psf.upfronthosting.co.za>
Message-ID: <1462767698.01.0.174571168994.issue26689@psf.upfronthosting.co.za>


James Tatum added the comment:

FYI, NamedTemporaryFile doesn't work well with Windows. There are a handful of issues about it.

----------
nosy: +James.Tatum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26689>
_______________________________________

From report at bugs.python.org  Mon May  9 01:29:10 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 09 May 2016 05:29:10 +0000
Subject: [issue26870] Unexpected call to readline's add_history in
 call_readline
In-Reply-To: <1461743534.82.0.668302064476.issue26870@psf.upfronthosting.co.za>
Message-ID: <1462771750.64.0.719524027167.issue26870@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is a patch including a unit test. I have only tested it on Linux. It would be awesome of other people could test it on other Unix platforms, in case the pseudoterminal stuff needs fixing.

----------
Added file: http://bugs.python.org/file42788/set_auto_history.v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26870>
_______________________________________

From report at bugs.python.org  Mon May  9 05:30:02 2016
From: report at bugs.python.org (Hans-Peter Jansen)
Date: Mon, 09 May 2016 09:30:02 +0000
Subject: [issue10808] ssl unwrap fails with Error 0
In-Reply-To: <1293997937.94.0.348375754935.issue10808@psf.upfronthosting.co.za>
Message-ID: <1462786202.73.0.809235017503.issue10808@psf.upfronthosting.co.za>


Hans-Peter Jansen added the comment:

Poor old bug.

Just being bitten from it today, while trying to package pyftpdlib on the openSUSE build service, which creates a clean reproducible build environment for all packages, and testing fails.

Part of the game: openssl 1.0.1k, Python 2.7.8

https://build.opensuse.org/package/show/home:frispete:python/python-pyftpdlib

It happens reproducible for i586 only, but not for x86_64, with all the same versions, and not with a local (much faster) build host.

So it is smells like a timing problem.

[   97s] ERROR: test_nlst (test_functional_ssl.TestFtpListingCmdsTLSMixin)
[   97s] ----------------------------------------------------------------------
[   97s] Traceback (most recent call last):
[   97s]   File "/home/abuild/rpmbuild/BUILD/pyftpdlib-1.5.1/pyftpdlib/test/test_functional_ssl.py", line 139, in test_nlst
[   97s]     super(TestFtpListingCmdsTLSMixin, self).test_nlst()
[   97s]   File "/home/abuild/.local/lib/python2.7/site-packages/pyftpdlib-1.5.1-py2.7.egg/pyftpdlib/test/test_functional.py", line 1187, in test_nlst
[   97s]     self._test_listing_cmds('nlst')
[   97s]   File "/home/abuild/.local/lib/python2.7/site-packages/pyftpdlib-1.5.1-py2.7.egg/pyftpdlib/test/test_functional.py", line 1180, in _test_listing_cmds
[   97s]     self.client.retrlines('%s %s' % (cmd, tempdir), x.append)
[   97s]   File "/usr/lib/python2.7/ftplib.py", line 735, in retrlines
[   97s]     conn.unwrap()
[   97s]   File "/usr/lib/python2.7/ssl.py", line 289, in unwrap
[   97s]     s = self._sslobj.shutdown()
[   97s] error: [Errno 0] Error

----------
nosy: +frispete

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10808>
_______________________________________

From report at bugs.python.org  Mon May  9 05:36:34 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 09 May 2016 09:36:34 +0000
Subject: [issue26974] Crash in Decimal.from_float
In-Reply-To: <1462684427.76.0.86950702335.issue26974@psf.upfronthosting.co.za>
Message-ID: <1462786594.15.0.561983218893.issue26974@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

[Serhiy, on the second patch]
> Disadvantages are that this changes behavior ignoring overriding as_integer_ratio() and __abs__() and slightly slows down Python implementation.

None of those seem like big issues to me. Certainly we shouldn't care too much about slowing down the Python implementation a bit more, and I think it's reasonable to say that code that's overriding as_integer_ratio (or `__abs__`) and then expecting that override to be picked up and used in `Decimal.from_float` is on its own.

> Advantages are that this fixes also issue26975 and slightly speeds up C implementation.

Sounds pretty good to me!

I'll let Stefan review the patch properly, but this seems like a good solution to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26974>
_______________________________________

From report at bugs.python.org  Mon May  9 05:42:28 2016
From: report at bugs.python.org (Thomas D.)
Date: Mon, 09 May 2016 09:42:28 +0000
Subject: [issue23213] subprocess communicate() hangs when stderr isn't closed
In-Reply-To: <1420848131.85.0.905282247977.issue23213@psf.upfronthosting.co.za>
Message-ID: <1462786948.36.0.0836094525791.issue23213@psf.upfronthosting.co.za>


Thomas D. added the comment:

Yep, I agree with you. This can be closed.

Thanks to your clarification the problem could be resolved upstream.

The udev problem was resolved in https://github.com/systemd/systemd/issues/190 and the PHP problem has a pending PR https://github.com/php/php-src/pull/1432

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23213>
_______________________________________

From report at bugs.python.org  Mon May  9 06:44:05 2016
From: report at bugs.python.org (Matthias Klose)
Date: Mon, 09 May 2016 10:44:05 +0000
Subject: [issue26673] Tkinter error when opening IDLE configuration menu
 (Tcl/Tk 8.6)
In-Reply-To: <1459351920.73.0.899924616631.issue26673@psf.upfronthosting.co.za>
Message-ID: <1462790645.56.0.0761984688542.issue26673@psf.upfronthosting.co.za>


Matthias Klose added the comment:

Seen on Debian and Ubuntu as well. All these distros have in common to use Tcl/Tk 8.6.

----------
nosy: +doko
title: Tkinter error when opening IDLE configuration menu -> Tkinter error when opening IDLE configuration menu (Tcl/Tk 8.6)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26673>
_______________________________________

From report at bugs.python.org  Mon May  9 06:58:16 2016
From: report at bugs.python.org (Matthias Klose)
Date: Mon, 09 May 2016 10:58:16 +0000
Subject: [issue26673] Tkinter error when opening IDLE configuration menu
 (Tcl/Tk 8.6)
In-Reply-To: <1459351920.73.0.899924616631.issue26673@psf.upfronthosting.co.za>
Message-ID: <1462791496.37.0.986792206656.issue26673@psf.upfronthosting.co.za>


Matthias Klose added the comment:

using this as a work-around, not tested with Tcl/Tk 8.5 or older.

--- a/Lib/idlelib/configDialog.py
+++ b/Lib/idlelib/configDialog.py
@@ -113,7 +113,11 @@ class ConfigDialog(Toplevel):
 
     def CreatePageFontTab(self):
         parent = self.parent
-        self.fontSize = StringVar(parent)
+        # see issue #26673
+        if TkVersion >= 8.6:
+            self.fontSize = IntVar(parent)
+        else:
+            self.fontSize = StringVar(parent)
         self.fontBold = BooleanVar(parent)
         self.fontName = StringVar(parent)
         self.spaceNum = IntVar(parent)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26673>
_______________________________________

From report at bugs.python.org  Mon May  9 08:13:23 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Mon, 09 May 2016 12:13:23 +0000
Subject: [issue18531] Undocumented different between METH_KEYWORDS and **kws
In-Reply-To: <1374519103.74.0.277776306074.issue18531@psf.upfronthosting.co.za>
Message-ID: <1462796003.77.0.508131021362.issue18531@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Oops, sorry. I'm an idiot. I was running in a venv where python was python3. Checking with my installed 2.7.10, I see the expected error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18531>
_______________________________________

From report at bugs.python.org  Mon May  9 09:20:13 2016
From: report at bugs.python.org (englabenny)
Date: Mon, 09 May 2016 13:20:13 +0000
Subject: [issue16113] Add SHA-3 and SHAKE (Keccak) support
In-Reply-To: <1349233804.79.0.00772371618682.issue16113@psf.upfronthosting.co.za>
Message-ID: <1462800013.86.0.377265704462.issue16113@psf.upfronthosting.co.za>


Changes by englabenny <ulrik.sverdrup at gmail.com>:


----------
nosy:  -englabenny

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16113>
_______________________________________

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: [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 09:49:24 2016
From: report at bugs.python.org (Meador Inge)
Date: Mon, 09 May 2016 13:49:24 +0000
Subject: [issue26870] Unexpected call to readline's add_history in
 call_readline
In-Reply-To: <1461743534.82.0.668302064476.issue26870@psf.upfronthosting.co.za>
Message-ID: <1462801764.41.0.914042085153.issue26870@psf.upfronthosting.co.za>


Meador Inge added the comment:

Works fine on Darwin (OS X Yosemite 10.10.5):

drago:cpython meadori$ uname -a
Darwin drago 14.5.0 Darwin Kernel Version 14.5.0: Mon Jan 11 18:48:35 PST 2016; root:xnu-2782.50.2~1/RELEASE_X86_64 x86_64

----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26870>
_______________________________________

From report at bugs.python.org  Mon May  9 09:49:41 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 May 2016 13:49:41 +0000
Subject: [issue26974] Crash in Decimal.from_float
In-Reply-To: <1462684427.76.0.86950702335.issue26974@psf.upfronthosting.co.za>
Message-ID: <1462801781.0.0.231727880281.issue26974@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Actually the part of the second patch for Python implementation not always works correctly due to a bug (issue26983). We should either first fix issue26983 or use more complicated code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26974>
_______________________________________

From report at bugs.python.org  Mon May  9 09:53:27 2016
From: report at bugs.python.org (Michael Felt)
Date: Mon, 09 May 2016 13:53:27 +0000
Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not
 available (e.g., AIX)
In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za>
Message-ID: <1462802007.77.0.567534729917.issue26439@psf.upfronthosting.co.za>


Michael Felt added the comment:

New patch of the Lib/ctypes directory - BUT - this time as a delta based on 3.5.0.

++ changes from last patch ++
* OSError gets raised (as expected) by test/test_loading.py
* test in util.py modified (libm is replaced by libc when "aix"), and
added an additional test for AIX (showing it finds the latest version
of libintl that is installed (frequently, there are two versions)
* moved RTLD_NOW and RTLD_MEMBER definitions to the "aix" blocks in __init__.py
* in test/test_loading.py added two more libraries to look for

----------
Added file: http://bugs.python.org/file42789/python.Lib.ctypes.160509.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26439>
_______________________________________

From report at bugs.python.org  Mon May  9 10:00:25 2016
From: report at bugs.python.org (Michael Felt)
Date: Mon, 09 May 2016 14:00:25 +0000
Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not
 available (e.g., AIX)
In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za>
Message-ID: <1462802425.91.0.755333518249.issue26439@psf.upfronthosting.co.za>


Michael Felt added the comment:

New version of aixutil.py

++ Changes ++
* more comments
* re-worked the 'searches' for matches after adding changing the way
the output from _get_dumpH was read (now to an array using readlines).
Also, p.stdout.close() and p.wait() are done within the _get_dumpH routine.

Suggestions on how to have cleaner workings with the 'arrays of text' and searching through them is welcomed! It is passing the internal tests is all I will say for now.

----------
versions: +Python 3.5
Added file: http://bugs.python.org/file42790/aixutil.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26439>
_______________________________________

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: [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: [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:11:26 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 09 May 2016 15:11:26 +0000
Subject: [issue26632] __all__ decorator
In-Reply-To: <1458786797.31.0.0749407715279.issue26632@psf.upfronthosting.co.za>
Message-ID: <1462806686.65.0.678960127583.issue26632@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

Here's a standalone version for older Python 3's:

http://public.readthedocs.io/en/latest/
https://pypi.python.org/pypi/atpublic

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26632>
_______________________________________

From report at bugs.python.org  Mon May  9 11:28:09 2016
From: report at bugs.python.org (Ilya Kulakov)
Date: Mon, 09 May 2016 15:28:09 +0000
Subject: [issue26969] ascynio should provide a policy to address
 pass-loop-everywhere problem
In-Reply-To: <1462517538.3.0.176027238089.issue26969@psf.upfronthosting.co.za>
Message-ID: <1462807689.44.0.727248805042.issue26969@psf.upfronthosting.co.za>


Ilya Kulakov added the comment:

> You don't know what else that coroutine is waiting for, and it may be waiting for some I/O whose socket is registered with the other event loop. Since the other event loop won't make progress, you'd be deadlocked.

As an end user I know what my coroutines may be waiting for. It's out of question to expect an ability to reuse coroutine and its associated context in multiple loops.

> PS. If you have something you sometimes want to run synchronously and sometimes as a coroutine, you probably need to refactor it somehow.

We have a service that is responsible for reporting various stages about our application's lifetime. Most of the time app does not care about when (and whether) data will be actually sent, so we run this service in its own thread, the rest of the app just schedules coroutines in its event loop (hidden and managed by service's API). However sometimes it does care and moreover needs to do that synchronously (i.e. when we handle fatal / unhandled exception. In order to reuse remaining code that constructs coroutines, in the place of invocation we create a temporary event loop and use run_until_complete.

This is all practical problem. The conceptual problem is that current API is not flexible enough to create an event policy that would do something more useful that changing default type of an event loop.

Having the ability to get currently running event loop from within executing coroutine sounds pretty convenient and in my opinion would greatly reduce the amount of passing loops everywhere for end users (library developery, unfortunately, have no chance to avoid this).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26969>
_______________________________________

From report at bugs.python.org  Mon May  9 11:37:17 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 09 May 2016 15:37:17 +0000
Subject: [issue26969] ascynio should provide a policy to address
 pass-loop-everywhere problem
In-Reply-To: <1462807689.44.0.727248805042.issue26969@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJLpCwX22csFJ_9NQRVbHrzeG_EZsw9DMiyQpYEBB3Toiw@mail.gmail.com>


Guido van Rossum added the comment:

Instead of starting a new event loop, you should figure out a way to wait
for an event in the existing loop. IIUC that loop runs in a different
thread -- I think you can solve this by using a threading.Event that you
set from a wrapper coroutine running in your event loop and waited for in
the main loop. (If you're worried about blocking the event loop just to
acquire the threading lock that's part of threading.Event, you can use
run_in_executor().

Good luck!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26969>
_______________________________________

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: [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 11:49:09 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 09 May 2016 15:49:09 +0000
Subject: [issue26986] Enhance PyFunction_New documentation
In-Reply-To: <1462808942.73.0.503495552069.issue26986@psf.upfronthosting.co.za>
Message-ID: <1462808949.21.0.714578920258.issue26986@psf.upfronthosting.co.za>


Changes by Xiang Zhang <angwerzx at 126.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26986>
_______________________________________

From report at bugs.python.org  Mon May  9 11:49:50 2016
From: report at bugs.python.org (Ilya Kulakov)
Date: Mon, 09 May 2016 15:49:50 +0000
Subject: [issue26969] ascynio should provide a policy to address
 pass-loop-everywhere problem
In-Reply-To: <1462517538.3.0.176027238089.issue26969@psf.upfronthosting.co.za>
Message-ID: <1462808990.2.0.226654953131.issue26969@psf.upfronthosting.co.za>


Ilya Kulakov added the comment:

> If you're worried about blocking the event loop just to acquire the threading lock that's part of threading.Event, you can use run_in_executor()

I'm more worried to delay invocation of a "synchronous" report because of outstanding tasks in event loop's queue. Given my situtation, that may not even happen because outstanding tasks may stop the loop by raising their own exceptions.

I'm willing to sacrifice them (i.e. I'm ok with not sending them) in order to send information about exception "for sure".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26969>
_______________________________________

From report at bugs.python.org  Mon May  9 11:54:08 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 09 May 2016 15:54:08 +0000
Subject: [issue26673] Tkinter error when opening IDLE configuration menu
 (Tcl/Tk 8.6)
In-Reply-To: <1459351920.73.0.899924616631.issue26673@psf.upfronthosting.co.za>
Message-ID: <1462809248.32.0.543812246352.issue26673@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Mark, changing the default font from Courier to TkFixedFont has introduced or exposed a bug in any of IDLE, tkinter, or tk 8.6.4 on Linux.  The result is that trying to open the configuration menu fails with TclError.  What do your think is the best solution?

Mathias, it seems to me that fontsize should alsways be an Intvar.  I have no idea why StringVar is used, except possibly as a workaround when the code was written.

----------
nosy: +markroseman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26673>
_______________________________________

From report at bugs.python.org  Mon May  9 12:09:45 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 09 May 2016 16:09:45 +0000
Subject: [issue26673] Tkinter error when opening IDLE configuration menu
 (Tcl/Tk 8.6)
In-Reply-To: <1459351920.73.0.899924616631.issue26673@psf.upfronthosting.co.za>
Message-ID: <1462810185.74.0.646662313907.issue26673@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Anyone seeing problem: In /Lib/idlelib/configHandler.py, about line 685, in "if size < 0:", change '<' to '<='.  Remove the workaround of overriding 'TkFixedFont' with 'courier'.  Does this fix the problem?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26673>
_______________________________________

From report at bugs.python.org  Mon May  9 12:10:12 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 09 May 2016 16:10:12 +0000
Subject: [issue24745] Better default font for editor
In-Reply-To: <1438129028.22.0.104228147207.issue24745@psf.upfronthosting.co.za>
Message-ID: <1462810212.65.0.956478931811.issue24745@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

This change caused a regression on Linux with 8.6.4 because TkFixedFont ends up with size = 0.  Cannot open configuration file.  See #26673.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24745>
_______________________________________

From report at bugs.python.org  Mon May  9 12:15:50 2016
From: report at bugs.python.org (Steve Dower)
Date: Mon, 09 May 2016 16:15:50 +0000
Subject: [issue26903] ProcessPoolExecutor(max_workers=64) crashes on Windows
In-Reply-To: <1462135538.41.0.857077084248.issue26903@psf.upfronthosting.co.za>
Message-ID: <1462810550.62.0.538419968984.issue26903@psf.upfronthosting.co.za>


Steve Dower added the comment:

> Some quick Googling strongly suggests there's no reasonably general way to overcome the Windows-defined MAXIMUM_WAIT_OBJECTS=64 for implementations that call the Windows WaitForMultipleObjects().

The recommended way to deal with this is to spin up threads to do the wait (which sounds horribly inefficient, but threads on Windows are cheap, especially if they are waiting on kernel objects), and then wait on each thread.

Personally I think it'd be fine to make the _winapi module do that transparently for WaitForMultipleObjects, as it's complicated to get right (you need to ensure you map back to the original handle, timeouts and cancellation get complicated, there are real race conditions (mainly for auto-reset events), etc.), but in all circumstances it's better than just failing immediately. Handling it within multiprocessing isn't a bad idea, but won't help other users.

I'd love to write the code to do it, but I doubt I'll get time (especially since I'm missing the PyCon US sprints this year). Happy to help someone else through it. We're going to see Python being used on more and more multicore systems over time, where this will become a genuine issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26903>
_______________________________________

From report at bugs.python.org  Mon May  9 12:16:21 2016
From: report at bugs.python.org (Steve Dower)
Date: Mon, 09 May 2016 16:16:21 +0000
Subject: [issue26903] ProcessPoolExecutor(max_workers=64) crashes on Windows
In-Reply-To: <1462135538.41.0.857077084248.issue26903@psf.upfronthosting.co.za>
Message-ID: <1462810581.03.0.279410648314.issue26903@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at python.org>:


----------
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26903>
_______________________________________

From report at bugs.python.org  Mon May  9 12:19:13 2016
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 09 May 2016 16:19:13 +0000
Subject: [issue26632] __all__ decorator
In-Reply-To: <1458786797.31.0.0749407715279.issue26632@psf.upfronthosting.co.za>
Message-ID: <1462810753.82.0.899393522045.issue26632@psf.upfronthosting.co.za>


Ethan Furman added the comment:

For the standalone version I suggest a disclaimer about the `from ... import *` ability.  Something like:

`from ... import *` should not be used with packages that do not have an __all__ unless they support that usage (check their docs).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26632>
_______________________________________

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: [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 12:28:24 2016
From: report at bugs.python.org (Stephen Paul Chappell)
Date: Mon, 09 May 2016 16:28:24 +0000
Subject: [issue24185] Add Function for Sending File to Trash (or Recycling Bin)
In-Reply-To: <1431574601.59.0.7462724115.issue24185@psf.upfronthosting.co.za>
Message-ID: <1462811303.99.0.514444029552.issue24185@psf.upfronthosting.co.za>


Changes by Stephen Paul Chappell <Noctis.Skytower at gmail.com>:


----------
nosy: +Zero

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24185>
_______________________________________

From report at bugs.python.org  Mon May  9 12:42:38 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 09 May 2016 16:42:38 +0000
Subject: [issue26987] Comment/implementation disagreement in
 Thread._bootstrap_inner
In-Reply-To: <1462811188.69.0.863333138348.issue26987@psf.upfronthosting.co.za>
Message-ID: <1462812158.44.0.66419060001.issue26987@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Good catch! Yes, this is just my mistake. Could you please fix this? I can't commit right now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26987>
_______________________________________

From report at bugs.python.org  Mon May  9 12:43:36 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 09 May 2016 16:43:36 +0000
Subject: [issue26984] int() can return not exact int instance
In-Reply-To: <1462802551.63.0.282711121635.issue26984@psf.upfronthosting.co.za>
Message-ID: <1462812216.53.0.912677923572.issue26984@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> But I think that the int constructor should convert its result to exact int.

Agreed. See also issue 17576 and previous discussions on python-dev (thread started in March, but most of the messages in April):

- https://mail.python.org/pipermail/python-dev/2013-March/125022.html
- https://mail.python.org/pipermail/python-dev/2013-April/125042.html

I don't have strong feelings about `__trunc__` (or `__floor__` and `__ceil__`); it seems fine to me for those to be returning something other than a strict int.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26984>
_______________________________________

From report at bugs.python.org  Mon May  9 12:59:09 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 09 May 2016 16:59:09 +0000
Subject: [issue26632] __all__ decorator
In-Reply-To: <1462810753.82.0.899393522045.issue26632@psf.upfronthosting.co.za>
Message-ID: <20160509125906.17f1df32@subdivisions.wooz.org>


Barry A. Warsaw added the comment:

On May 09, 2016, at 04:19 PM, Ethan Furman wrote:

>`from ... import *` should not be used with packages that do not have an
>__all__ unless they support that usage (check their docs).

Good idea; I added a warning-ish.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26632>
_______________________________________

From report at bugs.python.org  Mon May  9 15:50:51 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 09 May 2016 19:50:51 +0000
Subject: [issue26987] Comment/implementation disagreement in
 Thread._bootstrap_inner
In-Reply-To: <1462811188.69.0.863333138348.issue26987@psf.upfronthosting.co.za>
Message-ID: <20160509195046.13775.15831.5EC63D79@psf.io>


Roundup Robot added the comment:

New changeset 8842c02c02a2 by Zachary Ware in branch '3.5':
Issue #26987: Correct implementation to match comment
https://hg.python.org/cpython/rev/8842c02c02a2

New changeset 694dadd9f7bd by Zachary Ware in branch 'default':
Closes #26987: Merge with 3.5
https://hg.python.org/cpython/rev/694dadd9f7bd

----------
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26987>
_______________________________________

From report at bugs.python.org  Mon May  9 18:55:14 2016
From: report at bugs.python.org (Jakub Stasiak)
Date: Mon, 09 May 2016 22:55:14 +0000
Subject: [issue26814] [WIP] Add a new _PyObject_FastCall() function which
 avoids the creation of a tuple or dict for arguments
In-Reply-To: <1461229041.59.0.994194592206.issue26814@psf.upfronthosting.co.za>
Message-ID: <1462834514.61.0.824531645518.issue26814@psf.upfronthosting.co.za>


Changes by Jakub Stasiak <jakub+python.org at stasiak.at>:


----------
nosy: +jstasiak

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26814>
_______________________________________

From report at bugs.python.org  Mon May  9 18:56:49 2016
From: report at bugs.python.org (Jakub Stasiak)
Date: Mon, 09 May 2016 22:56:49 +0000
Subject: [issue23507] Tuple creation is too slow
In-Reply-To: <1424765312.55.0.269687406134.issue23507@psf.upfronthosting.co.za>
Message-ID: <1462834608.99.0.833149843147.issue23507@psf.upfronthosting.co.za>


Changes by Jakub Stasiak <jakub+python.org at stasiak.at>:


----------
nosy: +jstasiak

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23507>
_______________________________________

From report at bugs.python.org  Mon May  9 19:06:17 2016
From: report at bugs.python.org (Meador Inge)
Date: Mon, 09 May 2016 23:06:17 +0000
Subject: [issue6338] Error message displayed on stderr when no C compiler is
 present with ctypes
In-Reply-To: <1245877709.89.0.124582375066.issue6338@psf.upfronthosting.co.za>
Message-ID: <1462835177.87.0.346571731234.issue6338@psf.upfronthosting.co.za>


Changes by Meador Inge <meadori at gmail.com>:


----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6338>
_______________________________________

From report at bugs.python.org  Mon May  9 20:56:25 2016
From: report at bugs.python.org (Meador Inge)
Date: Tue, 10 May 2016 00:56:25 +0000
Subject: [issue26746] struct.pack(): trailing padding bytes on x64
In-Reply-To: <1460536729.2.0.723853097724.issue26746@psf.upfronthosting.co.za>
Message-ID: <1462841785.48.0.792847025797.issue26746@psf.upfronthosting.co.za>


Meador Inge added the comment:

I'm not to crazy about the trailing padding syntax either.  The behavior is documented all the way back to Python 2.6.  So, I would be hesitant to change it now.

If the new 'T{...}' struct syntax from issue3132 ever gets added, then maybe we could address this there?

FWIW, internal and trailing padding is implementation defined by the C standard.  That being said, most compilers I have worked with add the trailing padding.

----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26746>
_______________________________________

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: [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 21:53:58 2016
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 10 May 2016 01:53:58 +0000
Subject: [issue26988] Add AutoNumberedEnum to stdlib
In-Reply-To: <1462844071.91.0.106881823757.issue26988@psf.upfronthosting.co.za>
Message-ID: <1462845238.5.0.864452650107.issue26988@psf.upfronthosting.co.za>


Changes by Ethan Furman <ethan at stoneleaf.us>:


----------
nosy: +barry, eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26988>
_______________________________________

From report at bugs.python.org  Mon May  9 21:58:14 2016
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 10 May 2016 01:58:14 +0000
Subject: [issue26988] Add AutoNumberedEnum to stdlib
In-Reply-To: <1462844071.91.0.106881823757.issue26988@psf.upfronthosting.co.za>
Message-ID: <1462845494.53.0.997778763537.issue26988@psf.upfronthosting.co.za>


Ethan Furman added the comment:

On the other hand, if you use aenum you can do:

class Color(AutoNumber):
    red
    green
    blue

And isn't that better*?  ;)

* For those in danger of swallowing their tongue over the magic involved: The magic is turned off as soon as any descriptor is defined (property, function, etc.).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26988>
_______________________________________

From report at bugs.python.org  Mon May  9 22:01:21 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 10 May 2016 02:01:21 +0000
Subject: [issue26988] Add AutoNumberedEnum to stdlib
In-Reply-To: <1462844071.91.0.106881823757.issue26988@psf.upfronthosting.co.za>
Message-ID: <1462845681.74.0.558549635129.issue26988@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

Wow Ethan, that's quite interesting.  I'm not sure if I like it or not. :)

It's better than having to assign a dummy value to the enum items, and if we did require that, I'd suggest just throwing away the values for autonumbering.

But not having to specify any values at all is probably better, although it does look weird!

/me goes to look at the magic you're using...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26988>
_______________________________________

From report at bugs.python.org  Mon May  9 22:02:02 2016
From: report at bugs.python.org (Meador Inge)
Date: Tue, 10 May 2016 02:02:02 +0000
Subject: [issue26549] co_stacksize is calculated from unoptimized code
In-Reply-To: <1457822745.22.0.972836245522.issue26549@psf.upfronthosting.co.za>
Message-ID: <1462845722.17.0.222261451109.issue26549@psf.upfronthosting.co.za>


Meador Inge added the comment:

Strictly speaking, the stack size is calculated *after* the peephole optimizer is run, but the code that computes the stack depth operates on the basic block graph instead of the assembled and optimized byte code.

Anyway, the conclusion is the same as Brett noted -- the stack depth analysis would need to be re-written to operate on the optimized bytecode array.

----------
nosy: +meador.inge

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26549>
_______________________________________

From report at bugs.python.org  Mon May  9 22:06:34 2016
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 10 May 2016 02:06:34 +0000
Subject: [issue26988] Add AutoNumberedEnum to stdlib
In-Reply-To: <1462844071.91.0.106881823757.issue26988@psf.upfronthosting.co.za>
Message-ID: <1462845994.31.0.0707750709621.issue26988@psf.upfronthosting.co.za>


Ethan Furman added the comment:

It's in _EnumDict.__getitem__; there's some duplication in __setitem__ for supporting Python 2 (although with 2 you have to use either the empty tuple, or some other handy thing that may go in the __doc__ attribute, for example).

----------

_______________________________________
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: [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 22:37:13 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 10 May 2016 02:37:13 +0000
Subject: [issue26989] error in installation of ez_setup.py
In-Reply-To: <1462846783.15.0.752722442438.issue26989@psf.upfronthosting.co.za>
Message-ID: <1462847833.52.0.339810723508.issue26989@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

It seems pypi is blocked in China, :-( so try pypi mirror in China. ez_setup.py seems to have --download-base option to let you specify alternative URL. I don't think this is a bug.

----------
nosy: +xiang.zhang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26989>
_______________________________________

From report at bugs.python.org  Mon May  9 23:06:15 2016
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Tue, 10 May 2016 03:06:15 +0000
Subject: [issue14209] pkgutil.iter_zipimport_modules ignores the prefix
 parameter for packages
In-Reply-To: <1331046144.89.0.833633660995.issue14209@psf.upfronthosting.co.za>
Message-ID: <1462849575.33.0.379098671665.issue14209@psf.upfronthosting.co.za>


?ukasz Langa added the comment:

Brett, Facebook is using the proposed patch in prod since last year. It works fine. Maybe we should just include it for the time being?

----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14209>
_______________________________________

From report at bugs.python.org  Mon May  9 23:09:39 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 10 May 2016 03:09:39 +0000
Subject: [issue26985] Information about CodeType in inspect documentation is
 outdated
In-Reply-To: <1462803102.24.0.542356144335.issue26985@psf.upfronthosting.co.za>
Message-ID: <1462849779.21.0.0352104427385.issue26985@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Attach patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file42793/inspect_doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26985>
_______________________________________

From report at bugs.python.org  Mon May  9 23:09:45 2016
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 10 May 2016 03:09:45 +0000
Subject: [issue14209] pkgutil.iter_zipimport_modules ignores the prefix
 parameter for packages
In-Reply-To: <1331046144.89.0.833633660995.issue14209@psf.upfronthosting.co.za>
Message-ID: <1462849785.46.0.0952662578968.issue14209@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I don't deal with pkgutil so I have no problem if you want to go ahead and apply the patch if you think it's reasonable to accept, ?ukasz.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14209>
_______________________________________

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: [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 01:57:26 2016
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 10 May 2016 05:57:26 +0000
Subject: [issue26989] error in installation of ez_setup.py
In-Reply-To: <1462846783.15.0.752722442438.issue26989@psf.upfronthosting.co.za>
Message-ID: <1462859846.11.0.494401358981.issue26989@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26989>
_______________________________________

From report at bugs.python.org  Tue May 10 02:44:41 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 May 2016 06:44:41 +0000
Subject: [issue26986] Enhance PyFunction_New documentation
In-Reply-To: <1462808942.73.0.503495552069.issue26986@psf.upfronthosting.co.za>
Message-ID: <20160510064435.89099.82323.6AB40599@psf.io>


Roundup Robot added the comment:

New changeset bfc4c57a0986 by Benjamin Peterson in branch '3.5':
improve PyFunction_New docs (closes #26986)
https://hg.python.org/cpython/rev/bfc4c57a0986

New changeset 71afeb15f617 by Benjamin Peterson in branch 'default':
merge 3.5 (#26986)
https://hg.python.org/cpython/rev/71afeb15f617

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26986>
_______________________________________

From report at bugs.python.org  Tue May 10 04:13:07 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 May 2016 08:13:07 +0000
Subject: [issue26960] urllib hangs when closing connection
In-Reply-To: <1462407954.17.0.565805320206.issue26960@psf.upfronthosting.co.za>
Message-ID: <20160510081300.88888.36563.1993F575@psf.io>


Roundup Robot added the comment:

New changeset 44d02a5d59fb by Senthil Kumaran in branch '2.7':
Closes issue26960.
https://hg.python.org/cpython/rev/44d02a5d59fb

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26960>
_______________________________________

From report at bugs.python.org  Tue May 10 04:13:07 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 May 2016 08:13:07 +0000
Subject: [issue16270] urllib hangs when closing connection
In-Reply-To: <1350509929.7.0.680667591801.issue16270@psf.upfronthosting.co.za>
Message-ID: <20160510081300.88888.12959.8928E00E@psf.io>


Roundup Robot added the comment:

New changeset 44d02a5d59fb by Senthil Kumaran in branch '2.7':
Closes issue26960.
https://hg.python.org/cpython/rev/44d02a5d59fb

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16270>
_______________________________________

From report at bugs.python.org  Tue May 10 04:29:42 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 May 2016 08:29:42 +0000
Subject: [issue26960] urllib hangs when closing connection
In-Reply-To: <1462407954.17.0.565805320206.issue26960@psf.upfronthosting.co.za>
Message-ID: <20160510082939.9093.77118.ADB92B10@psf.io>


Roundup Robot added the comment:

New changeset 3388e249389d by Senthil Kumaran in branch '2.7':
Add NEWS entry for issue26960.
https://hg.python.org/cpython/rev/3388e249389d

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26960>
_______________________________________

From report at bugs.python.org  Tue May 10 04:30:10 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 10 May 2016 08:30:10 +0000
Subject: [issue26960] urllib hangs when closing connection
In-Reply-To: <1462407954.17.0.565805320206.issue26960@psf.upfronthosting.co.za>
Message-ID: <1462869010.81.0.701871100852.issue26960@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Thanks for raising this issue, Chris Beaumont.
Fixed in 2.7.x

----------
nosy: +orsenthil
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26960>
_______________________________________

From report at bugs.python.org  Tue May 10 04:37:27 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 May 2016 08:37:27 +0000
Subject: [issue23921] Standardize documentation whitespace, formatting
In-Reply-To: <1428814739.03.0.523944029114.issue23921@psf.upfronthosting.co.za>
Message-ID: <1462869447.81.0.450086399799.issue23921@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee: docs at python -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23921>
_______________________________________

From report at bugs.python.org  Tue May 10 04:38:42 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 10 May 2016 08:38:42 +0000
Subject: [issue4861] fix problems with ctypes.util.find_library
In-Reply-To: <1231279372.3.0.860713404681.issue4861@psf.upfronthosting.co.za>
Message-ID: <1462869522.27.0.184356230796.issue4861@psf.upfronthosting.co.za>


Martin Panter added the comment:

FYI the OSError exceptions added here were never triggered as intended, and they are proposed to be removed as part of Issue 25751.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4861>
_______________________________________

From report at bugs.python.org  Tue May 10 05:02:53 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 May 2016 09:02:53 +0000
Subject: [issue23921] Standardize documentation whitespace, formatting
In-Reply-To: <1428814739.03.0.523944029114.issue23921@psf.upfronthosting.co.za>
Message-ID: <20160510090248.15110.38801.0264ABCC@psf.io>


Roundup Robot added the comment:

New changeset 2b492ea961c1 by Serhiy Storchaka in branch '3.5':
Issue #23921: Standardized documentation whitespace formatting.
https://hg.python.org/cpython/rev/2b492ea961c1

New changeset 909099686e6e by Serhiy Storchaka in branch 'default':
Issue #23921: Standardized documentation whitespace formatting.
https://hg.python.org/cpython/rev/909099686e6e

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23921>
_______________________________________

From report at bugs.python.org  Tue May 10 06:12:26 2016
From: report at bugs.python.org (Thomas Kluyver)
Date: Tue, 10 May 2016 10:12:26 +0000
Subject: [issue26039] More flexibility in zipfile write interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <1462875146.91.0.384615243317.issue26039@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

Ping? Once this is landed, I intend to make a backport package of it so I can start using it before Python 3.6 comes out.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26039>
_______________________________________

From report at bugs.python.org  Tue May 10 06:46:11 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 May 2016 10:46:11 +0000
Subject: [issue23921] Standardize documentation whitespace, formatting
In-Reply-To: <1428814739.03.0.523944029114.issue23921@psf.upfronthosting.co.za>
Message-ID: <20160510104607.42351.78213.756095A0@psf.io>


Roundup Robot added the comment:

New changeset be85897e6d58 by Serhiy Storchaka in branch '2.7':
Issue #23921: Standardized documentation whitespace formatting.
https://hg.python.org/cpython/rev/be85897e6d58

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23921>
_______________________________________

From report at bugs.python.org  Tue May 10 06:48:40 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 May 2016 10:48:40 +0000
Subject: [issue23921] Standardize documentation whitespace, formatting
In-Reply-To: <1428814739.03.0.523944029114.issue23921@psf.upfronthosting.co.za>
Message-ID: <1462877320.03.0.486377811718.issue23921@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Addressed Martin's Georg's and my comments, resolved conflicts, stripped trailing spaces, backported to 2.7.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23921>
_______________________________________

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: [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 07:01:55 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 10 May 2016 11:01:55 +0000
Subject: [issue26991] Possible reference leak in MAKE_FUNCTION
In-Reply-To: <1462878017.45.0.401291205212.issue26991@psf.upfronthosting.co.za>
Message-ID: <1462878115.09.0.291199502109.issue26991@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Sorry, wrong patch. Attach the right one.

----------
Added file: http://bugs.python.org/file42795/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 07:17:13 2016
From: report at bugs.python.org (John Hagen)
Date: Tue, 10 May 2016 11:17:13 +0000
Subject: [issue26988] Add AutoNumberedEnum to stdlib
In-Reply-To: <1462844071.91.0.106881823757.issue26988@psf.upfronthosting.co.za>
Message-ID: <1462879033.02.0.191907728888.issue26988@psf.upfronthosting.co.za>


John Hagen added the comment:

@Ethan, I hadn't tried to use the aenum AutoNumberEnum that way, but I agree with Barry that I like it.  To me that is the ideal case we should shoot for as I think it's the best* long term and deviate only if practical concerns prevent it.

So I am +1 for empty member assignment and if that is rejected, +1 for = () assignment as at least it is a big step forward.  I feel both solutions already have some "magic", so would lean toward the one that leads to the least amount of boilerplate.

As for the empty assignment, I have played around with something similar before and will throw out one con for it: static analyzers get really confused.  PyCharm, for example, thinks this is has unresolved references in it:

class Color(AutoNumberEnum):
    red
    green
    blue

But the counter point is that if this is in the stdlib, static analyzer authors are much more likely to add a special case for it than if in a "non-official" third party package (PyCharm example: https://youtrack.jetbrains.com/issue/PY-19150).


Another piece of evidence to support inclusion is that Python already provides specialized Enum subclasses (like IntEnum).  I've written a lot of Python code that uses Enums and haven't personally needed IntEnum yet, but would have used an AutoEnum many, many times.

* I am assuming here that a true "enum" keyword is out of the question at this point for Python, which would probably be even better.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26988>
_______________________________________

From report at bugs.python.org  Tue May 10 07:21:26 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 10 May 2016 11:21:26 +0000
Subject: [issue12045] external shell command executed twice in
 ctypes.util._get_soname
In-Reply-To: <1304975347.59.0.150062632032.issue12045@psf.upfronthosting.co.za>
Message-ID: <1462879286.6.0.37660723121.issue12045@psf.upfronthosting.co.za>


Martin Panter added the comment:

The same code is in Python 2. It was introduced by Issue 4861 (r68487).

----------
nosy: +martin.panter
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12045>
_______________________________________

From report at bugs.python.org  Tue May 10 07:29:37 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 May 2016 11:29:37 +0000
Subject: [issue26991] Possible reference leak in MAKE_FUNCTION
In-Reply-To: <1462878017.45.0.401291205212.issue26991@psf.upfronthosting.co.za>
Message-ID: <1462879777.82.0.634730137713.issue26991@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM. Would be nice to have a test (just compile a function with annotations in a loop).

----------
components: +Interpreter Core
stage:  -> test needed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26991>
_______________________________________

From report at bugs.python.org  Tue May 10 07:41:51 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 May 2016 11:41:51 +0000
Subject: [issue12045] external shell command executed twice in
 ctypes.util._get_soname
In-Reply-To: <1304975347.59.0.150062632032.issue12045@psf.upfronthosting.co.za>
Message-ID: <20160510114147.13290.9909.D02C8283@psf.io>


Roundup Robot added the comment:

New changeset 0b15b5371c07 by Antoine Pitrou in branch '2.7':
Issue #12045: Avoid duplicate execution of command in ctypes.util._get_soname().
https://hg.python.org/cpython/rev/0b15b5371c07

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12045>
_______________________________________

From report at bugs.python.org  Tue May 10 07:49:16 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 10 May 2016 11:49:16 +0000
Subject: [issue14209] pkgutil.iter_zipimport_modules ignores the prefix
 parameter for packages
In-Reply-To: <1331046144.89.0.833633660995.issue14209@psf.upfronthosting.co.za>
Message-ID: <1462880956.61.0.521469398577.issue14209@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

+1 for just including the fix in the next round of maintenance releases, although a test case would be desirable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14209>
_______________________________________

From report at bugs.python.org  Tue May 10 08:01:49 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 10 May 2016 12:01:49 +0000
Subject: [issue22636] avoid using a shell in ctypes.util: replace os.popen
 with subprocess
In-Reply-To: <1413325975.89.0.175884398711.issue22636@psf.upfronthosting.co.za>
Message-ID: <1462881709.53.0.59346825364.issue22636@psf.upfronthosting.co.za>


Martin Panter added the comment:

I merged Victor?s patch with the current code and addressed most of the comments:

* restore re.escape()
* single "-l" + name argument
* copy with dict(os.environ)
* redirect GCC stderr=STDOUT
* changed tempfile cleanup to try / finally

I also added a test case.

I kept Victor?s behaviour of not raising OSError when the command is missing. I think this should be considered separately, and only changed for 3.6+, if at all. The buggy code was added in Issue 4861.

I only have Linux and GCC, but I briefly tested each platform-specific branch by hacking the ?if? statements and creating mock crle, ldconfig, etc commands, so I am somewhat confident that everything is still working.

----------
stage: needs patch -> patch review
versions:  -Python 3.4
Added file: http://bugs.python.org/file42796/ctypes_util_popen-3.py3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22636>
_______________________________________

From report at bugs.python.org  Tue May 10 08:42:43 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 10 May 2016 12:42:43 +0000
Subject: [issue22636] avoid using a shell in ctypes.util: replace os.popen
 with subprocess
In-Reply-To: <1413325975.89.0.175884398711.issue22636@psf.upfronthosting.co.za>
Message-ID: <1462884163.73.0.407528192782.issue22636@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is a possible patch for Python 2. One snag is that ctypes is currently supposed to be compatible with Python 2.3, but subprocess was added in 2.4. The patch assumes it is okay to lift that compatibility restriction.

The main differences are:

* shutil.which() does not exist in Python 2. In _findLib_gcc() and the Gnu version of _get_soname(), I restored the mini shell script that runs ?type? to check if commands are available. However I pass the library and file names as proper arguments, rather than inserting them into the shell syntax.

* subprocess.DEVNULL does not exist. Manually opened os.devnull where necessary.

* There was an extra Popen conversion for the Gnu ?ldconfig -p? call. In Python 3, this was already converted thanks to revision 19d9f0a177de (Issue 11258).

* No context manager support for Popen objects. Instead, use communicate() where appropriate, or manually close and wait.

Again, I tested the Python 2 patch on Linux, but with mock platform-specific commands to exercise each new Popen() call.

----------
Added file: http://bugs.python.org/file42797/ctypes_util_popen-3.py2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22636>
_______________________________________

From report at bugs.python.org  Tue May 10 08:51:38 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 10 May 2016 12:51:38 +0000
Subject: [issue22636] avoid using a shell in ctypes.util: replace os.popen
 with subprocess
In-Reply-To: <1413325975.89.0.175884398711.issue22636@psf.upfronthosting.co.za>
Message-ID: <1462884698.27.0.818951744092.issue22636@psf.upfronthosting.co.za>


Martin Panter added the comment:

Uploading the fake commands I used for testing.

----------
Added file: http://bugs.python.org/file42798/dump

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22636>
_______________________________________

From report at bugs.python.org  Tue May 10 08:53:22 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 10 May 2016 12:53:22 +0000
Subject: [issue22636] avoid using a shell in ctypes.util: replace os.popen
 with subprocess
In-Reply-To: <1413325975.89.0.175884398711.issue22636@psf.upfronthosting.co.za>
Message-ID: <1462884802.01.0.0538784554695.issue22636@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


Added file: http://bugs.python.org/file42799/ldconfig

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22636>
_______________________________________

From report at bugs.python.org  Tue May 10 08:54:10 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 10 May 2016 12:54:10 +0000
Subject: [issue22636] avoid using a shell in ctypes.util: replace os.popen
 with subprocess
In-Reply-To: <1413325975.89.0.175884398711.issue22636@psf.upfronthosting.co.za>
Message-ID: <1462884850.54.0.756021373216.issue22636@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


Added file: http://bugs.python.org/file42800/crle

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22636>
_______________________________________

From report at bugs.python.org  Tue May 10 09:05:16 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 10 May 2016 13:05:16 +0000
Subject: [issue6338] Error message displayed on stderr when no C compiler is
 present with ctypes
In-Reply-To: <1245877709.89.0.124582375066.issue6338@psf.upfronthosting.co.za>
Message-ID: <1462885516.39.0.759913729392.issue6338@psf.upfronthosting.co.za>


Martin Panter added the comment:

I presume the problem is that Free BSD?s ?type? command outputs the error to the shell?s original stderr, rather than the one given on the ?type? command line. If so, the Python 3 patches for Issue 22636 should avoid it by using shutil.which() instead.

However that function does not exist in Python 2, so a different solution needs to be found. Probably an improved version of Eric?s patch would be good.

----------
dependencies: +avoid using a shell in ctypes.util: replace os.popen with subprocess
stage: patch review -> needs patch
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6338>
_______________________________________

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: [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 10:15:43 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 10 May 2016 14:15:43 +0000
Subject: [issue26992] 64-bit Python 2.7.11 hangs in 64-bit Windows 10 - CMD
 and Git Bash
In-Reply-To: <1462886435.44.0.374942055679.issue26992@psf.upfronthosting.co.za>
Message-ID: <1462889743.08.0.912115552963.issue26992@psf.upfronthosting.co.za>


R. David Murray added the comment:

Is there any way you can attach a debugger to the process and see what it is doing or where it is stuck?  Otherwise, unless someone else can reproduce this, I don't think there is much we can do with this bug report.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26992>
_______________________________________

From report at bugs.python.org  Tue May 10 10:42:33 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 May 2016 14:42:33 +0000
Subject: [issue26925] android: test_multiprocessing_main_handling fails
In-Reply-To: <1462283212.06.0.365791110432.issue26925@psf.upfronthosting.co.za>
Message-ID: <1462891353.28.0.46435386323.issue26925@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Closing as duplicate of #26924.

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26925>
_______________________________________

From report at bugs.python.org  Tue May 10 10:47:34 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 May 2016 14:47:34 +0000
Subject: [issue26935] android: test_os fails
In-Reply-To: <1462287800.22.0.0769666286965.issue26935@psf.upfronthosting.co.za>
Message-ID: <1462891654.63.0.293289608155.issue26935@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

This is fixed at API 23 (Android 6.0) and test_os runs on an android-23-x86 emulator without failures.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26935>
_______________________________________

From report at bugs.python.org  Tue May 10 10:52:20 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 May 2016 14:52:20 +0000
Subject: [issue26936] android: test_socket fails
In-Reply-To: <1462288246.37.0.495121419926.issue26936@psf.upfronthosting.co.za>
Message-ID: <1462891940.04.0.0515153465938.issue26936@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

testGetaddrinfo does not fail anymore on an emulator running an android-23-x86, i.e. Android 6.0 or API 23.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26936>
_______________________________________

From report at bugs.python.org  Tue May 10 11:09:27 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Tue, 10 May 2016 15:09:27 +0000
Subject: [issue26944] android: test_posix fails
In-Reply-To: <1462348873.26.0.373017977506.issue26944@psf.upfronthosting.co.za>
Message-ID: <1462892967.12.0.755423852459.issue26944@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

'id -G' produces the expected result on an android-23-x86 emulator running Android 6.0 (API 23).

There is a new error now instead of the one reported at issue #26932:

======================================================================
FAIL: test_getgroups (test.test_posix.PosixTester)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/sdcard/org.bitbucket.pyona/lib/python3.6/test/test_posix.py", line 816, in test_getgroups
    set(posix.getgroups() + [posix.getegid()]))
AssertionError: Items in the second set but not the first:
0


The problem is that posix.getegid() returns 0, and 0 is not in the list printed by 'id -G'.

----------
nosy: +Chi Hsuan Yen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26944>
_______________________________________

From report at bugs.python.org  Tue May 10 11:10:35 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 10 May 2016 15:10:35 +0000
Subject: [issue26991] Possible reference leak in MAKE_FUNCTION
In-Reply-To: <1462878017.45.0.401291205212.issue26991@psf.upfronthosting.co.za>
Message-ID: <1462893035.72.0.683894413856.issue26991@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

I'm willing to. But I don't know where is the suitable place to put such a test and since the reference leak only appears in error case, can compile a function with annotations in a loop accomplish the test goal?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26991>
_______________________________________

From report at bugs.python.org  Tue May 10 12:06:01 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 10 May 2016 16:06:01 +0000
Subject: [issue26925] android: test_multiprocessing_main_handling fails
In-Reply-To: <1462283212.06.0.365791110432.issue26925@psf.upfronthosting.co.za>
Message-ID: <1462896361.92.0.759115800122.issue26925@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
stage:  -> resolved
superseder:  -> android: test_concurrent_futures fails

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26925>
_______________________________________

From report at bugs.python.org  Tue May 10 12:26:50 2016
From: report at bugs.python.org (John Mark Vandenberg)
Date: Tue, 10 May 2016 16:26:50 +0000
Subject: [issue26632] __all__ decorator
In-Reply-To: <1458786797.31.0.0749407715279.issue26632@psf.upfronthosting.co.za>
Message-ID: <1462897610.71.0.775773319875.issue26632@psf.upfronthosting.co.za>


Changes by John Mark Vandenberg <jayvdb at gmail.com>:


----------
nosy: +jayvdb

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26632>
_______________________________________

From report at bugs.python.org  Tue May 10 12:27:57 2016
From: report at bugs.python.org (John Mark Vandenberg)
Date: Tue, 10 May 2016 16:27:57 +0000
Subject: [issue22247] More incomplete module.__all__ lists
In-Reply-To: <1408675368.08.0.766854982306.issue22247@psf.upfronthosting.co.za>
Message-ID: <1462897677.64.0.681230434128.issue22247@psf.upfronthosting.co.za>


Changes by John Mark Vandenberg <jayvdb at gmail.com>:


----------
nosy: +jayvdb

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22247>
_______________________________________

From report at bugs.python.org  Tue May 10 13:44:09 2016
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 10 May 2016 17:44:09 +0000
Subject: [issue14209] pkgutil.iter_zipimport_modules ignores the prefix
 parameter for packages
In-Reply-To: <1331046144.89.0.833633660995.issue14209@psf.upfronthosting.co.za>
Message-ID: <1462902249.87.0.25259749914.issue14209@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee:  -> lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14209>
_______________________________________

From report at bugs.python.org  Tue May 10 14:25:14 2016
From: report at bugs.python.org (Michael Felt)
Date: Tue, 10 May 2016 18:25:14 +0000
Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not
 available (e.g., AIX)
In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za>
Message-ID: <1462904714.79.0.750970267143.issue26439@psf.upfronthosting.co.za>


Michael Felt added the comment:

Spent more time today, testing - on 3.5.1, 3.4.4 and 2.7.11.

The patches would not apply on both Python2 and Python3, but the new file Lib/ctypes/aixutil.py is identical on all three versions.

History of patching (starting from version 3.5.1(.1) is my patched version (as are Python-3.4.4.1 and Python-2.7.11.4)

michael at x071:[/data/prj/aixtools/python/python-3.4.4.1]for i in ../*patches/*patch^Jdo^Jcat $i | patch -p1 ^Jdone
patching file Lib/ctypes/__init__.py
Hunk #1 succeeded at 341 (offset 4 lines).
patching file Lib/ctypes/test/test_loading.py
patching file Lib/ctypes/util.py
Hunk #1 succeeded at 70 (offset -6 lines).
Hunk #2 succeeded at 256 (offset -6 lines).
Hunk #3 succeeded at 275 (offset -6 lines).
patching file Modules/_ctypes/_ctypes.c
Hunk #1 succeeded at 5508 (offset -1 lines).
michael at x071:[/data/prj/aixtools/python/python-3.4.4.1]

But, not with 2.7.11

michael at x071:[/data/prj/aixtools/python/python-2.7.11.4]for i in ../*patches/*patch^Jdo^Jcat $i | patch -p1 --dry-run^Jdone
patching file Lib/ctypes/__init__.py
Hunk #1 succeeded at 355 (offset 18 lines).
patching file Lib/ctypes/test/test_loading.py
Hunk #1 succeeded at 38 (offset -5 lines).
patching file Lib/ctypes/util.py
Hunk #1 succeeded at 71 (offset -5 lines).
Hunk #2 FAILED at 262.
Hunk #3 FAILED at 274.
2 out of 3 hunks FAILED -- saving rejects to file Lib/ctypes/util.py.rej
patching file Modules/_ctypes/_ctypes.c
Hunk #1 FAILED at 5509.
1 out of 1 hunk FAILED -- saving rejects to file Modules/_ctypes/_ctypes.c.rej

So, I made new patches against 2.7.11 after patching manually.

After the builds:

==============================
aixtools.python:aixtools.python.man.en_US:2.7.11.4::I:T:::::N:man pages::::0::
aixtools.python:aixtools.python.rte:2.7.11.4::I:T:::::N:built 10-May-2016 1810 UTC::::0::
==============================
root at x064:[/data/prj/aixtools/python/python-2.7.11.4]cd Lib/ctypes
root at x064:[/data/prj/aixtools/python/python-2.7.11.4/Lib/ctypes]../../python util.py
None
libc.a(shr.o)
libbz2.a(libbz2.so)
('aix.find_library("libiconv.so")', 'libiconv.a(shr4.o)')
('aix.find_library("libintl.so")', 'libintl.a(libintl.so.1)')
('aix.find_library("libintl.so.1")', 'libintl.a(libintl.so.1)')
('aix.find_library("libintl.so.2")', None, ':: should be None!')
('aix.find_library("libintl.so.8")', None)
<CDLL 'libc.a(shr.o)', handle c at 300e5810>
<CDLL 'libintl.a(libintl.so.1)', handle d at 300e5810>
<CDLL 'libcrypt.a(shr.o)', handle e at 300e5810>
libcrypt.a(shr.o)
root at x064:[/data/prj/aixtools/python/python-2.7.11.4/Lib/ctypes]../../python test/test_loading.py
libc_name is libc.a(shr.o)
ss..sss
----------------------------------------------------------------------
Ran 7 tests in 0.189s

OK (skipped=5)

==============================
aixtools.python:aixtools.python.man.en_US:3.4.4.1::I:T:::::N:man pages::::0::
aixtools.python:aixtools.python.rte:3.4.4.1::I:T:::::N:built 10-May-2016 1812 UTC::::0::
==============================
root at x064:[/data/prj/aixtools/python/python-3.4.4.1]cd Lib/ctypes
root at x064:[/data/prj/aixtools/python/python-3.4.4.1/Lib/ctypes]../../python util.py
None
libc.a(shr.o)
libbz2.a(libbz2.so)
aix.find_library("libiconv.so") libiconv.a(shr4.o)
aix.find_library("libintl.so") libintl.a(libintl.so.1)
aix.find_library("libintl.so.1") libintl.a(libintl.so.1)
aix.find_library("libintl.so.2") None :: should be None!
aix.find_library("libintl.so.8") None
<CDLL 'libc.a(shr.o)', handle b at 300e7250>
<CDLL 'libintl.a(libintl.so.1)', handle c at 300e7250>
<CDLL 'libcrypt.a(shr.o)', handle d at 300e7250>
libcrypt.a(shr.o)
root at x064:[/data/prj/aixtools/python/python-3.4.4.1/Lib/ctypes]../../python test/test_loading.py
libc_name is libc.a(shr.o)
ss..sss
----------------------------------------------------------------------
Ran 7 tests in 0.323s

OK (skipped=5)

root at x064:[/data/prj/aixtools/python/python-3.5.1.1]installp -d . -L
aixtools.python:aixtools.python.man.en_US:3.5.1.0::I:T:::::N:man pages::::0::
aixtools.python:aixtools.python.man.en_US:3.5.1.1::I:T:::::N:man pages::::0::
aixtools.python:aixtools.python.rte:3.5.1.0::I:T:::::N:built 03-Mar-2016 0856 UTC::::0::
aixtools.python:aixtools.python.rte:3.5.1.1::I:T:::::N:built 10-May-2016 1620 UTC::::0::

And, with a 64-bit build

root at x064:[/data/prj/aixtools/python/python-3.5.1.1]installp -d . -L
aixtools.python:aixtools.python.man.en_US:3.5.1.0::I:T:::::N:man pages::::0::
aixtools.python:aixtools.python.man.en_US:3.5.1.1::I:T:::::N:man pages::::0::
aixtools.python:aixtools.python.rte:3.5.1.0::I:T:::::N:built 03-Mar-2016 0856 UTC::::0::
aixtools.python:aixtools.python.rte:3.5.1.1::I:T:::::N:built 10-May-2016 1620 UTC::::0::
root at x064:[/data/prj/aixtools/python/python-3.5.1.1]cd lib/ctypes
ksh: lib/ctypes:  not found.
root at x064:[/data/prj/aixtools/python/python-3.5.1.1]cd Lib/ctypes
root at x064:[/data/prj/aixtools/python/python-3.5.1.1/Lib/ctypes]../../python util.py
None
libc.a(shr_64.o)
None
aix.find_library("libiconv.so") libiconv.a(shr4_64.o)
aix.find_library("libintl.so") libintl.a(libintl.so.1)
aix.find_library("libintl.so.1") libintl.a(libintl.so.1)
aix.find_library("libintl.so.2") None :: should be None!
aix.find_library("libintl.so.8") None
<CDLL 'libc.a(shr_64.o)', handle a at 0x7000000001c79e8>
<CDLL 'libintl.a(libintl.so.1)', handle b at 0x7000000001c79e8>
<CDLL 'libcrypt.a(shr_64.o)', handle c at 0x7000000001c79e8>
libcrypt.a(shr_64.o)
root at x064:[/data/prj/aixtools/python/python-3.5.1.1/Lib/ctypes]../../python test/test_loading.py
libc_name is libc.a(shr_64.o)
ss..sss
----------------------------------------------------------------------
Ran 7 tests in 0.414s

OK (skipped=5)

Patches follow (question, should these be in a tar file in the future?)

----------
versions: +Python 3.4
Added file: http://bugs.python.org/file42801/PythonX.Lib.ctypes.aixutil.py.160510

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26439>
_______________________________________

From report at bugs.python.org  Tue May 10 14:25:46 2016
From: report at bugs.python.org (Michael Felt)
Date: Tue, 10 May 2016 18:25:46 +0000
Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not
 available (e.g., AIX)
In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za>
Message-ID: <1462904746.51.0.708758584385.issue26439@psf.upfronthosting.co.za>


Changes by Michael Felt <aixtools at gmail.com>:


Added file: http://bugs.python.org/file42802/Python2.Lib.ctypes.160510.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26439>
_______________________________________

From report at bugs.python.org  Tue May 10 14:27:50 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 10 May 2016 18:27:50 +0000
Subject: [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:29:10 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 10 May 2016 18:29:10 +0000
Subject: [issue24225] Idlelib: changing file names
In-Reply-To: <1431934587.56.0.38760352205.issue24225@psf.upfronthosting.co.za>
Message-ID: <1462904950.04.0.107834757177.issue24225@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Alternate proposal is #26993.

----------
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24225>
_______________________________________

From report at bugs.python.org  Tue May 10 14:29:35 2016
From: report at bugs.python.org (Michael Felt)
Date: Tue, 10 May 2016 18:29:35 +0000
Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not
 available (e.g., AIX)
In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za>
Message-ID: <1462904975.57.0.00072336976151.issue26439@psf.upfronthosting.co.za>


Changes by Michael Felt <aixtools at gmail.com>:


Added file: http://bugs.python.org/file42803/Python2.Modules._ctypes.160510.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26439>
_______________________________________

From report at bugs.python.org  Tue May 10 14:30:22 2016
From: report at bugs.python.org (Michael Felt)
Date: Tue, 10 May 2016 18:30:22 +0000
Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not
 available (e.g., AIX)
In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za>
Message-ID: <1462905022.0.0.819300695925.issue26439@psf.upfronthosting.co.za>


Changes by Michael Felt <aixtools at gmail.com>:


Added file: http://bugs.python.org/file42804/Python3.Lib.ctypes.160510.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26439>
_______________________________________

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: [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:30:49 2016
From: report at bugs.python.org (Michael Felt)
Date: Tue, 10 May 2016 18:30:49 +0000
Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not
 available (e.g., AIX)
In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za>
Message-ID: <1462905049.87.0.541404675828.issue26439@psf.upfronthosting.co.za>


Changes by Michael Felt <aixtools at gmail.com>:


Added file: http://bugs.python.org/file42805/Python3.Modules._ctypes.160510.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26439>
_______________________________________

From report at bugs.python.org  Tue May 10 14:37:48 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 10 May 2016 18:37:48 +0000
Subject: [issue26994] unexpected behavior for booleans in argparse
In-Reply-To: <1462905029.96.0.678738443976.issue26994@psf.upfronthosting.co.za>
Message-ID: <1462905468.28.0.174618008688.issue26994@psf.upfronthosting.co.za>


R. David Murray added the comment:

type=bool doesn't do what you think it does.  It does 'bool(value)', and 'bool("False")' is True, since "False" is a non-empty string.

See issue 21208 for some further discussion.

----------
nosy: +r.david.murray
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Change default behavior of arguments with type bool when options are specified

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26994>
_______________________________________

From report at bugs.python.org  Tue May 10 14:45:20 2016
From: report at bugs.python.org (Ilya Kulakov)
Date: Tue, 10 May 2016 18:45:20 +0000
Subject: [issue26969] ascynio should provide a policy to address
 pass-loop-everywhere problem
In-Reply-To: <1462517538.3.0.176027238089.issue26969@psf.upfronthosting.co.za>
Message-ID: <1462905920.86.0.934859266417.issue26969@psf.upfronthosting.co.za>


Ilya Kulakov added the comment:

Yury, could you submit a patch implements this feature?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26969>
_______________________________________

From report at bugs.python.org  Tue May 10 14:55:22 2016
From: report at bugs.python.org (Nathan Naze)
Date: Tue, 10 May 2016 18:55:22 +0000
Subject: [issue26994] unexpected behavior for booleans in argparse
In-Reply-To: <1462905029.96.0.678738443976.issue26994@psf.upfronthosting.co.za>
Message-ID: <1462906522.76.0.10265284981.issue26994@psf.upfronthosting.co.za>


Nathan Naze added the comment:

> It does 'bool(value)', and 'bool("False")' is True, since "False" is a non-empty string.

Yes, I understand this. It's fine to mark as "working as intended", but coming from other flag-parsing libraries, I find the behavior unintuitive and do not understand the utility of accepting arbitrary strings given the  potential for user confusion. We uncovered this behavior debugging a script used internally at Google.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26994>
_______________________________________

From report at bugs.python.org  Tue May 10 14:56:15 2016
From: report at bugs.python.org (Nathan Naze)
Date: Tue, 10 May 2016 18:56:15 +0000
Subject: [issue26994] unexpected behavior for booleans in argparse
In-Reply-To: <1462905029.96.0.678738443976.issue26994@psf.upfronthosting.co.za>
Message-ID: <1462906575.87.0.797339612574.issue26994@psf.upfronthosting.co.za>


Nathan Naze added the comment:

I also buy the argument that changing the behavior now would be problematic given the existing usages in the wild.

----------

_______________________________________
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: [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 14:59:45 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 10 May 2016 18:59:45 +0000
Subject: [issue26969] ascynio should provide a policy to address
 pass-loop-everywhere problem
In-Reply-To: <1462517538.3.0.176027238089.issue26969@psf.upfronthosting.co.za>
Message-ID: <1462906785.76.0.270286585423.issue26969@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> Yury, could you submit a patch implements this feature?

Yes, the patch part is easy. The hard part is to get a green light from Guido on adding the 'get_running_loop()' function...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26969>
_______________________________________

From report at bugs.python.org  Tue May 10 15:01:24 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 10 May 2016 19:01:24 +0000
Subject: [issue26969] ascynio should provide a policy to address
 pass-loop-everywhere problem
In-Reply-To: <1462906785.76.0.270286585423.issue26969@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJL++SyXoGDhKUFMQovzwqnMGV-ShqmjWc0K=7PspfOrVg@mail.gmail.com>


Guido van Rossum added the comment:

Still no green light. Ilya just seems to want something misguided.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26969>
_______________________________________

From report at bugs.python.org  Tue May 10 15:06:42 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 10 May 2016 19:06:42 +0000
Subject: [issue26969] ascynio should provide a policy to address
 pass-loop-everywhere problem
In-Reply-To: <1462517538.3.0.176027238089.issue26969@psf.upfronthosting.co.za>
Message-ID: <1462907202.81.0.776178147752.issue26969@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Ilya, at this point I'd suggest you to craft a very clear and simple to digest email to python-ideas describing 'get_running_loop()', how it can be used, your case, other cases, etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26969>
_______________________________________

From report at bugs.python.org  Tue May 10 15:07:34 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 10 May 2016 19:07:34 +0000
Subject: [issue15786] IDLE code completion window can hang or misbehave with
 mouse
In-Reply-To: <1346027701.33.0.908436854594.issue15786@psf.upfronthosting.co.za>
Message-ID: <1462907254.71.0.300614044523.issue15786@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Suddha: Someone has to write a currently failing test and a patch that makes it pass without breaking anything else.  I cannot currently test this issue and therefore cannot currently patch it.  AutoComplete has numerous other issues that I can test.  About a month ago, I reviewed the code with an eye to fixing them.  I decided what I implied above, which is that I should not do anything until I can freely modify the code.  I just filed #26993 to make that possible.

Paul: For testing CPython in general, see https://docs.python.org/devguide/, chapter 4 and 5 (and the unittest docs).  For testing IDLE, see test/test_idle and idlelib/idle_test, in particular README and htest.py.  The latter is specific to IDLE.  If #26993 is approved, we will need LOTS of new tests for IDLE, as I want to properly follow the *written* failing test, write patch, passing test paradigm.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15786>
_______________________________________

From report at bugs.python.org  Tue May 10 15:07:54 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 10 May 2016 19:07:54 +0000
Subject: [issue26969] ascynio should provide a policy to address
 pass-loop-everywhere problem
In-Reply-To: <1462907202.81.0.776178147752.issue26969@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJL-Xu0Rn12=sqeKCE_XB+jMW+qFX1B4f_3DJQ19cLFpgQ@mail.gmail.com>


Guido van Rossum added the comment:

Yury, what do you think of this yourself? Maybe you can explain it better
than Ilya?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26969>
_______________________________________

From report at bugs.python.org  Tue May 10 15:08:27 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 10 May 2016 19:08:27 +0000
Subject: [issue26983] float() can return not exact float instance
In-Reply-To: <1462801593.23.0.789372695786.issue26983@psf.upfronthosting.co.za>
Message-ID: <1462907307.41.0.0196761530648.issue26983@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Proposed patch makes float() always returning exact float.

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file42807/float_exact.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26983>
_______________________________________

From report at bugs.python.org  Tue May 10 15:10:52 2016
From: report at bugs.python.org (Ilya Kulakov)
Date: Tue, 10 May 2016 19:10:52 +0000
Subject: [issue26969] ascynio should provide a policy to address
 pass-loop-everywhere problem
In-Reply-To: <1462517538.3.0.176027238089.issue26969@psf.upfronthosting.co.za>
Message-ID: <1462907452.96.0.716972213377.issue26969@psf.upfronthosting.co.za>


Ilya Kulakov added the comment:

Yury, we're building our own CPython anyway (and we just updated to 3.5.1). I'd be glad to test the patch during the next iteration.

Guido, I think my use case mixes up other things I find confusing about asyncio: e.g. inablitity to synchronously perform code written as standalone coroutine. It deserves its own task and discussion.

The purpose of this request is that access to a running loop is handy within coroutine. It's already there, since coroutine is executed within its context. However, instead of "self" library provides API to only access some globally default loop.

Python does not require a user to pass self whenever instance methods needs to be called. I consider relationship between event loop and awaitables alike.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26969>
_______________________________________

From report at bugs.python.org  Tue May 10 15:57:49 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 10 May 2016 19:57:49 +0000
Subject: [issue26969] ascynio should provide a policy to address
 pass-loop-everywhere problem
In-Reply-To: <1462907452.96.0.716972213377.issue26969@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJLARczB=sjtV5xgO+n1MtaJzk315ReSM0ct8OkU_JzgLQ@mail.gmail.com>


Guido van Rossum added the comment:

As long as there are still things you find confusing about asyncio's model,
you should probably consider yourself unqualified to start proposing new
features...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26969>
_______________________________________

From report at bugs.python.org  Tue May 10 16:15:41 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 10 May 2016 20:15:41 +0000
Subject: [issue26969] ascynio should provide a policy to address
 pass-loop-everywhere problem
In-Reply-To: <1462517538.3.0.176027238089.issue26969@psf.upfronthosting.co.za>
Message-ID: <1462911341.19.0.195312475835.issue26969@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> Yury, what do you think of this yourself? Maybe you can explain it better
than Ilya?

TBH, I don't fully understand Ilya's case with threads, synchronous coroutines, possible deadlocks etc.  So I'll just explain what I would want out of this.

I don't like a few aspects of the current design of 'get_event_loop'.  Mainly because it creates an event loop implicitly, or it can just fail with a RuntimeError under some conditions.  When one has a few event loops, implicitly called 'get_event_loop' from Future and other asyncio functions won't work correctly.  IMO, this is something that we at least should try to fix (even though it's not an idiomatic use case for asyncio).

I now think that we don't need a new function for getting the currently running event loop.  Instead we can try to improve the `get_event_loop()` function a little.

The core idea is to add a thread-local object `running_loop`, which will point to the currently running event loop in the current thread.  And `Loop._run` method will set/reset a reference to the loop to `running_loop`.

`get_event_loop()` will then try to use the `running_loop` object first, and if nothing is there, fall back to its current implementation.

Now, this is a point where everything becomes complicated. To quote myself,--"Yes, the patch part is easy",--I don't think it is that easy anymore ;)

Currently, event loops are decoupled from policies.  This means that we can't make loops to use some hidden shared thread-local object (`running_loop`) that policies and loops will work with.  There has to be another new public policy APIs that loops will use, for instance: 'set_running_event_loop()'.  This won't be the first case of event loop policy APIs being called from event loops -- another example is the `get_child_watcher` method.

With this new method, `Loop._run` will then look like this:

  def _run(self):
      policy = get_event_loop_policy()
      policy.set_running_event_loop(self)
      try:
         ... # current Loop._run implementation
      finally:
          policy.set_running_event_loop(None)

`policy.set_running_event_loop` call would raise a RuntimeError if it's called if another event loop is currently running.

And the `get_event_loop()` function will look like this:

  def get_event_loop():
      policy = get_event_loop_policy()
      loop = policy._get_running_event_loop()
      if loop is not None:
          return loop
      # ... current get_event_loop implementation

So it all boils down to:

1. Adding a new policy API 'set_running_event_loop'.

2. Updating 'get_event_loop' to return the currently running event loop if it's available, or else resorting to its current behaviour.

With this change it will be completely safe to use "get_event_loop" from running coroutines or just about any code that runs in a context of an event loop.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26969>
_______________________________________

From report at bugs.python.org  Tue May 10 16:22:05 2016
From: report at bugs.python.org (Ilya Kulakov)
Date: Tue, 10 May 2016 20:22:05 +0000
Subject: [issue26969] ascynio should provide a policy to address
 pass-loop-everywhere problem
In-Reply-To: <1462517538.3.0.176027238089.issue26969@psf.upfronthosting.co.za>
Message-ID: <1462911725.22.0.762297259165.issue26969@psf.upfronthosting.co.za>


Ilya Kulakov added the comment:

> TBH, I don't fully understand Ilya's case with threads, synchronous coroutines, possible deadlocks etc.

I feel sorry for sharing that example. It didn't help and made my points regarding original issue unclear, hidden behind example's complexity.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26969>
_______________________________________

From report at bugs.python.org  Tue May 10 16:36:53 2016
From: report at bugs.python.org (Ilya Kulakov)
Date: Tue, 10 May 2016 20:36:53 +0000
Subject: [issue26969] ascynio should provide a policy to address
 pass-loop-everywhere problem
In-Reply-To: <1462517538.3.0.176027238089.issue26969@psf.upfronthosting.co.za>
Message-ID: <1462912613.23.0.123388726572.issue26969@psf.upfronthosting.co.za>


Ilya Kulakov added the comment:

Yury,

> I now think that we don't need a new function for getting the currently running event loop.

May I ask you to elaborate on this? Asynchronous API I'm aware of (including  other languages) typically allows to get "main" (which in asyncio is lazily created for main thread only), and "current". Sometimes there is also a convenient "global" which can be used when you want to do some async work outside. E.g. take a look at public API of Apple's Grand Central Dispatch, specifically `dispatch_get_current_queue`.

Even Python's thread module allows to get "current_thread" instead of passing it into run callback and requiring a user to carry it around by hand.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26969>
_______________________________________

From report at bugs.python.org  Tue May 10 16:42:46 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 10 May 2016 20:42:46 +0000
Subject: [issue26969] ascynio should provide a policy to address
 pass-loop-everywhere problem
In-Reply-To: <1462517538.3.0.176027238089.issue26969@psf.upfronthosting.co.za>
Message-ID: <1462912966.18.0.114941347502.issue26969@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

>> I now think that we don't need a new function for getting the currently running event loop.

> May I ask you to elaborate on this?

In my last message I propose to modify 'get_event_loop' to return the running loop reliably.  To me this is to me the most important thing -- this will make things like Task.current more reliable.

Adding another function (get_running_loop) won't change much. It would have a slightly different behaviour, but likely it won't be used anywhere in asyncio, or other libraries.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26969>
_______________________________________

From report at bugs.python.org  Tue May 10 16:50:53 2016
From: report at bugs.python.org (Ilya Kulakov)
Date: Tue, 10 May 2016 20:50:53 +0000
Subject: [issue26969] ascynio should provide a policy to address
 pass-loop-everywhere problem
In-Reply-To: <1462517538.3.0.176027238089.issue26969@psf.upfronthosting.co.za>
Message-ID: <1462913453.1.0.794502301342.issue26969@psf.upfronthosting.co.za>


Ilya Kulakov added the comment:

Yury, 

> `get_event_loop()` will then try to use the `running_loop` object first, and if nothing is there, fall back to its current implementation.

Do you think hiding "default" event loop completly from a currently executing coroutine is safe?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26969>
_______________________________________

From report at bugs.python.org  Tue May 10 16:52:52 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 10 May 2016 20:52:52 +0000
Subject: [issue26969] ascynio should provide a policy to address
 pass-loop-everywhere problem
In-Reply-To: <1462517538.3.0.176027238089.issue26969@psf.upfronthosting.co.za>
Message-ID: <1462913572.61.0.778657918411.issue26969@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> Do you think hiding "default" event loop completly from a currently executing coroutine is safe?

Not sure I understand the question.  Anyways, let's see what Guido thinks about this all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26969>
_______________________________________

From report at bugs.python.org  Tue May 10 16:56:21 2016
From: report at bugs.python.org (Ilya Kulakov)
Date: Tue, 10 May 2016 20:56:21 +0000
Subject: [issue26969] ascynio should provide a policy to address
 pass-loop-everywhere problem
In-Reply-To: <1462517538.3.0.176027238089.issue26969@psf.upfronthosting.co.za>
Message-ID: <1462913781.98.0.277368565225.issue26969@psf.upfronthosting.co.za>


Ilya Kulakov added the comment:

Yury,

> Not sure I understand the question.

If I understood it correctly, get_event_loop() would never return "default" event loop (in terms of current implementation) for a running task, because it always be overridden with "running" event loop. If it's so, are you sure it won't raise any problems with backward compatibility?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26969>
_______________________________________

From report at bugs.python.org  Tue May 10 16:59:59 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 10 May 2016 20:59:59 +0000
Subject: [issue26969] ascynio should provide a policy to address
 pass-loop-everywhere problem
In-Reply-To: <1462517538.3.0.176027238089.issue26969@psf.upfronthosting.co.za>
Message-ID: <1462913999.67.0.230418751336.issue26969@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> If I understood it correctly, get_event_loop() would never return "default" event loop (in terms of current implementation) for a running task, because it always be overridden with "running" event loop. If it's so, are you sure it won't raise any problems with backward compatibility?

I think this is extremely unlikely.  I hope that there is not much code out there that relies on this behaviour.  But you have a point.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26969>
_______________________________________

From report at bugs.python.org  Tue May 10 17:25:51 2016
From: report at bugs.python.org (aixtools)
Date: Tue, 10 May 2016 21:25:51 +0000
Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not
 available (e.g., AIX)
In-Reply-To: <1462688973.52.0.610199997209.issue26439@psf.upfronthosting.co.za>
Message-ID: <ed2cd255-1465-f4bf-2576-c7b5393d8eb3@gmail.com>


aixtools added the comment:

On 5/8/2016 8:29 AM, Martin Panter wrote:
> Martin Panter added the comment:
>
> Your new patch calls find_library() internally in CDLL(); why?
Because arguments that work for GNU (aka Linux, even though internally 
it is called "posix") will not work for AIX.
> My understanding is CDLL() is a fairly lightweight wrapper around the dlopen() call.
For AIX, the dlopen() call is a front-end for the function 
initAndLoad(). I have not looked in depth at Module/_ctypes (only 
recently found it) and I do not know how much work is being done there 
for the different platforms.
> On Linux, you either pass a full library file name, or an SO-name.
Same for AIX: a full-path library name, relative-path library name, or a 
library name and the library search path (with optional additional 
directories provided via environment variables (LIBPATH or 
LD_LIBRARY_PATH - when it is a FILE, or an archive(member_name) (with 
archive part being full or relative, or stem) and RTLD_MEMBER ORed into 
the mode argument.
> Both these strings can be discovered for compiled objects using e.g.:
Likewise for AIX: - example: an executable - notice how many are named 
shr.o: how is cdll("shr.o") suppossed to know it is libc, or is it libcrypt?

root at x064:[/usr/lib]ldd /usr/sbin/sshd
/usr/sbin/sshd needs:
          /usr/lib/libc.a(shr.o)
          /usr/lib/libcrypto.a(libcrypto.so.1.0.0)
          /usr/lib/libz.a(libz.so.1)
          /usr/lib/libpam.a(shr.o)
          /usr/lib/libdl.a(shr.o)
          /unix
          /usr/lib/libcrypt.a(shr.o)
          /usr/lib/libpthreads.a(shr_xpg5.o)
          /usr/lib/libpthreads.a(shr_comm.o)

Or a file:
./perl-5.14.4/lib/5.14.4/aix-thread-multi-64int/auto/B/B.so needs:
          /usr/lib/libpthreads.a(shr_xpg5.o)
          /usr/lib/libc.a(shr.o)
          /unix
          /usr/lib/libpthreads.a(shr_comm.o)
          /usr/lib/libcrypt.a(shr.o)

Again, cdll("shr.o") is not going to find the correct archive.
> $ ldd build/lib.linux-x86_64-2.7-pydebug/_ssl.so
> 	linux-vdso.so.1 (0x00007fff567fe000)
> 	libssl.so.1.0.0 => /usr/lib/libssl.so.1.0.0 (0x00007f598474c000)
> 	libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0x00007f59842d4000)
> 	. . .
>
> So in Python, the SO-name or full path can be used, but not the compile-time name, unless you first pass it through find_library():

>>>> CDLL("libcrypto.so.1.0.0")  # soname
> <CDLL 'libcrypto.so.1.0.0', handle 7f1665e1eb90 at 7f16658f34d0>
>>>> CDLL("/usr/lib/libcrypto.so.1.0.0")  # Full path
> <CDLL '/usr/lib/libcrypto.so.1.0.0', handle 7f1665e1eb90 at 7f1663cddcd0>
>>>> CDLL("crypto")  # Compile-time name
> Traceback (most recent call last):
>    File "<stdin>", line 1, in <module>
>    File "/usr/lib/python2.7/ctypes/__init__.py", line 365, in __init__
>      self._handle = _dlopen(self._name, mode)
> OSError: crypto: cannot open shared object file: No such file or directory
>>>> find_library("crypto")  # Some people pass the result of this to CDLL()
> 'libcrypto.so.1.0.0'
Thank you for the explanation of what should be used when. Maybe I 
worked too hard for the current result: (note - 64-bit this time! and 
new member names, even for libc.so)

michael at x071:[/usr/lib]python -m ctypes.util
None
libc.a(shr_64.o)
None
aix.find_library("libiconv.so") libiconv.a(shr4_64.o)
aix.find_library("libintl.so") libintl.a(libintl.so.1)
aix.find_library("libintl.so.1") libintl.a(libintl.so.1)
aix.find_library("libintl.so.2") None :: should be None!
aix.find_library("libintl.so.8") None
<CDLL 'libc.a(shr_64.o)', handle a at 0x7000000002242b0>
<CDLL 'libintl.a(libintl.so.1)', handle b at 0x7000000002242b0>
<CDLL 'libcrypt.a(shr_64.o)', handle c at 0x7000000002242b0>
libcrypt.a(shr_64.o)

Back to Why though.

Ease of use, and portability with existing convention. My experience 
with just two python packages I wanted to port is that cdll("libFOO.so") 
is what is used, and works on GNU. I wanted that to work ASIS. I also 
noticed that sometimes code was explicit about the version (sometimes 
the latest was not right, and the code complained). So, since "short" 
names are preferred, and are portable - those are what programmers tend 
to use. Full-path-names imply an assumption.

dlopen() is not going to know that libc.so is actually libc.a(shr.o) - 
so I call find_library() for portability aka Ease of Use. While it may 
be slightly less performance I am hoping (assuming) cdll("foo") is not 
the most central part of any application - and the overhead is acceptable.

And thanks for the question. It is simple enough to remove now, should 
it be considered a sin.

> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue26439>
> _______________________________________

----------
nosy: +aixtools at gmail.com

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26439>
_______________________________________

From report at bugs.python.org  Tue May 10 17:33:24 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 10 May 2016 21:33:24 +0000
Subject: [issue19711] add test for changed portions after reloading a
 namespace package
In-Reply-To: <1385138827.34.0.898717139288.issue19711@psf.upfronthosting.co.za>
Message-ID: <20160510213306.42361.12263.684C6126@psf.io>


Roundup Robot added the comment:

New changeset c22ec7a45114 by Eric Snow in branch 'default':
Fixes #19711: Add tests for reloading namespace packages.
https://hg.python.org/cpython/rev/c22ec7a45114

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19711>
_______________________________________

From report at bugs.python.org  Tue May 10 17:34:09 2016
From: report at bugs.python.org (Eric Snow)
Date: Tue, 10 May 2016 21:34:09 +0000
Subject: [issue19711] add test for changed portions after reloading a
 namespace package
In-Reply-To: <1385138827.34.0.898717139288.issue19711@psf.upfronthosting.co.za>
Message-ID: <1462916049.56.0.437095689387.issue19711@psf.upfronthosting.co.za>


Eric Snow added the comment:

I've gone ahead and pushed the patch.

----------
resolution:  -> fixed
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19711>
_______________________________________

From report at bugs.python.org  Tue May 10 18:02:52 2016
From: report at bugs.python.org (Michael Felt)
Date: Tue, 10 May 2016 22:02:52 +0000
Subject: [issue9998] ctypes find_library should search LD_LIBRARY_PATH on linux
In-Reply-To: <1285857910.26.0.582948500976.issue9998@psf.upfronthosting.co.za>
Message-ID: <1462917772.79.0.524216535528.issue9998@psf.upfronthosting.co.za>


Michael Felt added the comment:

In https://bugs.python.org/issue26439 I have been working on this for AIX - as the default behavior was to depend on two things:
a) ldconfig -p (which generally does not exist on AIX, and I doubt it will know about the non-gnu libraries
b) that the objects are files rather than members of an archive

For python cdll() to work (as find_library generally did not) - the work-around was to extract archive members into standard directories and/or hard-code unique AIX names. But again, always as files, as CDLL did not modify the dlopen() mode to permit loading a shared library from an archive.

re: this issue and behavioral differences between find_library and cdll() (rather dlopen()) searches - a linker is different from a dlopen. When compiling an argument such as -lc -- on AIX -- tells the linker to look in libc.a for any member (of the right size) that satisfies an unknown symbol. That archive (base) and member (member) name is remembered in the "loader section" during linking. Note that static members have no loader section of their own, nor do they add one to the object (program or shared library) being linked.
As a compatibility feature - when a member is not found in an archive the AIX rtl (run-time-linker) also looks for a file named libFOO.so (e.g., libc.so) - this grace behavior is why CDLL() has worked somewhat using default behavior in Lib/ctypes.

As to LD_LIBRARY_PATH and LIBPATH. In AIX terms, these are environment variables to supplement the library search path - only when no PATH information is provided (i.e., cdll("./libc.so") will only look in the current directory of the process, and only for the file libc.so)
The default search path is a list of the directories used to link the executable (e.g., python). For me that list is:                         ***Import File Strings***
INDEX  PATH                          BASE                MEMBER
0      /usr/vac/lib:/usr/lib:/lib

In other words, python, by default, is only going to look in very standard locations - even though it knows it's prefix is not /usr.

There are two solutions - and I will make changes as appropriate.
a) automate setting an environment variable if it is not already set to something like 
 _os.environ['LIBPATH'] = "%s/lib" % _sys.prefix
and not something "arbitrary" such as /usr/local/lib
b) modify the LDFLAGS when packaging to include
-L${prefix}/lib which will have the effect of changing the default search path via -W,-blibpath=/usr/vac/lib:/usr/lib:/lib:${prefix}/lib


In any case, in my patch for AIX in ctypes the two will work identical (cdll() even calls aix.find_library() to simplify portability between GNU/posix environments that expect or support only filenames to work with AIX archive packaging.

My apologies for the wall of text. This is not a simple subject.

----------
nosy: +Michael.Felt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9998>
_______________________________________

From report at bugs.python.org  Tue May 10 18:24:09 2016
From: report at bugs.python.org (Eric Snow)
Date: Tue, 10 May 2016 22:24:09 +0000
Subject: [issue21099] Switch applicable importlib tests to use PEP 451 API
In-Reply-To: <1396128875.13.0.712473033591.issue21099@psf.upfronthosting.co.za>
Message-ID: <1462919049.17.0.885006123157.issue21099@psf.upfronthosting.co.za>


Eric Snow added the comment:

Could I get a quick review on this.  There shouldn't be anything surprising or controversial here.  I'm pretty confident about the patch and it's pretty low-impact so if I don't hear back in the next day or two I'll merge it.

Note: the posted patch does not apply cleanly but the difference is cosmetic.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21099>
_______________________________________

From report at bugs.python.org  Tue May 10 18:35:21 2016
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 10 May 2016 22:35:21 +0000
Subject: [issue21099] Switch applicable importlib tests to use PEP 451 API
In-Reply-To: <1396128875.13.0.712473033591.issue21099@psf.upfronthosting.co.za>
Message-ID: <1462919721.44.0.210769274158.issue21099@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I'll try to get to it today or tomorrow.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21099>
_______________________________________

From report at bugs.python.org  Tue May 10 19:03:51 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 10 May 2016 23:03:51 +0000
Subject: [issue26994] unexpected behavior for booleans in argparse
In-Reply-To: <1462905029.96.0.678738443976.issue26994@psf.upfronthosting.co.za>
Message-ID: <1462921431.12.0.171968100084.issue26994@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yes, it is an unitended consequence of the fact that argparse types are arbitrary single argument functions (that take an arbitrary string as the argument and convert it), and bool is a single argument function.  Unfortunately we're stuck with it now.  The correct answer, of course, is to write your own bool type converter if you need one.

It is possible there should be a documentation mention that bool is not approprate as a type function, since int and float, for example, are explicitly mentioned.  If you want to submit a patch to that end I'll reopen the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26994>
_______________________________________

From report at bugs.python.org  Tue May 10 19:07:44 2016
From: report at bugs.python.org (Demur Rumed)
Date: Tue, 10 May 2016 23:07:44 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1462921664.18.0.634653300224.issue26647@psf.upfronthosting.co.za>


Demur Rumed added the comment:

I've been waiting on storchaka to finish code reviewing peephole based on his statement of 'Reviewing peephole.c still is not completed.' before uploading a patch which addresses the issues raised since

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Tue May 10 21:45:33 2016
From: report at bugs.python.org (Meador Inge)
Date: Wed, 11 May 2016 01:45:33 +0000
Subject: [issue24194] tokenize yield an ERRORTOKEN if an identifier uses
 Other_ID_Start or Other_ID_Continue
In-Reply-To: <1431608427.75.0.966529056278.issue24194@psf.upfronthosting.co.za>
Message-ID: <1462931133.85.0.133047427677.issue24194@psf.upfronthosting.co.za>


Meador Inge added the comment:

Attached is a first cut patch for this.  (CC'd haypo as a unicode expert).

----------
assignee:  -> meador.inge
keywords: +patch
nosy: +haypo, meador.inge
stage: needs patch -> patch review
Added file: http://bugs.python.org/file42808/issue24194-v0.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24194>
_______________________________________

From report at bugs.python.org  Tue May 10 21:53:26 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 11 May 2016 01:53:26 +0000
Subject: [issue26977] Unnecessary line in statistics.pvariance
In-Reply-To: <1462708569.69.0.176390210867.issue26977@psf.upfronthosting.co.za>
Message-ID: <20160511015323.10513.53414.BD8DBE89@psf.io>


Roundup Robot added the comment:

New changeset 6f27dbc55f10 by Steven D'Aprano in branch '3.5':
Issue 26977, remove unneeded line in pvariance (duplicate call to _ss).
https://hg.python.org/cpython/rev/6f27dbc55f10

New changeset 3c75707045f5 by Steven D'Aprano in branch 'default':
Branch merge for issue 26977
https://hg.python.org/cpython/rev/3c75707045f5

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26977>
_______________________________________

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: [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  Tue May 10 22:56:28 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 11 May 2016 02:56:28 +0000
Subject: [issue26996] Add secrets module as per PEP 506.
In-Reply-To: <1462935278.01.0.338603165746.issue26996@psf.upfronthosting.co.za>
Message-ID: <1462935388.75.0.426925816979.issue26996@psf.upfronthosting.co.za>


Changes by Steven D'Aprano <steve+python at pearwood.info>:


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26996>
_______________________________________

From report at bugs.python.org  Tue May 10 23:01:58 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 11 May 2016 03:01:58 +0000
Subject: [issue26977] Unnecessary line in statistics.pvariance
In-Reply-To: <1462708569.69.0.176390210867.issue26977@psf.upfronthosting.co.za>
Message-ID: <20160511030155.8087.42768.8D88BC8E@psf.io>


Roundup Robot added the comment:

New changeset 87130512ef34 by Steven D'Aprano in branch '3.5':
NEWS message for issue #26977.
https://hg.python.org/cpython/rev/87130512ef34

New changeset 39faad3cd626 by Steven D'Aprano in branch 'default':
Merge NEWS update from 3.5 for issue #26977.
https://hg.python.org/cpython/rev/39faad3cd626

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26977>
_______________________________________

From report at bugs.python.org  Tue May 10 23:42:36 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 11 May 2016 03:42:36 +0000
Subject: [issue26993] Copy idlelib *.py files with new names
In-Reply-To: <1462904867.82.0.814804625056.issue26993@psf.upfronthosting.co.za>
Message-ID: <1462938156.53.0.828071646677.issue26993@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Terry, have you considered also doing a top level idlelib -> _idlelib rename in addition to the file level name changes?

My rationale for suggesting that:

1. The idle2 vs idle3 distinction will be clear at a glance (as they'll be in different directories)
2. The package level rename handles bifurcation of files that aren't themselves being renamed
3. You can subsequently iterate on the internal APIs without worrying about third party breakage
4. You set the stage for eventually moving IDLE to being an independently versioned implicitly pip-installed component (perhaps with an "ensure_default_ide" module akin to "ensurepip")

In relation to that last point, while I think it's important for CPython to come with a default IDE, I *don't* think it's important for the Python standard library to provide a default IDE-building toolkit (and, indeed, Linux distros tend to separate out not only IDLE, but also Tcl/Tk support in general, from the default Python installation).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26993>
_______________________________________

From report at bugs.python.org  Wed May 11 01:08:14 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 11 May 2016 05:08:14 +0000
Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not
 available (e.g., AIX)
In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za>
Message-ID: <1462943294.09.0.297898864925.issue26439@psf.upfronthosting.co.za>


Martin Panter added the comment:

Patches: I?m not sure, but maybe it would help the Reitveld review system if the src/ directory in them was eliminated (e.g. src/Python-3.5.1 vs just Python-3.5.1). Also, if you are using Gnu diff, maybe you can try the -N (--new-file) option to include aixutil.py in the diff, and -x (--exclude) __pycache__ to avoid that directory.

Personally, I would find patches a lot easier to handle than a tar file, especially if I cannot figure out which bits of the tar file are original code and which are changed code.

It seems you want to CDLL() to accept names using the Linux/BSD libFOO.so.N convention, but load an AIX library with a related name. This sounds like a bad design to me, for multiple reasons. I would like to hear other people?s opinions before going in that direction.

This is my understanding of the CDLL() calls currently needed to load the Open SSL library on various platforms:

openssl 1.0.2.g-3 package on Arch Linux: CDLL("libcrypto.so.1.0.0")
Windows: CDLL("libeay32.dll")
OS X (Darwin): CDLL("libcrypto.1.0.0.dylib")
FreeBSD: CDLL("libcrypto.so.8")
AIX: CDLL("libcrypto.a(libcrypto.so.1.0.0)", DEFAULT_MODE | RTLD_MEMBER)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26439>
_______________________________________

From report at bugs.python.org  Wed May 11 02:44:07 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 11 May 2016 06:44:07 +0000
Subject: [issue26857] gethostbyname_r() is broken on android
In-Reply-To: <1461677599.23.0.153884294057.issue26857@psf.upfronthosting.co.za>
Message-ID: <1462949047.31.0.145141869779.issue26857@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

gethostbyaddr_r() is implemented now on Android 6.0 (API 23). The attached patch has been tested on the android-21-x86 emulator (API 21) and android-23-x86 emulator (API 23). No new NDK has been released at Android 5.1 (API 22) so there is no need to test the patch for this release.

----------
resolution: fixed -> 
status: closed -> open
Added file: http://bugs.python.org/file42809/socketmodule_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26857>
_______________________________________

From report at bugs.python.org  Wed May 11 02:50:23 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 11 May 2016 06:50:23 +0000
Subject: [issue26993] Copy idlelib *.py files with new names
In-Reply-To: <1462904867.82.0.814804625056.issue26993@psf.upfronthosting.co.za>
Message-ID: <1462949423.96.0.372859601928.issue26993@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

In response to 1.  I considered copying idlelib as a whole as a serious possibility, meant to include it as an alternative, and am willing to reconsider my choice.  I specifically thought of something like idlelib3 or idlelib/idle3, but not _idlelib,  A complete copy in a new directory would be, as you say, a cleaner separation but it seemed like it would make import changes and startup more complicated.  It is also not obviously covered by PEP 434 -- unless you say so.

For users, making idle2 the copy would immediately break current external imports.  Making idle3 the copy would break new external imports sometime in the future.  But using _idlelib would warn of that possibility.

For importat, IDLE itself uses uses all of 'from idlelib import module', 'from idlelib.module import callable', 'from idlelib.idle_test.htest import run', and unittest.main('idlelib.idle_test.test_module' (but no relative imports).  A new directory would greatly increase the number of changes and mean changing 'idlelib' to 'something' now and 'something' back to 'idlelib' in the future.

I thought of using relative imports, but I have not used them and have read that they are limited, tricky, and discouraged.  I just did some experiments and it seems that they do not work when a file is run as __main__ instead of imported.  (Whatever the limitation, it is not obvious to me from the doc.)

I agree with 2. and 3. and will response to 4. in another message.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26993>
_______________________________________

From report at bugs.python.org  Wed May 11 03:50:37 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 11 May 2016 07:50:37 +0000
Subject: [issue26855] android: add platform.android_ver()
In-Reply-To: <1461676711.89.0.563475479331.issue26855@psf.upfronthosting.co.za>
Message-ID: <1462953037.83.0.546778989444.issue26855@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

IMHO returning an integer for the sdk field would be better. The patch could use shutil.which() to avoid subprocess calls when getprop is not available. It would be better to use a 'try/except ValueError' clause instead of isdigit(). The OSError and UnicodeDecodeError exceptions should not be masked, as well as ValueError if sdk cannot be parsed as an int.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26855>
_______________________________________

From report at bugs.python.org  Wed May 11 04:05:24 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 11 May 2016 08:05:24 +0000
Subject: [issue26983] float() can return not exact float instance
In-Reply-To: <1462801593.23.0.789372695786.issue26983@psf.upfronthosting.co.za>
Message-ID: <1462953924.63.0.419748419084.issue26983@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

+1 for the idea, and the patch LGTM.

I was initially a bit confused by the wording of the warning: presumably, we're not going to change Python to make returning an instance of a strict float subclass from __float__ illegal (I don't really see how that would be possible); we're just going to check the return type at the internal call sites to __float__ and raise if we get something other than an exact float. That is, I'd still expect this code to work on future versions of Python:

>>> class MyFloat(float): pass
... 
>>> class A:
...     def __float__(self): return MyFloat()
... 
>>> a = A()
>>> a.__float__()
0.0

But these would both become an error in Python 3.7 (say):

>>> float(a)
0.0
>>> math.sqrt(a)
0.0

Does that match your thinking?

We should probably add issues for checking and fixing other places that __float__ is used internally (like the math module).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26983>
_______________________________________

From report at bugs.python.org  Wed May 11 04:22:28 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 May 2016 08:22:28 +0000
Subject: [issue11549] Build-out an AST optimizer,
 moving some functionality out of the peephole optimizer
In-Reply-To: <1300164402.79.0.766591131661.issue11549@psf.upfronthosting.co.za>
Message-ID: <1462954948.92.0.333528645043.issue11549@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Regenerated for review.

----------
nosy: +serhiy.storchaka
Added file: http://bugs.python.org/file42810/issue11549.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11549>
_______________________________________

From report at bugs.python.org  Wed May 11 04:59:35 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 May 2016 08:59:35 +0000
Subject: [issue26983] float() can return not exact float instance
In-Reply-To: <1462801593.23.0.789372695786.issue26983@psf.upfronthosting.co.za>
Message-ID: <1462957175.58.0.691304449898.issue26983@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The warning message is copied from __int__. As I understand, the conclusion of the Python-Dev discussion is that __int__, __float__, __complex__, etc should return exact int, float, complex, not subclasses. I have another patch that adds a warning for __complex__, and I am working on patches for other special methods. If my understanding is wrong, we should remove the deprecation warning for __int__.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26983>
_______________________________________

From report at bugs.python.org  Wed May 11 05:45:22 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 11 May 2016 09:45:22 +0000
Subject: [issue26983] float() can return not exact float instance
In-Reply-To: <1462801593.23.0.789372695786.issue26983@psf.upfronthosting.co.za>
Message-ID: <1462959922.42.0.325762734547.issue26983@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> As I understand, the conclusion of the Python-Dev discussion is that __int__, __float__, __complex__, etc should return exact int, float, complex, not subclasses.

Agreed; that matches my understanding. I'm only observing that it would be difficult (and likely undesirable) to actually enforce that `__int__` itself always returns an exact int: I'm not sure where that check would/could take place, and I'd expect that a direct user-level call to `my_object.__int__` probably wouldn't be subject to such a check. What we *can* do is check that the result of the `nb_int` call is always an int in the places we use it.

Or we could even go further, and write custom slot_nb_float and slot_nb_int functions in Objects/typeobject.c that incorporates those checks. What I don't think we can do is check that a *direct* call to `__int__` or `__float__` always returns something of the exact type.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26983>
_______________________________________

From report at bugs.python.org  Wed May 11 06:20:50 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 May 2016 10:20:50 +0000
Subject: [issue26983] float() can return not exact float instance
In-Reply-To: <1462801593.23.0.789372695786.issue26983@psf.upfronthosting.co.za>
Message-ID: <1462962050.12.0.476551039767.issue26983@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is updated patch. Differences:

* Deprecation warning is now emitted in functions accepting floats (like math.sqrt).
* Improved error messages. Now reported wrong type name and a type of wrong __float__ method.
* float() now returns the same object for exact float argument.

Could you propose better warning message?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26983>
_______________________________________

From report at bugs.python.org  Wed May 11 06:21:29 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 May 2016 10:21:29 +0000
Subject: [issue26983] float() can return not exact float instance
In-Reply-To: <1462801593.23.0.789372695786.issue26983@psf.upfronthosting.co.za>
Message-ID: <1462962089.7.0.0815395800326.issue26983@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
dependencies: +Add tests for parsing float and object arguments

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26983>
_______________________________________

From report at bugs.python.org  Wed May 11 06:35:22 2016
From: report at bugs.python.org (Jakub Stasiak)
Date: Wed, 11 May 2016 10:35:22 +0000
Subject: [issue25998] doctest terminates when accessing __wrapped__ raises an
 error
In-Reply-To: <1451773843.64.0.986014558431.issue25998@psf.upfronthosting.co.za>
Message-ID: <1462962922.29.0.253789693969.issue25998@psf.upfronthosting.co.za>


Changes by Jakub Stasiak <jakub+python.org at stasiak.at>:


----------
nosy: +jstasiak

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25998>
_______________________________________

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: [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 06:41:58 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 11 May 2016 10:41:58 +0000
Subject: [issue26996] Add secrets module as per PEP 506.
In-Reply-To: <1462935278.01.0.338603165746.issue26996@psf.upfronthosting.co.za>
Message-ID: <1462963318.23.0.983813112946.issue26996@psf.upfronthosting.co.za>


Berker Peksag added the comment:

If you have time, documenting this at https://docs.python.org/3.6/whatsnew/3.6.html#new-features would be great :)

----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26996>
_______________________________________

From report at bugs.python.org  Wed May 11 06:50:20 2016
From: report at bugs.python.org (Michael Felt)
Date: Wed, 11 May 2016 10:50:20 +0000
Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not
 available (e.g., AIX)
In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za>
Message-ID: <1462963820.29.0.585114138046.issue26439@psf.upfronthosting.co.za>


Michael Felt added the comment:

a) https://bugs.python.org/review/26439/#msg12, but getting HTML 500 error)

The call to find_library here is for "ease of use" with existing code who use, e.g., cdll("libcrypto.so"). This format fails unless someone has previously done, e.g.: (cd /usr/lib; ar -X32 x libcrypto.a; mkdir -p /usr/lib64; cd /usr/lib64; ar -X64 x ../lib/libcrypto.a)

What I do think would be a valid addition here is to look for a '/' in the name anywhere (i.e., path info in name, and skip aix.find_library(). IMHO - if a programmer is usiong a relative path - he/she should take full responsilibilty (and this is basically what find_library will return anyway)

However, If there is a syntax issue I can rework the aixutil.py so there are multiple entry points - e.g., find_library() finds the .a file, and find_member() finds an archive containing a member (and returns a suitable base(member) argument for dlopen() and/or add an (undocumented) argument to modify find_library() return value.

But I think that only creates complexity for the user/programmer - additional complexity is an additional for an error (of omission) to occur.

Here, as it is now, if find_library() was used to find the name, find_library() is not called again. Again, if there is a behavior you want to force - then it can be made stricter - but compatibility with existing programs (I have been looking at cloud-init and salt) would be weak/non-existent. And, if ...startswith("aix") will be a very common addition to code.
Difficult to use is a reason programmers avoid a platform - and I would not like to see my favorite platform avoided because they had to add lots of "startswith("aix") - as one would always be forgotten, and then the attitude becomes - not going to bother with python on AIX. - my two bits.

p.s. Notice in the patches from yesterday - I have added the 'export' of RTLD_NOW and RTLD_MEMBER to Modules/_ctype/_ctype.c.
The "export" only occurs if the variable is defined, and the import only occurs in __init__.py behind 'startswith("aix")' blocks.

b) Yes, I can load and use GNU diff and resubmit (you can ignore them if you prefer - and I shall move the src/Python* to parallel with the build directories.

FYI: I tried to pip install Mercurial - but got an error message from an include file so the last bit did not compile. Problem for a later date - could be a user error on my part, or an AIX version dependency.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26439>
_______________________________________

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: [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 07:06:39 2016
From: report at bugs.python.org (Michael Felt)
Date: Wed, 11 May 2016 11:06:39 +0000
Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not
 available (e.g., AIX)
In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za>
Message-ID: <1462964799.22.0.957223070493.issue26439@psf.upfronthosting.co.za>


Michael Felt added the comment:

re:

AIX: CDLL("libcrypto.a(libcrypto.so.1.0.0)", DEFAULT_MODE | RTLD_MEMBER)

Officially it would be
dlopen("libcrypto.a(libcrypto.so.1.0.0)", RTLD_NOW | RTLD_MEMBER)

Further, that would only load the 32-bit version, as there is a legacy naming scheme for the 64-bit members (the same name may actually occur twice - once for each size)

Example: the ar command showing all members regardless of size:
root at x064:[/]ar -Xany tv /usr/lib/libcrypto.a
rwxr-xr-x     0/0     2967588 Jul 24 13:46 2015 libcrypto.so
rwxr-xr-x     0/0     2256131 Jul 24 13:43 2015 libcrypto.so.0.9.8
rwxr-xr-x     0/0     2967588 Jul 24 13:45 2015 libcrypto.so.1.0.0
rwxr-xr-x     0/0     3376521 Jul 24 13:46 2015 libcrypto64.so
rwxr-xr-x     0/0     2606185 Jul 24 13:44 2015 libcrypto64.so.0.9.8
rwxr-xr-x     0/0     3376521 Jul 24 13:45 2015 libcrypto64.so.1.0.0

Note: the default archives (ending in .so) are "same size, checksum, etc" as the .so.1.0.0 versioned members.

Also, this can be more complex - e.g., if LibreSSL is also included (I am re-working my packaging so that I will also have both 32 and 64-bit packaging, for now only 32-bit is available)

michael at x071:[/home/michael]ar -X32 tv /opt/lib/libcrypto.a
rwxr-xr-x     0/0     3060762 Jun 17 21:17 2015 libcrypto.so.33
rwxrwxr-x     0/0     2965597 Jul 25 16:57 2015 libcrypto.so
rwxrwxr-x     0/0     2253850 Jul 25 17:03 2015 libcrypto.so.0.9.8
rwxrwxr-x     0/0     2965597 Jul 25 17:03 2015 libcrypto.so.1.0.0

IMHO: this is a needless complication for a programmer using ctypes.cdll - but who am I?

>From the dlopen man page (aka InfoCenter)

Flags: (aka mode)
Specifies variations of the behavior of dlopen. Either RTLD_NOW or RTLD_LAZY must always be specified. Other flags may be OR'ed with RTLD_NOW or RTLD_LAZY.

RTLD_NOW 	Load all dependents of the module being loaded and resolve all symbols.

RTLD_LAZY 	Specifies the same behavior as RTLD_NOW. In a future release of the operating system, the behavior of the RTLD_LAZY may change so that loading of dependent modules is deferred of resolution of some symbols is deferred.

RTLD_MEMBER 	The dlopen subroutine can be used to load a module that is a member of an archive. The L_LOADMEMBER flag is used when the load subroutine is called. The module name FilePath names the archive and archive member according to the rules outlined in the load subroutine.

To be complete...

RTLD_GLOBAL 	Allows symbols in the module being loaded to be visible when resolving symbols used by other dlopen calls. These symbols will also be visible when the main application is opened with dlopen(NULL, mode).

RTLD_LOCAL 	Prevent symbols in the module being loaded from being used when resolving symbols used by other dlopen calls. Symbols in the module being loaded can only be accessed by calling dlsym subroutine. 

If neither RTLD_GLOBAL nor RTLD_LOCAL is specified, the default is RTLD_LOCAL. If both flags are specified, RTLD_LOCAL is ignored.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26439>
_______________________________________

From report at bugs.python.org  Wed May 11 07:44:18 2016
From: report at bugs.python.org (Michael Felt)
Date: Wed, 11 May 2016 11:44:18 +0000
Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not
 available (e.g., AIX)
In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za>
Message-ID: <1462967058.0.0.404341023367.issue26439@psf.upfronthosting.co.za>


Michael Felt added the comment:

used diff -rNu Python-3.5.1 Python-3.5.1.1 to generate

----------
Added file: http://bugs.python.org/file42811/Python3.issue26439.160511.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26439>
_______________________________________

From report at bugs.python.org  Wed May 11 07:46:31 2016
From: report at bugs.python.org (Michael Felt)
Date: Wed, 11 May 2016 11:46:31 +0000
Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not
 available (e.g., AIX)
In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za>
Message-ID: <1462967191.6.0.823785249196.issue26439@psf.upfronthosting.co.za>


Michael Felt added the comment:

used diff -rNu Python-2.7.11 Python-2.7.11.4 to generate

Note: content same as those from yesterday - except 
Lib/ctype/test/test_loading.py is no longer changed. No longer needed.

----------
Added file: http://bugs.python.org/file42812/Python2.issue26439.160511.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26439>
_______________________________________

From report at bugs.python.org  Wed May 11 07:57:53 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Wed, 11 May 2016 11:57:53 +0000
Subject: [issue26855] android: add platform.android_ver()
In-Reply-To: <1461676711.89.0.563475479331.issue26855@psf.upfronthosting.co.za>
Message-ID: <1462967873.89.0.497948845189.issue26855@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

Version 3.

Still using a try-catch clause to enclose the subprocess call, as _syscmd_ver does the same thing.

----------
Added file: http://bugs.python.org/file42813/android_ver.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26855>
_______________________________________

From report at bugs.python.org  Wed May 11 08:10:46 2016
From: report at bugs.python.org (AlexWMF)
Date: Wed, 11 May 2016 12:10:46 +0000
Subject: [issue26998] Unable to import "site" in an embedded application
In-Reply-To: <1462964428.89.0.669222260806.issue26998@psf.upfronthosting.co.za>
Message-ID: <1462968646.74.0.82706663338.issue26998@psf.upfronthosting.co.za>


AlexWMF added the comment:

I've checked the x86_64 version of python27.dll.
It contains "2.7-32" as well as x86 python dll. So strange, seems like "-32" is always there, independently of target bitness.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26998>
_______________________________________

From report at bugs.python.org  Wed May 11 08:17:38 2016
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 11 May 2016 12:17:38 +0000
Subject: [issue26857] gethostbyname_r() is broken on android
In-Reply-To: <1461677599.23.0.153884294057.issue26857@psf.upfronthosting.co.za>
Message-ID: <1462969058.29.0.530022719284.issue26857@psf.upfronthosting.co.za>


Stefan Krah added the comment:

How about supporting API >= 23 only? Can people upgrade their devices or do they have to buy a new one?

----------
nosy: +Chi Hsuan Yen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26857>
_______________________________________

From report at bugs.python.org  Wed May 11 08:48:14 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Wed, 11 May 2016 12:48:14 +0000
Subject: [issue26857] gethostbyname_r() is broken on android
In-Reply-To: <1461677599.23.0.153884294057.issue26857@psf.upfronthosting.co.za>
Message-ID: <1462970894.17.0.146144539959.issue26857@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

> Can people upgrade their devices or do they have to buy a new one?

AFAIK most models other than Nexus won't get updates with a bumped major version. (5.x => 6.x for example)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26857>
_______________________________________

From report at bugs.python.org  Wed May 11 08:57:32 2016
From: report at bugs.python.org (R. David Murray)
Date: Wed, 11 May 2016 12:57:32 +0000
Subject: [issue26998] Unable to import "site" in an embedded application
In-Reply-To: <1462964428.89.0.669222260806.issue26998@psf.upfronthosting.co.za>
Message-ID: <1462971452.89.0.993823993306.issue26998@psf.upfronthosting.co.za>


R. David Murray added the comment:

As far as I know the registry key is a supplament and not a requirement for a correctly functioning python.  There is an entire PEP about the registry keys and what to do with them...I'm not sure what the current status is on 2.7, but like I said, I believe that lack of registry keys should not keep python from working if it is installed correctly.  Python uses other methods to find its library.  Since you are in an embedded scenario, this probably means that there's something about the environment and/or disk layout that you haven't set up in the way that python expects it to be set up.  You migth try asking on python-list or the #python irc channel on freenode for help.  

I'm guessing this means there's something missing from the ebedding docs with respect to Windows, so I'm going to leave this open until that is confirmed or disproven :)

----------
components: +Windows
nosy: +paul.moore, r.david.murray, steve.dower, tim.golden, zach.ware

_______________________________________
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: [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 09:11:54 2016
From: report at bugs.python.org (Richard Neumann)
Date: Wed, 11 May 2016 13:11:54 +0000
Subject: [issue26999] Add child separator keyword to logging.basicConfig and
 use it in Logger.getChild()
In-Reply-To: <1462972267.52.0.758666146863.issue26999@psf.upfronthosting.co.za>
Message-ID: <1462972314.45.0.470186284916.issue26999@psf.upfronthosting.co.za>


Changes by Richard Neumann <r.neumann at homeinfo.de>:


----------
title: Add child seperator keyword to logging.basicConfig and use it in Logger.getChild() -> Add child separator keyword to logging.basicConfig and use it in Logger.getChild()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26999>
_______________________________________

From report at bugs.python.org  Wed May 11 09:13:10 2016
From: report at bugs.python.org (AlexWMF)
Date: Wed, 11 May 2016 13:13:10 +0000
Subject: [issue26998] Unable to import "site" in an embedded application
In-Reply-To: <1462964428.89.0.669222260806.issue26998@psf.upfronthosting.co.za>
Message-ID: <1462972390.85.0.836623911939.issue26998@psf.upfronthosting.co.za>


AlexWMF added the comment:

Could you provide link to that PEP?
As I posted in the previous message, both x86 and x86_64 python27.dll have version string "2.7-32" (shown in sys.winver). Is this right? Any of installers (x86 nor x86_64) don't create "2.7-32" subkey.

I understand that python should work without set up of sys.path from the registry, but after start of embedded python instance, sys.path don't have any valid path where 'c:\Python27x64\lib' folder resides. sys.path have ['c:\windows\system32\python27.zip', '.\Dlls', '.\Lib\'] and '.\\' expands to current application directory.
But directory is always different, not points to the python home.
When start the application which embeds x86_64 python, it just exits because can't find the 'site' module when tried to perform Py_InitializeEx(0).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26998>
_______________________________________

From report at bugs.python.org  Wed May 11 09:15:04 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Wed, 11 May 2016 13:15:04 +0000
Subject: [issue21099] Switch applicable importlib tests to use PEP 451 API
In-Reply-To: <1396128875.13.0.712473033591.issue21099@psf.upfronthosting.co.za>
Message-ID: <1462972504.45.0.630124368591.issue21099@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21099>
_______________________________________

From report at bugs.python.org  Wed May 11 09:18:29 2016
From: report at bugs.python.org (AlexWMF)
Date: Wed, 11 May 2016 13:18:29 +0000
Subject: [issue26998] Unable to import "site" in an embedded application
In-Reply-To: <1462964428.89.0.669222260806.issue26998@psf.upfronthosting.co.za>
Message-ID: <1462972709.18.0.401414888703.issue26998@psf.upfronthosting.co.za>


AlexWMF added the comment:

The output of both x86 and x86_64 python interpreters is attached

----------
Added file: http://bugs.python.org/file42814/Clipboard29.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26998>
_______________________________________

From report at bugs.python.org  Wed May 11 09:28:06 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Wed, 11 May 2016 13:28:06 +0000
Subject: [issue26857] gethostbyname_r() is broken on android
In-Reply-To: <1461677599.23.0.153884294057.issue26857@psf.upfronthosting.co.za>
Message-ID: <1462973286.54.0.355146977446.issue26857@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

By the way, socketmodule_2.patch is problematic. Developers may choose to build CPython against API level 21 and run it on all devices with API level >= 21. In general Android keeps ABI compatibility between consecutive versions. That is, most binaries built for API 21 can be run on API 21, 22, 23 and 24. With this patch, developers have to build two versions of CPython, one for API < 23 and one for API >= 23, or gethostbyname_r() may not be used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26857>
_______________________________________

From report at bugs.python.org  Wed May 11 10:05:17 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 11 May 2016 14:05:17 +0000
Subject: [issue26983] float() can return not exact float instance
In-Reply-To: <1462801593.23.0.789372695786.issue26983@psf.upfronthosting.co.za>
Message-ID: <1462975517.48.0.871116873404.issue26983@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Can you please attach the new patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26983>
_______________________________________

From report at bugs.python.org  Wed May 11 10:31:20 2016
From: report at bugs.python.org (AlexWMF)
Date: Wed, 11 May 2016 14:31:20 +0000
Subject: [issue26998] Unable to import "site" in an embedded application
In-Reply-To: <1462964428.89.0.669222260806.issue26998@psf.upfronthosting.co.za>
Message-ID: <1462977080.44.0.122238001641.issue26998@psf.upfronthosting.co.za>


AlexWMF added the comment:

I found the following PEP https://www.python.org/dev/peps/pep-0514/

According to this PEP, starting from python 2.7.11 the backward compatibility was broken, because .dll can't read from the following registry keys anymore:
HKEY_LOCAL_MACHINE\Software\Python\PythonCore\<Tag>
HKEY_LOCAL_MACHINE\Software\Wow6432Node\Python\PythonCore\<Tag>
HKEY_CURRENT_USER\Software\Python\PythonCore\<Tag>
HKEY_CURRENT_USER\Software\Wow6432Node\Python\PythonCore\<Tag>

That means, the python27.dll (x86/x86_64) tries to reads '2.7-32' and never see old keys like '2.7'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26998>
_______________________________________

From report at bugs.python.org  Wed May 11 10:54:48 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 May 2016 14:54:48 +0000
Subject: [issue26983] float() can return not exact float instance
In-Reply-To: <1462801593.23.0.789372695786.issue26983@psf.upfronthosting.co.za>
Message-ID: <1462978488.66.0.825210368595.issue26983@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Oh, sorry, how could I miss it?

----------
Added file: http://bugs.python.org/file42815/float_exact2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26983>
_______________________________________

From report at bugs.python.org  Wed May 11 11:28:05 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 11 May 2016 15:28:05 +0000
Subject: [issue6422] timeit called from within Python should allow autoranging
In-Reply-To: <1246806912.2.0.722769600334.issue6422@psf.upfronthosting.co.za>
Message-ID: <1462980485.3.0.420883578642.issue6422@psf.upfronthosting.co.za>


Steven D'Aprano added the comment:

This issue seems to have lost momentum, I'd like to revive it by proposing a slightly different interface for the autorange function.

Attached is a proof-of-concept patch. I've moved the code which determines the number of loops out of the main function into a new Timer method, ``autorange``. The main difference between my approach and Scott's is that my autorange method doesn't do any printing directly, it takes an optional callback function. This lets the caller take responsibility for all output.

If this approach is acceptable, I hope to:

- (in 3.6) add tests and docs for the new method;

- (in 3.6 if time permits, otherwise 3.7) modify the timeit and repeat methods and functions so that they can optionally call autorange(), e.g. if the caller passes 0 as the number.

I'm not sure that there's a good reason to add a top-level autorange() function to match the timeit() and repeat() functions. Especially not once they gain the ability to autorange themselves.

I think my approach will be compatible with cleaning up and refactoring the main() function. At the moment, main() is a mess IMO, it handles argument processing, autoranging, units of time, and unreliable timing detection all from one function.

----------
nosy: +steven.daprano
versions: +Python 3.6 -Python 3.5
Added file: http://bugs.python.org/file42816/timeit-autorange.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6422>
_______________________________________

From report at bugs.python.org  Wed May 11 11:37:00 2016
From: report at bugs.python.org (=?utf-8?b?5rGg5piM6KiA?=)
Date: Wed, 11 May 2016 15:37:00 +0000
Subject: [issue18454] distutils crashes when uploading to PyPI having only the
 username (no pw) defined
In-Reply-To: <1373822688.67.0.938925989206.issue18454@psf.upfronthosting.co.za>
Message-ID: <1462981020.54.0.442921900451.issue18454@psf.upfronthosting.co.za>


??? added the comment:

Patch for Python 3.5, using getpass module

----------
nosy: +???
Added file: http://bugs.python.org/file42817/issue18454_py35_prompt.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18454>
_______________________________________

From report at bugs.python.org  Wed May 11 11:42:37 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 11 May 2016 15:42:37 +0000
Subject: [issue26857] gethostbyname_r() is broken on android
In-Reply-To: <1461677599.23.0.153884294057.issue26857@psf.upfronthosting.co.za>
Message-ID: <1462981357.16.0.37425248039.issue26857@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

So what is problematic with this new patch ?  Obviously you need to build with API 23 to get gethostbyname_r() since it was not supported by android before, with the previous patch you don't get gethostbyname_r(), even when building with API 23.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26857>
_______________________________________

From report at bugs.python.org  Wed May 11 11:50:20 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 11 May 2016 15:50:20 +0000
Subject: [issue6422] timeit called from within Python should allow autoranging
In-Reply-To: <1246806912.2.0.722769600334.issue6422@psf.upfronthosting.co.za>
Message-ID: <1462981820.5.0.727050230427.issue6422@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I would suggest making the 0.2 tunable as an optional argument. Different applications (benchmarks) may want different duration / precision tradeoffs.
I also notice the repeat functionality isn't included in the patch, is there a reason?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6422>
_______________________________________

From report at bugs.python.org  Wed May 11 11:54:52 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Wed, 11 May 2016 15:54:52 +0000
Subject: [issue26857] gethostbyname_r() is broken on android
In-Reply-To: <1461677599.23.0.153884294057.issue26857@psf.upfronthosting.co.za>
Message-ID: <1462982092.38.0.13663155123.issue26857@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

I was thinking the (somewhat hacky) dlopen() approach so that gethostbyname_r() works in API 21 builds. If a universal build is not necessary this patch is OK.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26857>
_______________________________________

From report at bugs.python.org  Wed May 11 12:08:20 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 11 May 2016 16:08:20 +0000
Subject: [issue6422] timeit called from within Python should allow autoranging
In-Reply-To: <1462981820.5.0.727050230427.issue6422@psf.upfronthosting.co.za>
Message-ID: <20160511160814.GD12028@ando.pearwood.info>


Steven D'Aprano added the comment:

> I would suggest making the 0.2 tunable as an optional argument.

Sounds like a good idea to me.

> I also notice the repeat functionality isn't included in the patch, is there a reason?

I don't understand which repeat functionality you're referring to.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6422>
_______________________________________

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: [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 12:46:36 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 11 May 2016 16:46:36 +0000
Subject: [issue6422] timeit called from within Python should allow autoranging
In-Reply-To: <1246806912.2.0.722769600334.issue6422@psf.upfronthosting.co.za>
Message-ID: <1462985196.06.0.778837443359.issue6422@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> I don't understand which repeat functionality you're referring to.

https://docs.python.org/3/library/timeit.html#timeit.Timer.repeat

(or, similarly, what timeit's __main__ does: report the minimum of all N runs)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6422>
_______________________________________

From report at bugs.python.org  Wed May 11 13:08:05 2016
From: report at bugs.python.org (Franklin? Lee)
Date: Wed, 11 May 2016 17:08:05 +0000
Subject: [issue27000] improve document of filter
In-Reply-To: <1462985155.22.0.859825042381.issue27000@psf.upfronthosting.co.za>
Message-ID: <1462986485.4.0.93386714188.issue27000@psf.upfronthosting.co.za>


Franklin? Lee added the comment:

Aren't these both implementation details? As in, they only affect efficiency, not effect, right?

----------
nosy: +leewz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27000>
_______________________________________

From report at bugs.python.org  Wed May 11 13:08:31 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 11 May 2016 17:08:31 +0000
Subject: [issue27000] improve document of filter
In-Reply-To: <1462985155.22.0.859825042381.issue27000@psf.upfronthosting.co.za>
Message-ID: <1462986511.07.0.416278707361.issue27000@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

bool is not enough of a special case to call it out without confusing the issue. No, the bool constructor is not actually called. But it will still behave as if it was called for all intents and purpose, it just skips the reference counting shenanigans for the actual True/False singleton objects. Drawing a distinction might make people worry that it wouldn't invoke __len__ or __bool__ as normal.

Similarly, for all intents and purposes, your mental model of the identity function is mostly correct (I suspect the wording meant to use "function" in the mathematical sense, but it works either way). Yes, it never actually calls a function, but that's irrelevant to observed behavior. Your only mistake is in assuming the function actually returns the specific values True or False; no filter function needs to return True or False, they simply evaluate for truth or falsehood (that's why filter's docs use "true" and "false" to describe it, not "True" and "False"). filter(str.strip, list_of_strings) is perfectly legal, and yields those strings that contain non-whitespace characters.

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27000>
_______________________________________

From report at bugs.python.org  Wed May 11 13:10:26 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Wed, 11 May 2016 17:10:26 +0000
Subject: [issue27000] improve document of filter
In-Reply-To: <1462985155.22.0.859825042381.issue27000@psf.upfronthosting.co.za>
Message-ID: <1462986626.04.0.268877561641.issue27000@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

Franklin said it better: The only difference between documentation and behavior is invisible implementation details, which have no business being documented in any event (since they needlessly tie the hands of maintainers of CPython and other Python interpreters, while providing no useful benefit).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27000>
_______________________________________

From report at bugs.python.org  Wed May 11 13:14:05 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 May 2016 17:14:05 +0000
Subject: [issue26039] More flexibility in zipfile write interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <1462986845.05.0.301438567964.issue26039@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I have added comments for tests and documentation. The implementation looks correct. But I prefer simpler solution on this stage. Here is something between zipfile-open-w5.patch and zipfile-open-w8.patch, close to zipfile-open-w5.patch with fixed issues.

* Writer doesn't use look and seeking.
* Writing while there are open read handlers is permitted.
* Reading while there is open write handler is forbidden.

This works in all cases when current code works. The ability to read while there is open write handler is separate new feature (and I don't know whether there is a need in it).

----------
Added file: http://bugs.python.org/file42819/zipfile-open-w9.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26039>
_______________________________________

From report at bugs.python.org  Wed May 11 13:33:10 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 11 May 2016 17:33:10 +0000
Subject: [issue27000] improve document of filter
In-Reply-To: <1462985155.22.0.859825042381.issue27000@psf.upfronthosting.co.za>
Message-ID: <1462987990.03.0.688601316815.issue27000@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

First I have to clarify that my mistake is not in understanding but in writing. What I mean by 'identify the return value True or False' is actually what you say, 'evaluate for truth or falsehood'. I also notice the lowercase false and true in the doc. I know they are deliberate. Sorry about this.

For ``bool``, I almost agree with you now. Although I still think it's telling readers incorrect info in the second part. For ``bool``, it is not equivalent to ``(item for item in iterable if function(item))`` but ``(item for item in iterable if item)``. For CPython, you are not telling the truth.

And for identity function, I insist. I don't see any advantage with this sentence other than confusion. I don't think this will affect other implementation either.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27000>
_______________________________________

From report at bugs.python.org  Wed May 11 13:58:13 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 11 May 2016 17:58:13 +0000
Subject: [issue26881] modulefinder should reuse the dis module
In-Reply-To: <1462741429.3.0.902441171907.issue26881@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwYAaR2JcB72fi2kd6S16=j_v=vz-mz8sogrrp7AweHTtg@mail.gmail.com>


STINNER Victor added the comment:

It looks like the change is mentionned twice in Misc/NEWS.

IMHO it's worth to add an optional argument to skip extended opcodes in
_unpack_opcodes() to simplify the code in modulefinder.

Is the scancode method public? If yes, I'm not sure that it's ok to rename
it in a minor release.

Thanks for the change, it prepares the work for wordcode.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26881>
_______________________________________

From report at bugs.python.org  Wed May 11 14:12:22 2016
From: report at bugs.python.org (SilentGhost)
Date: Wed, 11 May 2016 18:12:22 +0000
Subject: [issue26999] Add child separator keyword to logging.basicConfig and
 use it in Logger.getChild()
In-Reply-To: <1462972267.52.0.758666146863.issue26999@psf.upfronthosting.co.za>
Message-ID: <1462990342.96.0.879665629454.issue26999@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +vinay.sajip
versions: +Python 3.6 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26999>
_______________________________________

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: [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:53:27 2016
From: report at bugs.python.org (Eugene Toder)
Date: Wed, 11 May 2016 18:53:27 +0000
Subject: [issue23640] int.from_bytes() is broken for subclasses
In-Reply-To: <1426080876.51.0.657090719237.issue23640@psf.upfronthosting.co.za>
Message-ID: <1462992807.78.0.0857920263338.issue23640@psf.upfronthosting.co.za>


Eugene Toder added the comment:

There's a similar issue with replace() methods on date/time/datetime classes. They create instances of derived types without calling derived __new__/__init__, thus potentially leaving those uninitialized.

>>> from datetime import date
>>> class D(date):
...   def __init__(self, y, m, d):
...     self.y = y
>>> D(2016,1,1).y
2016
>>> D(2016,1,1).replace(2015).y
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'D' object has no attribute 'y'

----------
nosy: +eltoder

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23640>
_______________________________________

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: [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 14:58:58 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 May 2016 18:58:58 +0000
Subject: [issue19717] resolve() fails when the path doesn't exist
In-Reply-To: <1385142353.37.0.842056066182.issue19717@psf.upfronthosting.co.za>
Message-ID: <1462993138.59.0.784160646806.issue19717@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I have written a patch that implements all three mode for posixpath.realpath() (issue27002). Having the implementation we can test and research it. After discussion this solution can be adopted for Path.resolve().

----------
versions: +Python 3.6 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19717>
_______________________________________

From report at bugs.python.org  Wed May 11 15:14:19 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 11 May 2016 19:14:19 +0000
Subject: [issue27000] improve document of filter
In-Reply-To: <1462985155.22.0.859825042381.issue27000@psf.upfronthosting.co.za>
Message-ID: <1462994059.82.0.184362502326.issue27000@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> bool is not enough of a special case to call it out without 
> confusing the issue.

I concur.  It would be easy to make the docs less usable by elaborating on this special case.  For the most part, a user should use None if they just want to test the truth value of the input.

The docs for filter() have been through a number of revisions and much discussion.  Let's not undo previous efforts.  For the most part, these docs have been successful in communicating what filter() does.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27000>
_______________________________________

From report at bugs.python.org  Wed May 11 15:21:37 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 11 May 2016 19:21:37 +0000
Subject: [issue26881] modulefinder should reuse the dis module
In-Reply-To: <1461912649.38.0.754834410981.issue26881@psf.upfronthosting.co.za>
Message-ID: <20160511192122.89095.65823.91D357A9@psf.io>


Roundup Robot added the comment:

New changeset f0a4d563b32e by Serhiy Storchaka in branch '3.5':
Issue #26881: Restored the name of scan_opcodes_25().
https://hg.python.org/cpython/rev/f0a4d563b32e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26881>
_______________________________________

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: [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:24:00 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 11 May 2016 19:24:00 +0000
Subject: [issue26884] android: cross-compilation of extension module links to
 the wrong python library
In-Reply-To: <1461925930.98.0.579147295527.issue26884@psf.upfronthosting.co.za>
Message-ID: <1462994640.15.0.234917590196.issue26884@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Another description of the problem:
* On the build system, the native python (in one of the search directories of PATH) has been built without --with-pydebug.
* The cross-compilation is done on this build system with --with-pydebug.
* The cross-compilation of all the Python extension modules fails with:
    /bin/ld: error: cannot find -lpython3.6m
    collect2: error: ld returned 1 exit status

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26884>
_______________________________________

From report at bugs.python.org  Wed May 11 15:26:04 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 11 May 2016 19:26:04 +0000
Subject: [issue26881] modulefinder should reuse the dis module
In-Reply-To: <1461912649.38.0.754834410981.issue26881@psf.upfronthosting.co.za>
Message-ID: <20160511192551.51752.42913.B4B10516@psf.io>


Roundup Robot added the comment:

New changeset d60040b3bb8c by Serhiy Storchaka in branch '3.5':
Removed duplicated NEWS entity for issue #26881.
https://hg.python.org/cpython/rev/d60040b3bb8c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26881>
_______________________________________

From report at bugs.python.org  Wed May 11 15:30:44 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 May 2016 19:30:44 +0000
Subject: [issue26881] modulefinder should reuse the dis module
In-Reply-To: <1461912649.38.0.754834410981.issue26881@psf.upfronthosting.co.za>
Message-ID: <1462995044.05.0.324507556265.issue26881@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Victor. Fixed.

> IMHO it's worth to add an optional argument to skip extended opcodes in
_unpack_opcodes() to simplify the code in modulefinder.

But this would complicate the code in dis.

If the disassembler would changed to skip extended opcodes, we would add this option in _unpack_opargs().

If there would be some Python 3 analogue of PEP 291, modulefinder would be changed to use public dis API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26881>
_______________________________________

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: [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  Wed May 11 15:47:25 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 May 2016 19:47:25 +0000
Subject: [issue27004] Handle script shbang options
In-Reply-To: <1462995550.58.0.0858558226193.issue27004@psf.upfronthosting.co.za>
Message-ID: <1462996045.97.0.752331281243.issue27004@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Yet one option:

- Add a wrapper /usr/bin/python2-s and pass it to to --executable.

$ cat /usr/bin/python2-s
#!/bin/sh
exec /usr/bin/python2 -s "$@"

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27004>
_______________________________________

From report at bugs.python.org  Wed May 11 15:55:27 2016
From: report at bugs.python.org (Franklin? Lee)
Date: Wed, 11 May 2016 19:55:27 +0000
Subject: [issue27000] improve document of filter
In-Reply-To: <1462985155.22.0.859825042381.issue27000@psf.upfronthosting.co.za>
Message-ID: <1462996527.39.0.0667398545983.issue27000@psf.upfronthosting.co.za>


Franklin? Lee added the comment:

> Although I still think it's telling readers incorrect info in the second part. For ``bool``, it is not equivalent to ``(item for item in iterable if function(item))`` but ``(item for item in iterable if item)``. For CPython, you are not telling the truth.

What do you mean by, "it is not equivalent"? Are you saying that the first one will give a different result from the second? In general, when interpreting an object in a boolean context, Python will do the "equivalent" of calling ``bool`` on it, where "equivalent" in the docs means "has the same result as". See, for example, the ``itertools`` docs:
https://docs.python.org/3/library/itertools.html#itertools.accumulate

--------

In this case:

If ``filter`` is passed ``None`` or ``bool``, it will call "PyObject_IsTrue" on the object.
    (https://github.com/python/cpython/blob/c750281ef5d8fa89d13990792163605302e972d4/Python/bltinmodule.c#L481)

"PyObject_IsTrue" is defined here:
    https://github.com/python/cpython/blob/6aea3c26a22c5d7e3ffa3d725d8d75dac0e1b83b/Objects/object.c#L1223

On the other hand, ``bool`` is defined here, as "PyBool_Type":
    https://github.com/python/cpython/blob/c750281ef5d8fa89d13990792163605302e972d4/Python/bltinmodule.c#L2686


"PyBool_Type" is defined here, with the ``bool.__new__`` function defined as "bool_new":
    https://github.com/python/cpython/blob/2d264235f6e066611b412f7c2e1603866e0f7f1b/Objects/boolobject.c#L133

"bool_new" is defined here, using "PyObject_IsTrue":
    https://github.com/python/cpython/blob/2d264235f6e066611b412f7c2e1603866e0f7f1b/Objects/boolobject.c#L43

Both "filter_next" and "bool_new" call "PyObject_IsTrue" and take 0 as False, positive as True, and negative as an error. So it's equivalent to calling ``bool``, but the "bool_new" call is sort of inlined.

Does that clear things up?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27000>
_______________________________________

From report at bugs.python.org  Wed May 11 15:58:27 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 11 May 2016 19:58:27 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1462996707.71.0.137709734782.issue26647@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Oh, sorry for misleading. I was going to continue reviewing peephole.c after found issues would addressed. In any case the patch needs to be synchronized with current sources (I expected that changes for modulefinder is no longer needed and changes for dis will be simpler). Please also wrap long lines in peephole.c.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Wed May 11 16:22:50 2016
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 11 May 2016 20:22:50 +0000
Subject: [issue21099] Switch applicable importlib tests to use PEP 451 API
In-Reply-To: <1396128875.13.0.712473033591.issue21099@psf.upfronthosting.co.za>
Message-ID: <1462998170.66.0.0874372519243.issue21099@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Patch LGTM

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21099>
_______________________________________

From report at bugs.python.org  Wed May 11 16:32:19 2016
From: report at bugs.python.org (Bennet Fauber)
Date: Wed, 11 May 2016 20:32:19 +0000
Subject: [issue27003] Python 3.5.1 fails at HTTPSTest with SSL CERT error
In-Reply-To: <1462994596.94.0.421418085673.issue27003@psf.upfronthosting.co.za>
Message-ID: <1462998739.68.0.759301236396.issue27003@psf.upfronthosting.co.za>


Bennet Fauber added the comment:

Just for the sake of completeness, I tested outside of the test harness.

/sw/arcts/centos7/python-dev/3.5.1/bin/python3
[bennet at flux-build-centos7-dev test]$ python3
Python 3.5.1 (default, May 11 2016, 08:50:05) 
[GCC 4.8.5 20150623 (Red Hat 4.8.5-4)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import http.client
>>> conn = http.client.HTTPSConnection("www.python.org")
>>> conn.request("GET", "/")
>>> r1 = conn.getresponse()
>>> print(r1.status, r1.reason)
200 OK

I think that indicates that it can do certificate verification of some sort and might be an indication that the issue is not with the setup but with the test.  There was some discussion of making the tests independent of connectivity in Issue25940.

There are a couple of expired certs in the test directory, but they may not be used; e.g.,

nokia.pem,
            Not After : Sep 20 23:59:59 2012 GMT
sha256.pem
            Not After : Feb 17 23:59:59 2014 GMT

I should have included this in the first submission.  Sorry for any additional mail this may generate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27003>
_______________________________________

From report at bugs.python.org  Wed May 11 16:40:12 2016
From: report at bugs.python.org (SilentGhost)
Date: Wed, 11 May 2016 20:40:12 +0000
Subject: [issue27003] Python 3.5.1 fails at HTTPSTest with SSL CERT error
In-Reply-To: <1462994596.94.0.421418085673.issue27003@psf.upfronthosting.co.za>
Message-ID: <1462999212.68.0.514954144061.issue27003@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
components: +Extension Modules -Build
nosy: +alex, christian.heimes, dstufft, giampaolo.rodola, janssen, pitrou
type: compile error -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27003>
_______________________________________

From report at bugs.python.org  Wed May 11 18:26:32 2016
From: report at bugs.python.org (Ned Deily)
Date: Wed, 11 May 2016 22:26:32 +0000
Subject: [issue26993] Copy idlelib *.py files with new names
In-Reply-To: <1462904867.82.0.814804625056.issue26993@psf.upfronthosting.co.za>
Message-ID: <1463005592.05.0.0346246291877.issue26993@psf.upfronthosting.co.za>


Ned Deily added the comment:

Terry, I'm all for having IDLE using the newer Ttk widgets and for refactoring to make it easier to enhance and maintain IDLE.  I'm not sure I understand the proposal to make two sets of IDLE files: does this mean there would be two versions of IDLE in one branch, e.g. Python 3.6?  That doesn't make sense to me.  One issue you mention is continuing to support Tk 8.4 (which lacks Ttk) on legacy systems.  Tk 8.4 support ended some years ago by the Tcl Core team. I think it is time for us to draw a line in the sand and say we no longer need to continue to support it for IDLE.  (It would be nice to not intentionally break basic non-IDLE Tkinter support for 8.4.)  I haven't yet announced any proposals for Mac installer support for 3.6 but I'm willing to commit to not requiring any Tcl/Tk 8.4 dependencies.   So, if we assume 8.4 is no longer an issue, what other issues remain?  I believe you've already stated that you will no longer attempt to keep the 2.7 version of IDLE in sync with the latest IDLE 3; I thinks that's the right approach at this stage.  That means there will be only some backporting of selected IDLE bugfixes to 2.7 and we don't do any direct VCS merging between 2.7 and default anyway.  So it seems to me there is no reason why the default branch (e.g. what is going into 3.6) needs to retain any copies of IDLE files from the 2.7 branch.  In other words, all the file renamings (via hg mv or otherwise) and deletions just take place in default without disturbing 2.7.  If there are any external incompatibilities, it's fine to announce them as part of the 3.6 feature release.  This is assuming that the externally incompatible work is in place in time for the 3.6 feature code cutoff (3.6.0 beta 1, currently scheduled for 2016-09-08).  As far as 3.5.n is concerned, the last bugfix release for 3.5 is likely to be less than a year away (assuming 3.6.0 releases by the end of 2016 as planned).  So I would also recommend not making any refactoring changes for 3.5, just important bugfixes similar to 2.7.  We should try to make it easier for you and the others working on IDLE.  And try to minimize the risks of inadvertent breakages going into maintenance releases.  Does that make sense?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26993>
_______________________________________

From report at bugs.python.org  Wed May 11 20:07:12 2016
From: report at bugs.python.org (R. David Murray)
Date: Thu, 12 May 2016 00:07:12 +0000
Subject: [issue27000] improve document of filter
In-Reply-To: <1462985155.22.0.859825042381.issue27000@psf.upfronthosting.co.za>
Message-ID: <1463011632.32.0.275473578239.issue27000@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks for wanting to improve the docs, but the docs are a specification of syntax and behavior, not of implementation.  So, the existing docs are correct, and changing them would over-specify the function.  Since Raymond has also voted for rejection, I'm closing this.

----------
nosy: +r.david.murray
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27000>
_______________________________________

From report at bugs.python.org  Wed May 11 20:10:10 2016
From: report at bugs.python.org (R. David Murray)
Date: Thu, 12 May 2016 00:10:10 +0000
Subject: [issue27001] Python Interface X-Plane 10.45
In-Reply-To: <1462992742.15.0.272722103174.issue27001@psf.upfronthosting.co.za>
Message-ID: <1463011810.81.0.571662103971.issue27001@psf.upfronthosting.co.za>


R. David Murray added the comment:

I don't know what X-Plane is, but it isn't part of python.  You should talk to the maintainers of it, and if they find there's a bug in python causing problems, open a specific issue about whatever that bug is.  You could also try asking for help on the python-list mailing list.

----------
nosy: +r.david.murray
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27001>
_______________________________________

From report at bugs.python.org  Wed May 11 20:13:18 2016
From: report at bugs.python.org (R. David Murray)
Date: Thu, 12 May 2016 00:13:18 +0000
Subject: [issue23640] int.from_bytes() is broken for subclasses
In-Reply-To: <1426080876.51.0.657090719237.issue23640@psf.upfronthosting.co.za>
Message-ID: <1463011998.0.0.374045009228.issue23640@psf.upfronthosting.co.za>


R. David Murray added the comment:

No, they do not return instances of the derived type, they return instances of the base type.  This is an intentional design decision that has been discussed elsewhere (including, I think, somewhere in this tracker).

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23640>
_______________________________________

From report at bugs.python.org  Wed May 11 20:39:34 2016
From: report at bugs.python.org (Erik Rasmussen)
Date: Thu, 12 May 2016 00:39:34 +0000
Subject: [issue27001] Python Interface X-Plane 10.45
In-Reply-To: <1463011810.81.0.571662103971.issue27001@psf.upfronthosting.co.za>
Message-ID: <CAD-6aYvD7v_YAkBSJkmdrtDePkVHFJ-HBW0QTMQcP36nWTOS_w@mail.gmail.com>


Erik Rasmussen added the comment:

X-plane is a simulator - and I used the attached Interface .. but since the
new version 2.7.11 it is not working .. and it DID work in version 2.7.10
...
Have tryed to downgrade Python... but not possible .. for some reason it
still registered as 2.7.11 , no matter what I do...
Any Ideas?

 -  Kindly / Mvh -
*E. Rasmussen*
Odense s? - DK

2016-05-12 2:10 GMT+02:00 R. David Murray <report at bugs.python.org>:

>
> R. David Murray added the comment:
>
> I don't know what X-Plane is, but it isn't part of python.  You should
> talk to the maintainers of it, and if they find there's a bug in python
> causing problems, open a specific issue about whatever that bug is.  You
> could also try asking for help on the python-list mailing list.
>
> ----------
> nosy: +r.david.murray
> resolution:  -> third party
> stage:  -> resolved
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue27001>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27001>
_______________________________________

From report at bugs.python.org  Wed May 11 21:19:20 2016
From: report at bugs.python.org (Eugene Toder)
Date: Thu, 12 May 2016 01:19:20 +0000
Subject: [issue23640] int.from_bytes() is broken for subclasses
In-Reply-To: <1426080876.51.0.657090719237.issue23640@psf.upfronthosting.co.za>
Message-ID: <1463015960.13.0.0603404198574.issue23640@psf.upfronthosting.co.za>


Eugene Toder added the comment:

They sure do. Check the example in my comment, or if you prefer the source code, it's pretty clear as well: https://hg.python.org/cpython/file/fff0c783d3db/Modules/_datetimemodule.c#l2770

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23640>
_______________________________________

From report at bugs.python.org  Wed May 11 22:07:53 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 12 May 2016 02:07:53 +0000
Subject: [issue27000] improve document of filter
In-Reply-To: <1462985155.22.0.859825042381.issue27000@psf.upfronthosting.co.za>
Message-ID: <1463018873.92.0.285402152037.issue27000@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

It's OK. Thanks for all your info and do learn. BTW, Franklin, I knew what will happen when ``bool`` is passed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27000>
_______________________________________

From report at bugs.python.org  Wed May 11 22:10:52 2016
From: report at bugs.python.org (Franklin? Lee)
Date: Thu, 12 May 2016 02:10:52 +0000
Subject: [issue27000] improve document of filter
In-Reply-To: <1462985155.22.0.859825042381.issue27000@psf.upfronthosting.co.za>
Message-ID: <1463019052.25.0.651545656144.issue27000@psf.upfronthosting.co.za>


Franklin? Lee added the comment:

In that case, I'm still wondering what you mean by "not equivalent". Are you saying there is code which will work only if the ``bool`` function is really called?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27000>
_______________________________________

From report at bugs.python.org  Wed May 11 22:24:00 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 12 May 2016 02:24:00 +0000
Subject: [issue27000] improve document of filter
In-Reply-To: <1462985155.22.0.859825042381.issue27000@psf.upfronthosting.co.za>
Message-ID: <1463019840.6.0.959335987152.issue27000@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Not about code, just the doc. In my opinion, if ``bool`` is not called it is definitely not equivalent to ``(item for item in iterable if function(item))``, which actually calls the function, even there is nothing different in the result. But, this is a rather subjective and not important now. I am OK with all your opinions. And considering other interpreters, leaving it untouched is a good idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27000>
_______________________________________

From report at bugs.python.org  Thu May 12 00:30:14 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 12 May 2016 04:30:14 +0000
Subject: [issue26993] Copy idlelib *.py files with new names
In-Reply-To: <1462904867.82.0.814804625056.issue26993@psf.upfronthosting.co.za>
Message-ID: <1463027414.73.0.0720669358097.issue26993@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Ned, thank you for the helpful response.  Yes, I *was* proposing two versions in 3.5 and subsequent releases until the current version could be deleted.  Its an ugly, least bad alternative that only made sense under the presumption that 'idle2' had to remain in 3.6.   With that assumption dropped ...

I would be delighted to start renaming (and refactoring) existing files in default *now*.  Whether to renames all at once (the current #24225 proposal) or in batches would be a sub-issue of #24225.

I believe that the PEP 434 exemption from separating 'behavior' from 'enhancement' issue applies during the beta period as well as after.  For IDLE, danger of accidental regression and thoroughness of testing are more relevant for deciding timing of commits.

As for 3.5, if we assume that substantial numbers of people, including instructors, will use the final 3.5 (likely 3.5.3) instead of 3.6.0, then it might be better for users to include 'idle3' in 3.5.3 as an option.  This could be done a couple of weeks before the release by copying 3.6 idlelib into, for instance, 3.5 idlelib._, editing imports, and adding a switch to the startup code.  If Ned's alternative is accepted, the backport decision should be deferred until there is something worth backporting.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26993>
_______________________________________

From report at bugs.python.org  Thu May 12 00:49:58 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 12 May 2016 04:49:58 +0000
Subject: [issue6422] timeit called from within Python should allow autoranging
In-Reply-To: <1246806912.2.0.722769600334.issue6422@psf.upfronthosting.co.za>
Message-ID: <1463028598.38.0.991195359239.issue6422@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

The embedded side-effects were my main concern with Scott's original patch, so Steven's callback-based approach strikes me as a definite improvement. However, the awkwardness of the revised calling code in main does make me wonder whether or not this might be better implemented as a generator rather than as a function accepting a callback:

    try:
        results = list(t.autorange())
    except:
        t.print_exc()
        return 1
    if verbose:
        for number, time_taken in results:
            msg = "{} loops -> {:.{}g} secs"
            print(msg.format(number, time_taken, precision))

(Originally I had the "if verbose: print" embedded in a direct loop over t.autorange(), but writing it that way made it immediately clear that the scope of the exception handler was too broad, so I changed it to extract all the results and only then print them)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6422>
_______________________________________

From report at bugs.python.org  Thu May 12 00:54:29 2016
From: report at bugs.python.org (Robert Collins)
Date: Thu, 12 May 2016 04:54:29 +0000
Subject: [issue26807] mock_open()().readline() fails at EOF
In-Reply-To: <1461140283.7.0.219960203136.issue26807@psf.upfronthosting.co.za>
Message-ID: <1463028869.57.0.772879478245.issue26807@psf.upfronthosting.co.za>


Robert Collins added the comment:

./python Lib/unittest/test/testmock/testmock.py
..........................................s.....................................
----------------------------------------------------------------------
Ran 80 tests in 0.180s

OK (skipped=1)


So thats great. I am going to have to stare that this quite hard to be sure I understand why it fails without the change away from 'for line in ' - but yes, this is the right place, and I'll commit it to 3.5 and 3.6 and backport it to the external mock tomorrow.

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26807>
_______________________________________

From report at bugs.python.org  Thu May 12 01:13:32 2016
From: report at bugs.python.org (Robert Collins)
Date: Thu, 12 May 2016 05:13:32 +0000
Subject: [issue26807] mock_open()().readline() fails at EOF
In-Reply-To: <1461140283.7.0.219960203136.issue26807@psf.upfronthosting.co.za>
Message-ID: <1463030012.4.0.290358558134.issue26807@psf.upfronthosting.co.za>


Robert Collins added the comment:

Actually, further inspection and a teddybear with Angus Lees uncovers this:

diff --git a/Lib/unittest/test/testmock/testmock.py b/Lib/unittest/test/testmock/testmock.py
--- a/Lib/unittest/test/testmock/testmock.py
+++ b/Lib/unittest/test/testmock/testmock.py
@@ -1419,6 +1419,18 @@
         self.assertEqual('abc', first)
         self.assertEqual('abc', second)

+    def test_mock_open_after_eof(self):
+        # read, readline and readlines should work after end of file.
+        _open = mock.mock_open(read_data='foo')
+        h = _open('bar')
+        h.read()
+        self.assertEqual('', h.read())
+        self.assertEqual('', h.read())
+        self.assertEqual('', h.readline())
+        self.assertEqual('', h.readline())
+        self.assertEqual([], h.readlines())
+        self.assertEqual([], h.readlines())
+
     def test_mock_parents(self):
         for Klass in Mock, MagicMock:
             m = Klass()



 ./python Lib/unittest/test/testmock/testmock.py
..........................................s........E............................
======================================================================
ERROR: test_mock_open_after_eof (__main__.MockTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/unittest/test/testmock/testmock.py", line 1430, in test_mock_open_after_eof
    self.assertEqual('', h.readline())
  File "/home/robertc/work/cpython-3.5.hg/Lib/unittest/mock.py", line 917, in __call__
    return _mock_self._mock_call(*args, **kwargs)
  File "/home/robertc/work/cpython-3.5.hg/Lib/unittest/mock.py", line 976, in _mock_call
    result = next(effect)
StopIteration

----------------------------------------------------------------------
Ran 80 tests in 0.197s

FAILED (errors=1, skipped=1)


That is, we need the yield '' to be infinite - while True: yield '', or the while True: to be outside the try:except.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26807>
_______________________________________

From report at bugs.python.org  Thu May 12 01:39:40 2016
From: report at bugs.python.org (Ned Deily)
Date: Thu, 12 May 2016 05:39:40 +0000
Subject: [issue26993] Copy idlelib *.py files with new names
In-Reply-To: <1462904867.82.0.814804625056.issue26993@psf.upfronthosting.co.za>
Message-ID: <1463031580.1.0.603815398037.issue26993@psf.upfronthosting.co.za>


Ned Deily added the comment:

Glad to be of help with regards to 8.4 :=)  With my 3.6 release manager hat on, I think the best way to think of this is as a new feature: call it "Ttk IDLE" or some such (and not idle2 vs idle3 which I think is confusing) and, rather than inventing something new, I suggest you should just follow the standard procedure for new feature development as documented in the Developers Guide.  That is, create a temporary repository on hg.python.org and make all the changes in a new branch in that repo.  Or, if you'd rather work in private, just create your own local repo clone and branch within it.  When you are satisfied that it is ready to be integrated into the release, we can either merge the branch in or extract the changes as one big patch to be applied to the main cpython default branch.  And I'll be happy to help with making that happen when the time comes.  That way you and any one else wanting to work on IDLE can work unimpeded, you don't have to worry about temporary changes and hacks to accommodate two versions of IDLE in the same repo, the old version of IDLE continues to work in the main cpython default branch until TtkIDLE is ready, and the cpython repo is not cluttered with all the intermediate commits from the feature dev cycle (although they could be preserved during integration, if desired).  Plus, during feature development you should be able to use TtkIDLE from the feature repo with a standard 3.6 (or 3.5) binary install of Python.

As for timing, I would prefer to get such a major feature in by feature code cutoff but, as you say, IDLE is pretty self-contained so we can be flexible.  A similar argument would apply to 3.5.  But I think it makes sense to focus on 3.6 first and then later separately consider dropping it all into 3.5.x, a decision that would be up to Larry as the 3.5 release manager.  For 3.6, I don't think there's a need for further discussion or to wait to begin, as long as the development work is done in a feature repo.  Have at it!

https://docs.python.org/devguide/committing.html#long-term-development-of-features

By the way, if you are essentially replacing the IDLE files, then (contrary to what I suggested earlier) you probably don't want to use hg mv to rename files.  Otherwise you can end up with needless merge conflicts between 3.x branches.  In the feature branch, you can just do the equivalent of: hg rm Lib/idlelib and hg commit then copy any old idlelib files you want to retain back into Lib/idlelib, and do an hg add and hg commit.  Then the feature branch files are no longer "connected" to the old IDLE files from hg's perspective.  On the other hand, if you go the feature repo route, you won't have two copies of IDLE in the same branch at a time, so you don't *have* to rename files if you don't otherwise want to.  In any case, if the feature is integrated as one big commit, all of this can be handled at integration time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26993>
_______________________________________

From report at bugs.python.org  Thu May 12 01:59:59 2016
From: report at bugs.python.org (Robert Collins)
Date: Thu, 12 May 2016 05:59:59 +0000
Subject: [issue26807] mock_open()().readline() fails at EOF
In-Reply-To: <1461140283.7.0.219960203136.issue26807@psf.upfronthosting.co.za>
Message-ID: <1463032799.61.0.434477239035.issue26807@psf.upfronthosting.co.za>


Robert Collins added the comment:

So something like

  for line in _state[0]:
      yield line
  while True:
    yield ''

Will probably do it just fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26807>
_______________________________________

From report at bugs.python.org  Thu May 12 02:30:04 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 12 May 2016 06:30:04 +0000
Subject: [issue26993] Copy idlelib *.py files with new names
In-Reply-To: <1462904867.82.0.814804625056.issue26993@psf.upfronthosting.co.za>
Message-ID: <1463034604.15.0.678005049627.issue26993@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

+1 for Ned's point that PEP 434 grants the IDLE developers *permission* to backport IDLE enhancements to maintenance releases, but doesn't *oblige* them to provide such backports.

For Python 3.6, another point to keep in mind is that if anyone particularly wants to keep the old idlelib API alive, they can either fork the existing code as a PyPI project, or create a compatibility shim that runs atop the new ttk-based API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26993>
_______________________________________

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: [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:00:55 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 12 May 2016 07:00:55 +0000
Subject: [issue27005] Faster float.fromhex()
In-Reply-To: <1463035702.18.0.00292240428989.issue27005@psf.upfronthosting.co.za>
Message-ID: <1463036454.99.0.96984968595.issue27005@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

LGTM

----------

_______________________________________
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: [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 03:21:41 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 12 May 2016 07:21:41 +0000
Subject: [issue27005] Faster float.fromhex()
In-Reply-To: <1463035702.18.0.00292240428989.issue27005@psf.upfronthosting.co.za>
Message-ID: <20160512072136.89107.79610.AE0E196A@psf.io>


Roundup Robot added the comment:

New changeset 3b19660611a4 by Serhiy Storchaka in branch 'default':
Issue #27005: Optimized the float.fromhex() class method for exact float.
https://hg.python.org/cpython/rev/3b19660611a4

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27005>
_______________________________________

From report at bugs.python.org  Thu May 12 03:22:17 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 May 2016 07:22:17 +0000
Subject: [issue27005] Faster float.fromhex()
In-Reply-To: <1463035702.18.0.00292240428989.issue27005@psf.upfronthosting.co.za>
Message-ID: <1463037737.76.0.0194307530863.issue27005@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Mark.

----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27005>
_______________________________________

From report at bugs.python.org  Thu May 12 03:32:54 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 12 May 2016 07:32:54 +0000
Subject: [issue27005] Faster float.fromhex()
In-Reply-To: <1463035702.18.0.00292240428989.issue27005@psf.upfronthosting.co.za>
Message-ID: <20160512073250.1845.56555.4A3A986F@psf.io>


Roundup Robot added the comment:

New changeset 1bae2a6bb37c by Serhiy Storchaka in branch 'default':
Issue #27005: Fixed the call of PyObject_CallFunctionObjArgs().
https://hg.python.org/cpython/rev/1bae2a6bb37c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27005>
_______________________________________

From report at bugs.python.org  Thu May 12 03:40:08 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 12 May 2016 07:40:08 +0000
Subject: [issue23640] int.from_bytes() is broken for subclasses
In-Reply-To: <1426080876.51.0.657090719237.issue23640@psf.upfronthosting.co.za>
Message-ID: <20160512074002.67129.862.D46F033C@psf.io>


Roundup Robot added the comment:

New changeset 0af15b8ef3b2 by Serhiy Storchaka in branch '3.5':
Issue #23640: int.from_bytes() no longer bypasses constructors for subclasses.
https://hg.python.org/cpython/rev/0af15b8ef3b2

New changeset df14ea17a517 by Serhiy Storchaka in branch 'default':
Issue #23640: int.from_bytes() no longer bypasses constructors for subclasses.
https://hg.python.org/cpython/rev/df14ea17a517

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23640>
_______________________________________

From report at bugs.python.org  Thu May 12 03:49:10 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 May 2016 07:49:10 +0000
Subject: [issue23640] int.from_bytes() is broken for subclasses
In-Reply-To: <1426080876.51.0.657090719237.issue23640@psf.upfronthosting.co.za>
Message-ID: <1463039350.24.0.713797718479.issue23640@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Discussion on Python-Dev: http://comments.gmane.org/gmane.comp.python.devel/157649 .

The conclusion is that alternate constructors should return an instance of the subclass, and either call constructor or use pickling machinery for creating an object in correct state.

Pushed the fix for int.from_bytes() and tests. I'll open separate issues for other alternate constructors (for example issue27006 -- for Decimal.from_float()).

Yes, there is similar bug in date.replace(). C implementation doesn't match Python implementation and bypasses the constructor. Please open separate issue for this Eugene.

----------
assignee:  -> serhiy.storchaka
components: +Interpreter Core -Library (Lib)
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed
versions: +Python 3.6 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23640>
_______________________________________

From report at bugs.python.org  Thu May 12 03:53:10 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 May 2016 07:53:10 +0000
Subject: [issue27005] Faster float.fromhex()
In-Reply-To: <1463035702.18.0.00292240428989.issue27005@psf.upfronthosting.co.za>
Message-ID: <1463039590.6.0.707194188068.issue27005@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

A mistake in using PyObject_CallFunctionObjArgs() caused a crash in using fromhex() for subclasses. New tests added in issue23640 covers this case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27005>
_______________________________________

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: [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: [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 04:18:19 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 May 2016 08:18:19 +0000
Subject: [issue27008] error message of ord is not intuitive
In-Reply-To: <1463040290.52.0.305686008758.issue27008@psf.upfronthosting.co.za>
Message-ID: <1463041099.28.0.161216835449.issue27008@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This not the only place where "string" means unicode string or bytes string. I don't think this is large issue.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27008>
_______________________________________

From report at bugs.python.org  Thu May 12 04:23:56 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 12 May 2016 08:23:56 +0000
Subject: [issue27008] error message of ord is not intuitive
In-Reply-To: <1463040290.52.0.305686008758.issue27008@psf.upfronthosting.co.za>
Message-ID: <1463041436.73.0.635867028458.issue27008@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

If you think it's OK, it's fine. Please close this thread.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27008>
_______________________________________

From report at bugs.python.org  Thu May 12 04:27:57 2016
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 12 May 2016 08:27:57 +0000
Subject: [issue26999] Add child separator keyword to logging.basicConfig and
 use it in Logger.getChild()
In-Reply-To: <1462972267.52.0.758666146863.issue26999@psf.upfronthosting.co.za>
Message-ID: <1463041677.28.0.689105462815.issue26999@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

This is a change with wide-ranging ramifications. I don't propose to do this, as the use of '.' as a logging separator mirrors the separator used in the Python package namespace.

Logger names are supposed to indicate the "where" of a logging event - nothing more.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26999>
_______________________________________

From report at bugs.python.org  Thu May 12 04:35:05 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 12 May 2016 08:35:05 +0000
Subject: [issue27008] error message of ord is not intuitive
In-Reply-To: <1463040290.52.0.305686008758.issue27008@psf.upfronthosting.co.za>
Message-ID: <1463042105.15.0.667721770363.issue27008@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

BTW, what do you think about the second TypeError in ``ord``. Shouldn't it be ValueError?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27008>
_______________________________________

From report at bugs.python.org  Thu May 12 04:40:52 2016
From: report at bugs.python.org (Richard Neumann)
Date: Thu, 12 May 2016 08:40:52 +0000
Subject: [issue26999] Add child separator keyword to logging.basicConfig and
 use it in Logger.getChild()
In-Reply-To: <1462972267.52.0.758666146863.issue26999@psf.upfronthosting.co.za>
Message-ID: <1463042452.48.0.625567779751.issue26999@psf.upfronthosting.co.za>


Richard Neumann added the comment:

I am using loggers and sub-loggers (getChild()) in classes, which contain sub-classes, wich contain sub-sub-classes and so on for complex data processing.
Hence I was using the logging library with sub-loggers to see in which of the (sub-)classes things happen.
Most classes are, however, instanced for different configuration and are represented by strings like {instance_config}@{class_name} where {instance_config} often contains dots as separators for IDs.
Example:

INFO	1000 at TerminalsSyncer            :	Aggregating customer data: 1031002 at Facebook
INFO	1000 at TerminalsSyncer            :	Aggregating virtual data: v60.1031002 at Config
INFO	1000 at TerminalsSyncer            :	Aggregating virtual data: v60.1031002 at Presentation
WARNING	1000 at TerminalsSyncer->1.1000 at TerminalSyncer:	Terminal 1.1000 is offline


However, if you still think that this is not, what the logging library is meant for, I'd appreciate to know.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26999>
_______________________________________

From report at bugs.python.org  Thu May 12 04:53:47 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 May 2016 08:53:47 +0000
Subject: [issue27008] error message of ord is not intuitive
In-Reply-To: <1463040290.52.0.305686008758.issue27008@psf.upfronthosting.co.za>
Message-ID: <1463043227.81.0.695271585363.issue27008@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

In any case it doesn't make much sense to change just one separate docstring. If you want to avoid misleading and support consistent wording, you should examine all occurrences of the word "string" in the documentation, docstrings, error messages and comments -- does it mean Unicode string, bytes-like object that supports the buffer protocol (including memoryview), bytes-like object that supports str-like interface (including bytes, bytearray, but excluding memoryview), either Unicode or bytes string? I tried to do this but abandoned the work on half-way. This is too large work.

> BTW, what do you think about the second TypeError in ``ord``. Shouldn't it be ValueError?

It could be ValueError. But for compatibility it should stay TypeError. This is not wrong if we consider strings of size 1 as separate type.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27008>
_______________________________________

From report at bugs.python.org  Thu May 12 05:03:01 2016
From: report at bugs.python.org (Richard Neumann)
Date: Thu, 12 May 2016 09:03:01 +0000
Subject: [issue26999] Add child separator keyword to logging.basicConfig and
 use it in Logger.getChild()
In-Reply-To: <1462972267.52.0.758666146863.issue26999@psf.upfronthosting.co.za>
Message-ID: <1463043781.4.0.499185159585.issue26999@psf.upfronthosting.co.za>


Richard Neumann added the comment:

PS: @vinay.sajip

You do realize that I want this argument to be optional and to retain '.' as default setting in order to keep the current behaviour?!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26999>
_______________________________________

From report at bugs.python.org  Thu May 12 05:11:55 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 12 May 2016 09:11:55 +0000
Subject: [issue27008] error message of ord is not intuitive
In-Reply-To: <1463040290.52.0.305686008758.issue27008@psf.upfronthosting.co.za>
Message-ID: <1463044315.49.0.743089511811.issue27008@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Ohh, you have tried to do that. It must be a large work.

But on the other hand, if this is a too large work, why not solve this case by case? This work is too large to get someone work on it, even you, the most active developer in the community I see have abandoned. And then maybe improving the situation a little bit every time is the only solution.

> This is not wrong if we consider strings of size 1 as separate type

This sounds weird. But I can understand the importance of compatibility.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27008>
_______________________________________

From report at bugs.python.org  Thu May 12 05:16:17 2016
From: report at bugs.python.org (Richard Neumann)
Date: Thu, 12 May 2016 09:16:17 +0000
Subject: [issue26999] Add child separator keyword to logging.basicConfig and
 use it in Logger.getChild()
In-Reply-To: <1462972267.52.0.758666146863.issue26999@psf.upfronthosting.co.za>
Message-ID: <1463044577.33.0.173031836034.issue26999@psf.upfronthosting.co.za>


Richard Neumann added the comment:

Added proposed patch

----------
keywords: +patch
Added file: http://bugs.python.org/file42825/logger.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26999>
_______________________________________

From report at bugs.python.org  Thu May 12 05:34:56 2016
From: report at bugs.python.org (Richard Neumann)
Date: Thu, 12 May 2016 09:34:56 +0000
Subject: [issue26999] Add child separator keyword to logging.basicConfig and
 use it in Logger.getChild()
In-Reply-To: <1462972267.52.0.758666146863.issue26999@psf.upfronthosting.co.za>
Message-ID: <1463045696.9.0.543318552084.issue26999@psf.upfronthosting.co.za>


Changes by Richard Neumann <r.neumann at homeinfo.de>:


Removed file: http://bugs.python.org/file42825/logger.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26999>
_______________________________________

From report at bugs.python.org  Thu May 12 05:57:10 2016
From: report at bugs.python.org (Thomas Kluyver)
Date: Thu, 12 May 2016 09:57:10 +0000
Subject: [issue26039] More flexibility in zipfile write interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <1463047030.94.0.249068752045.issue26039@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

Thanks Serhiy. I'm quite happy with that set of constraints. I had a look over your patch set, and just spotted one thing in writestr that I have overlooked all along.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26039>
_______________________________________

From report at bugs.python.org  Thu May 12 06:09:08 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 May 2016 10:09:08 +0000
Subject: [issue27007] Alternate constructors bytes.fromhex() and
 bytearray.fromhex() return an instance of base type
In-Reply-To: <1463040199.11.0.588158577385.issue27007@psf.upfronthosting.co.za>
Message-ID: <1463047748.19.0.552270541278.issue27007@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch.

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file42826/bytes_fromhex.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27007>
_______________________________________

From report at bugs.python.org  Thu May 12 06:12:43 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 May 2016 10:12:43 +0000
Subject: [issue26039] More flexibility in zipfile write interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <1463047963.3.0.0768380008838.issue26039@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your contribution Thomas. I'll push the patch with fixed writestr in short time unless Martin left comments.

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26039>
_______________________________________

From report at bugs.python.org  Thu May 12 06:14:07 2016
From: report at bugs.python.org (Ben Spiller)
Date: Thu, 12 May 2016 10:14:07 +0000
Subject: [issue26369] unicode.decode and str.encode are unnecessarily
 confusing for non-ascii
In-Reply-To: <1455623938.04.0.928922751587.issue26369@psf.upfronthosting.co.za>
Message-ID: <1463048047.49.0.297094367952.issue26369@psf.upfronthosting.co.za>


Ben Spiller added the comment:

Thanks that's really helpful

Having thought about it some more, I think if possible it'd be really so much better to actually 'fix' the behaviour for the unicode<->str standard codecs (i.e. not base64) rather than just documenting around it. The current behaviour is not only confusing but leads to bugs that are very easy to miss since the methods work correctly when given 7-bit ascii characters. 

I had a poke around in the python source but couldn't quite identify where it's happening - presumably there is somewhere in the str.encode('utf-8') implementation that first "decodes" the string and does so using the ascii codec. If it could be made to use the same encoding that was passed in (e.g. utf8) then this would end up being a no-op and there would be no unpleasant bugs that only appear when the input includes non-ascii characters. 

It would also allow X.encode('utf-8') to be called successfully whether X is already a str or is a unicode object, which would save callers having to explicitly check what kind of string they've been passed. 

Is anyone able to look into the code to see where this would need to be fixed and how difficult it would be to do? I have a feeling that once the line is located it might be quite a straightforward fix

Many thanks

----------
components: +Interpreter Core -Documentation
title: doc for unicode.decode and str.encode is unnecessarily confusing -> unicode.decode and str.encode are unnecessarily confusing for non-ascii

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26369>
_______________________________________

From report at bugs.python.org  Thu May 12 06:25:50 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 May 2016 10:25:50 +0000
Subject: [issue26369] unicode.decode and str.encode are unnecessarily
 confusing for non-ascii
In-Reply-To: <1455623938.04.0.928922751587.issue26369@psf.upfronthosting.co.za>
Message-ID: <1463048750.98.0.485648980524.issue26369@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Note that with the -3 option Python 2.7 already warns about incompatibilities. 

>>> 'abc'.encode('base64')
__main__:1: DeprecationWarning: 'base64' is not a text encoding; use codecs.encode() to handle arbitrary codecs
'YWJj\n'
>>> 'YWJj\n'.decode('base64')
__main__:1: DeprecationWarning: 'base64' is not a text encoding; use codecs.decode() to handle arbitrary codecs
'abc'
>>> u'abc'.decode('ascii')
__main__:1: DeprecationWarning: decoding Unicode is not supported in 3.x
u'abc'

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26369>
_______________________________________

From report at bugs.python.org  Thu May 12 06:34:22 2016
From: report at bugs.python.org (Richard Neumann)
Date: Thu, 12 May 2016 10:34:22 +0000
Subject: [issue26999] Add child separator keyword to logging.basicConfig and
 use it in Logger.getChild()
In-Reply-To: <1462972267.52.0.758666146863.issue26999@psf.upfronthosting.co.za>
Message-ID: <1463049262.21.0.111348711139.issue26999@psf.upfronthosting.co.za>


Changes by Richard Neumann <r.neumann at homeinfo.de>:


Added file: http://bugs.python.org/file42827/logger.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26999>
_______________________________________

From report at bugs.python.org  Thu May 12 06:44:59 2016
From: report at bugs.python.org (Richard Neumann)
Date: Thu, 12 May 2016 10:44:59 +0000
Subject: [issue25452] Add __bool__() method to subprocess.CompletedProcess
In-Reply-To: <1445424658.54.0.134413313052.issue25452@psf.upfronthosting.co.za>
Message-ID: <1463049899.29.0.433345678053.issue25452@psf.upfronthosting.co.za>


Richard Neumann added the comment:

I took the liberty to create a patch for Python v3.5.1.

----------
keywords: +patch
nosy: +Richard Neumann
Added file: http://bugs.python.org/file42828/subprocess.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25452>
_______________________________________

From report at bugs.python.org  Thu May 12 07:02:53 2016
From: report at bugs.python.org (Ben Spiller)
Date: Thu, 12 May 2016 11:02:53 +0000
Subject: [issue26369] unicode.decode and str.encode are unnecessarily
 confusing for non-ascii
In-Reply-To: <1455623938.04.0.928922751587.issue26369@psf.upfronthosting.co.za>
Message-ID: <1463050973.56.0.441119212211.issue26369@psf.upfronthosting.co.za>


Ben Spiller added the comment:

yes the situation is loads better in python 3, this issue is specific to 2.x, but like many people sadly we're not able to move to 3 for the time being. 

Since making this mistake is quite common and there's some sensible behaviour that would make it disappear (resulting in ascii and non-ascii strings being treated the same way by these methods) I'd much prefer if we could actually fix it for python 2.7

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26369>
_______________________________________

From report at bugs.python.org  Thu May 12 07:03:01 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 12 May 2016 11:03:01 +0000
Subject: [issue25452] Add __bool__() method to subprocess.CompletedProcess
In-Reply-To: <1463049899.29.0.433345678053.issue25452@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwY4yzw0GYzz1vZDp5FbV_y+pHa7fBHQQiHx+CteCzsP=w@mail.gmail.com>


STINNER Victor added the comment:

It's a new feature, it should only go to Python 3.6.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25452>
_______________________________________

From report at bugs.python.org  Thu May 12 07:20:01 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 May 2016 11:20:01 +0000
Subject: [issue26369] unicode.decode and str.encode are unnecessarily
 confusing for non-ascii
In-Reply-To: <1455623938.04.0.928922751587.issue26369@psf.upfronthosting.co.za>
Message-ID: <1463052001.0.0.315580653394.issue26369@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

What do you propose? Note that str.encode() doesn't raise an exception. Ascii unicode and 8-bit strings are interchangeable. Ascii unicode strings can be packed in str for less memory consumption (see xmlrpclib or ElementTree), a lot of str constant are used in unicode context (like os.sep or empty string). Breaking str.encode() will break valid existing code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26369>
_______________________________________

From report at bugs.python.org  Thu May 12 07:42:06 2016
From: report at bugs.python.org (Ben Spiller)
Date: Thu, 12 May 2016 11:42:06 +0000
Subject: [issue26369] unicode.decode and str.encode are unnecessarily
 confusing for non-ascii
In-Reply-To: <1455623938.04.0.928922751587.issue26369@psf.upfronthosting.co.za>
Message-ID: <1463053326.97.0.0990348505488.issue26369@psf.upfronthosting.co.za>


Ben Spiller added the comment:

I'm proposing that str.encode() should _not_ throw a 'decode' exception  for non-ascii characters and be effectively a no-op, to match what it already does for ascii characters - which therefore shouldn't break behavior anyone will be depending on. This could be achieved by passing the encoding parameter through to the implicit decode() call (which is where the exception is coming from it appears), rather than (arbitrarily and surprisingly) using "ascii" (which of course sometimes works and sometimes doesn't depending on the input string)

Does that make sense?

If someone can find the place in the code (sorry I tried and failed!) where str.encode('utf-8') is resulting in an implicit call to the equivalent of decode('ascii') (as suggested by the exception message) I think it'll be easier to discuss the details

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26369>
_______________________________________

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: [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 08:23:00 2016
From: report at bugs.python.org (R. David Murray)
Date: Thu, 12 May 2016 12:23:00 +0000
Subject: [issue23640] int.from_bytes() is broken for subclasses
In-Reply-To: <1426080876.51.0.657090719237.issue23640@psf.upfronthosting.co.za>
Message-ID: <1463055780.91.0.643278113303.issue23640@psf.upfronthosting.co.za>


R. David Murray added the comment:

@eltoder: Ah, you are right, I was looking at the python version.  There's an open issue about this, #20371, which indicates that the design decision was to support subclasses.  Clearly I was remembering the conversation backward based on looking at the wrong code :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23640>
_______________________________________

From report at bugs.python.org  Thu May 12 08:23:16 2016
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 12 May 2016 12:23:16 +0000
Subject: [issue23640] int.from_bytes() is broken for subclasses
In-Reply-To: <1426080876.51.0.657090719237.issue23640@psf.upfronthosting.co.za>
Message-ID: <1463055796.98.0.290508739927.issue23640@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy:  -pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23640>
_______________________________________

From report at bugs.python.org  Thu May 12 08:28:40 2016
From: report at bugs.python.org (Hartmann)
Date: Thu, 12 May 2016 12:28:40 +0000
Subject: [issue27009] multiprocessing Connection data length limited to
 max(int32)
In-Reply-To: <1463054927.27.0.521137668509.issue27009@psf.upfronthosting.co.za>
Message-ID: <1463056120.37.0.811520347322.issue27009@psf.upfronthosting.co.za>


Changes by Hartmann <cimatosa at gmx.de>:


----------
versions: +Python 3.5 -Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27009>
_______________________________________

From report at bugs.python.org  Thu May 12 08:28:59 2016
From: report at bugs.python.org (R. David Murray)
Date: Thu, 12 May 2016 12:28:59 +0000
Subject: [issue20371] datetime.datetime.replace bypasses a subclass's __new__
In-Reply-To: <1390506444.15.0.286575412745.issue20371@psf.upfronthosting.co.za>
Message-ID: <1463056139.46.0.59495095165.issue20371@psf.upfronthosting.co.za>


R. David Murray added the comment:

To summarize, it looks like there are three issues here: (1) the python and C versions are out of sync behavior wise (the python should work like the C in this case, it seems) (2) there are some missing tests, since we are running the same tests against both code bases and not getting any errors and (3) replace is doing its copy in a way that does not actually supporting subclassing (which again speaks to missing tests).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20371>
_______________________________________

From report at bugs.python.org  Thu May 12 08:29:22 2016
From: report at bugs.python.org (R. David Murray)
Date: Thu, 12 May 2016 12:29:22 +0000
Subject: [issue20371] datetime.datetime.replace bypasses a subclass's __new__
In-Reply-To: <1390506444.15.0.286575412745.issue20371@psf.upfronthosting.co.za>
Message-ID: <1463056162.34.0.604702183584.issue20371@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.5, Python 3.6 -Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20371>
_______________________________________

From report at bugs.python.org  Thu May 12 08:31:43 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 May 2016 12:31:43 +0000
Subject: [issue26369] unicode.decode and str.encode are unnecessarily
 confusing for non-ascii
In-Reply-To: <1455623938.04.0.928922751587.issue26369@psf.upfronthosting.co.za>
Message-ID: <1463056303.99.0.690781462111.issue26369@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

If str.encode() raises a decoding exception, this is a programming bug. It would be bad to hide it.

FYI, the default encoding is not hardcoded 'ascii'. Google "Changing default encoding in Python". Maybe this will help in your program.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26369>
_______________________________________

From report at bugs.python.org  Thu May 12 08:44:46 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 May 2016 12:44:46 +0000
Subject: [issue27009] multiprocessing Connection data length limited to
 max(int32)
In-Reply-To: <1463054927.27.0.521137668509.issue27009@psf.upfronthosting.co.za>
Message-ID: <1463057086.32.0.191526473626.issue27009@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is a duplicate of issue17560.

----------
nosy: +serhiy.storchaka
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> problem using multiprocessing with really big objects?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27009>
_______________________________________

From report at bugs.python.org  Thu May 12 08:46:13 2016
From: report at bugs.python.org (R. David Murray)
Date: Thu, 12 May 2016 12:46:13 +0000
Subject: [issue27008] error message of ord is not intuitive
In-Reply-To: <1463040290.52.0.305686008758.issue27008@psf.upfronthosting.co.za>
Message-ID: <1463057173.43.0.0307428061981.issue27008@psf.upfronthosting.co.za>


R. David Murray added the comment:

You are right, if it is too big a job to do it all at once, then we can fix them as we find them.  Do you want to propose a patch?

However, in this case I think there is arguably not a bug.  It looks as though the intent is that ord only support strings (see the documentation).  The fact that it supports bytes-like objects is redudant (ord(b'a') == b'a'[0]).  I'd call it a bug that it supports bytes-like objects, but we probably kept (and should keep it) it to make it easier to port python2 code to python3.

So, if any change were to be made here, it would probably be to change the error message if and only if the input is not in fact a string, and perhaps even recommend using the indexing syntax.

On the gripping hand, I've never been a fan of the fact that indexing a byte string gets you an integer :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27008>
_______________________________________

From report at bugs.python.org  Thu May 12 08:47:40 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 May 2016 12:47:40 +0000
Subject: [issue21199] Python on 64-bit Windows uses signed 32-bit type for
 read length
In-Reply-To: <1397149133.44.0.946556558932.issue21199@psf.upfronthosting.co.za>
Message-ID: <1463057260.58.0.669138994901.issue21199@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Ping?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21199>
_______________________________________

From report at bugs.python.org  Thu May 12 08:53:09 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 May 2016 12:53:09 +0000
Subject: [issue24550] maxint on 64 bit platforms breaks os.read
In-Reply-To: <1435814869.69.0.586441983811.issue24550@psf.upfronthosting.co.za>
Message-ID: <1463057589.48.0.211321910451.issue24550@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The 32-bit size limit in multiprocessing is issue17560. AFAIK read() and write() now support 64-bit size on 64-bit systems.

----------
nosy: +haypo, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24550>
_______________________________________

From report at bugs.python.org  Thu May 12 09:27:08 2016
From: report at bugs.python.org (Richard Neumann)
Date: Thu, 12 May 2016 13:27:08 +0000
Subject: [issue25452] Add __bool__() method to subprocess.CompletedProcess
In-Reply-To: <1445424658.54.0.134413313052.issue25452@psf.upfronthosting.co.za>
Message-ID: <1463059628.81.0.67971907701.issue25452@psf.upfronthosting.co.za>


Richard Neumann added the comment:

Please excuse my ambiguous phrasing.
What I meant was I created the patch _from_ the Python 3.5.1 module _for_ Python 3.6.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25452>
_______________________________________

From report at bugs.python.org  Thu May 12 09:59:42 2016
From: report at bugs.python.org (Marcos Dione)
Date: Thu, 12 May 2016 13:59:42 +0000
Subject: [issue26826] Expose new copy_file_range() syscall in os module.
In-Reply-To: <1461325239.41.0.30054024313.issue26826@psf.upfronthosting.co.za>
Message-ID: <1463061582.67.0.774237676282.issue26826@psf.upfronthosting.co.za>


Marcos Dione added the comment:

I settled for s/in/src/ and s/out/dst/, fixed typos, made sure the docs are in sync (parameters in the docstring were out of order), rephrased paragraph about flags parameter and included the configure.ac code for detecting availability of the syscall. I'm also thinking of leaving flags out, what do you think?

----------
Added file: http://bugs.python.org/file42829/copy_file_range.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26826>
_______________________________________

From report at bugs.python.org  Thu May 12 10:00:56 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 May 2016 14:00:56 +0000
Subject: [issue25452] Add __bool__() method to subprocess.CompletedProcess
In-Reply-To: <1445424658.54.0.134413313052.issue25452@psf.upfronthosting.co.za>
Message-ID: <1463061656.78.0.459324992083.issue25452@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is not enough. New feature should be documented (in new method docstring, in subprocess documentation and in What's New document) and tested.

And please sign a Contributor Licensing Agreement.

http://www.python.org/psf/contrib/contrib-form/
http://www.python.org/psf/contrib/

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25452>
_______________________________________

From report at bugs.python.org  Thu May 12 10:02:05 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 12 May 2016 14:02:05 +0000
Subject: [issue21099] Switch applicable importlib tests to use PEP 451 API
In-Reply-To: <1396128875.13.0.712473033591.issue21099@psf.upfronthosting.co.za>
Message-ID: <20160512140136.81015.68449.4405BE07@psf.io>


Roundup Robot added the comment:

New changeset fceaa0dc715e by Eric Snow in branch 'default':
Issue #21099: Switch applicable importlib tests to use PEP 451 API.
https://hg.python.org/cpython/rev/fceaa0dc715e

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21099>
_______________________________________

From report at bugs.python.org  Thu May 12 10:06:05 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 May 2016 14:06:05 +0000
Subject: [issue26765] Factor out common bytes and bytearray implementation
In-Reply-To: <1460707559.13.0.709090380773.issue26765@psf.upfronthosting.co.za>
Message-ID: <1463061965.41.0.593241362131.issue26765@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26765>
_______________________________________

From report at bugs.python.org  Thu May 12 10:35:19 2016
From: report at bugs.python.org (Eric Snow)
Date: Thu, 12 May 2016 14:35:19 +0000
Subject: [issue21099] Switch applicable importlib tests to use PEP 451 API
In-Reply-To: <1396128875.13.0.712473033591.issue21099@psf.upfronthosting.co.za>
Message-ID: <1463063719.8.0.419929752202.issue21099@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.6 -Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21099>
_______________________________________

From report at bugs.python.org  Thu May 12 10:36:21 2016
From: report at bugs.python.org (Eric Snow)
Date: Thu, 12 May 2016 14:36:21 +0000
Subject: [issue19711] add test for changed portions after reloading a
 namespace package
In-Reply-To: <1385138827.34.0.898717139288.issue19711@psf.upfronthosting.co.za>
Message-ID: <1463063781.07.0.28301590924.issue19711@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
versions: +Python 3.6 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19711>
_______________________________________

From report at bugs.python.org  Thu May 12 10:37:11 2016
From: report at bugs.python.org (Eric Snow)
Date: Thu, 12 May 2016 14:37:11 +0000
Subject: [issue18864] Implementation for PEP 451
 (importlib.machinery.ModuleSpec)
In-Reply-To: <1377672978.26.0.119702109188.issue18864@psf.upfronthosting.co.za>
Message-ID: <1463063831.3.0.808615240759.issue18864@psf.upfronthosting.co.za>


Eric Snow added the comment:

The last dependencies have now been closed!

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18864>
_______________________________________

From report at bugs.python.org  Thu May 12 10:38:15 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 12 May 2016 14:38:15 +0000
Subject: [issue27008] error message of ord is not intuitive
In-Reply-To: <1463040290.52.0.305686008758.issue27008@psf.upfronthosting.co.za>
Message-ID: <1463063895.44.0.494210318383.issue27008@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

I also notice the document. I get surprised when I see the implementation also supports bytes while the doc says one unicode character. But then I tell myself that maybe unicode character also includes bytes? I am not sure about the English description.

But giving your opinion that maybe the bytes supports are not intended now, I think leaving the error message untouched is quite OK. It describes what it is intended to do, same as the doc.

Really glad to have your comments, Serhiy and David.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27008>
_______________________________________

From report at bugs.python.org  Thu May 12 10:46:27 2016
From: report at bugs.python.org (Richard Neumann)
Date: Thu, 12 May 2016 14:46:27 +0000
Subject: [issue25452] Add __bool__() method to subprocess.CompletedProcess
In-Reply-To: <1445424658.54.0.134413313052.issue25452@psf.upfronthosting.co.za>
Message-ID: <1463064387.67.0.72500389481.issue25452@psf.upfronthosting.co.za>


Richard Neumann added the comment:

Thank you for the hint.
I never before contributed code to the python foundation and thus am not familiar with the process.
I will look into it when I find the time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25452>
_______________________________________

From report at bugs.python.org  Thu May 12 11:22:50 2016
From: report at bugs.python.org (A. Skrobov)
Date: Thu, 12 May 2016 15:22:50 +0000
Subject: [issue26526] In parsermodule.c,
 replace over 2KLOC of hand-crafted validation code, with a DFA
In-Reply-To: <1457600551.84.0.318395917649.issue26526@psf.upfronthosting.co.za>
Message-ID: <1463066570.97.0.574502658383.issue26526@psf.upfronthosting.co.za>


A. Skrobov added the comment:

Ping? This patch is two months old now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26526>
_______________________________________

From report at bugs.python.org  Thu May 12 11:22:58 2016
From: report at bugs.python.org (A. Skrobov)
Date: Thu, 12 May 2016 15:22:58 +0000
Subject: [issue26415] Fragmentation of the heap memory in the Python parser
In-Reply-To: <1456182380.09.0.81920177296.issue26415@psf.upfronthosting.co.za>
Message-ID: <1463066578.66.0.997174964099.issue26415@psf.upfronthosting.co.za>


A. Skrobov added the comment:

Ping? This patch is two months old now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26415>
_______________________________________

From report at bugs.python.org  Thu May 12 11:27:29 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 12 May 2016 15:27:29 +0000
Subject: [issue26526] In parsermodule.c,
 replace over 2KLOC of hand-crafted validation code, with a DFA
In-Reply-To: <1457600551.84.0.318395917649.issue26526@psf.upfronthosting.co.za>
Message-ID: <1463066849.03.0.700571765601.issue26526@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26526>
_______________________________________

From report at bugs.python.org  Thu May 12 11:42:04 2016
From: report at bugs.python.org (Fedele Mantuano)
Date: Thu, 12 May 2016 15:42:04 +0000
Subject: [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:04:20 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 12 May 2016 16:04:20 +0000
Subject: [issue22570] Better stdlib support for Path objects
In-Reply-To: <1412609631.43.0.978086278536.issue22570@psf.upfronthosting.co.za>
Message-ID: <1463069060.33.0.349122679136.issue22570@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Reopening as we need to rename the path attribute to __fspath__ once Brett's PEP is accepted (which will be soon). https://github.com/brettcannon/path-pep/blob/master/pep-0NNN.rst

The 3.4 and 3.5 versions of this should probably just be reversed before their releases (early June).

----------
resolution: fixed -> out of date
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22570>
_______________________________________

From report at bugs.python.org  Thu May 12 12:11:08 2016
From: report at bugs.python.org (R. David Murray)
Date: Thu, 12 May 2016 16:11:08 +0000
Subject: [issue27008] error message of ord is not intuitive
In-Reply-To: <1463040290.52.0.305686008758.issue27008@psf.upfronthosting.co.za>
Message-ID: <1463069468.28.0.91994734042.issue27008@psf.upfronthosting.co.za>


R. David Murray added the comment:

All right, we'll close this then.

----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27008>
_______________________________________

From report at bugs.python.org  Thu May 12 12:26:15 2016
From: report at bugs.python.org (R. David Murray)
Date: Thu, 12 May 2016 16:26:15 +0000
Subject: [issue27010] Attachments not detected from email library
In-Reply-To: <1463067718.45.0.558318505018.issue27010@psf.upfronthosting.co.za>
Message-ID: <1463070375.81.0.586304921234.issue27010@psf.upfronthosting.co.za>


R. David Murray added the comment:

When you say the attachment is not detected, what do you mean?  What call are you making to the email library that you are expecting to see the attachment in that it is not in?  Your 'parsed' pastebin isn't something the library produces, so I assume that's the Tika output.

(By the way, pastbin links are problematic in tracker issues, since they may expire.  Please paste directly in to the issue, or attach files to the issue.)

Oh, wait.  Looking at the email I think I see the problem:

----------------------------------------
</BODY>
</HTML>

--51a14337d8625bb8ce4a5b1667f--

--51a14337d8625bb8ce4a5b1667f
<attachment content>
----------------------------------------

That line that ends with '--' signals the end of the last MIME part in the message.  So by RFC standards the remainder of the message is part of the 'epilogue'.  If you check msg.epilogue I think you'll find that it contains the raw text of the remainder of the message.

It is interesting that your email client treats it as an actual attachment.  It would be possible to have the email library recognize such out of place mime dividers and register it as an error.  I would review a patch for that if someone wants to propose one.

--David

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27010>
_______________________________________

From report at bugs.python.org  Wed May 11 20:43:28 2016
From: report at bugs.python.org (Erik Rasmussen)
Date: Thu, 12 May 2016 00:43:28 +0000
Subject: [issue27001] Python Interface X-Plane 10.45
In-Reply-To: <CAD-6aYvD7v_YAkBSJkmdrtDePkVHFJ-HBW0QTMQcP36nWTOS_w@mail.gmail.com>
Message-ID: <CAD-6aYv4EYnCviquAnN9M=5YZQBjQ3q9Co-Q3bRsBwUWqO0Arg@mail.gmail.com>


Erik Rasmussen added the comment:

[image: Billede indsat i tekst 1]

 -  Kindly / Mvh -
*E. Rasmussen*
Odense s? - DK

2016-05-12 2:38 GMT+02:00 E. Rasmussen <e00rasmussen at gmail.com>:

> X-plane is a simulator - and I used the attached Interface .. but since
> the new version 2.7.11 it is not working .. and it DID work in version
> 2.7.10 ...
> Have tryed to downgrade Python... but not possible .. for some reason it
> still registered as 2.7.11 , no matter what I do...
> Any Ideas?
>
>  -  Kindly / Mvh -
> *E. Rasmussen*
> Odense s? - DK
>
> 2016-05-12 2:10 GMT+02:00 R. David Murray <report at bugs.python.org>:
>
>>
>> R. David Murray added the comment:
>>
>> I don't know what X-Plane is, but it isn't part of python.  You should
>> talk to the maintainers of it, and if they find there's a bug in python
>> causing problems, open a specific issue about whatever that bug is.  You
>> could also try asking for help on the python-list mailing list.
>>
>> ----------
>> nosy: +r.david.murray
>> resolution:  -> third party
>> stage:  -> resolved
>> status: open -> closed
>>
>> _______________________________________
>> Python tracker <report at bugs.python.org>
>> <http://bugs.python.org/issue27001>
>> _______________________________________
>>
>
>

----------
Added file: http://bugs.python.org/file42823/image.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27001>
_______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 128451 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20160512/3fb5791b/attachment-0001.png>

From report at bugs.python.org  Thu May 12 12:37:08 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Thu, 12 May 2016 16:37:08 +0000
Subject: [issue19711] add test for changed portions after reloading a
 namespace package
In-Reply-To: <1385138827.34.0.898717139288.issue19711@psf.upfronthosting.co.za>
Message-ID: <1463071028.32.0.184623897259.issue19711@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19711>
_______________________________________

From report at bugs.python.org  Thu May 12 12:44:31 2016
From: report at bugs.python.org (Fedele Mantuano)
Date: Thu, 12 May 2016 16:44:31 +0000
Subject: [issue27010] Attachments not detected from email library
In-Reply-To: <1463067718.45.0.558318505018.issue27010@psf.upfronthosting.co.za>
Message-ID: <1463071471.36.0.0486206950308.issue27010@psf.upfronthosting.co.za>


Fedele Mantuano added the comment:

Hi David,

I use email library to detect malicious attachments, so:

message = email.message_from_file(open('mail'))
for i in message.walk():
   do somethings

Not detected means that in for loop I can't see these attachments.

The same problem there is with tika parser (now I attached file).

I think that all automatics tools that using email library can't extract and post analyze these mails.

----------
Added file: http://bugs.python.org/file42831/mail.json

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27010>
_______________________________________

From report at bugs.python.org  Thu May 12 12:49:28 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 12 May 2016 16:49:28 +0000
Subject: [issue6422] timeit called from within Python should allow autoranging
In-Reply-To: <1463028598.38.0.991195359239.issue6422@psf.upfronthosting.co.za>
Message-ID: <20160512164921.GF12028@ando.pearwood.info>


Steven D'Aprano added the comment:

On Thu, May 12, 2016 at 04:49:59AM +0000, Nick Coghlan wrote:
> The embedded side-effects were my main concern with Scott's original 
> patch, so Steven's callback-based approach strikes me as a definite 
> improvement. However, the awkwardness of the revised calling code in 
> main does make me wonder whether or not this might be better 
> implemented as a generator rather than as a function accepting a 
> callback:

I thought about a generator too, but then I thought about the *non* 
verbose case, where you don't care about the intermediate results, only 
the final (number, time_taken) pair.

# function with callback:
number, time_taken = t.autorange()

# generator
number, time_taken = list(t.autorange())[-1]

Which hints that your code snippet is buggy, or at least incomplete:

>     try:
>         results = list(t.autorange())
>     except:
>         t.print_exc()
>         return 1
>     if verbose:
>         for number, time_taken in results:
>             msg = "{} loops -> {:.{}g} secs"
>             print(msg.format(number, time_taken, precision))

If verbose is False, you never set number and time_taken. So you need an 
else clause:

    else:
        number, time_taken = results[-1]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6422>
_______________________________________

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: [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 13:06:43 2016
From: report at bugs.python.org (R. David Murray)
Date: Thu, 12 May 2016 17:06:43 +0000
Subject: [issue27010] email library could "recover" from bad mime boundary
 like (some?) email clients do
In-Reply-To: <1463067718.45.0.558318505018.issue27010@psf.upfronthosting.co.za>
Message-ID: <1463072803.98.0.224016864225.issue27010@psf.upfronthosting.co.za>


R. David Murray added the comment:

I'm going to change the title of this and see if anyone wants to propose a patch. It'll probably end up getting closed as not a bug if no one does for a while, though.

----------
title: Attachments not detected from email library -> email library could "recover" from bad mime boundary like (some?) email clients do
versions: +Python 3.6 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27010>
_______________________________________

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: [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  Thu May 12 16:04:40 2016
From: report at bugs.python.org (R. David Murray)
Date: Thu, 12 May 2016 20:04:40 +0000
Subject: [issue27012] Rename the posix module to _os
In-Reply-To: <1463080606.17.0.881585678376.issue27012@psf.upfronthosting.co.za>
Message-ID: <1463083480.19.0.578660913712.issue27012@psf.upfronthosting.co.za>


R. David Murray added the comment:

I know you know this, but to be clear for other readers, the module naming happens at compile time, not runtime.

If you alias the module, it's __name__ will still be '_os', won't it?  Might that not have backward compatibility issues?  And if you also change that, then what's the point of not having it use an os specific name?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27012>
_______________________________________

From report at bugs.python.org  Thu May 12 16:08:28 2016
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 12 May 2016 20:08:28 +0000
Subject: [issue27012] Rename the posix module to _os
In-Reply-To: <1463080606.17.0.881585678376.issue27012@psf.upfronthosting.co.za>
Message-ID: <1463083708.27.0.834492782986.issue27012@psf.upfronthosting.co.za>


Brett Cannon added the comment:

You're correct that it could break code checking the module's __name__ value if that was changed.

As for why I care, it sucks trying to import this module for any reason. Any place you touch this module you have to proper try/except ImportError checks to work around its multiple names. I just personally think it's a bit silly to have to do that.

Anyway, there's a reason why I marked this a low priority. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27012>
_______________________________________

From report at bugs.python.org  Thu May 12 16:32:45 2016
From: report at bugs.python.org (Ned Deily)
Date: Thu, 12 May 2016 20:32:45 +0000
Subject: [issue26556] Update expat to 2.2.1
In-Reply-To: <1457951495.3.0.910401967595.issue26556@psf.upfronthosting.co.za>
Message-ID: <1463085165.34.0.727939730649.issue26556@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26556>
_______________________________________

From report at bugs.python.org  Thu May 12 16:34:42 2016
From: report at bugs.python.org (Ned Deily)
Date: Thu, 12 May 2016 20:34:42 +0000
Subject: [issue22970] asyncio: Cancelling wait() after notification leaves
 Condition in an inconsistent state
In-Reply-To: <1417404582.01.0.276361050449.issue22970@psf.upfronthosting.co.za>
Message-ID: <1463085282.51.0.93174196843.issue22970@psf.upfronthosting.co.za>


Ned Deily added the comment:

Is this still a Release Blocker for 3.6?

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22970>
_______________________________________

From report at bugs.python.org  Thu May 12 16:38:29 2016
From: report at bugs.python.org (Ned Deily)
Date: Thu, 12 May 2016 20:38:29 +0000
Subject: [issue26556] Update expat to 2.2.1
In-Reply-To: <1457951495.3.0.910401967595.issue26556@psf.upfronthosting.co.za>
Message-ID: <1463085509.9.0.839636168646.issue26556@psf.upfronthosting.co.za>


Ned Deily added the comment:

Any progress on this?  It is still flagged as a Release Blocker and releases are approaching.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26556>
_______________________________________

From report at bugs.python.org  Thu May 12 16:51:13 2016
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 12 May 2016 20:51:13 +0000
Subject: [issue26556] Update expat to 2.2.1
In-Reply-To: <1457951495.3.0.910401967595.issue26556@psf.upfronthosting.co.za>
Message-ID: <1463086273.5.0.708150058817.issue26556@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Another critical bug fix will be released next Tuesday.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26556>
_______________________________________

From report at bugs.python.org  Thu May 12 17:18:22 2016
From: report at bugs.python.org (Colm Buckley)
Date: Thu, 12 May 2016 21:18:22 +0000
Subject: [issue26839] Python 3.5 running in a virtual machine with Linux
 kernel 3.17+ can block at startup or on importing the random module on
 getrandom()
In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za>
Message-ID: <1463087902.48.0.220761536264.issue26839@psf.upfronthosting.co.za>


Colm Buckley added the comment:

It's worth noting that this issue now affects every installation of Debian testing track with systemd and systemd-cron installed; the python program /lib/systemd/system-generators/systemd-crontab-generator is called very early in the boot process; it imports hashlib (although only .md5() is used) and blocks on getrandom(), delaying boot time until a 90s timeout has occurred.

Suggestions: modify hashlib to avoid calling getrandom() until entropy is actually required, rather than on import; change the logic to use /dev/urandom (or an in-process PRNG) when getrandom() blocks; or both.

----------
nosy: +Colm Buckley

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26839>
_______________________________________

From report at bugs.python.org  Thu May 12 17:27:16 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 12 May 2016 21:27:16 +0000
Subject: [issue26632] __all__ decorator
In-Reply-To: <1458786797.31.0.0749407715279.issue26632@psf.upfronthosting.co.za>
Message-ID: <1463088436.91.0.550367077571.issue26632@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

Now with docs and tests.

----------
Added file: http://bugs.python.org/file42833/26632-in-c-5.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26632>
_______________________________________

From report at bugs.python.org  Thu May 12 17:33:32 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 12 May 2016 21:33:32 +0000
Subject: [issue22970] asyncio: Cancelling wait() after notification leaves
 Condition in an inconsistent state
In-Reply-To: <1463085282.51.0.93174196843.issue22970@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJ+jFmJP-qksFLoVj+_FcNkR0kTS_o7xDTisAd4m4voYrg@mail.gmail.com>


Guido van Rossum added the comment:

Presumably. :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22970>
_______________________________________

From report at bugs.python.org  Thu May 12 17:48:02 2016
From: report at bugs.python.org (Colm Buckley)
Date: Thu, 12 May 2016 21:48:02 +0000
Subject: [issue26839] Python 3.5 running in a virtual machine with Linux
 kernel 3.17+ can block at startup or on importing the random module on
 getrandom()
In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za>
Message-ID: <1463089682.06.0.30851636634.issue26839@psf.upfronthosting.co.za>


Colm Buckley added the comment:

Oh; it's not actually hashlib which is calling getrandom(), it's the main runtime - the initialization of the per-process secret hash seed in _PyRandom_Init

Don't know enough about the internal logic here to comment on what the Right Thing is; but I second the suggestion of msg264303. This might just require setting "flags" to GRND_NONBLOCK in py_getrandom() assuming that's portable to other OS.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26839>
_______________________________________

From report at bugs.python.org  Thu May 12 18:47:58 2016
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 12 May 2016 22:47:58 +0000
Subject: [issue26970] Replace OpenSSL's CPRNG with system entropy source
In-Reply-To: <1462525827.05.0.33480267606.issue26970@psf.upfronthosting.co.za>
Message-ID: <1463093278.87.0.800498194381.issue26970@psf.upfronthosting.co.za>


Christian Heimes added the comment:

I have to replace _PyOS_URandom with a variant that doesn't need the GIL, https://mail.python.org/pipermail/cryptography-dev/2016-May/000595.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26970>
_______________________________________

From report at bugs.python.org  Thu May 12 18:48:26 2016
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 12 May 2016 22:48:26 +0000
Subject: [issue26359] CPython build options for out-of-the box performance
In-Reply-To: <1455445693.01.0.984013993837.issue26359@psf.upfronthosting.co.za>
Message-ID: <1463093306.11.0.102974457114.issue26359@psf.upfronthosting.co.za>


Brett Cannon added the comment:

The patch LGTM but I'm not a configure/make expert. Anyone else want to have a look?

Alecsandru, if no one takes a look within the next week then just assign the issue to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26359>
_______________________________________

From report at bugs.python.org  Thu May 12 18:57:27 2016
From: report at bugs.python.org (Vinay Sajip)
Date: Thu, 12 May 2016 22:57:27 +0000
Subject: [issue26999] Add child separator keyword to logging.basicConfig and
 use it in Logger.getChild()
In-Reply-To: <1462972267.52.0.758666146863.issue26999@psf.upfronthosting.co.za>
Message-ID: <1463093847.01.0.527153005622.issue26999@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

> However, if you still think that this is not, what the logging library is meant for, I'd appreciate to know.

Confirmed. I would advise against using logger names in this way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26999>
_______________________________________

From report at bugs.python.org  Thu May 12 20:26:59 2016
From: report at bugs.python.org (Eric Snow)
Date: Fri, 13 May 2016 00:26:59 +0000
Subject: [issue24254] Make class definition namespace ordered by default
In-Reply-To: <1432186488.39.0.20621749373.issue24254@psf.upfronthosting.co.za>
Message-ID: <1463099219.87.0.464251297502.issue24254@psf.upfronthosting.co.za>


Eric Snow added the comment:

Here's a refresh of the patch that only sets the default definition namespace (and does not introduce __definition_order__).

----------
Added file: http://bugs.python.org/file42834/just-default-to-odict.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24254>
_______________________________________

From report at bugs.python.org  Thu May 12 20:28:28 2016
From: report at bugs.python.org (Eric Snow)
Date: Fri, 13 May 2016 00:28:28 +0000
Subject: [issue24254] Make class definition namespace ordered by default
In-Reply-To: <1432186488.39.0.20621749373.issue24254@psf.upfronthosting.co.za>
Message-ID: <1463099308.27.0.141855170203.issue24254@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


Removed file: http://bugs.python.org/file39456/just-default-to-odict.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24254>
_______________________________________

From report at bugs.python.org  Thu May 12 20:45:59 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 13 May 2016 00:45:59 +0000
Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not
 available (e.g., AIX)
In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za>
Message-ID: <1463100359.28.0.83634743721.issue26439@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for trying to move the directory in the new patch, but it does not seem to have been picked up by Rietveld. I have only seen patches generated with Mercurial and Git work, but I don?t exactly know _why_ they work :)

Here is a summary of what I would be comfortable adding to Python:

1. Add ctypes.RTLD_MEMBER constant (new API, so 3.6+ only)

2. Basic ctypes.util.find_library("crypto") implementation for AIX. But cases like find_library("libintl.so") should fail. I think your earlier patches were closer to this implementation than the later ones.

I am a bit hesitant about the automatic behaviour of CDLL("libcrypto.a(libcrypto.so.1.0.0)") using RTLD_MEMBER. IMO it may be better to let the caller specify RTLD_MEMBER explicitly. If a shared library file literally called ?/usr/lib/libcrypto.a(libcrypto.so.1.0.0)? existed, i.e. not inside an archive, would dlopen("libcrypto.a(libcrypto.so.1.0.0)", RTLD_NOW) succeed? I admit this is an unlikely scenario, but it seems bad to reduce the domain of a low-level API.

I understand it would be good to have the return value of find_library() consistent with the name accepted by CDLL(). Perhaps a new parameter format would help, such as a tuple (archive, member).

I am not comfortable with other aspects. I think I would have to see more discussion with other people to change my opinion:

1. CDLL("libintl.so") should not load ?libintl.a(libintl.so.1)?. I understand you want this to help code written for Gnu or Linux automatically work on AIX, but it doesn?t feel correct and robust to me. Perhaps moving this sort of thing to a separate function or package would be better.

2. find_library("libintl.so") -> "libintl.a(libintl.so.1)". I would expect it to look for a shared library installed in something like "/usr/lib/liblibintl.so.a", unless I have misunderstood how compile-time linking (cc -llibintl.so) works.

3. find_library() should not set the LIBPATH environment variable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26439>
_______________________________________

From report at bugs.python.org  Thu May 12 21:20:34 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 13 May 2016 01:20:34 +0000
Subject: [issue26993] Copy idlelib *.py files with new names
In-Reply-To: <1462904867.82.0.814804625056.issue26993@psf.upfronthosting.co.za>
Message-ID: <1463102434.47.0.885560166489.issue26993@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I should have explained my usage of 'idle2' and 'idle3'.  'Idle1' was the original IDLE that executed user code in the idle process.  'Idle2' was the re-write, still in use, that executes user code in a separate process.  'Idle3' is intended to be a re-write of similar scope that uses ttk, but also refactors to make automated tests and other changes easier.  (Adding multi-pane windows might be called 'idle4'.)  It is the tests and other changes that require refactoring.  Hence 'ttk-idle' partly misses the point unless understood as including name changes and refactoring.

For the idle2 re-writes, all the new code needed to execute remotely, by default, while keeping local execution as an option, had to be in place for any of it to be useful. The idle3 changes can be broken up into multiple usable and testable pieces.  I wish the renames could be in alpha1 and definitely want them in alpha2, along with a notice in What's New.  Anyone who has code that will break because of the changes should have opportunity to find out as soon as possible.  I would like to do simple ttk replacements by alpha 3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26993>
_______________________________________

From report at bugs.python.org  Thu May 12 21:31:10 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 13 May 2016 01:31:10 +0000
Subject: [issue26993] Copy idlelib *.py files with new names
In-Reply-To: <1462904867.82.0.814804625056.issue26993@psf.upfronthosting.co.za>
Message-ID: <1463103070.85.0.15700097009.issue26993@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

In response to Nick's point 4: To me, these are important aspects of 'in the stdlib'.

First is having issues on this tracker.  As Guido said in his King Day speech, non-trivial software is a collective project.  IDLE needs continued access to dependency experts, such as Serhiy for tkinter, and platform experts, such as Ned for Mac.  In April, I nosyed Kristj?n Valur J?nsson to ask an IDLE question that seemed related to a socket patch he pushed, and he helpfully answered.  On the other side, users are much more likely to participate here than on a separate tracker.

Second is being easily installable with the rest of Python.  I think some out-of-the-box augment to the console is crucial on Windows.

I am aware that Linux distributions have a separate tkinter-gui install instead of just a checkbox option.  I think it should consistently, on all plateforms, comprise _tkinter, tkinter, idlelib, turtle, and turtledemo.

All of those except idlelib are documented even though optional.  So I think idlelib could be also.  But documenting direct usage, which Nick recommended in #24225, could be relegated to the modules themselves and the idlelib README or a new text file.  Ditto for indicating replacements for thing known or strongly  suspected of external use.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26993>
_______________________________________

From report at bugs.python.org  Thu May 12 22:31:18 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 13 May 2016 02:31:18 +0000
Subject: [issue24550] maxint on 64 bit platforms breaks os.read
In-Reply-To: <1435814869.69.0.586441983811.issue24550@psf.upfronthosting.co.za>
Message-ID: <1463106678.79.0.731048868588.issue24550@psf.upfronthosting.co.za>


Martin Panter added the comment:

Yes 3.5 should do 64-bit reads (if you have enough memory) thanks to revision 0c57aba6b1a3 (Argument Clinic conversion):

>>> os.read(0, 2**32)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
MemoryError
>>> os.read(0, 2**63)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: Python int too large to convert to C ssize_t

I understand 3.4 is only open to security fixes, not changes like this. But 2.7 is affected:

>>> os.read(0, 2**32)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: signed integer is greater than maximum

I guess this could be considered a bug in 2.7 (not an enhancement), but I?m not really sure.

----------
nosy: +martin.panter
versions: +Python 2.7 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24550>
_______________________________________

From report at bugs.python.org  Thu May 12 22:46:12 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 13 May 2016 02:46:12 +0000
Subject: [issue27003] Python 3.5.1 fails at HTTPSTest with SSL CERT error
In-Reply-To: <1462994596.94.0.421418085673.issue27003@psf.upfronthosting.co.za>
Message-ID: <1463107572.16.0.437633579403.issue27003@psf.upfronthosting.co.za>


Martin Panter added the comment:

After 3.5.1 was released, there were some SSL certificate changes with a server (ab)used in the test suite. See Issue 25940. The result was that I changed some tests over to use the https://self-signed.pythontest.net/ server, and I had to enable the CA flag in its certificate (https://hg.python.org/pythontestdotnet/rev/1882edb402ab).

A workaround might be to grab the updated Lib/test/selfsigned_pythontestdotnet.pem file, and perhaps some of the other changes made in Issue 25940 if necessary.

----------
nosy: +martin.panter
resolution:  -> out of date
status: open -> closed
superseder:  -> SSL tests failed due to expired svn.python.org SSL certificate

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27003>
_______________________________________

From report at bugs.python.org  Thu May 12 22:47:35 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 13 May 2016 02:47:35 +0000
Subject: [issue27003] Python 3.5.1 fails at HTTPSTest with SSL CERT error
In-Reply-To: <1462994596.94.0.421418085673.issue27003@psf.upfronthosting.co.za>
Message-ID: <1463107655.06.0.102824587471.issue27003@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
components: +Tests -Extension Modules

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27003>
_______________________________________

From report at bugs.python.org  Thu May 12 23:06:10 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 13 May 2016 03:06:10 +0000
Subject: [issue26993] Copy idlelib *.py files with new names
In-Reply-To: <1462904867.82.0.814804625056.issue26993@psf.upfronthosting.co.za>
Message-ID: <1463108770.01.0.396450667724.issue26993@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Both Serhiy and Ned have expressed concern about the difficulty of merging patches from 3.5 to 3.6 once the 3.6 files are renamed.  To me, this is a non-issue since I don't expect to do that more than a few times, and some may be null merges of backports of fixes originally developed for and applied to 3.6.  And I don't expect another core developer to start applying patches to 3.5.

Hence my opinion that I should use hg rename, to keep continuity of revision history as much as possible, and that I should push a complete rename patch as soom as possible.

Two things that I *will* apply to 3.5, if and when possible, are fixing the third regression (Idle preferences not opening on Linux with tk 8.6, #26673) and fixing freezing of Macs when clicking on a completion window (#15786).

To me, this issue is a start on paying down IDLE's technical debt.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26993>
_______________________________________

From report at bugs.python.org  Thu May 12 23:17:56 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 13 May 2016 03:17:56 +0000
Subject: [issue26826] Expose new copy_file_range() syscall in os module.
In-Reply-To: <1461325239.41.0.30054024313.issue26826@psf.upfronthosting.co.za>
Message-ID: <1463109476.76.0.108788784178.issue26826@psf.upfronthosting.co.za>


Martin Panter added the comment:

Another option could be to use Serhiy?s proposed partial keywords support in Issue 26282. It is not yet committed, but it looks like it will go ahead, and then you could make ?in? and ?out? positional-only parameters, and the rest keywords. But IMO ?src? and ?dst? is fine.

Also, dropping ?flags? support seems reasonable. One benefit is that if Linux added an unexpected flag in the future that conflicts with Python?s assumptions, it could do weird stuff or crash Python. See Issue 24933 for example, where socket.recv(n, MSG_TRUNC) returns uninitialized data.

The latest patch looks pretty good to me. Is there a consensus yet to add it as a public function? Before this goes in, it would be good to have a test case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26826>
_______________________________________

From report at bugs.python.org  Thu May 12 23:46:33 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 13 May 2016 03:46:33 +0000
Subject: [issue6422] timeit called from within Python should allow autoranging
In-Reply-To: <1246806912.2.0.722769600334.issue6422@psf.upfronthosting.co.za>
Message-ID: <1463111193.03.0.776668940178.issue6422@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Good point - given that, +1 from me for the callback based version, especially since exception chaining will still disambiguate failures in the callback from other errors.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6422>
_______________________________________

From report at bugs.python.org  Fri May 13 00:04:54 2016
From: report at bugs.python.org (Demur Rumed)
Date: Fri, 13 May 2016 04:04:54 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1463112294.87.0.287247306933.issue26647@psf.upfronthosting.co.za>


Changes by Demur Rumed <gunkmute at gmail.com>:


Added file: http://bugs.python.org/file42835/wpy8.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Fri May 13 00:49:52 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 13 May 2016 04:49:52 +0000
Subject: [issue21313] Py_GetVersion() is broken when using mqueue and a long
 patch name
In-Reply-To: <1397945838.86.0.227153547567.issue21313@psf.upfronthosting.co.za>
Message-ID: <1463114992.88.0.669383616161.issue21313@psf.upfronthosting.co.za>


Martin Panter added the comment:

Currently Py_GetBuildInfo() just returns a long untruncated string. Perhaps it would be safer to leave that as it is, and just make the parsing in the ?platform? module more tolerant. What do you think?

I never really cared about the details in Py_GetBuildInfo(), but it would be nice if the test suite would run :)

----------
keywords: +patch
nosy: +martin.panter
versions: +Python 3.6 -Python 3.4
Added file: http://bugs.python.org/file42836/parse-version.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21313>
_______________________________________

From report at bugs.python.org  Fri May 13 00:56:35 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 13 May 2016 04:56:35 +0000
Subject: [issue21313] Py_GetVersion() is broken when using mqueue and a long
 patch name
In-Reply-To: <1397945838.86.0.227153547567.issue21313@psf.upfronthosting.co.za>
Message-ID: <1463115395.43.0.82943195589.issue21313@psf.upfronthosting.co.za>


Martin Panter added the comment:

>>> Py_GetBuildInfo = pythonapi.Py_GetBuildInfo
>>> Py_GetBuildInfo.restype = c_char_p
>>> Py_GetBuildInfo()  # Not truncated
'qbase qtip subprocess-stderr_redirect_with_no_stdout_redirect-2.diff tip:0b641285389d+, May 13 2016, 02:10:26'

Demo of my problem with the test suite:

$ ./python -m test.regrtest
Traceback (most recent call last):
  [. . .]
  File "/media/disk/home/proj/python/cpython/Lib/test/test_support.py", line 1423, in check_impl_detail
    return guards.get(platform.python_implementation().lower(), default)
  File "/media/disk/home/proj/python/cpython/Lib/platform.py", line 1451, in python_implementation
    return _sys_version()[0]
  File "/media/disk/home/proj/python/cpython/Lib/platform.py", line 1416, in _sys_version
    repr(sys_version))
ValueError: failed to parse CPython sys.version: '2.7.11+ (qbase qtip subprocess-stderr_redirect_with_no_stdout_redirect-2.diff tip:0b64128) \n[GCC 5.3.0]'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21313>
_______________________________________

From report at bugs.python.org  Fri May 13 01:41:25 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 May 2016 05:41:25 +0000
Subject: [issue24550] maxint on 64 bit platforms breaks os.read
In-Reply-To: <1435814869.69.0.586441983811.issue24550@psf.upfronthosting.co.za>
Message-ID: <1463118085.86.0.14969567056.issue24550@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There is more specific issue for 32-bit reads in 2.7 (with patch): issue21199.

I think this issue can be closed as a duplicate of two other issues.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24550>
_______________________________________

From report at bugs.python.org  Fri May 13 01:48:16 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 13 May 2016 05:48:16 +0000
Subject: [issue15786] IDLE code completion window can hang or misbehave with
 mouse
In-Reply-To: <1346027701.33.0.908436854594.issue15786@psf.upfronthosting.co.za>
Message-ID: <1463118496.61.0.984485849847.issue15786@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I experimented more with 3.5.1, Win 10 and formulated a question and hypothesis.

In a text widget, pressing button 1 (usually the left) moves the cursor to the nearest between-character slice line.  Hold the button down allows selecting text.  Releasing and pressing again selects a word after moving the cursor.  Pretty standard behavior, independent of IDLE.  I believe the bindings are Text class rather than instance bindings.

When a completion box is present, button 1 down outside the box dismiss the box and moves the cursor.  I believe this is intended.  I don't know how general this behavior is.

The IDLE completion box binds the button *release* to, I believe, "move cursor to line clicked and display line in text".  A double click is supposed to do something more.  So the button1 press event goes to the Text, which dismisses the popup and moves the cursor.

Question: does the text widget freezes on button down or not until button up.  The experiment is to press and hold the button while moving the mouse.  Does the cursor move and select text while the button is down, or does it freeze immediately.  Paul, could you try this?

Hypothesis (cause): a delicate timing issue? Is the button-up event somehow 'half-caught'?

Hypothesis (fix): prevent the text from seeing or acting on the button down event.  It should be possible to have the completion box catch the down event first and return 'break'.  My first attempt failed but I was too tired to continue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15786>
_______________________________________

From report at bugs.python.org  Fri May 13 02:11:26 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 May 2016 06:11:26 +0000
Subject: [issue26073] Update the list of magic numbers in launcher
In-Reply-To: <1452412193.99.0.751958856998.issue26073@psf.upfronthosting.co.za>
Message-ID: <1463119886.85.0.38547755411.issue26073@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Steve, could you please add a comment in Lib/importlib/_bootstrap_external.py about the need to update PC/launcher.c?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26073>
_______________________________________

From report at bugs.python.org  Fri May 13 02:14:40 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 May 2016 06:14:40 +0000
Subject: [issue27011] Identation error
Message-ID: <20160513061435.88900.68300.5681C5B9@psf.io>


New submission from Roundup Robot:

New changeset 2c6b6667a26e by Benjamin Peterson in branch '3.5':
fix indentation of comments in cellobject.c (closes #27011)
https://hg.python.org/cpython/rev/2c6b6667a26e

New changeset 907b13eb24d0 by Benjamin Peterson in branch '2.7':
fix indentation of comments in cellobject.c (closes #27011)
https://hg.python.org/cpython/rev/907b13eb24d0

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27011>
_______________________________________

From report at bugs.python.org  Fri May 13 02:20:46 2016
From: report at bugs.python.org (aixtools)
Date: Fri, 13 May 2016 06:20:46 +0000
Subject: [issue11063] uuid.py module import has heavy side effects
In-Reply-To: <1462677894.34.0.849473945862.issue11063@psf.upfronthosting.co.za>
Message-ID: <5735724A.7060709@gmail.com>


aixtools added the comment:

The way I have seen that resolved - in many locations, is to have the 
option to specify a specific version, e.g., libFOO.so.1 and then as long 
as that version remains available, perhaps as read-only for running with 
existing programs,they continue to work even when libFOO.so.2. However, 
for some who believes, or expects, to be able to deal with potential ABI 
changes - they can specify simply libFOO.so and let the loader decide 
(what I see is that libFOO.so is a symbolic link to, or a copy of the 
latest version.)

So, I agree wholeheartedly, if a versioned number is requested, that, or 
nothing, should be returned. However, if it is generic - try to find a 
generic named library (and get the link or copy), and when that is not 
available either, take the latest versioned number.

It has been over two months, and I may have read it wrong - but that 
appears to be what the current "ldconfig -p" solution implements. (in 
ctypes, not uuid, so perhaps this is not the correct place to be 
responding. If so, my apologies).

On 08-May-16 05:24, Martin Panter wrote:
> Martin Panter added the comment:
>
> The versioning problem with libFOO.so.N already occurs with compiled programs. A C program compiled against libuuid.so.1 will fail to load if you only have libuuid.so.2. On the other hand, a Python program using find_library() will find either version. My point about robustness is that if a version 2 is invented, it might have different semantics or function signatures, and Python would then be assuming the wrong semantics.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue11063>
> _______________________________________

----------
nosy: +aixtools at gmail.com

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11063>
_______________________________________

From report at bugs.python.org  Fri May 13 02:25:00 2016
From: report at bugs.python.org (paul czyzewski)
Date: Fri, 13 May 2016 06:25:00 +0000
Subject: [issue15786] IDLE code completion window can hang or misbehave with
 mouse
In-Reply-To: <1346027701.33.0.908436854594.issue15786@psf.upfronthosting.co.za>
Message-ID: <1463120700.42.0.215721204831.issue15786@psf.upfronthosting.co.za>


paul czyzewski added the comment:

> Question: does the text widget freezes on button down or not until button up.  The experiment is to press and hold the button while moving the mouse.  Does the cursor move and select text while the button is down, or does it freeze immediately.  Paul, could you try this?

Hi Terry, 
   It's definitely on button down.  The popup immediately disappears and I'm hung, without ever releasing the mouse button.

  Newbie question: what is the "normal" way to use this feature.  I see that it apparently only works when I'm at the dot (eg, at   op.  ). So,if I want op.getcwd, I have to scroll a *long* way to get to it (rather than, eg, tyep   op.g or whatever) and then, when op.getcwd shows (below the box), I need to type "()" and hit return.  this seems a bit painful.  Is that the best use of this feature?

  Paul

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15786>
_______________________________________

From report at bugs.python.org  Fri May 13 03:55:51 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 May 2016 07:55:51 +0000
Subject: [issue22274] subprocess.Popen(stderr=STDOUT) fails to redirect
 subprocess stderr to stdout
In-Reply-To: <1409003162.0.0.312391949761.issue22274@psf.upfronthosting.co.za>
Message-ID: <20160513075547.26208.87927.E884ECCE@psf.io>


Roundup Robot added the comment:

New changeset 642933771fa5 by Martin Panter in branch '3.5':
Issue #22274: Redirect stderr=STDOUT when stdout not redirected, by Akira Li
https://hg.python.org/cpython/rev/642933771fa5

New changeset 5979e7aadd59 by Martin Panter in branch 'default':
Issue #22274: Merge stderr=STDOUT fix from 3.5
https://hg.python.org/cpython/rev/5979e7aadd59

New changeset 5f46ecaf8c6e by Martin Panter in branch '2.7':
Issue #22274: Redirect stderr=STDOUT when stdout not redirected, by Akira Li
https://hg.python.org/cpython/rev/5f46ecaf8c6e

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22274>
_______________________________________

From report at bugs.python.org  Fri May 13 04:18:43 2016
From: report at bugs.python.org (Colm Buckley)
Date: Fri, 13 May 2016 08:18:43 +0000
Subject: [issue26839] Python 3.5 running in a virtual machine with Linux
 kernel 3.17+ can block at startup or on importing the random module on
 getrandom()
In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za>
Message-ID: <1463127523.86.0.358210205168.issue26839@psf.upfronthosting.co.za>


Colm Buckley added the comment:

The attached patch (against 20160330) addresses the issue for me on Linux; it has not been tested on other platforms. It adds the GRND_NONBLOCK flag to the getrandom() call and sends the appropriate failure return if it returns due to lack of entropy. The enclosing functions fall back to reading from /dev/urandom in this case.

Affected files:

Python/random.c - changes to py_getrandom()
configure.ac and pyconfig.h.in - look for linux/random.h for inclusion

Can this, or something similar, be considered for integration with mainline?

----------
keywords: +patch
Added file: http://bugs.python.org/file42837/nonblocking-getrandom.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26839>
_______________________________________

From report at bugs.python.org  Fri May 13 04:35:38 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 May 2016 08:35:38 +0000
Subject: [issue26892] debuglevel not honored in urllib
In-Reply-To: <1462010683.91.0.12780176416.issue26892@psf.upfronthosting.co.za>
Message-ID: <20160513083535.22612.26457.E0B0AEA1@psf.io>


Roundup Robot added the comment:

New changeset 63e23b2dedcc by Senthil Kumaran in branch '3.5':
Issue #26892: Honor debuglevel flag in urllib.request.HTTPHandler.
https://hg.python.org/cpython/rev/63e23b2dedcc

New changeset e0ec68d46464 by Senthil Kumaran in branch 'default':
merge from 3.5
https://hg.python.org/cpython/rev/e0ec68d46464

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26892>
_______________________________________

From report at bugs.python.org  Fri May 13 04:36:15 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 13 May 2016 08:36:15 +0000
Subject: [issue26892] debuglevel not honored in urllib
In-Reply-To: <1462010683.91.0.12780176416.issue26892@psf.upfronthosting.co.za>
Message-ID: <1463128575.97.0.516702745529.issue26892@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Thank you for the patch, Chi Hsuan Yen.

----------
assignee:  -> orsenthil
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26892>
_______________________________________

From report at bugs.python.org  Fri May 13 04:48:56 2016
From: report at bugs.python.org (Jonas H.)
Date: Fri, 13 May 2016 08:48:56 +0000
Subject: [issue24358] Should compression file-like objects provide .fileno(), 
 misleading subprocess?
In-Reply-To: <1433206981.32.0.719516838977.issue24358@psf.upfronthosting.co.za>
Message-ID: <1463129336.75.0.259338274398.issue24358@psf.upfronthosting.co.za>


Jonas H. added the comment:

I just hit this too. I'd say remove the fileno() method from wrapper objects like GzipFile. I'm happy to submit a patch.

----------
nosy: +jonash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24358>
_______________________________________

From report at bugs.python.org  Fri May 13 04:56:35 2016
From: report at bugs.python.org (Tal Einat)
Date: Fri, 13 May 2016 08:56:35 +0000
Subject: [issue15786] IDLE code completion window can hang or misbehave with
 mouse
In-Reply-To: <1346027701.33.0.908436854594.issue15786@psf.upfronthosting.co.za>
Message-ID: <1463129795.24.0.242006477419.issue15786@psf.upfronthosting.co.za>


Tal Einat added the comment:

Regarding your questions about completion behavior:

You don't have to scroll, you can continue typing and the completion list will filter itself to options that match the additional characters. Deleting characters works too (options reappear in the list).

The second thing you mention is having to manually type the parenthesis after completing a function/method name. A long time ago, I had a prototype which added them automatically, but I never got it polished enough to add to IDLE. However, this has rarely been raised as a request. Also, Terry said he wants to refactor the code and get it well tested, so I imagine new features like this won't get in any time soon...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15786>
_______________________________________

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: [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 05:07:35 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 13 May 2016 09:07:35 +0000
Subject: [issue26919] android: test_cmd_line fails
In-Reply-To: <1462267115.39.0.594600458307.issue26919@psf.upfronthosting.co.za>
Message-ID: <1463130455.08.0.390446827969.issue26919@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

This patch follows Victor suggestion in msg230407 and brings the changes made in issue #4388 and issue #16416 to the Android platform. As a consequence, it adds a new test for Android in test_cmd_line named test_osx_android_utf8 (was previously test_osx_utf8). The platform.android_ver() function is defined by issue #26855: "add platform.android_ver() for android".

With this patch test_cmd_line does not have any failure.

----------
keywords: +patch
Added file: http://bugs.python.org/file42838/retrofit_osx.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26919>
_______________________________________

From report at bugs.python.org  Fri May 13 05:58:04 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 13 May 2016 09:58:04 +0000
Subject: [issue26039] More flexibility in zipfile write interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <1463133484.53.0.191350601053.issue26039@psf.upfronthosting.co.za>


Martin Panter added the comment:

Yes this looks okay to me, so go ahead.

My only concern was other methods affecting the file position while in the middle of writing, but it looks like those methods maintain separate objects like self.filelist, so there is no conflict.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26039>
_______________________________________

From report at bugs.python.org  Fri May 13 06:00:07 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 13 May 2016 10:00:07 +0000
Subject: [issue22274] subprocess.Popen(stderr=STDOUT) fails to redirect
 subprocess stderr to stdout
In-Reply-To: <1409003162.0.0.312391949761.issue22274@psf.upfronthosting.co.za>
Message-ID: <1463133607.23.0.769441958848.issue22274@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for the patch Akira.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22274>
_______________________________________

From report at bugs.python.org  Fri May 13 06:53:31 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 May 2016 10:53:31 +0000
Subject: [issue26039] More flexibility in zipfile write interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <20160513105328.30895.47212.D6B10CA5@psf.io>


Roundup Robot added the comment:

New changeset 175c3f1d0256 by Serhiy Storchaka in branch 'default':
Issue #26039: zipfile.ZipFile.open() can now be used to write data into a ZIP
https://hg.python.org/cpython/rev/175c3f1d0256

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26039>
_______________________________________

From report at bugs.python.org  Fri May 13 07:11:54 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 13 May 2016 11:11:54 +0000
Subject: [issue26919] android: test_cmd_line fails
In-Reply-To: <1462267115.39.0.594600458307.issue26919@psf.upfronthosting.co.za>
Message-ID: <1463137914.22.0.270139692878.issue26919@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Patch updated after vadmium review.

----------
Added file: http://bugs.python.org/file42839/retrofit_osx_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26919>
_______________________________________

From report at bugs.python.org  Fri May 13 07:15:11 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 13 May 2016 11:15:11 +0000
Subject: [issue26920] android: test_sys fails
In-Reply-To: <1462267582.58.0.744255750518.issue26920@psf.upfronthosting.co.za>
Message-ID: <1463138111.56.0.499508893534.issue26920@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

test_ioencoding_nonascii does not fail when LANG is set to en_GB.UTF-8 in the environment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26920>
_______________________________________

From report at bugs.python.org  Fri May 13 07:36:25 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 13 May 2016 11:36:25 +0000
Subject: [issue24358] Should compression file-like objects provide .fileno(), 
 misleading subprocess?
In-Reply-To: <1433206981.32.0.719516838977.issue24358@psf.upfronthosting.co.za>
Message-ID: <1463139385.52.0.457602360849.issue24358@psf.upfronthosting.co.za>


Martin Panter added the comment:

Where would you draw the line though? At one extreme, BufferedWriter is a wrapper, but if you removed BufferedWriter.fileno() it would break all the code that does

with open(os.devnull, "wb") as null:
    proc = subprocess.Popen(..., stdout=null)

Would you remove it from HTTPResponse? Some HTTP responses can be chunked, so the child process would see the chunk headers using fileno(). But other HTTP responses are more direct and would work smoothly with the subprocess module.

Considering the compatibility problems and other possible uses of fileno(), I suspect removing it would be a bad idea. ?Throwing the baby out with the bathwater? comes to mind. A less drastic change would be to require an explicit fileno() call and only passing the file descriptor to subprocess.

There is already a bug open for improving the documentation: Issue 19992

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24358>
_______________________________________

From report at bugs.python.org  Fri May 13 07:42:31 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 13 May 2016 11:42:31 +0000
Subject: [issue19992] subprocess documentation not explicit about fileno()
In-Reply-To: <1387158760.79.0.499761911724.issue19992@psf.upfronthosting.co.za>
Message-ID: <1463139751.87.0.779342157709.issue19992@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
stage:  -> needs patch
versions: +Python 2.7, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19992>
_______________________________________

From report at bugs.python.org  Fri May 13 07:47:38 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 13 May 2016 11:47:38 +0000
Subject: [issue26920] android: test_sys fails
In-Reply-To: <1462267582.58.0.744255750518.issue26920@psf.upfronthosting.co.za>
Message-ID: <1463140058.17.0.0903629570456.issue26920@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

> test_ioencoding_nonascii does not fail when LANG is set to en_GB.UTF-8 in the environment.

When LANG is not set, we have on an android emulator:

>>> from test.support import FS_NONASCII
>>> print(FS_NONASCII)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode character '\xe6' in position 0: ordinal not in range(128)


But on linux when LANG is not set:

$ LANG= ./python
Python 3.6.0a0 (default:eee959fee5f5+, May 13 2016, 11:32:27) 
[GCC 6.1.1 20160501] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from test.support import FS_NONASCII
>>> print(FS_NONASCII)
None
>>> 

And test_ioencoding_nonascii is skipped accordingly on linux for the following printed reason: 'requires OS support of non-ASCII encodings'.

On Android, os.fsdecode(os.fsencode('\xe6')) does not raise UnicodeError in the test.support module. And locale.getpreferredencoding() returns 'ascii'. So it seems that this criterion (FS_NONASCII is not None) is not sufficient to decide when this test should be run and not skipped.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26920>
_______________________________________

From report at bugs.python.org  Fri May 13 07:56:54 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 13 May 2016 11:56:54 +0000
Subject: [issue15786] IDLE code completion window can hang or misbehave with
 mouse
In-Reply-To: <1346027701.33.0.908436854594.issue15786@psf.upfronthosting.co.za>
Message-ID: <1463140614.79.0.13875450632.issue15786@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Thanks Paul, that will probably be helpful somehow.  I was expecting the opposite.  Hmmmm.

Box comes up after cntl-space or time delay after key char.  I have time delay much shorter than default.  I do what Tal said  -- type a couple of letters, then sometimes use down arrow key, I guess I learned years ago not to click, and had forgotten, so I seldom have a problem.  But I completely understand that a new user could get very upset.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15786>
_______________________________________

From report at bugs.python.org  Fri May 13 08:03:26 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 13 May 2016 12:03:26 +0000
Subject: [issue27013] IDLE completion for dict keys
In-Reply-To: <1463130033.92.0.0595376142117.issue27013@psf.upfronthosting.co.za>
Message-ID: <1463141006.61.0.317551704222.issue27013@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

#21261 has a patch that I have not looked at.  Comment and review welcome.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Teach IDLE to Autocomplete dictionary keys

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27013>
_______________________________________

From report at bugs.python.org  Fri May 13 08:04:04 2016
From: report at bugs.python.org (Sergey B Kirpichev)
Date: Fri, 13 May 2016 12:04:04 +0000
Subject: [issue26092] doctest should allow custom sys.displayhook
In-Reply-To: <1452622857.37.0.137754453324.issue26092@psf.upfronthosting.co.za>
Message-ID: <1463141044.17.0.296311935682.issue26092@psf.upfronthosting.co.za>


Sergey B Kirpichev added the comment:

> What problem does replacing __displayhook__ provoke?

I don't know for sure.

But the documentation says "These objects contain the original values of displayhook and excepthook at the start of the program."  So, other code in stdlib may assume something about __displayhook__ value.  I.e. it writes the values it gets to sys.stdout.  (Apparently, doctest thinks so.) Such assumptions should be documented, before people can override __displayhook__ safely.

> What solution do you propose instead of 8048, which fixed a bug?

IMHO, it's not a bug.  Why not override sys.displayhook just for doctests in this application?

PS:
Sorry for late answer, somehow I haven't got mail notification after your reply.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26092>
_______________________________________

From report at bugs.python.org  Fri May 13 08:11:01 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 13 May 2016 12:11:01 +0000
Subject: [issue22141] rlcompleter.Completer matches too much
In-Reply-To: <1407254399.39.0.799670201718.issue22141@psf.upfronthosting.co.za>
Message-ID: <1463141461.3.0.685222076551.issue22141@psf.upfronthosting.co.za>


Martin Panter added the comment:

Maybe there are two special cases colliding here:

1. complete("A.foo", 0) returns "A.foo(". But the opening bracket is in readline.get_completer_delims(), which means the completer has suggested not only a ?word? but also a delimiter.

2. Perhaps Lorenz has taken "A.foo(" directly and passed it back to the completer. But as Robert said, if Readline were used, it would see the bracket as a delimiter, and only pass an empty string as the text.

The question is how should the completer behave when it gets (invalid) input that would not be possible from default Readline usage?

Lorenz: why are you passing "A.foo(" to the completer, when it only parses attribute names, and not other Python syntax such as brackets?

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22141>
_______________________________________

From report at bugs.python.org  Fri May 13 08:28:37 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 13 May 2016 12:28:37 +0000
Subject: [issue22143] rlcompleter.Completer has duplicate matches
In-Reply-To: <1407255195.5.0.870338576239.issue22143@psf.upfronthosting.co.za>
Message-ID: <1463142517.63.0.357754385998.issue22143@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think this was fixed by Issue 25663. (Sorry I wasn?t aware of the work already done here.)

----------
nosy: +martin.panter
resolution:  -> out of date
status: open -> closed
superseder:  -> Make rlcompleter avoid duplicate global names

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22143>
_______________________________________

From report at bugs.python.org  Fri May 13 08:39:24 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 13 May 2016 12:39:24 +0000
Subject: [issue22143] rlcompleter.Completer has duplicate matches
In-Reply-To: <1407255195.5.0.870338576239.issue22143@psf.upfronthosting.co.za>
Message-ID: <1463143164.9.0.78090529014.issue22143@psf.upfronthosting.co.za>


Martin Panter added the comment:

Actually more like Issue 25590 (this was about attribute names, not global names)

----------
superseder: Make rlcompleter avoid duplicate global names -> tab-completition on instances repeatedly accesses attribute/descriptors values

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22143>
_______________________________________

From report at bugs.python.org  Fri May 13 08:51:25 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 13 May 2016 12:51:25 +0000
Subject: [issue14782] Tab-completion of callables displays opening paren
In-Reply-To: <1336738586.42.0.602618902889.issue14782@psf.upfronthosting.co.za>
Message-ID: <1463143885.86.0.916848498829.issue14782@psf.upfronthosting.co.za>


Martin Panter added the comment:

FWIW, count me against the automatic brackets as well. Another way it gets in the road:

>>> class C(object(. . .

In Issue 5062, Carl thought there might be a switch to turn the behaviour off. Perhaps we could add some sort of configuration option.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14782>
_______________________________________

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: [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 09:20:23 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 13 May 2016 13:20:23 +0000
Subject: [issue5062] Rlcompleter.Completer does not use __dir__ magic method
In-Reply-To: <1232933338.03.0.797305426871.issue5062@psf.upfronthosting.co.za>
Message-ID: <1463145623.84.0.576145371798.issue5062@psf.upfronthosting.co.za>


Martin Panter added the comment:

Issue 14782 is open for complaints about the opening brackets.

I think this report was mainly about attributes that fail the hasattr() test. In Issue 25590 we were conservative and only fixed it in 3.6+.

----------
nosy: +martin.panter
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> tab-completition on instances repeatedly accesses attribute/descriptors values
versions: +Python 3.6 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5062>
_______________________________________

From report at bugs.python.org  Fri May 13 09:20:46 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 13 May 2016 13:20:46 +0000
Subject: [issue5062] Rlcompleter.Completer does not use __dir__ magic method
In-Reply-To: <1232933338.03.0.797305426871.issue5062@psf.upfronthosting.co.za>
Message-ID: <1463145646.87.0.390510105512.issue5062@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
components: +Library (Lib) -Documentation, Extension Modules

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5062>
_______________________________________

From report at bugs.python.org  Fri May 13 09:29:49 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 13 May 2016 13:29:49 +0000
Subject: [issue21261] Teach IDLE to Autocomplete dictionary keys
In-Reply-To: <1397672472.64.0.119805531416.issue21261@psf.upfronthosting.co.za>
Message-ID: <1463146189.86.0.972082545133.issue21261@psf.upfronthosting.co.za>


Martin Panter added the comment:

I have no idea how IDLE works internally, but I wonder if it is possible to share some of the work with the Readline completer (rlcompleter module). Despite the name, rlcompleter should be usable without also using Readline, though recently (Issue 25660) I think this was broken. Anyway, maybe see Issue 10351 for the beginning of an rlcompleter patch and some potential test cases.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21261>
_______________________________________

From report at bugs.python.org  Fri May 13 09:54:14 2016
From: report at bugs.python.org (David Coles)
Date: Fri, 13 May 2016 13:54:14 +0000
Subject: [issue22970] asyncio: Cancelling wait() after notification leaves
 Condition in an inconsistent state
In-Reply-To: <1417404582.01.0.276361050449.issue22970@psf.upfronthosting.co.za>
Message-ID: <1463147654.28.0.314619261506.issue22970@psf.upfronthosting.co.za>


David Coles added the comment:

Since I reported this, I haven't seen any proposed solutions other other than a retry loop to ensure that the lock is guaranteed to be reacquired when the sleeping coroutine is woken.

The four possibilities of cancelling the waiting coroutine are:

1. Before wait is scheduled
   (Because the coroutine is never run, the lock is never released and a CancelledError is thrown by the runtime)
2. While waiting to be notified
   (CancelledError is thrown, but the 'finally' clause reacquires lock)
3. After wait has returned
   (This is a no-op since the wait coroutine has already completed - no CancelledError is thrown)
4. After notification, but while waiting on lock reaquisition
   (The problem discussed here)

Cancellation is quite analogous to EINTER of system calls interrupted by signals - you'll notice that the CPython runtime will retry acquiring the lock forever https://hg.python.org/cpython/file/default/Python/thread_pthread.h#l355 . This is acceptable behaviour acording the the POSIX spec http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_cond_timedwait.html , in particular:

"If a signal is delivered to a thread waiting for a condition variable, upon return from the signal handler the thread resumes waiting for the condition variable as if it was not interrupted, or it shall return zero due to spurious wakeup."

"Upon successful return, the mutex shall have been locked and shall be owned by the calling thread."

"These functions shall not return an error code of [EINTR]."

Thus, other than throwing something like a RuntimeError, there's no way to legally return from a Condition.wait without having that lock reacquired. Thus the only option is to retry if the lock reacquire is interrupted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22970>
_______________________________________

From report at bugs.python.org  Fri May 13 10:39:59 2016
From: report at bugs.python.org (Colm Buckley)
Date: Fri, 13 May 2016 14:39:59 +0000
Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at
 startup or on importing the random module on getrandom()
In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za>
Message-ID: <1463150399.16.0.161738701069.issue26839@psf.upfronthosting.co.za>


Colm Buckley added the comment:

A couple of things to note:

* Despite the earlier title; this does not just apply to VMs; any system with a potentially-blocking getrandom() (including all Linux 3.17+ and Solaris 11+) is affected.

* It's true that getrandom() only blocks on Linux when called before the RNG entropy pool is initialized. However, Python should not be limited to only being called after this initialization.

* In particular, systemd-cron relies on a Python script being called very early in the boot process (before the urandom pool is initialized), this is now prevalent on the Debian testing track; causing a 90-second boot delay.

* The patch I supplied causes getrandom() to be only called in nonblocking mode; this seems consistent with the desired semantics of os.urandom and _PyRandomInit.

Hope this helps.

Colm

----------
title: Python 3.5 running in a virtual machine with Linux kernel 3.17+ can block at startup or on importing the random module on getrandom() -> Python 3.5 running on Linux kernel 3.17+ can block at startup or on importing the random module on getrandom()
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26839>
_______________________________________

From report at bugs.python.org  Fri May 13 11:46:12 2016
From: report at bugs.python.org (Steve Dower)
Date: Fri, 13 May 2016 15:46:12 +0000
Subject: [issue26998] Unable to import "site" in an embedded application
In-Reply-To: <1462964428.89.0.669222260806.issue26998@psf.upfronthosting.co.za>
Message-ID: <1463154372.07.0.220953417869.issue26998@psf.upfronthosting.co.za>


Steve Dower added the comment:

The PEP doesn't really apply to 2.7, apart from explicitly expecting tools to still detect 32-bit and 64-bit versions despite sys.winver being the same.

As for sys.winver being incorrect in 2.7.11, that's been fixed (issue25824), but wasn't deemed critical enough to release 2.7.12 immediately. The next update will be released soon with the fix.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> 32-bit 2.7.11 installer creates registry keys that are incompatible with the installed python27.dll

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26998>
_______________________________________

From report at bugs.python.org  Fri May 13 11:50:07 2016
From: report at bugs.python.org (Steve Dower)
Date: Fri, 13 May 2016 15:50:07 +0000
Subject: [issue26992] 64-bit Python 2.7.11 hangs in 64-bit Windows 10 - CMD
 and Git Bash
In-Reply-To: <1462886435.44.0.374942055679.issue26992@psf.upfronthosting.co.za>
Message-ID: <1463154607.12.0.0704228546081.issue26992@psf.upfronthosting.co.za>


Steve Dower added the comment:

I wonder if it's related to issue26882? Seems unlikely as they are very different versions, but it's possible.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26992>
_______________________________________

From report at bugs.python.org  Fri May 13 11:58:25 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 13 May 2016 15:58:25 +0000
Subject: [issue26920] android: test_sys fails
In-Reply-To: <1462267582.58.0.744255750518.issue26920@psf.upfronthosting.co.za>
Message-ID: <1463155105.45.0.32821924751.issue26920@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

> On Android, os.fsdecode(os.fsencode('\xe6')) does not raise UnicodeError in the test.support module.

Because of changeset ad6be34ce8c9.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26920>
_______________________________________

From report at bugs.python.org  Fri May 13 12:31:41 2016
From: report at bugs.python.org (Colm Buckley)
Date: Fri, 13 May 2016 16:31:41 +0000
Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at
 startup or on importing the random module on getrandom()
In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za>
Message-ID: <1463157101.09.0.627894417244.issue26839@psf.upfronthosting.co.za>


Colm Buckley added the comment:

@haypo - yes, it's strange that Linux's getrandom() might block even when reading the urandom pool. However, I think we need to just cope with this and add the GRND_NONBLOCK flag rather than attempting to force a change in the Linux kernel

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26839>
_______________________________________

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: [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 14:20:11 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 May 2016 18:20:11 +0000
Subject: [issue8886] zipfile.ZipExtFile is a context manager,
 but that is not documented
In-Reply-To: <1275565167.77.0.94387257463.issue8886@psf.upfronthosting.co.za>
Message-ID: <20160513182007.89101.44908.5046C17A@psf.io>


Roundup Robot added the comment:

New changeset ae50bf6e3ac8 by Serhiy Storchaka in branch '3.5':
Restored test_interleaved. After issue #8886 it was a duplicate of
https://hg.python.org/cpython/rev/ae50bf6e3ac8

New changeset 62d844d2bd07 by Serhiy Storchaka in branch 'default':
Restored test_interleaved. After issue #8886 it was a duplicate of
https://hg.python.org/cpython/rev/62d844d2bd07

New changeset ba823131b25e by Serhiy Storchaka in branch '2.7':
Restored test_interleaved. After issue #8886 it was a duplicate of
https://hg.python.org/cpython/rev/ba823131b25e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8886>
_______________________________________

From report at bugs.python.org  Fri May 13 15:14:12 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 May 2016 19:14:12 +0000
Subject: [issue26293] Embedded zipfile fields dependent on absolute position
In-Reply-To: <1454662355.53.0.48718125489.issue26293@psf.upfronthosting.co.za>
Message-ID: <1463166852.6.0.465968879785.issue26293@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Yes, this may be a bug. After appending all offsets are absolute file positions. Here is a patch that presumably fixes this issue. Unfortunately I can't write tests for this issue. ZipFile is too lenient and all written tests are passes with unpatched code. Please test the patch manually.

----------
keywords: +patch
stage:  -> patch review
versions: +Python 2.7, Python 3.5
Added file: http://bugs.python.org/file42841/zipfile_concatenated.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26293>
_______________________________________

From report at bugs.python.org  Fri May 13 15:35:12 2016
From: report at bugs.python.org (Colm Buckley)
Date: Fri, 13 May 2016 19:35:12 +0000
Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at
 startup or on importing the random module on getrandom()
In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za>
Message-ID: <1463168112.82.0.965616713352.issue26839@psf.upfronthosting.co.za>


Colm Buckley added the comment:

See https://lwn.net/Articles/606141/ for an explanation of the blocking behavior of getrandom(). This makes sense to me - before the pool has initialized, /dev/urandom will be readable but will return highly predictable data - ie: it should not be considered safe. In other words, I think that getrandom() offers a sensible API.

The only circumstances where we hit the EAGAIN in getrandom() should be when it's called extremely early in the boot process (as is the case for the systemd-cron generator script I mentioned earlier). I think this is safe enough; a more thorough approach would be to flag that the per-process hash seed (_Py_HashSecret) is predictable and shouldn't be used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26839>
_______________________________________

From report at bugs.python.org  Fri May 13 15:37:28 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 13 May 2016 19:37:28 +0000
Subject: [issue27015] subprocess.CalledProcessError's repr changes based on
 kwargs, and doesn't unpickle
In-Reply-To: <1463158749.5.0.182634970623.issue27015@psf.upfronthosting.co.za>
Message-ID: <1463168248.34.0.0746936107058.issue27015@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is a problem not only with CalledProcessError, but with all custom exceptions with overridden __init__. BaseException.__new__ saves positional arguments as the "args" attribute, but ignores keyword arguments. repr() and pickle use "args".

----------
nosy: +astrand, gregory.p.smith, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27015>
_______________________________________

From report at bugs.python.org  Fri May 13 15:39:18 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 13 May 2016 19:39:18 +0000
Subject: [issue26848] asyncio.subprocess's communicate() method mishandles
 empty input bytes
In-Reply-To: <1461645634.01.0.295749785908.issue26848@psf.upfronthosting.co.za>
Message-ID: <20160513193913.15001.87486.3DFE81BA@psf.io>


Roundup Robot added the comment:

New changeset 148757a88f19 by Yury Selivanov in branch '3.5':
Issue #26848: Fix asyncio/subprocess.communicate() to handle empty input.
https://hg.python.org/cpython/rev/148757a88f19

New changeset f5e69e2f50d7 by Yury Selivanov in branch 'default':
Merge 3.5 (issue #26848)
https://hg.python.org/cpython/rev/f5e69e2f50d7

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26848>
_______________________________________

From report at bugs.python.org  Fri May 13 15:40:42 2016
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 13 May 2016 19:40:42 +0000
Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at
 startup or on importing the random module on getrandom()
In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za>
Message-ID: <1463168442.95.0.897221536655.issue26839@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan at bytereef.org>:


----------
nosy:  -skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26839>
_______________________________________

From report at bugs.python.org  Fri May 13 16:52:36 2016
From: report at bugs.python.org (Maciej Szulik)
Date: Fri, 13 May 2016 20:52:36 +0000
Subject: [issue27010] email library could "recover" from bad mime boundary
 like (some?) email clients do
In-Reply-To: <1463067718.45.0.558318505018.issue27010@psf.upfronthosting.co.za>
Message-ID: <1463172756.61.0.0290137422766.issue27010@psf.upfronthosting.co.za>


Changes by Maciej Szulik <soltysh at gmail.com>:


----------
nosy: +maciej.szulik

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27010>
_______________________________________

From report at bugs.python.org  Fri May 13 17:05:19 2016
From: report at bugs.python.org (paul czyzewski)
Date: Fri, 13 May 2016 21:05:19 +0000
Subject: [issue15786] IDLE code completion window can hang or misbehave with
 mouse
In-Reply-To: <1346027701.33.0.908436854594.issue15786@psf.upfronthosting.co.za>
Message-ID: <1463173519.04.0.40016856984.issue15786@psf.upfronthosting.co.za>


paul czyzewski added the comment:

hi Tal and Terry,
  
I hadn't noticed that continuing to type does go to the appropriate spot.  However, I see what I think are two or three bugs (not sure is 'a)' is a bug) in the behavior:

  a) on my system it does not visibly filter the list. EG, if I type 'os.', wait for the popup, then type ge (so, 'os.ge') it scrolls down to, and selects, "get_blocking", but the rest of the list is still there.  
  This is still useful but, Tal, I'm just pointing out that I don't see any options disappear (as I think you're saying they should).  Should the list really be visibly filtered?

  b) say I want os.get_terminal_size.  I type "os." and wait for the popup to appear (see 'c)' for why this is necessary); then I type 'get_t".   Now  "get_terminal_size" is visible and selected but autocompletion doesn't occur.  I.E., I still have 'os.get_t" below the popup.  To get the full word I have to arrow *away* from the correct answer and then arrow back to it.  Now "get_terminal_size" appears below the popup.  This is obviously less serious, and less mysterious, than the original hang issue, but it's still a usability issue.

  c) Terry: regarding "Box comes up after cntl-space or time delay after key char." On my IDLE, the box *never* appears if I initially type beyond the ".".  E.G.
   import os
   type "os.g" and wait.
      RESULT: the popup never appears.  It will appear if I then do "cntl-space" but not from a time delay.  This seems like another biggish usability bug.  The time delay should work (as I think you're saying) and obviously "cntl-space" isn't something a newbie is likely to know to try.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15786>
_______________________________________

From report at bugs.python.org  Fri May 13 17:12:44 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 13 May 2016 21:12:44 +0000
Subject: [issue21261] Teach IDLE to Autocomplete dictionary keys
In-Reply-To: <1397672472.64.0.119805531416.issue21261@psf.upfronthosting.co.za>
Message-ID: <1463173964.48.0.462950660546.issue21261@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Thanks.  Being on Windows, I never paid attention to rlcompleter.  The big difference is that IDLE completions use IDLE's hyperparser module (which is used for other purposes also).  I will look at the tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21261>
_______________________________________

From report at bugs.python.org  Fri May 13 17:21:00 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 13 May 2016 21:21:00 +0000
Subject: [issue15786] IDLE code completion window can hang or misbehave with
 mouse
In-Reply-To: <1346027701.33.0.908436854594.issue15786@psf.upfronthosting.co.za>
Message-ID: <1463174460.18.0.856839720809.issue15786@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The time delay and popup is only after a key letter, like '.' or '"'.  Having the box appear whenever one pauses would be maddening.  I have the delay set to .1 second.

The list is not supposed to shrink. Having everything disappear on a typo would not seem good to me.  But it might be possible to visually separate remaining possibilities, so when only one option (or none) is left, it is visually obvious.  Once the overt bugs are fixed, it would not hurt to review details of intended behavior, perhaps with some review of other completers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15786>
_______________________________________

From report at bugs.python.org  Fri May 13 17:34:00 2016
From: report at bugs.python.org (paul czyzewski)
Date: Fri, 13 May 2016 21:34:00 +0000
Subject: [issue15786] IDLE code completion window can hang or misbehave with
 mouse
In-Reply-To: <1346027701.33.0.908436854594.issue15786@psf.upfronthosting.co.za>
Message-ID: <1463175240.76.0.709979105056.issue15786@psf.upfronthosting.co.za>


paul czyzewski added the comment:

hi Terry,  thanks for all the responses.

Well, what *I* found maddening was that typing  "os." pause "g" works but typing  "os.g" (with no pause) does nothing. :)  But, anyway, I guess you're saying that that's as designed.


>The list is not supposed to shrink. Having everything disappear on a typo would not seem good to me.

   Actually, I think that many widgets do work that way, but I think that, here, I agree with you, since the user might notice a nearby entry which is what they wanted.

What about my "b)" (copied just below)?  Is there a reason not to autocomplete what's on the command line, as is done if you *arrow* to a selection?  Again, not nearly as big an issue as the original hang but I can't think of a reason not to autocomplete in this case, and the code to do so must already exist. 

 b) say I want os.get_terminal_size.  I type "os." and wait for the popup to appear (see 'c)' for why this is necessary); then I type 'get_t".   Now  "get_terminal_size" is visible and selected but autocompletion doesn't occur.  I.E., I still have 'os.get_t" below the popup.  To get the full word I have to arrow *away* from the correct answer and then arrow back to it.  Now "get_terminal_size" appears below the popup.  This is obviously less serious, and less mysterious, than the original hang issue, but it's still a usability issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15786>
_______________________________________

From report at bugs.python.org  Fri May 13 17:35:16 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 13 May 2016 21:35:16 +0000
Subject: [issue22970] asyncio: Cancelling wait() after notification leaves
 Condition in an inconsistent state
In-Reply-To: <1417404582.01.0.276361050449.issue22970@psf.upfronthosting.co.za>
Message-ID: <1463175316.62.0.254942826588.issue22970@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Yury can you take this on?

----------
assignee:  -> yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22970>
_______________________________________

From report at bugs.python.org  Fri May 13 17:42:46 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 13 May 2016 21:42:46 +0000
Subject: [issue22970] asyncio: Cancelling wait() after notification leaves
 Condition in an inconsistent state
In-Reply-To: <1417404582.01.0.276361050449.issue22970@psf.upfronthosting.co.za>
Message-ID: <1463175766.33.0.687408340119.issue22970@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

OK, I'll see what I can do (this is some code that I don't know/use).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22970>
_______________________________________

From report at bugs.python.org  Fri May 13 17:44:19 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 13 May 2016 21:44:19 +0000
Subject: [issue23749] asyncio missing wrap_socket (starttls)
In-Reply-To: <1427119199.61.0.485462184824.issue23749@psf.upfronthosting.co.za>
Message-ID: <1463175859.71.0.674154150263.issue23749@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

I'll create a PR on the GitHub for this.  I like the proposed design, and I've implemented an SSL test micro-framework that we can use to test starttls in asyncio.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23749>
_______________________________________

From report at bugs.python.org  Fri May 13 19:19:06 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 13 May 2016 23:19:06 +0000
Subject: [issue15786] IDLE code completion window can hang or misbehave with
 mouse
In-Reply-To: <1346027701.33.0.908436854594.issue15786@psf.upfronthosting.co.za>
Message-ID: <1463181546.78.0.882503137055.issue15786@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

When the correct item is highlighted, hit tab once to copy it to the text, hit tab a second time to close the box.  If you use the arrow keys to select and copy as you go, you still have to hit tab twice to close the box (or click elsewhere).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15786>
_______________________________________

From report at bugs.python.org  Fri May 13 19:24:10 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 13 May 2016 23:24:10 +0000
Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at
 startup or on importing the random module on getrandom()
In-Reply-To: <1463168443.01.0.556192662664.issue26839@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwYe5-J1wRWi1kuL=uVsQ4q4NuxZKUC07=VDszf1ApxJsw@mail.gmail.com>


STINNER Victor added the comment:

Please elaborate the comment in the patch:

- explain that the RNG is not initialized yet with enough entropy
- add a refer?nce to this issue
- explain that it's a deliberate choice to use weak (non initialized) RNG
for practical reasons

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26839>
_______________________________________

From report at bugs.python.org  Fri May 13 19:38:31 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 13 May 2016 23:38:31 +0000
Subject: [issue27014] maximum recursion depth when using typing options
In-Reply-To: <1463144236.79.0.623590161328.issue27014@psf.upfronthosting.co.za>
Message-ID: <1463182711.9.0.439274682187.issue27014@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27014>
_______________________________________

From report at bugs.python.org  Fri May 13 19:40:38 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 13 May 2016 23:40:38 +0000
Subject: [issue26870] Unexpected call to readline's add_history in
 call_readline
In-Reply-To: <1461743534.82.0.668302064476.issue26870@psf.upfronthosting.co.za>
Message-ID: <1463182838.08.0.669479771965.issue26870@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thankyou for testing this Meador, it increases my confidence in my code. I?ll try to commit this soon if there are no objections.

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26870>
_______________________________________

From report at bugs.python.org  Fri May 13 19:55:53 2016
From: report at bugs.python.org (paul czyzewski)
Date: Fri, 13 May 2016 23:55:53 +0000
Subject: [issue15786] IDLE code completion window can hang or misbehave with
 mouse
In-Reply-To: <1346027701.33.0.908436854594.issue15786@psf.upfronthosting.co.za>
Message-ID: <1463183753.06.0.379439537649.issue15786@psf.upfronthosting.co.za>


paul czyzewski added the comment:

>If you use the arrow keys to select and copy as you go, you still have
> to hit tab twice to close the box (or click elsewhere).

Not for me.  If i use arrow keys then I just type "()" and the box disappears.  So there's two(?) fewer keystrokes needed if you use the arrow keys.

But anyway, I'll quit looking for additional minor bugs in this thread. :D
thanks
  Paul

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15786>
_______________________________________

From report at bugs.python.org  Fri May 13 19:57:53 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 13 May 2016 23:57:53 +0000
Subject: [issue27014] maximum recursion depth when using typing options
In-Reply-To: <1463144236.79.0.623590161328.issue27014@psf.upfronthosting.co.za>
Message-ID: <1463183873.34.0.241872408182.issue27014@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Ow, that's bad. :-(

Great job reducing this to a  minimal repro!

I'm guessing it's got to do with registration.  I'll try to figure out how to fix it; the fix should appear in Python 3.5.2.

----------
assignee:  -> gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27014>
_______________________________________

From report at bugs.python.org  Fri May 13 21:42:18 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 14 May 2016 01:42:18 +0000
Subject: [issue26848] asyncio.subprocess's communicate() method mishandles
 empty input bytes
In-Reply-To: <1461645634.01.0.295749785908.issue26848@psf.upfronthosting.co.za>
Message-ID: <1463190138.77.0.556735859882.issue26848@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26848>
_______________________________________

From report at bugs.python.org  Fri May 13 21:51:31 2016
From: report at bugs.python.org (Colm Buckley)
Date: Sat, 14 May 2016 01:51:31 +0000
Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at
 startup or on importing the random module on getrandom()
In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za>
Message-ID: <1463190690.99.0.464005741808.issue26839@psf.upfronthosting.co.za>


Colm Buckley added the comment:

@haypo - new version of patch attached with comments and references per your request.

----------
Added file: http://bugs.python.org/file42842/getrandom-nonblocking-v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26839>
_______________________________________

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: [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  Fri May 13 22:07:24 2016
From: report at bugs.python.org (padraic cunningham)
Date: Sat, 14 May 2016 02:07:24 +0000
Subject: [issue27016] BlockingIOError not raised inside function.
In-Reply-To: <1463191419.08.0.084074707962.issue27016@psf.upfronthosting.co.za>
Message-ID: <1463191644.14.0.863958461324.issue27016@psf.upfronthosting.co.za>


padraic cunningham added the comment:

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()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27016>
_______________________________________

From report at bugs.python.org  Fri May 13 22:09:16 2016
From: report at bugs.python.org (Ned Deily)
Date: Sat, 14 May 2016 02:09:16 +0000
Subject: [issue27016] BlockingIOError not raised inside function.
In-Reply-To: <1463191419.08.0.084074707962.issue27016@psf.upfronthosting.co.za>
Message-ID: <1463191756.31.0.753756831671.issue27016@psf.upfronthosting.co.za>


Ned Deily added the comment:

What platform are you running this on and can you give a more detailed procedure for reproducing the problem you see?

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27016>
_______________________________________

From report at bugs.python.org  Sat May 14 00:27:29 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 14 May 2016 04:27:29 +0000
Subject: [issue26168] Py_BuildValue may leak 'N' arguments on PyTuple_New
 failure
In-Reply-To: <1453314385.46.0.703497250236.issue26168@psf.upfronthosting.co.za>
Message-ID: <1463200049.26.0.828073452243.issue26168@psf.upfronthosting.co.za>


Martin Panter added the comment:

Patch 3 looks good to me

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26168>
_______________________________________

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: [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 03:08:20 2016
From: report at bugs.python.org (SilentGhost)
Date: Sat, 14 May 2016 07:08:20 +0000
Subject: [issue27017] Python3.5.1: type().startswith()
In-Reply-To: <1463208940.1.0.915796688613.issue27017@psf.upfronthosting.co.za>
Message-ID: <1463209700.55.0.55995114654.issue27017@psf.upfronthosting.co.za>


SilentGhost added the comment:

This is exactly how methods on Python object have been behaving for year: any method can be called either as method on instance, or as method on class, with instance passed as the first argument.

----------
nosy: +SilentGhost
resolution:  -> not a bug
stage:  -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27017>
_______________________________________

From report at bugs.python.org  Sat May 14 03:08:56 2016
From: report at bugs.python.org (SilentGhost)
Date: Sat, 14 May 2016 07:08:56 +0000
Subject: [issue27017] Python3.5.1: type().startswith()
In-Reply-To: <1463208940.1.0.915796688613.issue27017@psf.upfronthosting.co.za>
Message-ID: <1463209736.61.0.874521842848.issue27017@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27017>
_______________________________________

From report at bugs.python.org  Sat May 14 03:26:55 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 14 May 2016 07:26:55 +0000
Subject: [issue26721] Avoid socketserver.StreamRequestHandler.wfile doing
 partial writes
In-Reply-To: <1460204395.72.0.250418211057.issue26721@psf.upfronthosting.co.za>
Message-ID: <1463210815.02.0.00605544197731.issue26721@psf.upfronthosting.co.za>


Martin Panter added the comment:

Merged with current code, and copied the original wsgiref test case from Issue 24291, since this patch also fixes that bug.

----------
Added file: http://bugs.python.org/file42843/buffered-wfile.v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26721>
_______________________________________

From report at bugs.python.org  Sat May 14 03:44:39 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Sat, 14 May 2016 07:44:39 +0000
Subject: [issue27017] Python3.5.1: type().startswith()
In-Reply-To: <1463208940.1.0.915796688613.issue27017@psf.upfronthosting.co.za>
Message-ID: <1463211879.81.0.478045408463.issue27017@psf.upfronthosting.co.za>


Steven D'Aprano added the comment:

To explain in more detail: ``type('s').startswith`` is the same as ``str.startswith``, which is an unbound method in Python 2 and a regular function in Python 3. Either way, it expects *two* arguments: a string which becomes "self", and a second string argument, which is the prefix being tested for.

So type('any string').startswith('alphabet', 'al') is a long way of writing 'alphabet'.startswith('al').

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27017>
_______________________________________

From report at bugs.python.org  Sat May 14 04:02:19 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 14 May 2016 08:02:19 +0000
Subject: [issue26920] android: test_sys fails
In-Reply-To: <1462267582.58.0.744255750518.issue26920@psf.upfronthosting.co.za>
Message-ID: <1463212939.65.0.23577634768.issue26920@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

This patch fixes test_ioencoding_nonascii.

----------
keywords: +patch
Added file: http://bugs.python.org/file42844/test_ioencoding_nonascii.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26920>
_______________________________________

From report at bugs.python.org  Sat May 14 04:38:29 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 14 May 2016 08:38:29 +0000
Subject: [issue8450] httplib: false BadStatusLine() raised
In-Reply-To: <1271630731.08.0.327097174192.issue8450@psf.upfronthosting.co.za>
Message-ID: <1463215109.26.0.212444396913.issue8450@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
stage:  -> needs patch
versions:  -Python 2.6, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8450>
_______________________________________

From report at bugs.python.org  Sat May 14 04:48:52 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 14 May 2016 08:48:52 +0000
Subject: [issue23813] RSS and Atom feeds of buildbot results are broken
In-Reply-To: <1427740551.98.0.543585412367.issue23813@psf.upfronthosting.co.za>
Message-ID: <1463215732.67.0.378227239207.issue23813@psf.upfronthosting.co.za>


Martin Panter added the comment:

Both links seem to be working for me at the moment. Perhaps we can close this?

Maybe the server was crashing due to specific content in the feeds (non-ASCII buildbot log output?), that not there now.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23813>
_______________________________________

From report at bugs.python.org  Sat May 14 05:12:11 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 14 May 2016 09:12:11 +0000
Subject: [issue26920] android: test_sys fails
In-Reply-To: <1462267582.58.0.744255750518.issue26920@psf.upfronthosting.co.za>
Message-ID: <1463217131.21.0.698753899129.issue26920@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

About the failures in test_c_locale_surrogateescape, it seems that on Android the locale is not set correctly on startup when LC_ALL is set to C:

root at generic_x86:/data/local/tmp # LC_ALL=C python
Python 3.6.0a0 (default:eee959fee5f5+, May 14 2016, 10:19:09) 
[GCC 4.9 20150123 (prerelease)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale; locale.getlocale()
('en_US', 'UTF-8')
>>> locale.setlocale(locale.LC_ALL, '')
'C'
>>> locale.getlocale()
(None, None)
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26920>
_______________________________________

From report at bugs.python.org  Sat May 14 05:40:53 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 14 May 2016 09:40:53 +0000
Subject: [issue26920] android: test_sys fails
In-Reply-To: <1462267582.58.0.744255750518.issue26920@psf.upfronthosting.co.za>
Message-ID: <1463218853.44.0.770588487125.issue26920@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

This patch fixes the locale setting on startup when the LC_ALL environment variable is set to C, and as a consequence test_c_locale_surrogateescape does not fail anymore. Note that on Android HAVE_LANGINFO_H is undefined, see issue #22747.

----------
Added file: http://bugs.python.org/file42845/test_c_locale_surrogateescape.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26920>
_______________________________________

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: [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 06:38:39 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 14 May 2016 10:38:39 +0000
Subject: [issue14132] Redirect is not working correctly in urllib2
In-Reply-To: <1330269331.97.0.613564747875.issue14132@psf.upfronthosting.co.za>
Message-ID: <1463222319.68.0.458562681503.issue14132@psf.upfronthosting.co.za>


Martin Panter added the comment:

I will try to commit this soon

----------
stage: patch review -> commit review
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14132>
_______________________________________

From report at bugs.python.org  Sat May 14 06:51:04 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 14 May 2016 10:51:04 +0000
Subject: [issue26168] Py_BuildValue may leak 'N' arguments on PyTuple_New
 failure
In-Reply-To: <1453314385.46.0.703497250236.issue26168@psf.upfronthosting.co.za>
Message-ID: <1463223064.79.0.108144028815.issue26168@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you Martin.

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26168>
_______________________________________

From report at bugs.python.org  Sat May 14 06:52:19 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 14 May 2016 10:52:19 +0000
Subject: [issue23813] RSS and Atom feeds of buildbot results are broken
In-Reply-To: <1427740551.98.0.543585412367.issue23813@psf.upfronthosting.co.za>
Message-ID: <1463223139.45.0.966969202736.issue23813@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Yes, there were commits with non-ASCII messages near that time:

changeset:   95165:f6c6304c8193
user:        Benjamin Peterson <benjamin at python.org>
date:        Tue Mar 24 12:12:44 2015 -0400
files:       Doc/library/functions.rst
description:
change ? to ? for obscure joke reasons

https://twitter.com/ncoghlan_dev/status/579173053793353728


changeset:   94994:35a780a9a3b4
branch:      3.4
parent:      94991:5f49f79d5a83
user:        Berker Peksag <berker.peksag at gmail.com>
date:        Sun Mar 15 01:51:56 2015 +0200
files:       Lib/unittest/mock.py Lib/unittest/test/testmock/testmagicmethods.py Misc/NEWS
description:
Issue #23568: Add rdivmod support to MagicMock() objects.

Patch by H?kan L?vdahl.


I think the bug still exists and can be reproduced if make a commit with non-ASCII message.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23813>
_______________________________________

From report at bugs.python.org  Sat May 14 06:53:57 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 14 May 2016 10:53:57 +0000
Subject: [issue3213] "pydoc -p" should listen to [::] if IPv6 is supported
In-Reply-To: <1214525489.78.0.574038651579.issue3213@psf.upfronthosting.co.za>
Message-ID: <1463223237.78.0.669193852773.issue3213@psf.upfronthosting.co.za>


Martin Panter added the comment:

Currently pydoc only binds to IPv4 localhost, not the ?any-address? 0.0.0.0. See Issue 22421 and Issue 672656.

Apart from satisfying Hans?s expectation, what is the benefit of running pydoc on IPv6? I guess it would be possible to bind two sockets, one to IPv4 localhost (127.1 or ::ffff:127.0.0.1), and the other IPv6 localhost (::1). But why bother?

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3213>
_______________________________________

From report at bugs.python.org  Sat May 14 06:55:18 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 14 May 2016 10:55:18 +0000
Subject: [issue26920] android: test_sys fails
In-Reply-To: <1462267582.58.0.744255750518.issue26920@psf.upfronthosting.co.za>
Message-ID: <1463223318.1.0.42805342222.issue26920@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See also issue19058.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26920>
_______________________________________

From report at bugs.python.org  Sat May 14 06:55:31 2016
From: report at bugs.python.org (SilentGhost)
Date: Sat, 14 May 2016 10:55:31 +0000
Subject: [issue27018] Incorrect documentation of select module
In-Reply-To: <1463221477.58.0.675652051466.issue27018@psf.upfronthosting.co.za>
Message-ID: <1463223331.53.0.0694721636347.issue27018@psf.upfronthosting.co.za>


SilentGhost added the comment:

Here is the patch.

----------
keywords: +patch
nosy: +SilentGhost
stage:  -> patch review
type:  -> behavior
versions: +Python 3.6
Added file: http://bugs.python.org/file42846/issue27018.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27018>
_______________________________________

From report at bugs.python.org  Sat May 14 07:14:55 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 14 May 2016 11:14:55 +0000
Subject: [issue25841] In FancyURLopener error in example with http address.
In-Reply-To: <1449848545.54.0.701964592914.issue25841@psf.upfronthosting.co.za>
Message-ID: <1463224495.64.0.702537293191.issue25841@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
resolution:  -> works for me
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25841>
_______________________________________

From report at bugs.python.org  Sat May 14 07:16:32 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 14 May 2016 11:16:32 +0000
Subject: [issue26937] android: test_tarfile fails
In-Reply-To: <1462288467.92.0.772791237683.issue26937@psf.upfronthosting.co.za>
Message-ID: <1463224592.78.0.758795742818.issue26937@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

On the android-21-x86 emulator:

>>> import grp
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: dlopen failed: cannot locate symbol "setgrent" referenced by "grp.cpython-36m-i386-linux-gnu.so"...

The attached patch fixes the tarfile module to handle the case where the pwd module can be imported and the grp module cannot. With this fix test_tarfile runs without any failure.

----------
keywords: +patch
Added file: http://bugs.python.org/file42847/pwd_grp.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26937>
_______________________________________

From report at bugs.python.org  Sat May 14 07:22:24 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 14 May 2016 11:22:24 +0000
Subject: [issue17214] http.client.HTTPConnection.putrequest encode  error
In-Reply-To: <1361011959.8.0.221376430084.issue17214@psf.upfronthosting.co.za>
Message-ID: <1463224944.79.0.242821448002.issue17214@psf.upfronthosting.co.za>


Martin Panter added the comment:

I will look at committing this soon

----------
stage: patch review -> commit review
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17214>
_______________________________________

From report at bugs.python.org  Sat May 14 07:49:35 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 14 May 2016 11:49:35 +0000
Subject: [issue26920] android: test_sys fails
In-Reply-To: <1462267582.58.0.744255750518.issue26920@psf.upfronthosting.co.za>
Message-ID: <1463226575.88.0.287436764318.issue26920@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

With Serhiy's latest patch named sys_test_ioencoding.patch in issue19058, test_sys fails only in test_c_locale_surrogateescape on the android-21-x86 emulator.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26920>
_______________________________________

From report at bugs.python.org  Sat May 14 07:51:49 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 14 May 2016 11:51:49 +0000
Subject: [issue1705393] Document select() failure with buffered file
Message-ID: <1463226709.79.0.763358488148.issue1705393@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
title: Select() failure (race condition) -> Document select() failure with buffered file
versions: +Python 3.5, Python 3.6 -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1705393>
_______________________________________

From report at bugs.python.org  Sat May 14 07:53:23 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 14 May 2016 11:53:23 +0000
Subject: [issue24358] Should compression file-like objects provide .fileno(), 
 misleading subprocess?
In-Reply-To: <1433206981.32.0.719516838977.issue24358@psf.upfronthosting.co.za>
Message-ID: <1463226803.24.0.597941270072.issue24358@psf.upfronthosting.co.za>


Martin Panter added the comment:

Also stumbled upon Issue 1705393: confusion with select() and buffered files

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24358>
_______________________________________

From report at bugs.python.org  Sat May 14 08:18:20 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 14 May 2016 12:18:20 +0000
Subject: [issue16027] pkgutil doesn't support frozen modules
In-Reply-To: <1348506161.12.0.954547119673.issue16027@psf.upfronthosting.co.za>
Message-ID: <1463228300.02.0.214671221749.issue16027@psf.upfronthosting.co.za>


Martin Panter added the comment:

FWIW Python 3.3 is almost a distant memory, but I think it works properly:

$ wine c:/Python33/python.exe -m __hello__
Hello world!
$ wine c:/Python33/python.exe -m __phello__.spam
Hello world!
Hello world!

On Python 2, it does fail. Is this what the original problem was?

$ python2.7 -m __hello__
/sbin/python2.7: No code object available for __hello__
[Exit 1]
$ python2.7 -c 'import __hello__'
Hello world...

As I see it, this only needs to be fixed in Python 2. Or is it not applicable to 2?

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16027>
_______________________________________

From report at bugs.python.org  Sat May 14 08:28:56 2016
From: report at bugs.python.org (Daniel Griffin)
Date: Sat, 14 May 2016 12:28:56 +0000
Subject: [issue3213] "pydoc -p" should listen to [::] if IPv6 is supported
In-Reply-To: <1214525489.78.0.574038651579.issue3213@psf.upfronthosting.co.za>
Message-ID: <1463228936.78.0.0931756726316.issue3213@psf.upfronthosting.co.za>


Changes by Daniel Griffin <danielgriffin828 at gmail.com>:


----------
nosy: +Daniel Griffin
status: pending -> open
type: enhancement -> crash
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3213>
_______________________________________

From report at bugs.python.org  Sat May 14 08:29:42 2016
From: report at bugs.python.org (Daniel Griffin)
Date: Sat, 14 May 2016 12:29:42 +0000
Subject: [issue3213] "pydoc -p" should listen to [::] if IPv6 is supported
In-Reply-To: <1214525489.78.0.574038651579.issue3213@psf.upfronthosting.co.za>
Message-ID: <1463228982.8.0.83708522869.issue3213@psf.upfronthosting.co.za>


Changes by Daniel Griffin <danielgriffin828 at gmail.com>:


Added file: http://bugs.python.org/file42848/sync_node.xml

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3213>
_______________________________________

From report at bugs.python.org  Sat May 14 08:33:45 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 14 May 2016 12:33:45 +0000
Subject: [issue17085] test_socket crashes the whole test suite
In-Reply-To: <1359580628.83.0.173179383331.issue17085@psf.upfronthosting.co.za>
Message-ID: <1463229225.0.0.593451024445.issue17085@psf.upfronthosting.co.za>


Martin Panter added the comment:

The patch looks okay to me, to cancel the alarm before removing its signal handler.

----------
nosy: +martin.panter
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17085>
_______________________________________

From report at bugs.python.org  Sat May 14 08:46:10 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 14 May 2016 12:46:10 +0000
Subject: [issue8732] Should urllib2.urlopen send an Accept-Encoding header?
In-Reply-To: <1274021231.2.0.0953300031131.issue8732@psf.upfronthosting.co.za>
Message-ID: <1463229970.8.0.523530633494.issue8732@psf.upfronthosting.co.za>


Martin Panter added the comment:

I suspect for Demian?s 2.7 experiment, he used the older urllib.urlopen(), rather than urllib2.urlopen() as given in the original description. When I use urllib2.urlopen("http://localhost/"), I see

GET / HTTP/1.1
Accept-Encoding: identity
Host: localhost
Connection: close
User-Agent: Python-urllib/2.7

Even in the urllib (no 2) case, since it is using HTTP 1.0, I suspect not having Accept-Encoding is not such a problem.

The underlying HTTP library has always added ?Accept-Encoding: identity? for HTTP 1.1 by default (https://hg.python.org/cpython/annotate/4a3e9871b41b/Lib/httplib.py#l444), so I am closing this.

----------
nosy: +martin.panter
resolution:  -> works for me
status: pending -> closed
title: Should urrllib2.urlopen send an Accept-Encoding header? -> Should urllib2.urlopen send an Accept-Encoding header?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8732>
_______________________________________

From report at bugs.python.org  Sat May 14 08:47:42 2016
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 14 May 2016 12:47:42 +0000
Subject: [issue16027] pkgutil doesn't support frozen modules
In-Reply-To: <1348506161.12.0.954547119673.issue16027@psf.upfronthosting.co.za>
Message-ID: <1463230062.41.0.24921457266.issue16027@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

We're not supporting Python 3.3 with PyRun, but I can confirm that it works fine in Python 3.4 and 3.5.

In Python 2.7, it's still broken, as you can test with

pyrun2.7 -m wsgiref.simple_server

----------
versions: +Python 2.7 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16027>
_______________________________________

From report at bugs.python.org  Sat May 14 08:53:21 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 14 May 2016 12:53:21 +0000
Subject: [issue3213] "pydoc -p" should listen to [::] if IPv6 is supported
In-Reply-To: <1214525489.78.0.574038651579.issue3213@psf.upfronthosting.co.za>
Message-ID: <1463230401.51.0.944266618717.issue3213@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


Removed file: http://bugs.python.org/file42848/sync_node.xml

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3213>
_______________________________________

From report at bugs.python.org  Sat May 14 08:53:55 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 14 May 2016 12:53:55 +0000
Subject: [issue3213] "pydoc -p" should listen to [::] if IPv6 is supported
In-Reply-To: <1214525489.78.0.574038651579.issue3213@psf.upfronthosting.co.za>
Message-ID: <1463230435.51.0.565907888016.issue3213@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
status: open -> pending
type: crash -> enhancement
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3213>
_______________________________________

From report at bugs.python.org  Sat May 14 09:15:20 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 14 May 2016 13:15:20 +0000
Subject: [issue24291] Many servers (wsgiref, http.server,
 etc) can truncate large output blobs
In-Reply-To: <1432671481.51.0.762064908488.issue24291@psf.upfronthosting.co.za>
Message-ID: <1463231720.93.0.972713668357.issue24291@psf.upfronthosting.co.za>


Martin Panter added the comment:

Since there are three different people reporting the problem with wsgiref, but no other reports for other server modules, I might commit the change to Lib/wsgiref/simple_server.py soon, and leave the other changes until they can get a wider review.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24291>
_______________________________________

From report at bugs.python.org  Sat May 14 09:22:32 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 14 May 2016 13:22:32 +0000
Subject: [issue24291] Many servers (wsgiref, http.server,
 etc) can truncate large output blobs
In-Reply-To: <1432671481.51.0.762064908488.issue24291@psf.upfronthosting.co.za>
Message-ID: <1463232152.84.0.190310523656.issue24291@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24291>
_______________________________________

From report at bugs.python.org  Sat May 14 09:42:10 2016
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 14 May 2016 13:42:10 +0000
Subject: [issue16027] pkgutil doesn't support frozen modules
In-Reply-To: <1348506161.12.0.954547119673.issue16027@psf.upfronthosting.co.za>
Message-ID: <1463233330.93.0.908864835058.issue16027@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

Side note, as already indicated by Nick: pkgutil may well still not support frozen modules in Python 3.4 and 3.5, since runpy, which pyrun uses, does not rely on pkgutil in Python 3.4 and 3.5.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16027>
_______________________________________

From report at bugs.python.org  Sat May 14 09:58:00 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 14 May 2016 13:58:00 +0000
Subject: [issue16027] pkgutil doesn't support frozen modules
In-Reply-To: <1348506161.12.0.954547119673.issue16027@psf.upfronthosting.co.za>
Message-ID: <1463234280.29.0.99181352324.issue16027@psf.upfronthosting.co.za>


Martin Panter added the comment:

I know I had a bit of trouble adding support to iter_modules() and related functions, see Issue 25533.

Also, Issue 21749 about ImpLoader came up in my search.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16027>
_______________________________________

From report at bugs.python.org  Sat May 14 10:26:42 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 14 May 2016 14:26:42 +0000
Subject: [issue22970] asyncio: Cancelling wait() after notification leaves
 Condition in an inconsistent state
In-Reply-To: <1417404582.01.0.276361050449.issue22970@psf.upfronthosting.co.za>
Message-ID: <1463236002.38.0.178250837804.issue22970@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Hi David, thanks for working on this issue.  Your patch and reasoning behind it looks correct, but it's hard to say that definitively without tests and full code review.

Could you please submit a PR to https://github.com/python/asyncio (upstream for asyncio) with tests, and I'll do my best to review it before 3.5.2 happens.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22970>
_______________________________________

From report at bugs.python.org  Sat May 14 12:01:35 2016
From: report at bugs.python.org (Thomas Kluyver)
Date: Sat, 14 May 2016 16:01:35 +0000
Subject: [issue26039] More flexibility in zipfile write interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <1463241695.72.0.0439281410586.issue26039@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

Thanks Serhiy! I am marking this as fixed.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26039>
_______________________________________

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: [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 12:56:13 2016
From: report at bugs.python.org (David Coles)
Date: Sat, 14 May 2016 16:56:13 +0000
Subject: [issue22970] asyncio: Cancelling wait() after notification leaves
 Condition in an inconsistent state
In-Reply-To: <1417404582.01.0.276361050449.issue22970@psf.upfronthosting.co.za>
Message-ID: <1463244973.72.0.532874437053.issue22970@psf.upfronthosting.co.za>


David Coles added the comment:

Hi Yury,

Sure - I'll create a PR along with a test that reproduces the issue. Should be able to get that done this weekend.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22970>
_______________________________________

From report at bugs.python.org  Sat May 14 13:00:50 2016
From: report at bugs.python.org (paul j3)
Date: Sat, 14 May 2016 17:00:50 +0000
Subject: [issue26994] unexpected behavior for booleans in argparse
In-Reply-To: <1462905029.96.0.678738443976.issue26994@psf.upfronthosting.co.za>
Message-ID: <1463245250.67.0.93152185614.issue26994@psf.upfronthosting.co.za>


paul j3 added the comment:

I answered a similar question recently on Stackoverflow when the user wanted to use `type=hex`.

http://stackoverflow.com/questions/37006387/python-argparse-hex-error


In another recent bug/issue the poster want a `enum` type.  It's not hard to define a function, or factory class, that handles mappings like this, but it isn't as simple or intuitive as some would like.

There is a registries mechanism, which could allow the user to use `type='bool'`, where 'bool' is the name of a function that that converts some set of strings to True/False.  But people are used to providing strings for the `action`, they aren't used to do so for the `type`.

http://stackoverflow.com/questions/15008758/parsing-boolean-values-with-argparse

----------
nosy: +paul.j3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26994>
_______________________________________

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: [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: [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: [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: [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  Sat May 14 15:21:33 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 14 May 2016 19:21:33 +0000
Subject: [issue26039] More flexibility in zipfile write interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <1463253693.49.0.238646495509.issue26039@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Let me know when you create a backport package Thomas. I'd like to help.

----------
stage: commit review -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26039>
_______________________________________

From report at bugs.python.org  Sat May 14 16:59:48 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 14 May 2016 20:59:48 +0000
Subject: [issue26039] More flexibility in zipfile write interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <1463259588.47.0.834036486375.issue26039@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There are yet few issues.

1. Currently RuntimeError is widely used in zipfile. But in most cases ValueError would be more appropriate since it programming error (for example ValueError is raised when try to read or write to closed file). See issue24693, but this is backward incompatible change. For new exceptions we are free to use any exception type without breaking backward compatibility. It looks to me, that ValueError is more appropriate is these cases than RuntimeError. What do you think about this Thomas? Here is a patch that changes exceptions types.

2. ZipInfo.is_dir() is not documented and lacks a docstring.

3. It would be better to make force_zip64 a keyword-only parameter. This would allow to add new positional parameters without breaking compatibility.

----------
resolution: fixed -> 
stage: resolved -> patch review
status: closed -> open
Added file: http://bugs.python.org/file42850/zipfile-open-w-exceptions.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26039>
_______________________________________

From report at bugs.python.org  Sat May 14 17:05:47 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 14 May 2016 21:05:47 +0000
Subject: [issue27020] os.writev() does not accept generators (as buffers
 argument)
In-Reply-To: <1463247043.26.0.60216509871.issue27020@psf.upfronthosting.co.za>
Message-ID: <1463259947.53.0.658904300864.issue27020@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This makes sense. The purpose of writev() is to write all data in single atomic operation. In any case a sequence should be built.

This looks rather as intentional behavior than as a bug to me.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27020>
_______________________________________

From report at bugs.python.org  Sat May 14 17:15:10 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 14 May 2016 21:15:10 +0000
Subject: [issue11980] zipfile.ZipFile.write should accept fp as argument
In-Reply-To: <1304354092.27.0.477434523561.issue11980@psf.upfronthosting.co.za>
Message-ID: <1463260510.85.0.910112842814.issue11980@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

A more general feature is implemented in issue26039. Now you can write to ZIP archive the content of opened file object with following two lines:

        with zipf.open('file.txt', 'wb') as target:
            shutil.copyfileobj(source, target)

----------
resolution:  -> rejected
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11980>
_______________________________________

From report at bugs.python.org  Sat May 14 17:25:05 2016
From: report at bugs.python.org (Thomas Kluyver)
Date: Sat, 14 May 2016 21:25:05 +0000
Subject: [issue26039] More flexibility in zipfile write interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <1463261105.91.0.33667636107.issue26039@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

1. For the cases like read/write handles conflicting, ValueError doesn't seem quite right to me - I take ValueError to mean that you have passed an invalid value to a function. RuntimeError feels like the closest fit for 'the current state does not allow this operation'. It is rather broad, though.

If I was writing it anew, I would use ValueError for something like an invalid mode parameter: zf.open('foo', mode='q') . That particular case was already in the code, though, so I think backwards compatibility should take precedence.

2 & 3. Agreed, I'll prepare a patch

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26039>
_______________________________________

From report at bugs.python.org  Sat May 14 18:01:06 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 14 May 2016 22:01:06 +0000
Subject: [issue24225] Idlelib: changing file names
In-Reply-To: <1431934587.56.0.38760352205.issue24225@psf.upfronthosting.co.za>
Message-ID: <1463263266.39.0.165201464853.issue24225@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The conclusion of issue 26993 is that we should apply this issue to 3.6.  My target for inclusion is alpha2, scheduled for June 12.

I am aware that this will require changing file names in existing patches on the tracker.  But they nearly all have the much larger problem of needing the new tests that I will now start to require.

Nick suggested above that breaking code should be more palatable if introduced in a context of overall improvement, including better clarity in supported APIs.  Here is a start on the IDLE What's New entry that should be part of this issue.

"Idlelib is being revamped to make IDLE look better and work better and to make it easier to maintain and improve IDLE.

Part of looking better is the use of ttk widgets.  As a result, IDLE no longer runs with tcl/tk 8.4.  It now requires tcl/tk 8.5 or 8.6.  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."

----------
nosy: +ned.deily
versions:  -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24225>
_______________________________________

From report at bugs.python.org  Sat May 14 18:02:22 2016
From: report at bugs.python.org (Thomas Kluyver)
Date: Sat, 14 May 2016 22:02:22 +0000
Subject: [issue26039] More flexibility in zipfile write interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <1463263342.2.0.949006370929.issue26039@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

Patch attached for points 2 and 3

----------
Added file: http://bugs.python.org/file42851/zipfile-flex-bonus.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26039>
_______________________________________

From report at bugs.python.org  Sat May 14 18:03:21 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 14 May 2016 22:03:21 +0000
Subject: [issue24225] Idlelib: changing file names
In-Reply-To: <1431934587.56.0.38760352205.issue24225@psf.upfronthosting.co.za>
Message-ID: <1463263401.46.0.404831678385.issue24225@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution: later -> 
stage:  -> test needed
superseder:  -> Idlelib: changing file names

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24225>
_______________________________________

From report at bugs.python.org  Sat May 14 18:03:39 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 14 May 2016 22:03:39 +0000
Subject: [issue24225] Idlelib: changing file names
In-Reply-To: <1431934587.56.0.38760352205.issue24225@psf.upfronthosting.co.za>
Message-ID: <1463263419.76.0.446975452644.issue24225@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
superseder: Idlelib: changing file names -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24225>
_______________________________________

From report at bugs.python.org  Sat May 14 18:09:05 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 14 May 2016 22:09:05 +0000
Subject: [issue26993] Copy idlelib *.py files with new names
In-Reply-To: <1462904867.82.0.814804625056.issue26993@psf.upfronthosting.co.za>
Message-ID: <1463263745.61.0.10124411797.issue26993@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I finished reopening #24225 (renaming), for 3.6 only.  I will open a new issue with Larry Hastings nosy, should I proposed (next fall) to backport the revamped idlelib to 3.5.

----------
resolution:  -> postponed
superseder:  -> Idlelib: changing file names

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26993>
_______________________________________

From report at bugs.python.org  Sat May 14 18:45:27 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 14 May 2016 22:45:27 +0000
Subject: [issue26920] android: test_sys fails
In-Reply-To: <1462267582.58.0.744255750518.issue26920@psf.upfronthosting.co.za>
Message-ID: <1463265927.6.0.764234944375.issue26920@psf.upfronthosting.co.za>


STINNER Victor added the comment:

test_c_locale_surrogateescape.patch LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26920>
_______________________________________

From report at bugs.python.org  Sat May 14 18:49:20 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 14 May 2016 22:49:20 +0000
Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at
 startup or on importing the random module on getrandom()
In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za>
Message-ID: <1463266160.59.0.47565241417.issue26839@psf.upfronthosting.co.za>


STINNER Victor added the comment:

getrandom-nonblocking-v2.patch:

+		/* Alternative might be to return all-zeroes as a strong
+		 * signal that these are not random data. */

I don't understand why you propose that in a comment of your change. I don't recall that this idea was proposed or discussed here.

IMHO it's a very bad idea to fill the buffer with zeros, the caller simply has no idea how to check the quality of the entropy. A buffer filled with zeros is "possible" even with high quality RNG, but it's really very very rare :-)

If you consider that a strong signal is required, you must raise an exception. But it looks like users don't care of the quality of the RNG, they request that Python "just works".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26839>
_______________________________________

From report at bugs.python.org  Sat May 14 18:50:57 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 14 May 2016 22:50:57 +0000
Subject: [issue26919] android: test_cmd_line fails
In-Reply-To: <1462267115.39.0.594600458307.issue26919@psf.upfronthosting.co.za>
Message-ID: <1463266257.6.0.545011427147.issue26919@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I commented retrofit_osx_2.patch on the review.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26919>
_______________________________________

From report at bugs.python.org  Sat May 14 18:57:13 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 14 May 2016 22:57:13 +0000
Subject: [issue26970] Replace OpenSSL's CPRNG with system entropy source
In-Reply-To: <1462525827.05.0.33480267606.issue26970@psf.upfronthosting.co.za>
Message-ID: <1463266633.75.0.639776891788.issue26970@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> I have to replace _PyOS_URandom with a variant that doesn't need the GIL

Please don't replace it, but add a new function which report errors differently. Which kind of granularity do you expect for the error reporting? Just a boolean (success or failure)?

Most implementations of _PyOS_URandom() already has a private "int raise" parameter to specify how errors are reported: raise an exception or call Py_FatalError().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26970>
_______________________________________

From report at bugs.python.org  Sat May 14 18:58:14 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 14 May 2016 22:58:14 +0000
Subject: [issue21199] Python on 64-bit Windows uses signed 32-bit type for
 read length
In-Reply-To: <1397149133.44.0.946556558932.issue21199@psf.upfronthosting.co.za>
Message-ID: <1463266694.64.0.946965535766.issue21199@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I'm lost in this old issue. Can someone please try to summarize it? What is the problem? What is the proposed fix? What is the status?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21199>
_______________________________________

From report at bugs.python.org  Sat May 14 19:00:48 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 14 May 2016 23:00:48 +0000
Subject: [issue11549] Build-out an AST optimizer,
 moving some functionality out of the peephole optimizer
In-Reply-To: <1300164402.79.0.766591131661.issue11549@psf.upfronthosting.co.za>
Message-ID: <1463266848.39.0.955827989215.issue11549@psf.upfronthosting.co.za>


STINNER Victor added the comment:

"issue11549.patch: serhiy.storchaka, 2016-05-11 08:22: Regenerated for review"

diff -r 1e00b161f5f5 PC/os2emx/python33.def
--- a/PC/os2emx/python33.def	Wed Mar 09 12:53:30 2011 +0100
+++ b/PC/os2emx/python33.def	Wed May 11 11:21:24 2016 +0300

The revision 1e00b161f5f5 is 4 years old. The patch looks very outdated :-/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11549>
_______________________________________

From report at bugs.python.org  Sat May 14 19:02:51 2016
From: report at bugs.python.org (Eugene Toder)
Date: Sat, 14 May 2016 23:02:51 +0000
Subject: [issue11549] Build-out an AST optimizer,
 moving some functionality out of the peephole optimizer
In-Reply-To: <1300164402.79.0.766591131661.issue11549@psf.upfronthosting.co.za>
Message-ID: <1463266971.69.0.239851180427.issue11549@psf.upfronthosting.co.za>


Eugene Toder added the comment:

Fairly sure it's 5 years old.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11549>
_______________________________________

From report at bugs.python.org  Sat May 14 19:09:28 2016
From: report at bugs.python.org (Colm Buckley)
Date: Sat, 14 May 2016 23:09:28 +0000
Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at
 startup or on importing the random module on getrandom()
In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za>
Message-ID: <1463267368.81.0.11462956767.issue26839@psf.upfronthosting.co.za>


Colm Buckley added the comment:

@haypo - yes, I think you're right. Can you delete those two lines (or I can upload another version if you prefer).

I think the pragmatic thing here is to proceed by reading /dev/urandom (as we've discussed). It's not safe to raise an exception in py_getrandom from what I can see; a thorough effort to signal the lack of randomness to outer functions needs more code examination than I have time to carry out at the moment.

>From looking at when PyRandom_Init is called and how the hash secret is used; I think it is safe to proceed with /dev/urandom. The general understanding is that urandom has a lower entropy quotient than random, so it's hopefully not going to be used in strong crypto contexts.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26839>
_______________________________________

From report at bugs.python.org  Sat May 14 19:12:32 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 14 May 2016 23:12:32 +0000
Subject: [issue26934] android: test_faulthandler fails
In-Reply-To: <1462287504.69.0.311102051296.issue26934@psf.upfronthosting.co.za>
Message-ID: <1463267552.47.0.113639626678.issue26934@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> This is due to something mysterious in Android's bionic & kernel. For the following C program:
> (...)

Please try without "sigaction(SIGSEGV, NULL, NULL);". Does the program still quit?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26934>
_______________________________________

From report at bugs.python.org  Sat May 14 19:14:24 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 14 May 2016 23:14:24 +0000
Subject: [issue26934] android: test_faulthandler fails
In-Reply-To: <1462287504.69.0.311102051296.issue26934@psf.upfronthosting.co.za>
Message-ID: <1463267664.88.0.656141743907.issue26934@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Does faulthandler._read_null() crash Python? If yes, I should patch test_faulthandler to replace all _sigsegv() with faulthandler._read_null().

I was too lazy to do that because currently the unit tests checks the exact error message, whereas _read_null() gives different error messages depending on the platform.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26934>
_______________________________________

From report at bugs.python.org  Sat May 14 19:18:23 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 14 May 2016 23:18:23 +0000
Subject: [issue24693] zipfile: change RuntimeError to more appropriate
 exception type
In-Reply-To: <1437654224.43.0.502488912035.issue24693@psf.upfronthosting.co.za>
Message-ID: <1463267903.7.0.178052869231.issue24693@psf.upfronthosting.co.za>


Martin Panter added the comment:

I have hardly used the zipfile module, but here are my thoughts on some of the exceptions anyway :)

Some of these exceptions are documented, so the documentation would need updating.

BadZipFile for corrupted field seems reasonable.

The purpose of RuntimeError is not clearly documented, but I have the feeling it gets used mainly for programmer errors, rather than errors caused by external data. So I tend to agree a couple of the changes away from RuntimeError, such as the invalid password case.

For programmer errors, I doubt the exception type matters much for compatibility. RuntimeError seems fine to me, but I accept that ValueError is more consistent with open(..., mode="invalid"), operations on closed files, etc.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24693>
_______________________________________

From report at bugs.python.org  Sat May 14 19:28:06 2016
From: report at bugs.python.org (Cameron Simpson)
Date: Sat, 14 May 2016 23:28:06 +0000
Subject: [issue19251] bitwise ops for bytes of equal length
In-Reply-To: <1381694847.24.0.709324715816.issue19251@psf.upfronthosting.co.za>
Message-ID: <1463268486.77.0.914170720223.issue19251@psf.upfronthosting.co.za>


Changes by Cameron Simpson <cs at zip.com.au>:


----------
nosy: +cameron

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19251>
_______________________________________

From report at bugs.python.org  Sat May 14 19:29:05 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 14 May 2016 23:29:05 +0000
Subject: [issue26039] More flexibility in zipfile write interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <1463268545.68.0.516814608182.issue26039@psf.upfronthosting.co.za>


Martin Panter added the comment:

The bonus patch looks okay, although I wonder if the directory slash (/) information should be in the RST rather than doc string. Usually the RST has all the details, and doc strings are just summaries.

Regarding exceptions, I can sympathise with both sides of the argument and don?t have a strong opinion (why does the exception type matter for programmer errors anyway?). But I think it might be better to be locally consistent within the zipfile module, and the module is already heavily documented with RuntimeError for similar programmer errors.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26039>
_______________________________________

From report at bugs.python.org  Sat May 14 19:49:39 2016
From: report at bugs.python.org (Cameron Simpson)
Date: Sat, 14 May 2016 23:49:39 +0000
Subject: [issue19251] bitwise ops for bytes of equal length
In-Reply-To: <1381694847.24.0.709324715816.issue19251@psf.upfronthosting.co.za>
Message-ID: <1463269779.89.0.948949353072.issue19251@psf.upfronthosting.co.za>


Cameron Simpson added the comment:

I'd like speak my support for bitwise ops on bytes and bytearray (agree, on equal lengths only).

I've got 2 arguments here:

- readability: a ^ b, a | b and so forth are clear and direct

- all the various incantation presented must be _understood_, not to mention invented anew by anyone wanting to do they same, with the same burden of getting it correct; of course one can say the same of any feature not already present in a language but that is trite; there are several ways to say this and all have varying degrees of speed, obtuseness and verbosity. And they're all SLOW.

Regarding some of the counter arguments in the discussion:

- gregory.p.smith in reply to cowlicks: "Security claims?  Nonsense. This has nothing to do with security.  It is *fundamentally impossible* to write constant time side channel attack resistant algorithms [...]"

Maybe cowlicks should have said "reliable", though to my naive eye a normal implementation would be constant time for a given size. I would argue that the clarity and directness of just writing "a^b" immediately makes for trivially correct code, which itself is a necessary prerequisite for secure code.

- gregory.p.smith again: "Neither of the above "look as nice" as a simple operator would. But they are at least both understandable and frankly about the same as what you would naively write in C for the task."

This is not an argument against the feature. That one had to perform similar activitie in Python as in C merely reflects the present lack of these operators, not a preexisting gleaming sufficiency of operator richness.

- Terry J. Reddy: "'XOR of two bytes in one place' strikes me as a thin excuse for a new feature that abbreviates a simple, short, one-liner". Christian Heimes's code has this single example, but anyone wanting to work on chunks of bytes may find themselves here. Just because a lot of things can be written/constructed as one liners doesn't mean they should be operators when (a) the operator is available (==unused) for this type, (b) the meaning of the operator is straight forward and intuitive and (c) any pure Python construction is both wordier and much slower.

Anyway, I an for this feature, for the record.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19251>
_______________________________________

From report at bugs.python.org  Sat May 14 19:51:45 2016
From: report at bugs.python.org (Cameron Simpson)
Date: Sat, 14 May 2016 23:51:45 +0000
Subject: [issue19251] bitwise ops for bytes of equal length
In-Reply-To: <1381694847.24.0.709324715816.issue19251@psf.upfronthosting.co.za>
Message-ID: <1463269905.22.0.801474901692.issue19251@psf.upfronthosting.co.za>


Cameron Simpson added the comment:

Amendment: I wrote above: "Just because a lot of things can be written/constructed as one liners doesn't mean they should be operators". Of course I meant to write "doesn't mean they should _not_ be operators".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19251>
_______________________________________

From report at bugs.python.org  Sat May 14 20:34:56 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 15 May 2016 00:34:56 +0000
Subject: [issue25533] Make pkgutil.iter_modules() yield built-in modules
In-Reply-To: <1446462853.43.0.928344730721.issue25533@psf.upfronthosting.co.za>
Message-ID: <1463272496.54.0.210931869424.issue25533@psf.upfronthosting.co.za>


Martin Panter added the comment:

It looks like Issue 1644818 is the one for built-in _packages_.

I might wind back the frozen module stuff and go back to just builtins and sys.path searching. The two problems were the existing frozen packages that print stuff out for the test suite, and the lack of search ?paths? for frozen submodules. I feel that these might be solved without too much effort, so if people want this feature or have suggestions, I am happy to revisit this.

For the record, I think walk_packages() would import every _package_ (not non-packages), in order to be able to properly find their submodules. Also, ?pydoc -k? would have to import every module to be able to search its defined classes, functions, doc strings, etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25533>
_______________________________________

From report at bugs.python.org  Sat May 14 20:57:41 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 15 May 2016 00:57:41 +0000
Subject: [issue3948] readline steals sigwinch
In-Reply-To: <1222203569.91.0.225970694441.issue3948@psf.upfronthosting.co.za>
Message-ID: <1463273861.34.0.501656415609.issue3948@psf.upfronthosting.co.za>


Martin Panter added the comment:

Is this actually about how SIGWINCH handlers are installed, or is it a complaint about readline affecting how curses handles resize events? I am assuming this is about handling resize events, so is a duplicate of Issue 2675.

If it is specifically about SIGWINCH, I understand Gnu Readline recently changed its SIGWINCH handling so that it only installs the handler when it is active. As a result, we recently changed Python to install its own SIGWINCH handler on behalf of Readline (Issue 23735). But I understand in both cases, the handler for Readline chain calls the original handler, so there should be no problem.

----------
nosy: +martin.panter
resolution:  -> duplicate
status: open -> closed
superseder:  -> Curses terminal resize problems when Python is in interactive mode

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3948>
_______________________________________

From report at bugs.python.org  Sat May 14 21:05:47 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 15 May 2016 01:05:47 +0000
Subject: [issue2675] Curses terminal resize problems when Python is in
 interactive mode
In-Reply-To: <1208965300.42.0.575050740888.issue2675@psf.upfronthosting.co.za>
Message-ID: <1463274347.82.0.497968921144.issue2675@psf.upfronthosting.co.za>


Martin Panter added the comment:

For the record, this is my interpretation of Pavel?s demo:

If you press a key (other than lowercase ?q?) or resize the terminal, it displays the terminal dimensions in the top-left corner. Without Readline, the dimensions are updated when the terminal resizes.

When Readline is used (interactive mode, or simply ?import readline?), the reported dimensions are static, which I understand is the bug.

Documentating this quirk may be a good start.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, martin.panter
stage: test needed -> needs patch
versions: +Python 2.7, Python 3.5, Python 3.6 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2675>
_______________________________________

From report at bugs.python.org  Sat May 14 21:13:20 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 May 2016 01:13:20 +0000
Subject: [issue25533] Make pkgutil.iter_modules() yield built-in modules
In-Reply-To: <1446462853.43.0.928344730721.issue25533@psf.upfronthosting.co.za>
Message-ID: <20160515011317.9373.96239.650ED7A4@psf.io>


Roundup Robot added the comment:

New changeset 2f19766d4b20 by Martin Panter in branch '3.5':
Issue #25533: Update documentation regarding the frozen modules table
https://hg.python.org/cpython/rev/2f19766d4b20

New changeset b20b580bc186 by Martin Panter in branch 'default':
Issue #25533: Merge frozen module docs from 3.5
https://hg.python.org/cpython/rev/b20b580bc186

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25533>
_______________________________________

From report at bugs.python.org  Sat May 14 21:37:40 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 15 May 2016 01:37:40 +0000
Subject: [issue27014] maximum recursion depth when using typing options
In-Reply-To: <1463144236.79.0.623590161328.issue27014@psf.upfronthosting.co.za>
Message-ID: <1463276260.83.0.923573139021.issue27014@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Simpler repro:

from collections import UserList
from typing import Sequence
class MyList(UserList, Sequence):
    pass
isinstance(None, Sequence)

No progress yet in understanding. :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27014>
_______________________________________

From report at bugs.python.org  Sat May 14 22:07:45 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 May 2016 02:07:45 +0000
Subject: [issue26870] Unexpected call to readline's add_history in
 call_readline
In-Reply-To: <1461743534.82.0.668302064476.issue26870@psf.upfronthosting.co.za>
Message-ID: <20160515020742.21214.35609.FC2A0FC6@psf.io>


Roundup Robot added the comment:

New changeset 4195fa81b188 by Martin Panter in branch 'default':
Issue #26870: Add readline.set_auto_history(), originally by Tyler Crompton
https://hg.python.org/cpython/rev/4195fa81b188

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26870>
_______________________________________

From report at bugs.python.org  Sat May 14 22:17:15 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 15 May 2016 02:17:15 +0000
Subject: [issue20886] Disabling logging to ~/.python_history is not simple
 enough
In-Reply-To: <1394483435.54.0.13789888009.issue20886@psf.upfronthosting.co.za>
Message-ID: <1463278634.99.0.691988019084.issue20886@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks to Issue 26870, in Python 3.6 you should be able to call readline.set_auto_history(False) to stop entries being added to the history list. Does that change anything here?

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20886>
_______________________________________

From report at bugs.python.org  Sat May 14 22:38:54 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Sun, 15 May 2016 02:38:54 +0000
Subject: [issue27023] Documentation of tempfile.gettempdir() does not mention
 it only supports existing directories
In-Reply-To: <1463247583.74.0.311593159637.issue27023@psf.upfronthosting.co.za>
Message-ID: <1463279934.29.0.936557286201.issue27023@psf.upfronthosting.co.za>


Steven D'Aprano added the comment:

I don't understand. The documentation clearly states:

"Python searches a standard list of directories to find one which the calling user can create files in." How do you expect to be able to write files to a directory that doesn't exist?

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27023>
_______________________________________

From report at bugs.python.org  Sat May 14 23:07:54 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 May 2016 03:07:54 +0000
Subject: [issue26870] Unexpected call to readline's add_history in
 call_readline
In-Reply-To: <1461743534.82.0.668302064476.issue26870@psf.upfronthosting.co.za>
Message-ID: <20160515030750.35015.94146.B0C71E89@psf.io>


Roundup Robot added the comment:

New changeset 27a49daf7925 by Martin Panter in branch 'default':
Issue #26870: Close pty master in case of exception
https://hg.python.org/cpython/rev/27a49daf7925

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26870>
_______________________________________

From report at bugs.python.org  Sat May 14 23:12:14 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 15 May 2016 03:12:14 +0000
Subject: [issue26870] Unexpected call to readline's add_history in
 call_readline
In-Reply-To: <1461743534.82.0.668302064476.issue26870@psf.upfronthosting.co.za>
Message-ID: <1463281934.55.0.472606896592.issue26870@psf.upfronthosting.co.za>


Martin Panter added the comment:

My test locked up on an OS X buildbot <http://buildbot.python.org/all/builders/AMD64%20Snow%20Leop%203.x/builds/4623/steps/test/logs/stdio>:

Timeout (0:15:00)!
Thread 0x00007fff71296cc0 (most recent call first):
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/subprocess.py", line 1612 in _try_wait
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/subprocess.py", line 1662 in wait
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/subprocess.py", line 1003 in __exit__
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/test_readline.py", line 146 in run_pty
  File "/Users/buildbot/buildarea/3.x.murray-snowleopard/build/Lib/test/test_readline.py", line 115 in test_auto_history_disabled

The parent was hanging as it exits the child proc context manager, waiting for the child to exit. Perhaps some exception happened in the parent before it could write to the child, so the child is still waiting on input. So I added code to close the master in case of exception, which may at least help understand the situation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26870>
_______________________________________

From report at bugs.python.org  Sat May 14 23:36:47 2016
From: report at bugs.python.org (Tyler Crompton)
Date: Sun, 15 May 2016 03:36:47 +0000
Subject: [issue26870] Unexpected call to readline's add_history in
 call_readline
In-Reply-To: <1461743534.82.0.668302064476.issue26870@psf.upfronthosting.co.za>
Message-ID: <1463283407.51.0.101432424374.issue26870@psf.upfronthosting.co.za>


Tyler Crompton added the comment:

I suppose the only thing that could be left is adding remarks in the documentations for previous versions. If I understand correctly, this would only be added to the documentations for Python 2.7 and 3.5. Is this correct?

Since this is the first issue in which I've submitted a patch, I'm still quite new to the CPython development workflow; is there a special way to indicate that a patch should be applied to a branch other than default? Or is that done simply by informally indicating so in a message?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26870>
_______________________________________

From report at bugs.python.org  Sat May 14 23:44:30 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 15 May 2016 03:44:30 +0000
Subject: [issue25533] Make pkgutil.iter_modules() yield built-in modules
In-Reply-To: <1446462853.43.0.928344730721.issue25533@psf.upfronthosting.co.za>
Message-ID: <1463283870.86.0.909225539599.issue25533@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

To answer Brett's question about "Why does walk_packages import parent modules?", the answer is "Because __init__ can modify __path__, so if you don't import the parent module, you may miss things that actually doing the import would find".

The classic example of this is pre-3.3 namespace packages: those work by calling pkgutil.extend_path() or pkg_resources.declare_namespace() from the package's __init__ file, and they can be made to work regardless of whether or not the parent module is implemented as "foo.py" or "foo/__init__.py". 

My recollection is that the pkgutil APIs treat that capability as a basic operating assumption: they import everything they find and check it for a __path__ attribute on the grounds that arbitrary modules *might* set __path__ dynamically.


It would potentially be worthwhile introducing side-effect free variants of these two APIs: "pkgutil.iter_modules_static()" and "pkgutil.walk_packages_static()" (suggested suffix inspired by "inspect.getattr_static()".

The idea with those would be to report all packages that can be found whilst assuming that no module dynamically adds a __path__ attribute to itself, or alters a __path__ attribute calculated by a standard import hook.

Actually doing that in a generic fashion would require either expanding the APIs for meta_path importers and path import hooks or else using functools.simplegeneric to allow new walkers to be registered for unknown importers and hooks, with the latter approach being closer to the way pkgutil currently works.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25533>
_______________________________________

From report at bugs.python.org  Sat May 14 23:57:03 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 15 May 2016 03:57:03 +0000
Subject: [issue26870] Unexpected call to readline's add_history in
 call_readline
In-Reply-To: <1461743534.82.0.668302064476.issue26870@psf.upfronthosting.co.za>
Message-ID: <1463284623.34.0.340741646496.issue26870@psf.upfronthosting.co.za>


Martin Panter added the comment:

Yes 3.5 and 2.7 are open for documentation fixes. As long as there are no major differences, it is usually easier to make one patch against 3.5 or 3.6, and then I can fix any minor differences when applying it to 2.7.

----------
versions: +Python 2.7, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26870>
_______________________________________

From report at bugs.python.org  Sun May 15 00:07:11 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 May 2016 04:07:11 +0000
Subject: [issue26870] Unexpected call to readline's add_history in
 call_readline
In-Reply-To: <1461743534.82.0.668302064476.issue26870@psf.upfronthosting.co.za>
Message-ID: <20160515040708.31181.59113.9A7D2A1E@psf.io>


Roundup Robot added the comment:

New changeset b8b2c5cc7e9d by Martin Panter in branch 'default':
Issue #26870: Temporary debugging for OS X Snow Leopard lockup
https://hg.python.org/cpython/rev/b8b2c5cc7e9d

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26870>
_______________________________________

From report at bugs.python.org  Sun May 15 00:29:12 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 May 2016 04:29:12 +0000
Subject: [issue27018] Incorrect documentation of select module
In-Reply-To: <1463221477.58.0.675652051466.issue27018@psf.upfronthosting.co.za>
Message-ID: <20160515042909.19082.24603.86C70BC6@psf.io>


Roundup Robot added the comment:

New changeset 37c95a4b979a by Senthil Kumaran in branch '3.5':
issue27018 - Fix the documentation of select.epoll.register method.
https://hg.python.org/cpython/rev/37c95a4b979a

New changeset eca161a355d4 by Senthil Kumaran in branch 'default':
merge from 3.5
https://hg.python.org/cpython/rev/eca161a355d4

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27018>
_______________________________________

From report at bugs.python.org  Sun May 15 00:30:12 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 15 May 2016 04:30:12 +0000
Subject: [issue27018] Incorrect documentation of select module
In-Reply-To: <1463221477.58.0.675652051466.issue27018@psf.upfronthosting.co.za>
Message-ID: <1463286612.39.0.583802190824.issue27018@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Thanks for the report, Salvo.
And thank you for the patch, SilentGhost. This is fixed in the active versions of python.

----------
nosy: +orsenthil
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27018>
_______________________________________

From report at bugs.python.org  Sun May 15 00:41:28 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Sun, 15 May 2016 04:41:28 +0000
Subject: [issue27020] os.writev() does not accept generators (as buffers
 argument)
In-Reply-To: <1463247043.26.0.60216509871.issue27020@psf.upfronthosting.co.za>
Message-ID: <1463287288.12.0.502809134478.issue27020@psf.upfronthosting.co.za>


???? ????????? added the comment:

Well, I'm improving asyncio performance.

Instead of using bytearray as a big buffer and appending to it, I use deque of buffers. This eliminates memory copying.

When writing is possible, I call writev()/sendmsg().

Unfortunatelly, OS sets limit on count of buffers passed to writev()/sendmsg(). So I should slice deque to cut first N members. This is not possible too, deque()[:N] does not work.

So, I decide to use itertools.islice(deque(), 0, N) for that. This work great with sendmsg(). But fail with writev().

Also, writev guarantee atimicity with ther writes in kernel, we must not limit way of obtainig buffers before passing to kernel.

If Python have emulation of writev() on OS where it is not supported, it should be thrown out, because atomicity requirements will not be accomplished. And writes to non-seekable fd from another process may be intermixed. Say, for example, files opened in append-only mode.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27020>
_______________________________________

From report at bugs.python.org  Sun May 15 00:42:11 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Sun, 15 May 2016 04:42:11 +0000
Subject: [issue27020] os.writev() does not accept generators (as buffers
 argument)
In-Reply-To: <1463247043.26.0.60216509871.issue27020@psf.upfronthosting.co.za>
Message-ID: <1463287331.63.0.596265823949.issue27020@psf.upfronthosting.co.za>


???? ????????? added the comment:

Pull request to asyncio:

https://github.com/python/asyncio/pull/339

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27020>
_______________________________________

From report at bugs.python.org  Sun May 15 01:25:10 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 May 2016 05:25:10 +0000
Subject: [issue26039] More flexibility in zipfile write interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <1463289910.06.0.0843045178079.issue26039@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Agreed that the docstring should be shorten version of the documentation and not vice versa. The directory slash information is implementation detail. I'm not sure it is needed in the documentation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26039>
_______________________________________

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: [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 01:31:20 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 May 2016 05:31:20 +0000
Subject: [issue20640] Idle: test configHelpSourceEdit
In-Reply-To: <1392563325.46.0.352105521636.issue20640@psf.upfronthosting.co.za>
Message-ID: <20160515053116.89093.75994.7DD65581@psf.io>


Roundup Robot added the comment:

New changeset c05689e630d3 by Terry Jan Reedy in branch '3.5':
Issue #20640: Add tests for idlelib.configHelpSourceEdit.
https://hg.python.org/cpython/rev/c05689e630d3

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20640>
_______________________________________

From report at bugs.python.org  Sun May 15 01:37:02 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 15 May 2016 05:37:02 +0000
Subject: [issue20640] Idle: test configHelpSourceEdit
In-Reply-To: <1392563325.46.0.352105521636.issue20640@psf.upfronthosting.co.za>
Message-ID: <1463290622.43.0.332126076374.issue20640@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The glitch with the section name was that the second time the name was pulled from the StringVar, it was not stripped.  The possible fixes were to strip after the second get, get once in ok(), strip, and pass to name_ok, or get once in name_ok, strip, and return to ok().  Both the latter two simplify the code a bit.

For help-source, the second gets were alreads stripped as well, so the glitch is not present.  I applied the patch as posted.  If I were to make a change to get once, I would do it in ok rather than in xyz_ok.  Maybe when I combine the files.

----------
assignee:  -> terry.reedy
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
versions: +Python 3.6 -Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20640>
_______________________________________

From report at bugs.python.org  Sun May 15 01:56:51 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 15 May 2016 05:56:51 +0000
Subject: [issue23977] Enhancing IDLE's test_delegator.py unit test
In-Reply-To: <1429222717.34.0.436460627497.issue23977@psf.upfronthosting.co.za>
Message-ID: <1463291811.38.0.0537322912262.issue23977@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The patch adds too much.  Some of the comments are too obvious.  See PEP 8.  Many of the messages repeat the information already provided in the custom messages already provided by the assertXyz failure methods.  For instance, when assertEqual(a, b) fails, the message already prints out something like "%s != $s" % (repr(a), repr(b)).  Perhaps you were not familiar with this.  One of the problems of retrofitting tests is that we do not see the default failure messages.

In any case, over-commenting and over-messaging are not harmless as they make code and failure messages harder, not easier to read.  I will review and add what I think is useful.

----------
assignee:  -> terry.reedy
nosy: +terry.reedy
stage:  -> patch review
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23977>
_______________________________________

From report at bugs.python.org  Sun May 15 02:18:26 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 15 May 2016 06:18:26 +0000
Subject: [issue24225] Idlelib: changing file names
In-Reply-To: <1431934587.56.0.38760352205.issue24225@psf.upfronthosting.co.za>
Message-ID: <1463293106.29.0.457647151503.issue24225@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

turtledemo.__main__ imports from idlelib will also need fixing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24225>
_______________________________________

From report at bugs.python.org  Sun May 15 02:22:09 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Sun, 15 May 2016 06:22:09 +0000
Subject: [issue26934] android: test_faulthandler fails
In-Reply-To: <1462287504.69.0.311102051296.issue26934@psf.upfronthosting.co.za>
Message-ID: <1463293329.62.0.0199302992447.issue26934@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

> Please try without "sigaction(SIGSEGV, NULL, NULL);". Does the program still quit?

Nope.

int main()
{
    raise(SIGSEGV);
}

Still exits normally with 0.

> Does faulthandler._read_null() crash Python?

Yes.

int main()
{
    int *x = 0;
    int y = *x;
    return 0;
}

Is killed and exits with 139 as expected.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26934>
_______________________________________

From report at bugs.python.org  Sun May 15 02:41:49 2016
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 15 May 2016 06:41:49 +0000
Subject: [issue26331] Tokenizer: allow underscores for grouping in numeric
 literals
In-Reply-To: <1455126624.48.0.163167904941.issue26331@psf.upfronthosting.co.za>
Message-ID: <1463294509.23.0.484223595511.issue26331@psf.upfronthosting.co.za>


Georg Brandl added the comment:

New patch; implements the accepted version of the PEP. I added the additional tests, thanks Stefan!

----------
Added file: http://bugs.python.org/file42852/numeric_underscores_final_v5.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26331>
_______________________________________

From report at bugs.python.org  Sun May 15 02:45:19 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 May 2016 06:45:19 +0000
Subject: [issue24693] zipfile: change RuntimeError to more appropriate
 exception type
In-Reply-To: <1437654224.43.0.502488912035.issue24693@psf.upfronthosting.co.za>
Message-ID: <1463294719.3.0.507030042851.issue24693@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Updated patch includes changed tests and the documentation. It includes changes for new exceptions added in issue26039. Perhaps not all changes should be accepted, but I have included them for demonstrating.

RuntimeError was used in following cases:

1. Compressed or uncompressed file size unexpectedly exceeded 32-bit limit. I think this should left RuntimeError.

2. Compression requires the (missing) zlib/bz2/lzma module. I think this should left RuntimeError.

3. Unsupported compression method. This can be changed to more specific NotImplementedError without breaking compatibility.

4. Corrupted extra field. BadZipFile is more appropriate exception. Not documented.

5. Invalid mode for ZipFile() or ZipFile.open(). ValueError is more appropriate exception, this is programming error. Not documented.

6. File not ending with ".py" for PyZipFile.writepy(). ValueError looks more appropriate exception, but RuntimeError is documented.

7. Write in reading mode, use after closing. ValueError or io.UnsupportedOperation would be more consistent with files, but RuntimeError can be also used in similar cases. RuntimeError is explicitly documented (maybe because it is not typical exception for such cases). Unfortunately there is no special exception type for using an object in wrong state.

8. Read, write or close when there is other open writing handler. These are new exceptions and we are free to change them. There are arguments for using ValueError and RuntimeError in similar cases.

9. Absent or incorrect password for encrypted file. If file encryption is expected, this is programming error and can be ValueError, but if it is not expected, it should be RuntimeError.

I'm going to push changes for cases 3 and 4, this looks safe. Cases 5 and 6 are more discussable. There are reasons for RuntimeError in cases 7, 8 and 9. And I think RuntimeError is appropriate in cases 1 and 2.

----------
Added file: http://bugs.python.org/file42853/zipfile_exceptions2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24693>
_______________________________________

From report at bugs.python.org  Sun May 15 02:57:34 2016
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 15 May 2016 06:57:34 +0000
Subject: [issue26331] Tokenizer: allow underscores for grouping in numeric
 literals
In-Reply-To: <1455126624.48.0.163167904941.issue26331@psf.upfronthosting.co.za>
Message-ID: <1463295454.85.0.532657056372.issue26331@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


Removed file: http://bugs.python.org/file42852/numeric_underscores_final_v5.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26331>
_______________________________________

From report at bugs.python.org  Sun May 15 02:57:43 2016
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 15 May 2016 06:57:43 +0000
Subject: [issue26331] Tokenizer: allow underscores for grouping in numeric
 literals
In-Reply-To: <1455126624.48.0.163167904941.issue26331@psf.upfronthosting.co.za>
Message-ID: <1463295463.0.0.188533417629.issue26331@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


Added file: http://bugs.python.org/file42854/numeric_underscores_final_v6.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26331>
_______________________________________

From report at bugs.python.org  Sun May 15 02:57:55 2016
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 15 May 2016 06:57:55 +0000
Subject: [issue26331] Tokenizer: allow underscores for grouping in numeric
 literals
In-Reply-To: <1455126624.48.0.163167904941.issue26331@psf.upfronthosting.co.za>
Message-ID: <1463295475.1.0.612619261131.issue26331@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


Removed file: http://bugs.python.org/file41894/numeric_underscores_v3_full.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26331>
_______________________________________

From report at bugs.python.org  Sun May 15 02:58:00 2016
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 15 May 2016 06:58:00 +0000
Subject: [issue26331] Tokenizer: allow underscores for grouping in numeric
 literals
In-Reply-To: <1455126624.48.0.163167904941.issue26331@psf.upfronthosting.co.za>
Message-ID: <1463295480.27.0.792450088594.issue26331@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


Removed file: http://bugs.python.org/file41888/numeric_underscores.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26331>
_______________________________________

From report at bugs.python.org  Sun May 15 02:58:06 2016
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 15 May 2016 06:58:06 +0000
Subject: [issue26331] Tokenizer: allow underscores for grouping in numeric
 literals
In-Reply-To: <1455126624.48.0.163167904941.issue26331@psf.upfronthosting.co.za>
Message-ID: <1463295486.56.0.990197142918.issue26331@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


Removed file: http://bugs.python.org/file41892/numeric_underscores_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26331>
_______________________________________

From report at bugs.python.org  Sun May 15 03:01:42 2016
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 15 May 2016 07:01:42 +0000
Subject: [issue26331] Tokenizer: allow underscores for grouping in numeric
 literals
In-Reply-To: <1455126624.48.0.163167904941.issue26331@psf.upfronthosting.co.za>
Message-ID: <1463295702.92.0.596179829832.issue26331@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Note: the changes for format()ting ("_" as thousands separator) are still missing. Eric, would you consider doing this part?

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26331>
_______________________________________

From report at bugs.python.org  Sun May 15 03:08:12 2016
From: report at bugs.python.org (ProgVal)
Date: Sun, 15 May 2016 07:08:12 +0000
Subject: [issue27023] Documentation of tempfile.gettempdir() does not mention
 it only supports existing directories
In-Reply-To: <1463247583.74.0.311593159637.issue27023@psf.upfronthosting.co.za>
Message-ID: <1463296092.72.0.805223247355.issue27023@psf.upfronthosting.co.za>


ProgVal added the comment:

The directory could be created

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27023>
_______________________________________

From report at bugs.python.org  Sun May 15 04:04:06 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 May 2016 08:04:06 +0000
Subject: [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:05:23 2016
From: report at bugs.python.org (Thomas Kluyver)
Date: Sun, 15 May 2016 08:05:23 +0000
Subject: [issue26039] More flexibility in zipfile write interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <1463299523.37.0.763009223136.issue26039@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

Updated version of the patch with the detail moved to rst.

----------
Added file: http://bugs.python.org/file42855/zipfile-flex-bonus2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26039>
_______________________________________

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: [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 04:30:46 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 May 2016 08:30:46 +0000
Subject: [issue27024] IDLE shutdown glitch when started by import
In-Reply-To: <1463289946.09.0.360878393598.issue27024@psf.upfronthosting.co.za>
Message-ID: <1463301046.6.0.819426017664.issue27024@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

There are few possible workarounds:

1. Catch and ignore TclError in CodeContext.timer_event, CodeContext.font_timer_event and other callbacks.

2. Save results of after() and after_idle() calls and pass them to after_cancel() before destroying widgets. Maybe this should be done automatically in Tkinter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27024>
_______________________________________

From report at bugs.python.org  Sun May 15 04:38:52 2016
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 15 May 2016 08:38:52 +0000
Subject: [issue21199] Python on 64-bit Windows uses signed 32-bit type for
 read length
In-Reply-To: <1397149133.44.0.946556558932.issue21199@psf.upfronthosting.co.za>
Message-ID: <1463301532.76.0.440230380605.issue21199@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Summary: read Matt's original message on the bug.

Status: still broken.  Some people think it should be left that way.

Proposed fix: it's straightforward to fix.  You wrote a patch, I modified yours a little.  The patch is short and easy to read.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21199>
_______________________________________

From report at bugs.python.org  Sun May 15 05:12:15 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 15 May 2016 09:12:15 +0000
Subject: [issue27026] async/await keywords are missing from reference docs
In-Reply-To: <1463299580.57.0.0973198258941.issue27026@psf.upfronthosting.co.za>
Message-ID: <1463303535.14.0.868489659894.issue27026@psf.upfronthosting.co.za>


Martin Panter added the comment:

..Related: Issue 26264, about updating the keywords module.

Technically they are only reserved inside ?async def? functions. So it could be misleading adding them with the other always-reserved keywords without an explanation.

----------
nosy: +martin.panter, yselivanov
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27026>
_______________________________________

From report at bugs.python.org  Sun May 15 05:21:55 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 May 2016 09:21:55 +0000
Subject: [issue27024] IDLE shutdown glitch when started by import
In-Reply-To: <1463289946.09.0.360878393598.issue27024@psf.upfronthosting.co.za>
Message-ID: <1463304115.72.0.60553592618.issue27024@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Proposed patch fixes the issue for all Tkinter applications.

----------
components: +Tkinter -IDLE
keywords: +patch
stage: test needed -> patch review
type:  -> behavior
versions: +Python 2.7
Added file: http://bugs.python.org/file42857/tkinter_destroy_cancel_handlers.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27024>
_______________________________________

From report at bugs.python.org  Sun May 15 05:27:48 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 May 2016 09:27:48 +0000
Subject: [issue26039] More flexibility in zipfile write interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <20160515092745.6341.68814.99378072@psf.io>


Roundup Robot added the comment:

New changeset 29b470b8ab77 by Serhiy Storchaka in branch 'default':
Issue #26039: Document ZipInfo.is_dir() and make force_zip64 keyword-only.
https://hg.python.org/cpython/rev/29b470b8ab77

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26039>
_______________________________________

From report at bugs.python.org  Sun May 15 05:28:20 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 15 May 2016 09:28:20 +0000
Subject: [issue26870] Unexpected call to readline's add_history in
 call_readline
In-Reply-To: <1461743534.82.0.668302064476.issue26870@psf.upfronthosting.co.za>
Message-ID: <1463304500.1.0.966162529602.issue26870@psf.upfronthosting.co.za>


Martin Panter added the comment:

Unfortunately, I think my debugging messages needed a flush() call to be effective when the deadlock happens.

So the test is failing on three buildbots:

* AMD64 Snow Leop 3.x: stuck at Lib/subprocess.py:1612, os.waitpid() waiting for child to exit
* x86 OpenBSD 3.x: stuck at Lib/selectors.py:569, sel.select() -> self._kqueue.control() waiting for pty event
* x86 Tiger 3.x: sel.register() -> self._kqueue.control() raises ENOTSUP

On the other hand, the test is passing on Free BSD, Open Indiana, AIX, and Linux (+ Meador?s OS X Yosemite). I think I might just skip the test on the problematic platforms, unless anyone has any suggestions for these other platforms:

@unittest.skipIf(sys.platform.startswith(("darwin", "openbsd")))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26870>
_______________________________________

From report at bugs.python.org  Sun May 15 05:28:40 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 May 2016 09:28:40 +0000
Subject: [issue26039] More flexibility in zipfile write interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <1463304520.21.0.0530022130415.issue26039@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM. Thank you Thomas.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26039>
_______________________________________

From report at bugs.python.org  Sun May 15 05:33:52 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 15 May 2016 09:33:52 +0000
Subject: [issue20640] Idle: test configHelpSourceEdit
In-Reply-To: <1392563325.46.0.352105521636.issue20640@psf.upfronthosting.co.za>
Message-ID: <1463304832.45.0.760201053416.issue20640@psf.upfronthosting.co.za>


Martin Panter added the comment:

FYI this broke the OS X buildbots:

======================================================================
FAIL: test_ok (idlelib.idle_test.test_config_help.ConfigHelpTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.5.bolen-tiger/build/Lib/idlelib/idle_test/test_config_help.py", line 96, in test_ok
    'https://docs.python.org'))
AssertionError: ['help', 'file://https://docs.python.org'] != ('help', 'https://docs.python.org')

======================================================================
FAIL: test_idlever (idlelib.idle_test.test_warning.ImportWarnTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.5.bolen-tiger/build/Lib/idlelib/idle_test/test_warning.py", line 76, in test_idlever
    self.assertEqual(len(w), 1)
AssertionError: 0 != 1

(I?m partly to blame for the current 3.x OS X breakage, but not 3.5.)

----------
nosy: +martin.panter
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20640>
_______________________________________

From report at bugs.python.org  Sun May 15 05:38:38 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 May 2016 09:38:38 +0000
Subject: [issue11549] Build-out an AST optimizer,
 moving some functionality out of the peephole optimizer
In-Reply-To: <1300164402.79.0.766591131661.issue11549@psf.upfronthosting.co.za>
Message-ID: <1463305118.9.0.115071901815.issue11549@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Yes, the patch is outdated, conflicts with current code (and would conflict even more after pushing the wordcode patch) and contains bugs. But it moved in right direction, I think your _PyCode_ConstantKey() could help to fix bugs. I'm going to revive this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11549>
_______________________________________

From report at bugs.python.org  Sun May 15 05:43:02 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 May 2016 09:43:02 +0000
Subject: [issue20640] Idle: test configHelpSourceEdit
In-Reply-To: <1392563325.46.0.352105521636.issue20640@psf.upfronthosting.co.za>
Message-ID: <1463305382.12.0.390285787749.issue20640@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

For test_idlever see issue25747.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20640>
_______________________________________

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: [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 06:12:47 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 15 May 2016 10:12:47 +0000
Subject: [issue26865] Meta-issue: support of the android platform
In-Reply-To: <1461685011.99.0.617135447086.issue26865@psf.upfronthosting.co.za>
Message-ID: <1463307167.1.0.780082322572.issue26865@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

issue #27027: add is_android in test.support to detect Android platform

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26865>
_______________________________________

From report at bugs.python.org  Sun May 15 06:20:49 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 15 May 2016 10:20:49 +0000
Subject: [issue26934] android: test_faulthandler fails
In-Reply-To: <1462287504.69.0.311102051296.issue26934@psf.upfronthosting.co.za>
Message-ID: <1463307649.02.0.668793910808.issue26934@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

root at generic_x86:/data/local/tmp # python
Python 3.6.0a0 (default:eee959fee5f5+, May 14 2016, 13:43:41) 
[GCC 4.9 20150123 (prerelease)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import faulthandler
>>> faulthandler._read_null() 
Segmentation fault

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26934>
_______________________________________

From report at bugs.python.org  Sun May 15 06:30:06 2016
From: report at bugs.python.org (Jakub Stasiak)
Date: Sun, 15 May 2016 10:30:06 +0000
Subject: [issue26110] Speedup method calls 1.2x
In-Reply-To: <1452791347.05.0.923215900831.issue26110@psf.upfronthosting.co.za>
Message-ID: <1463308206.3.0.969575484469.issue26110@psf.upfronthosting.co.za>


Changes by Jakub Stasiak <jakub+python.org at stasiak.at>:


----------
nosy: +jstasiak

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26110>
_______________________________________

From report at bugs.python.org  Sun May 15 06:32:20 2016
From: report at bugs.python.org (Jakub Stasiak)
Date: Sun, 15 May 2016 10:32:20 +0000
Subject: [issue26058] PEP 509: Add ma_version to PyDictObject
In-Reply-To: <1452331848.43.0.271164045437.issue26058@psf.upfronthosting.co.za>
Message-ID: <1463308340.78.0.240273366679.issue26058@psf.upfronthosting.co.za>


Changes by Jakub Stasiak <jakub+python.org at stasiak.at>:


----------
nosy: +jstasiak

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26058>
_______________________________________

From report at bugs.python.org  Sun May 15 06:32:36 2016
From: report at bugs.python.org (Jakub Stasiak)
Date: Sun, 15 May 2016 10:32:36 +0000
Subject: [issue26219] implement per-opcode cache in ceval
In-Reply-To: <1453918500.26.0.0886095278127.issue26219@psf.upfronthosting.co.za>
Message-ID: <1463308356.17.0.170335825815.issue26219@psf.upfronthosting.co.za>


Changes by Jakub Stasiak <jakub+python.org at stasiak.at>:


----------
nosy: +jstasiak

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26219>
_______________________________________

From report at bugs.python.org  Sun May 15 07:28:07 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 15 May 2016 11:28:07 +0000
Subject: [issue21313] Py_GetVersion() is broken when using mqueue and a long
 patch name
In-Reply-To: <1397945838.86.0.227153547567.issue21313@psf.upfronthosting.co.za>
Message-ID: <1463311687.24.0.834317265652.issue21313@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21313>
_______________________________________

From report at bugs.python.org  Sun May 15 07:29:02 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Sun, 15 May 2016 11:29:02 +0000
Subject: [issue17085] test_socket crashes the whole test suite
In-Reply-To: <1359580628.83.0.173179383331.issue17085@psf.upfronthosting.co.za>
Message-ID: <1463311742.9.0.993434493367.issue17085@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17085>
_______________________________________

From report at bugs.python.org  Sun May 15 08:52:00 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 May 2016 12:52:00 +0000
Subject: [issue26168] Py_BuildValue may leak 'N' arguments on PyTuple_New
 failure
In-Reply-To: <1453314385.46.0.703497250236.issue26168@psf.upfronthosting.co.za>
Message-ID: <1463316720.94.0.974904194751.issue26168@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I'm not happy with pybuildvalue_leak3.patch. For failed keys it saves values with the same key (None). This means that old value can be deallocated before the end of building all dict.

Following patch collects all values after error in a tuple. This not only fixes the issue with building dict, but makes the code for building tuple, list and dict cleaner. It no longer contains the code for processing after error, it is moved in separate function.

----------
Added file: http://bugs.python.org/file42858/pybuildvalue_leak4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26168>
_______________________________________

From report at bugs.python.org  Sun May 15 09:17:52 2016
From: report at bugs.python.org (Eugene Toder)
Date: Sun, 15 May 2016 13:17:52 +0000
Subject: [issue11549] Build-out an AST optimizer,
 moving some functionality out of the peephole optimizer
In-Reply-To: <1300164402.79.0.766591131661.issue11549@psf.upfronthosting.co.za>
Message-ID: <1463318272.27.0.723745936808.issue11549@psf.upfronthosting.co.za>


Eugene Toder added the comment:

Serhiy: Nice! Yes, _PyCode_ConstantKey solved the problem.

But #16619 went in the opposite direction of this patch, and introduced a new type of literal node instead of unifying the existing ones. Kind of a shame, since *this* patch, I believe, both fixes that bug and removes the unreachable code in the example :)

I also see that Victor has been doing some of the same work, e.g. #26146.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11549>
_______________________________________

From report at bugs.python.org  Sun May 15 09:23:00 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 May 2016 13:23:00 +0000
Subject: [issue26870] Unexpected call to readline's add_history in
 call_readline
In-Reply-To: <1461743534.82.0.668302064476.issue26870@psf.upfronthosting.co.za>
Message-ID: <20160515132256.96441.90885.6779754A@psf.io>


Roundup Robot added the comment:

New changeset 816e1fe72c1e by Martin Panter in branch 'default':
Issue #26870: Avoid using kqueue() with pseudo-terminals
https://hg.python.org/cpython/rev/816e1fe72c1e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26870>
_______________________________________

From report at bugs.python.org  Sun May 15 09:47:44 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 May 2016 13:47:44 +0000
Subject: [issue24291] Many servers (wsgiref, http.server,
 etc) can truncate large output blobs
In-Reply-To: <1432671481.51.0.762064908488.issue24291@psf.upfronthosting.co.za>
Message-ID: <1463320064.28.0.825443991844.issue24291@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

SimpleHTTPRequestHandler uses shutil.copyfileobj(), and shutil.copyfileobj() expects that write() writes all data.

----------
components: +IO
nosy: +benjamin.peterson, pitrou, stutzbach, tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24291>
_______________________________________

From report at bugs.python.org  Sun May 15 09:57:06 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 15 May 2016 13:57:06 +0000
Subject: [issue26331] Tokenizer: allow underscores for grouping in numeric
 literals
In-Reply-To: <1455126624.48.0.163167904941.issue26331@psf.upfronthosting.co.za>
Message-ID: <1463320626.93.0.121329711397.issue26331@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

Yes, I'll read PEP 515 and work on the formatting.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26331>
_______________________________________

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: [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 11:05:47 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 May 2016 15:05:47 +0000
Subject: [issue26870] Unexpected call to readline's add_history in
 call_readline
In-Reply-To: <1461743534.82.0.668302064476.issue26870@psf.upfronthosting.co.za>
Message-ID: <20160515150537.96441.34389.1D8CE172@psf.io>


Roundup Robot added the comment:

New changeset daaead1dc3e0 by Martin Panter in branch 'default':
Issue #26870: Poll() also fails on OS X; try select()
https://hg.python.org/cpython/rev/daaead1dc3e0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26870>
_______________________________________

From report at bugs.python.org  Sun May 15 11:12:20 2016
From: report at bugs.python.org (R. David Murray)
Date: Sun, 15 May 2016 15:12:20 +0000
Subject: [issue27016] BlockingIOError not raised inside function.
In-Reply-To: <1463191419.08.0.084074707962.issue27016@psf.upfronthosting.co.za>
Message-ID: <1463325140.53.0.450051750241.issue27016@psf.upfronthosting.co.za>


R. David Murray added the comment:

If I copy the second code, and add an import for fcntl, and run the resulting program twice from two different shells, I get a BlockingIOError. This is on linux.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27016>
_______________________________________

From report at bugs.python.org  Sun May 15 11:32:51 2016
From: report at bugs.python.org (R. David Murray)
Date: Sun, 15 May 2016 15:32:51 +0000
Subject: [issue27023] Documentation of tempfile.gettempdir() does not mention
 it only supports existing directories
In-Reply-To: <1463247583.74.0.311593159637.issue27023@psf.upfronthosting.co.za>
Message-ID: <1463326371.4.0.629487784659.issue27023@psf.upfronthosting.co.za>


R. David Murray added the comment:

No, it shouldn't.

The design is that different systems use different locations for the default tempdir, and we look down a list of ones we know about until we find one that exists and can be used.  Likewise, different shells use different environment variables, so we look at a sequence of those as well.

It is arguable whether the fact that an environment variable that points to an invalid directory is ignored is a feature or a bug, but at this point tempfile has behaved that was for so long that we must class it as a feature.

In any case, I would find it objectionable for a program to create a temporary directory for me unasked.  It would be much more likely that I misspelled the directory when I set the environment variable.

----------
nosy: +r.david.murray
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27023>
_______________________________________

From report at bugs.python.org  Sun May 15 11:35:37 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 15 May 2016 15:35:37 +0000
Subject: [issue11549] Build-out an AST optimizer,
 moving some functionality out of the peephole optimizer
In-Reply-To: <CAMpsgwZxSMW9YsSVtPrsu=zPBiYuGbcaoKh1rs9meWcYX1w9ng@mail.gmail.com>
Message-ID: <CAMpsgwaChBvEE-aWXxLKCP_BLU=Bd+fczzBrhY-uPmWOAq8tDA@mail.gmail.com>


STINNER Victor added the comment:

> I also see that Victor has been doing some of the same work, e.g. #26146.

ast.Constant idea directly comes from your work. The implementatiln may ve
different.

It's a first step for AST optimizers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11549>
_______________________________________

From report at bugs.python.org  Sun May 15 11:40:54 2016
From: report at bugs.python.org (Eugene Toder)
Date: Sun, 15 May 2016 15:40:54 +0000
Subject: [issue20371] datetime.datetime.replace bypasses a subclass's __new__
In-Reply-To: <1390506444.15.0.286575412745.issue20371@psf.upfronthosting.co.za>
Message-ID: <1463326854.66.0.736519203855.issue20371@psf.upfronthosting.co.za>


Eugene Toder added the comment:

Properly supporting subclasses in replace() is hard, at least without some cooperation from subclasses. For a proper replace()

x.replace(a=newval).b == x.b

should hold for every b not dependent on a, including ones added by subclasses. That is, it should replicate subclass state. Arguably, ideal replace() would also allow changing attributes defined by subclasses -- otherwise subclasses need to override it anyway, and all this effort was for nothing.

The best I can think of is to assume that subclasses are immutable and all "primary" properties are settable via constructor arguments with the same names. Then replace() can be implemented like this:

def replace(self, *args, **kwargs):
    sig = inspect.signature(self.__new__)
    bound = sig.bind_partial(type(self), *args, **kwargs)
    for arg in sig.parameters:
        if arg not in bound.arguments:
            bound.arguments[arg] = getattr(self, arg)
    return self.__new__(*bound.args, **bound.kwargs)

This will not work for subclasses defined in C, but at least we can show a nice error about that. This will also not work if __new__ uses *args or **kwargs instead of listing every property as its own argument.

(Another approach I can think of is patching properties on self, making a copy of self via __reduce__, and reverting values on self back. This doesn't rely on any signatures, but gets really dirty really quick.)

So I don't know if we want to implement this, or if returning base class from replace() is a better choice.

----------
nosy: +eltoder, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20371>
_______________________________________

From report at bugs.python.org  Sun May 15 11:45:49 2016
From: report at bugs.python.org (R. David Murray)
Date: Sun, 15 May 2016 15:45:49 +0000
Subject: [issue27028] configparser BasicInterpolation issue with %()
In-Reply-To: <1463324449.1.0.433434193016.issue27028@psf.upfronthosting.co.za>
Message-ID: <1463327149.83.0.54260443844.issue27028@psf.upfronthosting.co.za>


R. David Murray added the comment:

You are missing the trailing 's' on the format string.

----------
nosy: +r.david.murray
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
title: BasicInterpolation issue with %() -> configparser BasicInterpolation issue with %()
type: compile error -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27028>
_______________________________________

From report at bugs.python.org  Sun May 15 11:50:35 2016
From: report at bugs.python.org (R. David Murray)
Date: Sun, 15 May 2016 15:50:35 +0000
Subject: [issue20371] datetime.datetime.replace bypasses a subclass's __new__
In-Reply-To: <1390506444.15.0.286575412745.issue20371@psf.upfronthosting.co.za>
Message-ID: <1463327435.42.0.149335716857.issue20371@psf.upfronthosting.co.za>


R. David Murray added the comment:

Why can't you make a copy and then patch the changed attributes on the copy?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20371>
_______________________________________

From report at bugs.python.org  Sun May 15 11:48:17 2016
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 15 May 2016 15:48:17 +0000
Subject: [issue21199] Python on 64-bit Windows uses signed 32-bit type for
 read length
In-Reply-To: <1397149133.44.0.946556558932.issue21199@psf.upfronthosting.co.za>
Message-ID: <1463327297.84.0.434274105145.issue21199@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Updated patch based on feedback from Serihy.  Thanks for the ping.

----------
Added file: http://bugs.python.org/file42860/larry.make.file_read.use.size_t.2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21199>
_______________________________________

From report at bugs.python.org  Sun May 15 11:57:49 2016
From: report at bugs.python.org (SilentGhost)
Date: Sun, 15 May 2016 15:57:49 +0000
Subject: [issue27022] expose sendmmsg() syscall  in sockets API
In-Reply-To: <1463247542.08.0.661246316661.issue27022@psf.upfronthosting.co.za>
Message-ID: <1463327869.07.0.53142341881.issue27022@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +pitrou
versions:  -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27022>
_______________________________________

From report at bugs.python.org  Sun May 15 12:01:48 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 15 May 2016 16:01:48 +0000
Subject: [issue26870] Unexpected call to readline's add_history in
 call_readline
In-Reply-To: <1461743534.82.0.668302064476.issue26870@psf.upfronthosting.co.za>
Message-ID: <1463328108.56.0.679332237671.issue26870@psf.upfronthosting.co.za>


Martin Panter added the comment:

Looks like I have ironed all the bugs out. These OS bugs/quirks have already been documented in the Python bug tracker:

1. kqueue() incompatible with PTYs on OS X < 10.9 and Open BSD (Issue Issue 20365, Issue 20667 respectively)
2. poll() also incompatible with PTYs on OS X (10.4, 10.6), probably the same as Issue 20472
3. kill() raises ESRCH if the pid is a zombie (Issue 16762)

I will leave this open for a documentation patch.

----------
stage: commit review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26870>
_______________________________________

From report at bugs.python.org  Sun May 15 12:04:28 2016
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 15 May 2016 16:04:28 +0000
Subject: [issue21199] Python on 64-bit Windows uses signed 32-bit type for
 read length
In-Reply-To: <1397149133.44.0.946556558932.issue21199@psf.upfronthosting.co.za>
Message-ID: <1463328268.09.0.867307643648.issue21199@psf.upfronthosting.co.za>


Larry Hastings added the comment:

Martin said:

> Josh: it's not as simple as just changing the type code and variable type. Systems used to require all kinds of types in the length parameter of read(2) and fread(3), including int, long, and size_t. If it was int, passing size_t would lead to silent truncation. So at a minimum, a careful review of the further processing, and a test case is necessary.

file_read() calls Py_UniversalNewlineFread() to do the actual reading.  The length argument of Py_UniversalNewlineFread(), "n", is already of type size_t, and it passes this parameter in to fread() for the number-of-elements argument.  Py_UniversalNewlineFread() is also used by file_readinto(), and that function already passes in a size_t.  So it's already successfully being used in 2.7.

If Python 2.7 still supports systems where fread()'s number-of-elements argument is smaller than size_t, this should already be causing a compilation warning on such platforms.  One would hope people supporting such platforms would fix it.  I don't know of any such platforms, so I cannot address this hypothetical issue.  Do you know of platforms supported by 2.7 where fread's number-of-elements parameter is smaller than size_t?


Antoine said:

> The benefit of fixing this in the next 2.7.x iteration is small compared to the cost of a potential regression in the core I/O implementation.

Although nobody wants to cause a regression in CPython, I'm having difficulty imagining how this change could plausibly cause one.  On the other hand, Matt makes it clear that it's a bug that has bitten hg, so I think it's worth fixing.

Can you suggest a way this change could plausibly cause a regression?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21199>
_______________________________________

From report at bugs.python.org  Sun May 15 12:16:50 2016
From: report at bugs.python.org (Sworddragon)
Date: Sun, 15 May 2016 16:16:50 +0000
Subject: [issue20886] Disabling logging to ~/.python_history is not simple
 enough
In-Reply-To: <1394483435.54.0.13789888009.issue20886@psf.upfronthosting.co.za>
Message-ID: <1463329010.79.0.97039799516.issue20886@psf.upfronthosting.co.za>


Sworddragon added the comment:

I'm assuming this means this must be called on every interactive python instance. If not just correct me.

While this might be an enhancement it would still be too inconvenient. Basically something that can be configured permanently for example with ~/.bashrc would be the preferred solution.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20886>
_______________________________________

From report at bugs.python.org  Sun May 15 12:23:25 2016
From: report at bugs.python.org (Eugene Toder)
Date: Sun, 15 May 2016 16:23:25 +0000
Subject: [issue20371] datetime.datetime.replace bypasses a subclass's __new__
In-Reply-To: <1390506444.15.0.286575412745.issue20371@psf.upfronthosting.co.za>
Message-ID: <1463329405.79.0.357374754183.issue20371@psf.upfronthosting.co.za>


Eugene Toder added the comment:

Yes, this is similar to my second approach. (You need to copy via __reduce__, because __copy__ my have been overriden to return self.)

The general problem with it, is that if a subclass is designed to be immutable (probably a common case here), it may not handle changing of its attributes well. Attributes will be readonly, so you can't support replace(derived_attr=newval). And while you can change base class' attributes under the covers, doing so may break subclass invariants. E.g. it may have cached hashcode or another property derived from other attributes.

There's also a smaller problem of figuring attribute names for positional arguments of replace() to support derived attributes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20371>
_______________________________________

From report at bugs.python.org  Sun May 15 12:27:55 2016
From: report at bugs.python.org (ProgVal)
Date: Sun, 15 May 2016 16:27:55 +0000
Subject: [issue27023] Documentation of tempfile.gettempdir() does not mention
 it only supports existing directories
In-Reply-To: <1463247583.74.0.311593159637.issue27023@psf.upfronthosting.co.za>
Message-ID: <1463329675.78.0.758918939415.issue27023@psf.upfronthosting.co.za>


ProgVal added the comment:

I know, that's why I did not ask to change the code. Only the doc to make that behavior more explicit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27023>
_______________________________________

From report at bugs.python.org  Sun May 15 12:43:22 2016
From: report at bugs.python.org (R. David Murray)
Date: Sun, 15 May 2016 16:43:22 +0000
Subject: [issue20371] datetime.datetime.replace bypasses a subclass's __new__
In-Reply-To: <1390506444.15.0.286575412745.issue20371@psf.upfronthosting.co.za>
Message-ID: <1463330602.65.0.823860282258.issue20371@psf.upfronthosting.co.za>


R. David Murray added the comment:

Hmm.  The contract is actually that replace returns a *new* instance with the specified values changed.  So I think it would be adequate in this case to simply call the subclass constructor with the values that replace manages, and not worry about anything else.  There is actually no (current) contract to preserve any other values of the existing instance.

A subclass that wants to add other values that can be replaced will have to override replace, which should not be unexpected.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20371>
_______________________________________

From report at bugs.python.org  Sun May 15 12:45:40 2016
From: report at bugs.python.org (R. David Murray)
Date: Sun, 15 May 2016 16:45:40 +0000
Subject: [issue27023] Documentation of tempfile.gettempdir() does not mention
 it only supports existing directories
In-Reply-To: <1463247583.74.0.311593159637.issue27023@psf.upfronthosting.co.za>
Message-ID: <1463330740.16.0.749850802767.issue27023@psf.upfronthosting.co.za>


R. David Murray added the comment:

As Steve pointed out, the documentation is explicit: "to *find* one the user can craete files in".  You can't find something that doesn't yet exist.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27023>
_______________________________________

From report at bugs.python.org  Sun May 15 13:02:56 2016
From: report at bugs.python.org (Eugene Toder)
Date: Sun, 15 May 2016 17:02:56 +0000
Subject: [issue20371] datetime.datetime.replace bypasses a subclass's __new__
In-Reply-To: <1390506444.15.0.286575412745.issue20371@psf.upfronthosting.co.za>
Message-ID: <1463331776.63.0.0336527338341.issue20371@psf.upfronthosting.co.za>


Eugene Toder added the comment:

This seems like it can lead to even more subtle bugs when replace() is not overriden. Currently, any extra state in the subclass is left uninitialized, which usually leads to obvious breakage and is relatively easy to trace back to replace(). (I've done it before.) If we call the constructor passing only base class values, the extra state may get initialized with default values. This is probably not what anyone wants, and is probably harder to debug, because there's no obvious breakage.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20371>
_______________________________________

From report at bugs.python.org  Sun May 15 13:25:58 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 May 2016 17:25:58 +0000
Subject: [issue20640] Idle: test configHelpSourceEdit
In-Reply-To: <1392563325.46.0.352105521636.issue20640@psf.upfronthosting.co.za>
Message-ID: <20160515172555.13290.89937.852A3AB4@psf.io>


Roundup Robot added the comment:

New changeset ada719145597 by Terry Jan Reedy in branch '3.5':
Issue #20640: Add https: to url prefixes so test passes on Darwin.
https://hg.python.org/cpython/rev/ada719145597

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20640>
_______________________________________

From report at bugs.python.org  Sun May 15 13:27:05 2016
From: report at bugs.python.org (Thomas Kluyver)
Date: Sun, 15 May 2016 17:27:05 +0000
Subject: [issue26039] More flexibility in zipfile write interface
In-Reply-To: <1452179451.89.0.468945044395.issue26039@psf.upfronthosting.co.za>
Message-ID: <1463333225.76.0.870122523128.issue26039@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

The backported package now exists on PyPI as zipfile36. It's passing the tests on 3.4 - I haven't tested further back. I'm trying out Gitlab for hosting it:
https://gitlab.com/takluyver/zipfile36

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26039>
_______________________________________

From report at bugs.python.org  Sun May 15 13:27:59 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 15 May 2016 17:27:59 +0000
Subject: [issue20640] Idle: test configHelpSourceEdit
In-Reply-To: <1392563325.46.0.352105521636.issue20640@psf.upfronthosting.co.za>
Message-ID: <1463333279.97.0.932127582618.issue20640@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Patch should fix test for this issue.  Please retest and close if it does.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20640>
_______________________________________

From report at bugs.python.org  Sun May 15 14:01:56 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 15 May 2016 18:01:56 +0000
Subject: [issue25747] test_idle failure in leaks searching mode
In-Reply-To: <1448647986.99.0.712792565134.issue25747@psf.upfronthosting.co.za>
Message-ID: <1463335316.79.0.623263071381.issue25747@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

>From Mantin Panter's msg265606:

======================================================================
FAIL: test_idlever (idlelib.idle_test.test_warning.ImportWarnTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.5.bolen-tiger/build/Lib/idlelib/idle_test/test_warning.py", line 76, in test_idlever
    self.assertEqual(len(w), 1)
AssertionError: 0 != 1

Serhiy got this by running leak tests, so that sys.modules caching prevented re-execution of warning code.  I am curious: are OSX builtbots doing something similar?  Or is the warning not being issued on the first import, making this a true failure?

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25747>
_______________________________________

From report at bugs.python.org  Sun May 15 14:16:12 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 15 May 2016 18:16:12 +0000
Subject: [issue25747] test_idle failure in leaks searching mode
In-Reply-To: <1448647986.99.0.712792565134.issue25747@psf.upfronthosting.co.za>
Message-ID: <1463336172.78.0.660263977304.issue25747@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

In msg255485 'copied replacements' should be 'copied with replacements'.  But 'import idlever' is not a reliable replacement for "# trigger a warning".

I wonder whether 'import_fresh_module' really executes the module twice, which seems foolish, or mere displays one warning twice.

It doesn't really matter here.  I have decided to remove the test.  We don't know if *anyone* imports idlever, and 3.6 will break nearly all external imports, not just that one, so this particular warning and test are not worth the time already spent on them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25747>
_______________________________________

From report at bugs.python.org  Sun May 15 14:20:31 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 15 May 2016 18:20:31 +0000
Subject: [issue25747] test_idle failure in leaks searching mode
In-Reply-To: <1448647986.99.0.712792565134.issue25747@psf.upfronthosting.co.za>
Message-ID: <20160515182029.23169.78616.916C87A8@psf.io>


Roundup Robot added the comment:

New changeset 5f561804bc8e by Terry Jan Reedy in branch '3.5':
Issue #25747: remove undependable and possibly useless test.
https://hg.python.org/cpython/rev/5f561804bc8e

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25747>
_______________________________________

From report at bugs.python.org  Sun May 15 14:21:47 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 15 May 2016 18:21:47 +0000
Subject: [issue25747] test_idle failure in leaks searching mode
In-Reply-To: <1448647986.99.0.712792565134.issue25747@psf.upfronthosting.co.za>
Message-ID: <1463336507.99.0.131002294967.issue25747@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
assignee:  -> terry.reedy
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25747>
_______________________________________

From report at bugs.python.org  Sun May 15 14:23:23 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 May 2016 18:23:23 +0000
Subject: [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: [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:50:08 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 15 May 2016 18:50:08 +0000
Subject: [issue20371] datetime.datetime.replace bypasses a subclass's __new__
In-Reply-To: <1390506444.15.0.286575412745.issue20371@psf.upfronthosting.co.za>
Message-ID: <1463338208.0.0.994160029726.issue20371@psf.upfronthosting.co.za>


Changes by Yury Selivanov <yselivanov at gmail.com>:


----------
nosy:  -yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20371>
_______________________________________

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: [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: [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:11:34 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 15 May 2016 19:11:34 +0000
Subject: [issue27024] IDLE shutdown glitch when started by import
In-Reply-To: <1463289946.09.0.360878393598.issue27024@psf.upfronthosting.co.za>
Message-ID: <1463339494.79.0.806118559363.issue27024@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

This is a partial fix.  Run python, import idlelib.idle, open idlelib.run, close editor, close shell, get clean >>> prompt in python. No 'bgerror ...'.  This is probably enough to justify patch.  (Directly opening and closing IDLE continues to work fine, as before.)

Close shell first, then editor, get >>> + similar 'invalid ... invalid ...' message as reported above.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27024>
_______________________________________

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: [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: [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  Sun May 15 15:34:31 2016
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sun, 15 May 2016 19:34:31 +0000
Subject: [issue27034] Remove derecated asynchat.fifo
In-Reply-To: <1463340774.13.0.31758132832.issue27034@psf.upfronthosting.co.za>
Message-ID: <1463340871.74.0.19534865554.issue27034@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

Looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27034>
_______________________________________

From report at bugs.python.org  Sun May 15 15:45:07 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 May 2016 19:45:07 +0000
Subject: [issue20371] datetime.datetime.replace bypasses a subclass's __new__
In-Reply-To: <1390506444.15.0.286575412745.issue20371@psf.upfronthosting.co.za>
Message-ID: <1463341507.53.0.805328470457.issue20371@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This looks as expected behavior to me. namedtuple._replace(), Parameter.replace(), Signature.replace() do it this way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20371>
_______________________________________

From report at bugs.python.org  Sun May 15 16:00:25 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 15 May 2016 20:00:25 +0000
Subject: [issue27025] More human readable generated widget names
In-Reply-To: <1463299445.94.0.887025569149.issue27025@psf.upfronthosting.co.za>
Message-ID: <1463342425.3.0.729728529163.issue27025@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

First thoughts on the proposal.  I overall like it.  The 'virtue' of the digit strings names is that they match tk behavior (I presume) and are consistently opaque ;-)  *Someone* will object to change.

Is your proposal to have (_)tkinter add a name= option when not provided by the user?  The main problem I see is breaking code that assumes digits if no name= options are given.  Is this currently guaranteed?

1. Canvas item ids are, in Python, ints (though I presume int strings in tcl) starting with 1.  They number consecutively within canvas, regardless of 'type'.  I wonder if tk uses them a indexes into an array of items for a particular canvas.  I think I prefer sequential within class.

Something else, I believe, generates alphanumeric names similar to what you propose.


2. Follow.

3. '#' seems a bit heavy, as it tends to overwhelm '.' as the separator.  I think leave it out or use '-'.  ".frame1.button2" or ".frame-1.button-2".  I prefer without.  These could be names I would give if I were to add name= options all over the place, except that it is too easy to reuse a number.  

Conflicts: tk does not prevent duplicate names by users.
...
>>> entry2
<tkinter.Entry object .e1>
>>> entry
<tkinter.Entry object .e1>
I am not sure of the consequence of this.

The doc could say, "If you want widget names of the form <class-name(lowercased)><sequence number> either consistently supply them yourself with name= options, or let tkinter supply them for you."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27025>
_______________________________________

From report at bugs.python.org  Sun May 15 16:32:53 2016
From: report at bugs.python.org (R. David Murray)
Date: Sun, 15 May 2016 20:32:53 +0000
Subject: [issue27033] Change the decode_data default in smtpd to False
In-Reply-To: <1463340039.51.0.670985844702.issue27033@psf.upfronthosting.co.za>
Message-ID: <1463344373.3.0.225440406101.issue27033@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27033>
_______________________________________

From report at bugs.python.org  Sun May 15 16:37:00 2016
From: report at bugs.python.org (Eugene Toder)
Date: Sun, 15 May 2016 20:37:00 +0000
Subject: [issue20371] datetime.datetime.replace bypasses a subclass's __new__
In-Reply-To: <1390506444.15.0.286575412745.issue20371@psf.upfronthosting.co.za>
Message-ID: <1463344620.06.0.763727534629.issue20371@psf.upfronthosting.co.za>


Eugene Toder added the comment:

namedtuple._replace() actually doesn't call subclass' __new__. It calls tuple.__new__ directly, so it has the same problem as datetime classes.

Parameter and Signature are new in 3.3. I'm not sure if they're expected to be used as base classes.

@r.david.murray: is that contract specified anywhere? The doc says "Return a datetime with the same attributes, except for those attributes given new values by whichever keyword arguments are specified." This doesn't explicitly mention subclasses, but also doesn't mention the possibility of discarding any attribute values.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20371>
_______________________________________

From report at bugs.python.org  Sun May 15 17:02:10 2016
From: report at bugs.python.org (R. David Murray)
Date: Sun, 15 May 2016 21:02:10 +0000
Subject: [issue20371] datetime.datetime.replace bypasses a subclass's __new__
In-Reply-To: <1390506444.15.0.286575412745.issue20371@psf.upfronthosting.co.za>
Message-ID: <1463346130.81.0.832213152549.issue20371@psf.upfronthosting.co.za>


R. David Murray added the comment:

Ah, interesting.  The python version (which is based on the original python code that served as the specification for the C version) has docstrings that explicitly say "new XXX".  The C docstrings and rest docs do not reflect that subtlety.

The docstrings of the two modules and the rest docs should be harmonized.  A single word can make a difference :)

Perhaps this should be brought up on python-dev again, as the issue here clearly applies to more than just datetime.  This in many ways highlights the heart of the subclassing issue.

In the email package I called the method "clone", and all properties that can be changed are accessible as keyword arguments...and in fact that set of properties is explicitly the set of all class non-method attributes.  Policy instance attributes are otherwise read-only.  So I solved the problem by specifying the behavior of the clone method in the face of subclassing, making it an explicit API.  That's more like your first option: specifying the API you need to follow in a subclass in order to support replace.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20371>
_______________________________________

From report at bugs.python.org  Sun May 15 17:02:25 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 15 May 2016 21:02:25 +0000
Subject: [issue27025] More human readable generated widget names
In-Reply-To: <1463299445.94.0.887025569149.issue27025@psf.upfronthosting.co.za>
Message-ID: <1463346145.01.0.881251156156.issue27025@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> The 'virtue' of the digit strings names is that they match tk behavior (I presume) and are consistently opaque ;-)

No, in Tk you have to give names for all widgets.

frame .main
button .main.ok

This is similar to how classes or functions are declared in Python. The name becomes an attribute of an object and a reference to an object. You shouldn't repeat it twice.

Here is a patch that implements nicer generated widget names.

The problem with ".frame1.button2" or ".frame-1.button-2" is that they look too human readable. If you use explicit names for the part of widgets and allow generating names for other part, there is large chance that generated "button2" or "button-2" will conflict with explicit names. I think we should use something that makes generated names uglier. Maybe prefix them with "_"? "._frame1._button2".

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file42867/tkinter_names.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27025>
_______________________________________

From report at bugs.python.org  Sun May 15 17:20:11 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 15 May 2016 21:20:11 +0000
Subject: [issue27034] Remove derecated asynchat.fifo
In-Reply-To: <1463340774.13.0.31758132832.issue27034@psf.upfronthosting.co.za>
Message-ID: <1463347211.0.0.834845125842.issue27034@psf.upfronthosting.co.za>


STINNER Victor added the comment:

LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27034>
_______________________________________

From report at bugs.python.org  Sun May 15 17:20:24 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 15 May 2016 21:20:24 +0000
Subject: [issue27034] Remove deprecated asynchat.fifo
In-Reply-To: <1463340774.13.0.31758132832.issue27034@psf.upfronthosting.co.za>
Message-ID: <1463347224.48.0.155257918756.issue27034@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
title: Remove derecated asynchat.fifo -> Remove deprecated asynchat.fifo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27034>
_______________________________________

From report at bugs.python.org  Sun May 15 17:21:01 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 15 May 2016 21:21:01 +0000
Subject: [issue27034] Remove deprecated asynchat.fifo
In-Reply-To: <1463340774.13.0.31758132832.issue27034@psf.upfronthosting.co.za>
Message-ID: <1463347261.95.0.6874462256.issue27034@psf.upfronthosting.co.za>


STINNER Victor added the comment:

The asynchat.fifo was deprecated in Python 3.5.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27034>
_______________________________________

From report at bugs.python.org  Sun May 15 17:21:40 2016
From: report at bugs.python.org (R. David Murray)
Date: Sun, 15 May 2016 21:21:40 +0000
Subject: [issue20371] datetime.datetime.replace bypasses a subclass's __new__
In-Reply-To: <1390506444.15.0.286575412745.issue20371@psf.upfronthosting.co.za>
Message-ID: <1463347300.82.0.985031520925.issue20371@psf.upfronthosting.co.za>


R. David Murray added the comment:

By the way, when I say "again", I'm referring to the "return type of alternative constructors" thread:

  http://www.mail-archive.com/python-dev at python.org/msg92163.html

This is effectively an extension of that discussion, because replace is an alternative constructor, with the additional complication of taking an existing instance as input.

Rereading that thread, I think Guido's answer is that the subclass API needs to be clearly documented:

   http://www.mail-archive.com/python-dev at python.org/msg92191.html

Which I guess means we get to decide what it is, and then figure out how to implement it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20371>
_______________________________________

From report at bugs.python.org  Sun May 15 19:34:59 2016
From: report at bugs.python.org (R. David Murray)
Date: Sun, 15 May 2016 23:34:59 +0000
Subject: [issue27033] Change the decode_data default in smtpd to False
In-Reply-To: <1463340039.51.0.670985844702.issue27033@psf.upfronthosting.co.za>
Message-ID: <1463355299.68.0.0275194953952.issue27033@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
components: +email

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27033>
_______________________________________

From report at bugs.python.org  Sun May 15 19:45:11 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 15 May 2016 23:45:11 +0000
Subject: [issue27025] More human readable generated widget names
In-Reply-To: <1463299445.94.0.887025569149.issue27025@psf.upfronthosting.co.za>
Message-ID: <1463355911.29.0.667595027839.issue27025@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Ah, the patch makes it clear.  Tkinter is already generating a name to submit to tk, and you are proposing to replace using the Python id for that purpose.  +1.

I also notice that duplicate names cause the old tk widget to be destroyed even if the Python instance is not.  Knowing that, I agree with the leading underscore to minimize interference. The consequence of collision and the new default should both be documented somehow.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27025>
_______________________________________

From report at bugs.python.org  Sun May 15 20:18:05 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 16 May 2016 00:18:05 +0000
Subject: [issue20640] Idle: test configHelpSourceEdit
In-Reply-To: <1392563325.46.0.352105521636.issue20640@psf.upfronthosting.co.za>
Message-ID: <1463357885.15.0.168725662298.issue20640@psf.upfronthosting.co.za>


Martin Panter added the comment:

Yep all four buildbots, x86 Tiger and AMD64 Snow Leop, 3.5 and 3.x, are now green.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20640>
_______________________________________

From report at bugs.python.org  Sun May 15 22:06:24 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 16 May 2016 02:06:24 +0000
Subject: [issue26168] Py_BuildValue may leak 'N' arguments on PyTuple_New
 failure
In-Reply-To: <1453314385.46.0.703497250236.issue26168@psf.upfronthosting.co.za>
Message-ID: <1463364384.09.0.833259940298.issue26168@psf.upfronthosting.co.za>


Martin Panter added the comment:

Is it really a problem if the old value is deallocated? It sounds like a similar case to <https://bugs.python.org/issue26168#msg259242>, and would only be a problem if you passed a borrowed reference, and relied on the reference staying alive for another argument.

I do like the separate do_ignore() function in patch 4, but I don?t think it is worthwhile allocating a temporary tuple to save values in. The allocation can fail. Also, I understand do_mktuple() etc are recursive, so nested borrowed references would still be released before the outer do_ignore() function releases the outer tuple.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26168>
_______________________________________

From report at bugs.python.org  Sun May 15 22:07:42 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 May 2016 02:07:42 +0000
Subject: [issue23977] Enhancing IDLE's test_delegator.py unit test
In-Reply-To: <1429222717.34.0.436460627497.issue23977@psf.upfronthosting.co.za>
Message-ID: <20160516020726.102598.47095.32418389@psf.io>


Roundup Robot added the comment:

New changeset 6bc08af57813 by Terry Jan Reedy in branch '3.5':
Issue #23977: Tweak IDLE Delegator and its test.
https://hg.python.org/cpython/rev/6bc08af57813

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23977>
_______________________________________

From report at bugs.python.org  Sun May 15 22:08:11 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 16 May 2016 02:08:11 +0000
Subject: [issue23977] Enhancing IDLE's test_delegator.py unit test
In-Reply-To: <1429222717.34.0.436460627497.issue23977@psf.upfronthosting.co.za>
Message-ID: <1463364491.16.0.993336767553.issue23977@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23977>
_______________________________________

From report at bugs.python.org  Sun May 15 22:40:38 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 16 May 2016 02:40:38 +0000
Subject: [issue20792] Idle: test PathBrowser more
In-Reply-To: <1393493383.85.0.956500002219.issue20792@psf.upfronthosting.co.za>
Message-ID: <1463366438.78.0.834115180283.issue20792@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The Feb 2014 patches contained changes to Pathbrowser.main.  In June/July 2014, module 'main' tests were converted to htests.  I have determined that the htest supercedes the main changes and that this issue can be closed.

----------
assignee:  -> terry.reedy
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20792>
_______________________________________

From report at bugs.python.org  Sun May 15 23:23:07 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 May 2016 03:23:07 +0000
Subject: [issue26807] mock_open()().readline() fails at EOF
In-Reply-To: <1461140283.7.0.219960203136.issue26807@psf.upfronthosting.co.za>
Message-ID: <20160516032304.22591.47483.91F04715@psf.io>


Roundup Robot added the comment:

New changeset cbb31b2a3dba by Robert Collins in branch '3.5':
Issue #26807: mock_open 'files' no longer error on readline at end of file.
https://hg.python.org/cpython/rev/cbb31b2a3dba

New changeset 72a798e27117 by Robert Collins in branch 'default':
Issue #26807: mock_open 'files' no longer error on readline at end of file.
https://hg.python.org/cpython/rev/72a798e27117

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26807>
_______________________________________

From report at bugs.python.org  Sun May 15 23:30:31 2016
From: report at bugs.python.org (Robert Collins)
Date: Mon, 16 May 2016 03:30:31 +0000
Subject: [issue26807] mock_open()().readline() fails at EOF
In-Reply-To: <1461140283.7.0.219960203136.issue26807@psf.upfronthosting.co.za>
Message-ID: <1463369431.98.0.875496933971.issue26807@psf.upfronthosting.co.za>


Robert Collins added the comment:

I've committed a minimal variation - thanks for the patches.

----------
resolution:  -> fixed
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26807>
_______________________________________

From report at bugs.python.org  Sun May 15 23:32:56 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 16 May 2016 03:32:56 +0000
Subject: [issue12669] test_curses skipped on buildbots
In-Reply-To: <1312149135.76.0.0319517534091.issue12669@psf.upfronthosting.co.za>
Message-ID: <1463369576.93.0.928992413713.issue12669@psf.upfronthosting.co.za>


Martin Panter added the comment:

FYI I just added a reasonably generic function pty_run(script, input) -> output to Lib/test/test_readline.py:120 for Issue 26870. It runs a Python script string in a child process under a pseudo-terminal. If you need to drive the curses tests with a pseudo-terminal, my code may be useful. There were about six different bugs and platform-specific quirks to work around (affecting Open BSD, Linux and various OS X versions), so I recommend learning from my experience rather than doing it all from scratch :)

Also, test_curses on Python 2 fails for me, but that is probably a separate bug.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12669>
_______________________________________

From report at bugs.python.org  Sun May 15 23:53:33 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 May 2016 03:53:33 +0000
Subject: [issue18910] IDle: test textView.py
In-Reply-To: <1378173406.38.0.908315708817.issue18910@psf.upfronthosting.co.za>
Message-ID: <20160516035328.89107.50146.0518A5A9@psf.io>


Roundup Robot added the comment:

New changeset f5e20abea871 by Terry Jan Reedy in branch '2.7':
Issue 18910: Edit idle_test/README.txt to add 'requires' warning.
https://hg.python.org/cpython/rev/f5e20abea871

New changeset 735eebce6765 by Terry Jan Reedy in branch '3.5':
Issue 18910: Edit idle_test/README.txt to add 'requires' usage at module scope.
https://hg.python.org/cpython/rev/735eebce6765

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18910>
_______________________________________

From report at bugs.python.org  Mon May 16 00:08:06 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 16 May 2016 04:08:06 +0000
Subject: [issue18910] IDle: test textView.py
In-Reply-To: <1378173406.38.0.908315708817.issue18910@psf.upfronthosting.co.za>
Message-ID: <1463371686.18.0.330425382641.issue18910@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I have stopped patching IDLE for 2.7 and will not add more tests.  So there is no reason to constrain tests for 3.5, and soon 3.6, to 2.7 limitations.

----------
assignee:  -> terry.reedy
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18910>
_______________________________________

From report at bugs.python.org  Mon May 16 00:13:21 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 16 May 2016 04:13:21 +0000
Subject: [issue1674555] sys.path in tests contains system directories
Message-ID: <1463372001.2.0.624362066096.issue1674555@psf.upfronthosting.co.za>


Martin Panter added the comment:

I did a quick merge of Arfrever?s 2.7 patch with current code (mainly pgo flags). Unfortunately it didn?t fix my problem with unhandled ImportWarning, but here it is in case it is useful.

----------
Added file: http://bugs.python.org/file42868/python-2.7-issue1674555.v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1674555>
_______________________________________

From report at bugs.python.org  Mon May 16 01:56:30 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Mon, 16 May 2016 05:56:30 +0000
Subject: [issue27020] os.writev() does not accept generators (as buffers
 argument)
In-Reply-To: <1463247043.26.0.60216509871.issue27020@psf.upfronthosting.co.za>
Message-ID: <1463378190.23.0.354490247433.issue27020@psf.upfronthosting.co.za>


???? ????????? added the comment:

How sequence is iterated in writev():

https://github.com/python/cpython/blob/e4945dbd854befd04fe2d5ad99ab52c8d13dc162/Modules/posixmodule.c#L8086

How IOV is filled in semdmsg():
https://github.com/python/cpython/blob/fa5d369fc83f695d19eb57048efa7ec07ca3c1d7/Modules/socketmodule.c#L3817


Also, IMHO these parts of code shoud be merged.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27020>
_______________________________________

From report at bugs.python.org  Mon May 16 02:00:51 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Mon, 16 May 2016 06:00:51 +0000
Subject: [issue27020] os.writev() does not accept generators (as buffers
 argument)
In-Reply-To: <1463247043.26.0.60216509871.issue27020@psf.upfronthosting.co.za>
Message-ID: <1463378451.87.0.459378882596.issue27020@psf.upfronthosting.co.za>


???? ????????? added the comment:

Proof for sendmsg:

In [1]: import socket
In [2]: (r, w) = socket.socketpair()
In [3]: w.sendmsg((i for i in [b'1', b'2']))
Out[3]: 2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27020>
_______________________________________

From report at bugs.python.org  Mon May 16 02:10:27 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Mon, 16 May 2016 06:10:27 +0000
Subject: [issue27020] os.writev() does not accept generators (as buffers
 argument)
In-Reply-To: <1463247043.26.0.60216509871.issue27020@psf.upfronthosting.co.za>
Message-ID: <1463379027.91.0.971643006913.issue27020@psf.upfronthosting.co.za>


???? ????????? added the comment:

Moreover, sendmsg() flattens iterable to a list -- this is not very good for performance and memory.

Why not to fill IOV one-by-one, doubling it's size (via realloc) when need ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27020>
_______________________________________

From report at bugs.python.org  Mon May 16 02:32:32 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 May 2016 06:32:32 +0000
Subject: [issue27034] Remove deprecated asynchat.fifo
In-Reply-To: <1463340774.13.0.31758132832.issue27034@psf.upfronthosting.co.za>
Message-ID: <20160516063224.71094.70555.3F34B107@psf.io>


Roundup Robot added the comment:

New changeset 2af26a93f87f by Serhiy Storchaka in branch 'default':
Issue #27034: Removed deprecated class asynchat.fifo.
https://hg.python.org/cpython/rev/2af26a93f87f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27034>
_______________________________________

From report at bugs.python.org  Mon May 16 02:36:52 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 May 2016 06:36:52 +0000
Subject: [issue27033] Change the decode_data default in smtpd to False
In-Reply-To: <1463340039.51.0.670985844702.issue27033@psf.upfronthosting.co.za>
Message-ID: <20160516063649.22591.51227.9D6A6C5B@psf.io>


Roundup Robot added the comment:

New changeset a31b9f353346 by Serhiy Storchaka in branch 'default':
Issue #27033: The default value of the decode_data parameter for
https://hg.python.org/cpython/rev/a31b9f353346

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27033>
_______________________________________

From report at bugs.python.org  Mon May 16 02:37:28 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 May 2016 06:37:28 +0000
Subject: [issue27034] Remove deprecated asynchat.fifo
In-Reply-To: <1463340774.13.0.31758132832.issue27034@psf.upfronthosting.co.za>
Message-ID: <1463380648.12.0.902293093754.issue27034@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27034>
_______________________________________

From report at bugs.python.org  Mon May 16 02:38:11 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 May 2016 06:38:11 +0000
Subject: [issue27033] Change the decode_data default in smtpd to False
In-Reply-To: <1463340039.51.0.670985844702.issue27033@psf.upfronthosting.co.za>
Message-ID: <1463380691.57.0.217614672971.issue27033@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27033>
_______________________________________

From report at bugs.python.org  Mon May 16 02:42:59 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 May 2016 06:42:59 +0000
Subject: [issue26765] Factor out common bytes and bytearray implementation
In-Reply-To: <1460707559.13.0.709090380773.issue26765@psf.upfronthosting.co.za>
Message-ID: <20160516064253.67143.72532.84873A44@psf.io>


Roundup Robot added the comment:

New changeset c6c1882ecc77 by Serhiy Storchaka in branch 'default':
Issue #26765: Ensure that bytes- and unicode-specific stringlib files are used
https://hg.python.org/cpython/rev/c6c1882ecc77

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26765>
_______________________________________

From report at bugs.python.org  Mon May 16 02:43:01 2016
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 16 May 2016 06:43:01 +0000
Subject: [issue21199] Python on 64-bit Windows uses signed 32-bit type for
 read length
In-Reply-To: <1397149133.44.0.946556558932.issue21199@psf.upfronthosting.co.za>
Message-ID: <1463380981.44.0.346189261692.issue21199@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Fixing seems fine with me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21199>
_______________________________________

From report at bugs.python.org  Mon May 16 03:12:59 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 May 2016 07:12:59 +0000
Subject: [issue18531] Undocumented different between METH_KEYWORDS and **kws
In-Reply-To: <1374519103.74.0.277776306074.issue18531@psf.upfronthosting.co.za>
Message-ID: <20160516071243.42363.1238.DA9399B3@psf.io>


Roundup Robot added the comment:

New changeset e3283b4ae61d by Serhiy Storchaka in branch '3.5':
Backported tests for issue #18531.
https://hg.python.org/cpython/rev/e3283b4ae61d

New changeset 621e0a3249c2 by Serhiy Storchaka in branch '2.7':
Backported tests for issue #18531.
https://hg.python.org/cpython/rev/621e0a3249c2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18531>
_______________________________________

From report at bugs.python.org  Mon May 16 03:12:59 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 May 2016 07:12:59 +0000
Subject: [issue26995] Add tests for parsing float and object arguments
In-Reply-To: <1462906715.34.0.789444535015.issue26995@psf.upfronthosting.co.za>
Message-ID: <20160516071243.42363.73974.5F9FF2E9@psf.io>


Roundup Robot added the comment:

New changeset 37d03507e9e9 by Serhiy Storchaka in branch '3.5':
Issue #26995: Added tests for "f", "d", "D", "S", "Y", and "U" format codes
https://hg.python.org/cpython/rev/37d03507e9e9

New changeset c3346c89f6d4 by Serhiy Storchaka in branch '2.7':
Issue #26995: Added tests for "f", "d", "D", "S", "Y", and "U" format codes
https://hg.python.org/cpython/rev/c3346c89f6d4

New changeset 8c973a2f4f50 by Serhiy Storchaka in branch 'default':
Issue #26995: Added tests for "f", "d", "D", "S", "Y", and "U" format codes
https://hg.python.org/cpython/rev/8c973a2f4f50

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26995>
_______________________________________

From report at bugs.python.org  Mon May 16 03:24:18 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 May 2016 07:24:18 +0000
Subject: [issue26995] Add tests for parsing float and object arguments
In-Reply-To: <1462906715.34.0.789444535015.issue26995@psf.upfronthosting.co.za>
Message-ID: <1463383458.49.0.0825265390568.issue26995@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26995>
_______________________________________

From report at bugs.python.org  Mon May 16 03:27:47 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 16 May 2016 07:27:47 +0000
Subject: [issue3213] "pydoc -p" should listen to [::] if IPv6 is supported
In-Reply-To: <1214525489.78.0.574038651579.issue3213@psf.upfronthosting.co.za>
Message-ID: <1463383667.46.0.277908539032.issue3213@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Agreed with Martin.

----------
nosy: +berker.peksag -Daniel Griffin
priority: normal -> low
resolution:  -> rejected
stage: needs patch -> resolved
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3213>
_______________________________________

From report at bugs.python.org  Mon May 16 03:37:55 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 May 2016 07:37:55 +0000
Subject: [issue25910] Fixing links in documentation
In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za>
Message-ID: <1463384275.88.0.971368171639.issue25910@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

XML-RPC link was fixed in issue26889 (using the a web archive).

Left links are http://www.zope.com/, http://www.pythonlabs.com/logos.html, and links to dead projects. What can we do with Zope and PythonLabs links?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25910>
_______________________________________

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: [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 03:58:03 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 May 2016 07:58:03 +0000
Subject: [issue26168] Py_BuildValue may leak 'N' arguments on PyTuple_New
 failure
In-Reply-To: <1453314385.46.0.703497250236.issue26168@psf.upfronthosting.co.za>
Message-ID: <1463385483.03.0.884960166366.issue26168@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Currently do_mktuple(), do_mklist() and do_mkdict() save references in a collection. I think that there are reasons to do this, and third-party code can be broken if just deallocate references. pybuildvalue_leak4.patch just implements this strategy more reliably. It guaranties (unless tuple allocation fails) that borrowed references in the same container or upper levels are kept until all content of the container is proceeded.

The more perfect solution is to allocate one list on error, save all references to it and deallocate it at the end of PyBuildValue(). But this leads to more complicated code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26168>
_______________________________________

From report at bugs.python.org  Mon May 16 04:08:14 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 May 2016 08:08:14 +0000
Subject: [issue26991] Possible reference leak in MAKE_FUNCTION
In-Reply-To: <1462878017.45.0.401291205212.issue26991@psf.upfronthosting.co.za>
Message-ID: <1463386094.76.0.96282335428.issue26991@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I don't know what is the best place for this function. You can just break compiling functions with annotations, run tests, found tests that use functions with annotations, and add new test near one of them.

You can test your test by removing the fix and running the test with the "-R :" option.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26991>
_______________________________________

From report at bugs.python.org  Mon May 16 04:09:39 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 May 2016 08:09:39 +0000
Subject: [issue19253] PyArg_ParseTuple: wrong use of seterror() clips helpful
 type error annotation
In-Reply-To: <1381698493.04.0.861687446453.issue19253@psf.upfronthosting.co.za>
Message-ID: <1463386179.8.0.785719085221.issue19253@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19253>
_______________________________________

From report at bugs.python.org  Mon May 16 04:15:08 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 May 2016 08:15:08 +0000
Subject: [issue19524] ResourceWarning when urlopen() forgets the
 HTTPConnection object
In-Reply-To: <1383882317.08.0.635493267684.issue19524@psf.upfronthosting.co.za>
Message-ID: <20160516081455.74108.90739.DAD58B03@psf.io>


Roundup Robot added the comment:

New changeset 19e4e0b7f1bd by Serhiy Storchaka in branch '2.7':
Issue #19524: Port fakehttp() from Py3 c1fb19907cc4 for use in test_urllib2
https://hg.python.org/cpython/rev/19e4e0b7f1bd

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19524>
_______________________________________

From report at bugs.python.org  Mon May 16 04:15:09 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 May 2016 08:15:09 +0000
Subject: [issue17214] http.client.HTTPConnection.putrequest encode  error
In-Reply-To: <1361011959.8.0.221376430084.issue17214@psf.upfronthosting.co.za>
Message-ID: <20160516081455.74108.33763.5FE16F45@psf.io>


Roundup Robot added the comment:

New changeset cb09fdef19f5 by Martin Panter in branch '3.5':
Issue #17214: Percent-encode non-ASCII bytes in redirect targets
https://hg.python.org/cpython/rev/cb09fdef19f5

New changeset 841a9a3f3cf6 by Martin Panter in branch 'default':
Issue #14132, Issue #17214: Merge two redirect handling fixes from 3.5
https://hg.python.org/cpython/rev/841a9a3f3cf6

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17214>
_______________________________________

From report at bugs.python.org  Mon May 16 04:15:10 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 May 2016 08:15:10 +0000
Subject: [issue14132] Redirect is not working correctly in urllib2
In-Reply-To: <1330269331.97.0.613564747875.issue14132@psf.upfronthosting.co.za>
Message-ID: <20160516081455.74108.27623.06A23A83@psf.io>


Roundup Robot added the comment:

New changeset 52a7f580580c by Martin Panter in branch '3.5':
Issue #14132: Fix redirect handling when target is just a query string
https://hg.python.org/cpython/rev/52a7f580580c

New changeset 789a3f87bde1 by Martin Panter in branch '2.7':
Issue #14132: Fix redirect handling when target is just a query string
https://hg.python.org/cpython/rev/789a3f87bde1

New changeset 841a9a3f3cf6 by Martin Panter in branch 'default':
Issue #14132, Issue #17214: Merge two redirect handling fixes from 3.5
https://hg.python.org/cpython/rev/841a9a3f3cf6

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14132>
_______________________________________

From report at bugs.python.org  Mon May 16 04:19:20 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 16 May 2016 08:19:20 +0000
Subject: [issue26168] Py_BuildValue may leak 'N' arguments on PyTuple_New
 failure
In-Reply-To: <1453314385.46.0.703497250236.issue26168@psf.upfronthosting.co.za>
Message-ID: <1463386760.33.0.0136765647846.issue26168@psf.upfronthosting.co.za>


Martin Panter added the comment:

Yeah okay, I agree that the code was already saving the references in a container, so it makes sense to keep doing that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26168>
_______________________________________

From report at bugs.python.org  Mon May 16 04:30:07 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 16 May 2016 08:30:07 +0000
Subject: [issue25910] Fixing links in documentation
In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za>
Message-ID: <1463387407.85.0.924434849052.issue25910@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

zope should be http://www.zope.org/
The pythonlabs link could be removed.
The logos at pythonlabs link does not exist. Reference for pythonlab exists in a humorous form  here: http://www.pythonlabs.com/

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25910>
_______________________________________

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: [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 04:51:40 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 May 2016 08:51:40 +0000
Subject: [issue19524] ResourceWarning when urlopen() forgets the
 HTTPConnection object
In-Reply-To: <1383882317.08.0.635493267684.issue19524@psf.upfronthosting.co.za>
Message-ID: <1463388700.95.0.668143156568.issue19524@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Oh, Roundup Robot reports about a commit made almost 2 years ago!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19524>
_______________________________________

From report at bugs.python.org  Mon May 16 05:32:20 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 16 May 2016 09:32:20 +0000
Subject: [issue27036] Mark up of references in different form
In-Reply-To: <1463387629.05.0.783453150634.issue27036@psf.upfronthosting.co.za>
Message-ID: <1463391140.79.0.938192927262.issue27036@psf.upfronthosting.co.za>


Martin Panter added the comment:

These bug me too. For the changes like the bytes-like objects example, you have my full support.

But for the changes that modify identifier names, I think the both the old and the new versions are pretty bad. Example:

- . . . for some :exc:`SyntaxError`\ s.
+ . . . for some :exc:`SyntaxErrors <SyntaxError>`.

In Firefox, the new version renders as if it is talking about something literally called SyntaxErrors. It is only obvious that the exception is called SyntaxError when you hover the mouse, follow the link, etc.

I wonder if it would be better to find another way to write these kind of cases. E.g.:

* . . . for some syntax errors. [Just drop the link and markup.]
* . . . for some :exc:`SyntaxError` exceptions.

For cases like ?eval()uated?, would it be acceptable changing to ?evaluated with :func:`eval` ??

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27036>
_______________________________________

From report at bugs.python.org  Mon May 16 05:40:20 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 16 May 2016 09:40:20 +0000
Subject: [issue19524] ResourceWarning when urlopen() forgets the
 HTTPConnection object
In-Reply-To: <1383882317.08.0.635493267684.issue19524@psf.upfronthosting.co.za>
Message-ID: <1463391620.76.0.413240546923.issue19524@psf.upfronthosting.co.za>


Martin Panter added the comment:

Sorry that was actually made by me earlier today. I grafted it from your commit, but I always forget to reset the author and date.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19524>
_______________________________________

From report at bugs.python.org  Mon May 16 05:44:51 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 16 May 2016 09:44:51 +0000
Subject: [issue17214] http.client.HTTPConnection.putrequest encode  error
In-Reply-To: <1361011959.8.0.221376430084.issue17214@psf.upfronthosting.co.za>
Message-ID: <1463391891.66.0.470997682728.issue17214@psf.upfronthosting.co.za>


Martin Panter added the comment:

I restored the ?redundant? encoding of space, in case someone?s code was relying on this behaviour, and because redirect_request() is a publicly documented method.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17214>
_______________________________________

From report at bugs.python.org  Mon May 16 05:45:40 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 16 May 2016 09:45:40 +0000
Subject: [issue14132] Redirect is not working correctly in urllib2
In-Reply-To: <1330269331.97.0.613564747875.issue14132@psf.upfronthosting.co.za>
Message-ID: <1463391940.64.0.514228726965.issue14132@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14132>
_______________________________________

From report at bugs.python.org  Mon May 16 07:29:58 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 16 May 2016 11:29:58 +0000
Subject: [issue24291] Many servers (wsgiref, http.server,
 etc) can truncate large output blobs
In-Reply-To: <1432671481.51.0.762064908488.issue24291@psf.upfronthosting.co.za>
Message-ID: <1463398198.98.0.61720720099.issue24291@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for your comments Serhiy. The main change in v3 is that I added a socketserver._write_exactly() function instead of the _BaseHTTPRequestHandler__write_exactly() method.

----------
Added file: http://bugs.python.org/file42870/wfile-partial.v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24291>
_______________________________________

From report at bugs.python.org  Mon May 16 08:37:43 2016
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Mon, 16 May 2016 12:37:43 +0000
Subject: [issue26359] CPython build options for out-of-the box performance
In-Reply-To: <1455445693.01.0.984013993837.issue26359@psf.upfronthosting.co.za>
Message-ID: <1463402263.46.0.259225380605.issue26359@psf.upfronthosting.co.za>


Changes by Alecsandru Patrascu <alecsandru.patrascu at intel.com>:


Added file: http://bugs.python.org/file42871/cpython2_with_optimizations_v01.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26359>
_______________________________________

From report at bugs.python.org  Mon May 16 08:37:56 2016
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Mon, 16 May 2016 12:37:56 +0000
Subject: [issue26359] CPython build options for out-of-the box performance
In-Reply-To: <1455445693.01.0.984013993837.issue26359@psf.upfronthosting.co.za>
Message-ID: <1463402276.73.0.470725329628.issue26359@psf.upfronthosting.co.za>


Changes by Alecsandru Patrascu <alecsandru.patrascu at intel.com>:


Added file: http://bugs.python.org/file42872/cpython3_with_optimizations_v02.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26359>
_______________________________________

From report at bugs.python.org  Mon May 16 08:40:34 2016
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Mon, 16 May 2016 12:40:34 +0000
Subject: [issue26359] CPython build options for out-of-the box performance
In-Reply-To: <1455445693.01.0.984013993837.issue26359@psf.upfronthosting.co.za>
Message-ID: <1463402434.31.0.0799988269679.issue26359@psf.upfronthosting.co.za>


Alecsandru Patrascu added the comment:

I've attached a cleaner version for CPython 3 and one for CPython 2. The problem with CPython 2 is that Gregory did not yet merged the LTO on this branch (#25702), but as soon as he does it, I'll post updated patches.

Regards,
Alecsandru

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26359>
_______________________________________

From report at bugs.python.org  Mon May 16 08:43:14 2016
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Mon, 16 May 2016 12:43:14 +0000
Subject: [issue26359] CPython build options for out-of-the box performance
In-Reply-To: <1455445693.01.0.984013993837.issue26359@psf.upfronthosting.co.za>
Message-ID: <1463402594.85.0.554886266414.issue26359@psf.upfronthosting.co.za>


Alecsandru Patrascu added the comment:

Brett, I tried to add you in the "assigned to", but I do not have any rights to update those :(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26359>
_______________________________________

From report at bugs.python.org  Mon May 16 10:17:44 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 May 2016 14:17:44 +0000
Subject: [issue27033] Change the decode_data default in smtpd to False
In-Reply-To: <1463340039.51.0.670985844702.issue27033@psf.upfronthosting.co.za>
Message-ID: <1463408264.23.0.0969090215287.issue27033@psf.upfronthosting.co.za>


R. David Murray added the comment:

Um, I changed to to commit review because I was planning to review it.  I don't expect to find any problems, but I'm surprised you committed it.

There does need to be a whatsnew entry, and specifically something in the porting section, since this is a behavior change.

----------
resolution: fixed -> 
stage: resolved -> commit review
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27033>
_______________________________________

From report at bugs.python.org  Mon May 16 10:26:51 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 16 May 2016 14:26:51 +0000
Subject: [issue27033] Change the decode_data default in smtpd to False
In-Reply-To: <1463340039.51.0.670985844702.issue27033@psf.upfronthosting.co.za>
Message-ID: <1463408811.21.0.299240636717.issue27033@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

aiosmtpd already defaults decode_data to False.  We should consider pulling this into 3.6 (not just for this reason of course).

http://aiosmtpd.readthedocs.io/en/latest/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27033>
_______________________________________

From report at bugs.python.org  Mon May 16 10:28:23 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 May 2016 14:28:23 +0000
Subject: [issue27035] Cannot set exit code in atexit callback
In-Reply-To: <1463385428.15.0.762354704325.issue27035@psf.upfronthosting.co.za>
Message-ID: <1463408903.86.0.147793519949.issue27035@psf.upfronthosting.co.za>


R. David Murray added the comment:

Calling sys.exit in an atexit function strikes me as a really bad idea.  It feels to me like it breaks the contract of what atexit is designed for, which is to run multiple handlers at exit.  If you call sys.exit you are in some sense restarting the exit processing, which feels broken to me.  It would feel equally broken, however, to call _exit, since that would mean the rest of the handlers in the chain would not be run.

In any case, I personally would *expect* an exit called in an atexit handler to have no effect, since an exit is already in progress and we've just taken a detour to run the handlers.  I can see the argument for the reverse, however, so it isn't obvious to me what the correct answer is.

I do note that the OP in #1257 prefers to use the sys.exit return code if an atexit handler raises an error, which argues for not replacing it if the atexit handler raises SystemExit with a different RC.  It would be more consistent with the proposed handling of atexit errors.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27035>
_______________________________________

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: [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:26:54 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 16 May 2016 15:26:54 +0000
Subject: [issue26938] android: test_concurrent_futures hangs on armv7
In-Reply-To: <1462289530.91.0.204802241019.issue26938@psf.upfronthosting.co.za>
Message-ID: <1463412414.72.0.0242164619864.issue26938@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

test_concurrent_futures is not run on Android because "This platform lacks a functioning sem_open implementation", see issue #26924.

Closing as won't fix.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26938>
_______________________________________

From report at bugs.python.org  Mon May 16 11:39:14 2016
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 16 May 2016 15:39:14 +0000
Subject: [issue26359] CPython build options for out-of-the box performance
In-Reply-To: <1455445693.01.0.984013993837.issue26359@psf.upfronthosting.co.za>
Message-ID: <1463413154.09.0.0117112592235.issue26359@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Just leave a comment next week in the issue if no one else beats me to the issue (I'm at OSCON so I don't have time to commit until May 24 at the earliest).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26359>
_______________________________________

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: [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 11:49:19 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 May 2016 15:49:19 +0000
Subject: [issue27038] Make os.DirEntry exist
In-Reply-To: <1463413415.02.0.145090656269.issue27038@psf.upfronthosting.co.za>
Message-ID: <1463413759.56.0.0182642514946.issue27038@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +benhoyt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27038>
_______________________________________

From report at bugs.python.org  Mon May 16 11:49:26 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 May 2016 15:49:26 +0000
Subject: [issue27038] Make os.DirEntry exist
In-Reply-To: <1463413415.02.0.145090656269.issue27038@psf.upfronthosting.co.za>
Message-ID: <1463413766.61.0.947940997669.issue27038@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27038>
_______________________________________

From report at bugs.python.org  Mon May 16 11:52:27 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 16 May 2016 15:52:27 +0000
Subject: [issue26939] android: test_functools hangs on armv7
In-Reply-To: <1462289866.52.0.349587333392.issue26939@psf.upfronthosting.co.za>
Message-ID: <1463413947.43.0.890855543836.issue26939@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Got now a full fledged gdb. Thread #1 loops infinitely in the "while (_Py_atomic_load_relaxed(&gil_locked))" loop in take_gil(). Thread #2 is stuck in the MUTEX_LOCK(gil_mutex) statement in drop_gil() as can be seen by setting a breakpoint at the following line and seeing that this breakpoint is never hit.

Setting gil_interval to 10 (from the initial value of 1) from gdb, allows the test to pass.

With this patch of PyCOND_TIMEDWAIT():

  diff -r eee959fee5f5 Python/condvar.h
  --- a/Python/condvar.h	Sat May 07 21:13:50 2016 +0300
  +++ b/Python/condvar.h	Mon May 16 15:52:49 2016 +0200
  @@ -99,6 +99,7 @@
       PyCOND_ADD_MICROSECONDS(deadline, us);
       ts.tv_sec = deadline.tv_sec;
       ts.tv_nsec = deadline.tv_usec * 1000;
  +    PyCOND_GETTIMEOFDAY(&deadline);

and a breakpoint set on pthread_cond_timedwait(). When this breakpoint is hit, there is 20 usec  elapsed time instead of the value of 1 (as requested by 'us') between ts and deadline as shown here:

  (gdb) p ts
  $1 = {tv_sec = 1463407197, tv_nsec = 468546000}
  (gdb) p deadline
  $2 = {tv_sec = 1463407197, tv_usec = 468566}

And when iterating the loop, the measured elapsed times are: 20, 12, 12, 11, 11, 11.

Clearly, the ts date is in the past when pthread_cond_timedwait() is called, and the function returns immediately without releasing the mutex. This is the expected behavior[1].

[1] http://linux.die.net/man/3/pthread_cond_wait

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26939>
_______________________________________

From report at bugs.python.org  Mon May 16 11:54:03 2016
From: report at bugs.python.org (Meador Inge)
Date: Mon, 16 May 2016 15:54:03 +0000
Subject: [issue26549] co_stacksize is calculated from unoptimized code
In-Reply-To: <1457822745.22.0.972836245522.issue26549@psf.upfronthosting.co.za>
Message-ID: <1463414043.53.0.13813831285.issue26549@psf.upfronthosting.co.za>


Meador Inge added the comment:

See also issue24340

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26549>
_______________________________________

From report at bugs.python.org  Mon May 16 12:01:58 2016
From: report at bugs.python.org (David Coles)
Date: Mon, 16 May 2016 16:01:58 +0000
Subject: [issue22970] asyncio: Cancelling wait() after notification leaves
 Condition in an inconsistent state
In-Reply-To: <1417404582.01.0.276361050449.issue22970@psf.upfronthosting.co.za>
Message-ID: <1463414518.33.0.663492597919.issue22970@psf.upfronthosting.co.za>


David Coles added the comment:

Please find the PR including a test to reproduce the issue here: https://github.com/python/asyncio/pull/346

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22970>
_______________________________________

From report at bugs.python.org  Mon May 16 12:02:31 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 May 2016 16:02:31 +0000
Subject: [issue26939] android: test_functools hangs on armv7
In-Reply-To: <1462289866.52.0.349587333392.issue26939@psf.upfronthosting.co.za>
Message-ID: <1463414551.78.0.731842210955.issue26939@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I don't know if it can fix the issue, but you may see my issue #23428: "Use the monotonic clock for thread conditions on POSIX platforms".

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26939>
_______________________________________

From report at bugs.python.org  Mon May 16 12:08:24 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 May 2016 16:08:24 +0000
Subject: [issue27037] Universal newline support for zipFile.ZipExtFile.read()
 is not working (deprecated?),
 and the missing functionality not documented
In-Reply-To: <1463410014.02.0.132222711737.issue27037@psf.upfronthosting.co.za>
Message-ID: <1463414904.08.0.602688679125.issue27037@psf.upfronthosting.co.za>


R. David Murray added the comment:

The decision was to deprecate 'U' *everywhere* in python3.

Yes, the 2.7 method you are concerned about is broken with respect to its documentation, which is what #6759 was about originally.  That issue was deemed too disruptive to the codebase to address effectively, but in fixing things propery for python3 we apparently lost track of the 2.7 bug.

You can fix the problem (in a forward compatible way) by wrapping the ZipExtFile in an io.TextIOWrapper.

The 2.7 documentation should be changed to address this issue and the solution.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27037>
_______________________________________

From report at bugs.python.org  Mon May 16 12:09:14 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 May 2016 16:09:14 +0000
Subject: [issue27037] Universal newline support for zipFile.ZipExtFile.read()
 is not working (deprecated?),
 and the missing functionality not documented
In-Reply-To: <1463410014.02.0.132222711737.issue27037@psf.upfronthosting.co.za>
Message-ID: <1463414954.57.0.499115935538.issue27037@psf.upfronthosting.co.za>


R. David Murray added the comment:

The decision was to deprecate 'U' *everywhere* in python3.

Yes, the 2.7 method you are concerned about is broken with respect to its documentation, which is what #6759 was about originally.  That issue was deemed too disruptive to the codebase to address effectively, but in fixing things properly for python3 we apparently lost track of the 2.7 bug.

You can fix the problem (in a forward compatible way) by wrapping the ZipExtFile in an io.TextIOWrapper.

The 2.7 documentation should be changed to address this issue and the solution.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27037>
_______________________________________

From report at bugs.python.org  Mon May 16 12:09:21 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 16 May 2016 16:09:21 +0000
Subject: [issue26939] android: test_functools hangs on armv7
In-Reply-To: <1462289866.52.0.349587333392.issue26939@psf.upfronthosting.co.za>
Message-ID: <1463414961.92.0.145191883603.issue26939@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

On a heavily loaded system, there is no guarantee that the date obtained from a call to gettimeofday() in PyCOND_TIMEDWAIT(), is not in the past when pthread_cond_timedwait() is called, as there may be a context switch in between. When this happens, a Python thread cannot take the gil even if it is available.

This tentative patch monitors the load of the system and dynamically increases the value used for the switch interval when needed. With this patch on the android-21-armv7 emulator:

python -m test -m test_lru_cache_threaded -v test_functools
Ok
python -m test -m test_deadlock -v test_importlib
Ok
python -m test -m test_is_alive_after_fork -v test_threading
Ok

The measured elapsed time is not correct in this patch when it is above 1 second.

----------
Added file: http://bugs.python.org/file42874/pycond_timedwait.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26939>
_______________________________________

From report at bugs.python.org  Mon May 16 12:09:22 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 May 2016 16:09:22 +0000
Subject: [issue27037] Universal newline support for zipFile.ZipExtFile.read()
 is not working (deprecated?),
 and the missing functionality not documented
In-Reply-To: <1463410014.02.0.132222711737.issue27037@psf.upfronthosting.co.za>
Message-ID: <1463414962.71.0.641892095446.issue27037@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
Removed message: http://bugs.python.org/msg265705

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27037>
_______________________________________

From report at bugs.python.org  Mon May 16 12:12:38 2016
From: report at bugs.python.org (SilentGhost)
Date: Mon, 16 May 2016 16:12:38 +0000
Subject: [issue25910] Fixing links in documentation
In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za>
Message-ID: <1463415158.69.0.303910403835.issue25910@psf.upfronthosting.co.za>


SilentGhost added the comment:

Does it not matter that the link to pythonlabs is a part of the official license text? Besides, it's not an actual html a tag, but rather a verbatim text, surely the only correction here is to make sure that the linkcheck doesn't check links within pre, code and similar tags.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25910>
_______________________________________

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: [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 12:35:49 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 May 2016 16:35:49 +0000
Subject: [issue26073] Update the list of magic numbers in launcher
In-Reply-To: <1452412193.99.0.751958856998.issue26073@psf.upfronthosting.co.za>
Message-ID: <20160516163546.13290.25848.AED38C3C@psf.io>


Roundup Robot added the comment:

New changeset d921932fe02f by Steve Dower in branch '3.5':
Issue #26073: Updates magic number comment in _bootstrap_external.py and changes numbers in launcher.py to decimal to match official table.
https://hg.python.org/cpython/rev/d921932fe02f

New changeset 0fe913de4702 by Steve Dower in branch 'default':
Issue #26073: Updates magic number comment in _bootstrap_external.py and changes numbers in launcher.py to decimal to match official table.
https://hg.python.org/cpython/rev/0fe913de4702

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26073>
_______________________________________

From report at bugs.python.org  Mon May 16 12:39:45 2016
From: report at bugs.python.org (SilentGhost)
Date: Mon, 16 May 2016 16:39:45 +0000
Subject: [issue27039] bytearray.remove cannot remove bytes with value greater
 than 127
In-Reply-To: <1463416188.61.0.0822560128487.issue27039@psf.upfronthosting.co.za>
Message-ID: <1463416785.56.0.192349774474.issue27039@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +serhiy.storchaka
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27039>
_______________________________________

From report at bugs.python.org  Mon May 16 12:41:58 2016
From: report at bugs.python.org (SilentGhost)
Date: Mon, 16 May 2016 16:41:58 +0000
Subject: [issue27039] bytearray.remove cannot remove bytes with value greater
 than 127
In-Reply-To: <1463416188.61.0.0822560128487.issue27039@psf.upfronthosting.co.za>
Message-ID: <1463416918.97.0.628520796712.issue27039@psf.upfronthosting.co.za>


SilentGhost added the comment:

Test is not catching it, because it only deals with ascii part.

----------
nosy: +SilentGhost

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27039>
_______________________________________

From report at bugs.python.org  Mon May 16 12:43:08 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 16 May 2016 16:43:08 +0000
Subject: [issue25650] Mismatching documentation <=> behaviour for typing.Any
In-Reply-To: <1447785383.67.0.0503638677753.issue25650@psf.upfronthosting.co.za>
Message-ID: <1463416988.55.0.79151275778.issue25650@psf.upfronthosting.co.za>


Berker Peksag added the comment:

This is basically a duplicate of issue 25830. We can update the docstring of Any once https://github.com/python/typing/issues/136 is solved.

----------
nosy: +berker.peksag
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> _TypeAlias: Discrepancy between docstring and behavior
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25650>
_______________________________________

From report at bugs.python.org  Mon May 16 12:44:59 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 16 May 2016 16:44:59 +0000
Subject: [issue26141] typing module documentation incomplete
In-Reply-To: <1453049740.68.0.762293537242.issue26141@psf.upfronthosting.co.za>
Message-ID: <1463417099.83.0.703864456277.issue26141@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26141>
_______________________________________

From report at bugs.python.org  Mon May 16 13:19:58 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 16 May 2016 17:19:58 +0000
Subject: [issue27031] Remove interface to obsolete Tk commands
In-Reply-To: <1463338391.3.0.784874070077.issue27031@psf.upfronthosting.co.za>
Message-ID: <1463419198.73.0.737065655676.issue27031@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Since the deprecation notice said 'will be removed in 3.6', go ahead ;-).

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27031>
_______________________________________

From report at bugs.python.org  Mon May 16 13:38:20 2016
From: report at bugs.python.org (Joe Jevnik)
Date: Mon, 16 May 2016 17:38:20 +0000
Subject: [issue27039] bytearray.remove cannot remove bytes with value greater
 than 127
In-Reply-To: <1463416188.61.0.0822560128487.issue27039@psf.upfronthosting.co.za>
Message-ID: <1463420300.19.0.270399981241.issue27039@psf.upfronthosting.co.za>


Joe Jevnik added the comment:

This seems to just be a bug in the implementation of remove. I have a patch to fix this and a test case.

----------
keywords: +patch
nosy: +llllllllll
Added file: http://bugs.python.org/file42875/bytearray-remove.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27039>
_______________________________________

From report at bugs.python.org  Mon May 16 14:26:27 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 May 2016 18:26:27 +0000
Subject: [issue19524] ResourceWarning when urlopen() forgets the
 HTTPConnection object
In-Reply-To: <1383882317.08.0.635493267684.issue19524@psf.upfronthosting.co.za>
Message-ID: <1463423187.72.0.819549695889.issue19524@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Interesting. I didn't know that "hg graft" keeps the author and data of the original commit. Maybe this is a Mercurial bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19524>
_______________________________________

From report at bugs.python.org  Mon May 16 14:42:31 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 May 2016 18:42:31 +0000
Subject: [issue27033] Change the decode_data default in smtpd to False
In-Reply-To: <1463340039.51.0.670985844702.issue27033@psf.upfronthosting.co.za>
Message-ID: <1463424151.41.0.0436088280589.issue27033@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Oh, sorry, I understood this as a sign that you already made a review and don't have comments. I was surprised that you made this silently.

Here is a patch that adds an entry in the porting section of What's New. Please also check changes in the smtpd documentation. I reformulated some sentences.

----------
Added file: http://bugs.python.org/file42876/smtpd_decode_data_false_doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27033>
_______________________________________

From report at bugs.python.org  Mon May 16 14:58:44 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 May 2016 18:58:44 +0000
Subject: [issue27039] bytearray.remove cannot remove bytes with value greater
 than 127
In-Reply-To: <1463416188.61.0.0822560128487.issue27039@psf.upfronthosting.co.za>
Message-ID: <1463425124.0.0.98895362541.issue27039@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM.

----------
assignee:  -> serhiy.storchaka
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27039>
_______________________________________

From report at bugs.python.org  Mon May 16 14:59:43 2016
From: report at bugs.python.org (Jason Curtis)
Date: Mon, 16 May 2016 18:59:43 +0000
Subject: [issue22955] Pickling of methodcaller, attrgetter, and itemgetter
In-Reply-To: <1417069983.84.0.769912375651.issue22955@psf.upfronthosting.co.za>
Message-ID: <1463425183.71.0.844337982421.issue22955@psf.upfronthosting.co.za>


Jason Curtis added the comment:

This is still an issue with operator.attrgetter in 3.4.3, even after clearing sys.modules['_operator']:

$ python3
Python 3.4.3 (default, Oct 14 2015, 20:28:29) 
[GCC 4.8.4] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.modules['_operator'] = None
>>> import operator
>>> import pickle
>>> pickle.loads(pickle.dumps(operator.attrgetter("foo")))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
_pickle.PicklingError: Can't pickle <function attrgetter.__init__.<locals>.func at 0x7f25728d5bf8>: attribute lookup func on operator failed

----------
nosy: +Jason Curtis
versions: +Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22955>
_______________________________________

From report at bugs.python.org  Mon May 16 15:02:57 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 May 2016 19:02:57 +0000
Subject: [issue27039] bytearray.remove cannot remove bytes with value greater
 than 127
In-Reply-To: <1463416188.61.0.0822560128487.issue27039@psf.upfronthosting.co.za>
Message-ID: <1463425377.41.0.801106899795.issue27039@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

But we first need to test that value is in the range from 0 to 255.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27039>
_______________________________________

From report at bugs.python.org  Mon May 16 15:03:01 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 May 2016 19:03:01 +0000
Subject: [issue27039] bytearray.remove cannot remove bytes with value greater
 than 127
In-Reply-To: <1463416188.61.0.0822560128487.issue27039@psf.upfronthosting.co.za>
Message-ID: <1463425381.87.0.937664415754.issue27039@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

But we first need to test that value is in the range from 0 to 255.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27039>
_______________________________________

From report at bugs.python.org  Mon May 16 15:07:19 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 16 May 2016 19:07:19 +0000
Subject: [issue26939] android: test_functools hangs on armv7
In-Reply-To: <1462289866.52.0.349587333392.issue26939@psf.upfronthosting.co.za>
Message-ID: <1463425639.1.0.884683676898.issue26939@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

> I don't know if it can fix the issue, but you may see my issue #23428: "Use the monotonic clock for thread conditions on POSIX platforms".

pthread_condattr_setclock() is declared in the Android API 21 headers.

When a monotonic clock is set for pthread_cond_timedwait(), one could measure the monotonic time elapsed to execute the instructions from _PyTime_monotonic() to the setting of the ts fields in PyCOND_TIMEDWAIT(), i.e the time to execute those statements taken from your patch:

#ifdef MONOTONIC
    _PyTime_monotonic(&deadline);
#else
    _PyTime_gettimeofday(&deadline);
#endif

    /* TODO: add overflow and truncation checks */
    assert(us <= LONG_MAX);
    deadline.tv_usec += (long)us;
    deadline.tv_sec += deadline.tv_usec / 1000000;
    deadline.tv_usec %= 1000000;


and prevent gil_interval to be set below that measured value. This would solve the problem for this soooo slow emulator. _PyTime_monotonic() does not exist, is this _PyTime_GetMonotonicClock() ? So I did not try to test it, not knowing the status of your patch.

IMHO PyCOND_TIMEDWAIT() should use a monotonic clock when available.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26939>
_______________________________________

From report at bugs.python.org  Mon May 16 15:07:35 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 May 2016 19:07:35 +0000
Subject: [issue27039] bytearray.remove cannot remove bytes with value greater
 than 127
In-Reply-To: <1463416188.61.0.0822560128487.issue27039@psf.upfronthosting.co.za>
Message-ID: <1463425655.98.0.804477127663.issue27039@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Ah, this is already checked in the converter.

----------

_______________________________________
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: [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:19:48 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 16 May 2016 19:19:48 +0000
Subject: [issue27040] asyncio: Add loop.get_exception_handler method
In-Reply-To: <1463426380.52.0.735203322245.issue27040@psf.upfronthosting.co.za>
Message-ID: <1463426388.03.0.277944285706.issue27040@psf.upfronthosting.co.za>


Changes by Yury Selivanov <yselivanov at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
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: [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 15:21:42 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 16 May 2016 19:21:42 +0000
Subject: [issue27041] asyncio: Add loop.create_future method
In-Reply-To: <1463426494.21.0.869664306544.issue27041@psf.upfronthosting.co.za>
Message-ID: <1463426502.36.0.707727045048.issue27041@psf.upfronthosting.co.za>


Changes by Yury Selivanov <yselivanov at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27041>
_______________________________________

From report at bugs.python.org  Mon May 16 15:21:59 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 16 May 2016 19:21:59 +0000
Subject: [issue27033] Change the decode_data default in smtpd to False
In-Reply-To: <1463340039.51.0.670985844702.issue27033@psf.upfronthosting.co.za>
Message-ID: <1463426519.98.0.300573754388.issue27033@psf.upfronthosting.co.za>


R. David Murray added the comment:

No problem.  I use 'commit review' as an indication that a committer should do a final review...before that, triage or general community people can be doing the reviews, then triage can move it to commit review to request the final review before commit.  What this means in practical terms is that if I do a search for 'email' issues in 'commit review' stage, I find all the issues I should be reviewing.

I'll try to do the review soon.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27033>
_______________________________________

From report at bugs.python.org  Mon May 16 15:25:07 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 May 2016 19:25:07 +0000
Subject: [issue27039] bytearray.remove cannot remove bytes with value greater
 than 127
In-Reply-To: <1463416188.61.0.0822560128487.issue27039@psf.upfronthosting.co.za>
Message-ID: <20160516192436.42361.85684.B0FC09FC@psf.io>


Roundup Robot added the comment:

New changeset 10444778d41c by Serhiy Storchaka in branch '3.5':
Issue #27039: Fixed bytearray.remove() for values greater than 127.
https://hg.python.org/cpython/rev/10444778d41c

New changeset 9acf44b7ff7b by Serhiy Storchaka in branch '2.7':
Issue #27039: Fixed bytearray.remove() for values greater than 127.
https://hg.python.org/cpython/rev/9acf44b7ff7b

New changeset 3eb502d43616 by Serhiy Storchaka in branch 'default':
Issue #27039: Fixed bytearray.remove() for values greater than 127.
https://hg.python.org/cpython/rev/3eb502d43616

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27039>
_______________________________________

From report at bugs.python.org  Mon May 16 15:25:52 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 May 2016 19:25:52 +0000
Subject: [issue27039] bytearray.remove cannot remove bytes with value greater
 than 127
In-Reply-To: <1463416188.61.0.0822560128487.issue27039@psf.upfronthosting.co.za>
Message-ID: <1463426752.59.0.841899906962.issue27039@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27039>
_______________________________________

From report at bugs.python.org  Mon May 16 15:28:48 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 May 2016 19:28:48 +0000
Subject: [issue22955] Pickling of methodcaller, attrgetter, and itemgetter
In-Reply-To: <1417069983.84.0.769912375651.issue22955@psf.upfronthosting.co.za>
Message-ID: <1463426928.8.0.219105427149.issue22955@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is new feature in 3.5.

----------
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22955>
_______________________________________

From report at bugs.python.org  Mon May 16 15:32:51 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 May 2016 19:32:51 +0000
Subject: [issue27040] asyncio: Add loop.get_exception_handler method
In-Reply-To: <1463426380.52.0.735203322245.issue27040@psf.upfronthosting.co.za>
Message-ID: <20160516193232.88912.22520.D550E1B5@psf.io>


Roundup Robot added the comment:

New changeset f51ecf47d416 by Yury Selivanov in branch '3.5':
Issue #27040: Add loop.get_exception_handler method
https://hg.python.org/cpython/rev/f51ecf47d416

New changeset a3db6aee74f3 by Yury Selivanov in branch 'default':
Merge 3.5 (issue #27040)
https://hg.python.org/cpython/rev/a3db6aee74f3

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27040>
_______________________________________

From report at bugs.python.org  Mon May 16 15:36:06 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 May 2016 19:36:06 +0000
Subject: [issue27031] Remove interface to obsolete Tk commands
In-Reply-To: <1463338391.3.0.784874070077.issue27031@psf.upfronthosting.co.za>
Message-ID: <20160516193603.9351.27054.D71943CD@psf.io>


Roundup Robot added the comment:

New changeset 774367d21bf3 by Serhiy Storchaka in branch 'default':
Issue #27031: Removed dummy methods in Tkinter widget classes: tk_menuBar()
https://hg.python.org/cpython/rev/774367d21bf3

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27031>
_______________________________________

From report at bugs.python.org  Mon May 16 15:36:55 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 May 2016 19:36:55 +0000
Subject: [issue27031] Remove interface to obsolete Tk commands
In-Reply-To: <1463338391.3.0.784874070077.issue27031@psf.upfronthosting.co.za>
Message-ID: <1463427415.2.0.425058821.issue27031@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27031>
_______________________________________

From report at bugs.python.org  Mon May 16 15:40:47 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 16 May 2016 19:40:47 +0000
Subject: [issue27041] asyncio: Add loop.create_future method
In-Reply-To: <1463426494.21.0.869664306544.issue27041@psf.upfronthosting.co.za>
Message-ID: <20160516194043.23169.49272.D14257C0@psf.io>


Roundup Robot added the comment:

New changeset 32ceaad6243d by Yury Selivanov in branch '3.5':
Issue #27041: asyncio: Add loop.create_future method
https://hg.python.org/cpython/rev/32ceaad6243d

New changeset fc7b366c4c8a by Yury Selivanov in branch 'default':
Merge 3.5 (Issue #27041)
https://hg.python.org/cpython/rev/fc7b366c4c8a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27041>
_______________________________________

From report at bugs.python.org  Mon May 16 16:34:35 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 May 2016 20:34:35 +0000
Subject: [issue27036] Mark up of references in different form
In-Reply-To: <1463387629.05.0.783453150634.issue27036@psf.upfronthosting.co.za>
Message-ID: <1463430875.75.0.848577987139.issue27036@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your review Martin! Absolutely agreed with you about references to classes and exceptions. I have removed this from the next version of the patch. I left your idea about ":exc:`SyntaxError` exceptions" for other patch.

?evaluated with :func:`eval` ? looks tautologically to me. In hypertext we can avoid the repetition.

----------
Added file: http://bugs.python.org/file42877/refs_forms2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27036>
_______________________________________

From report at bugs.python.org  Mon May 16 16:40:51 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 16 May 2016 20:40:51 +0000
Subject: [issue25910] Fixing links in documentation
In-Reply-To: <1450530544.1.0.9187941337.issue25910@psf.upfronthosting.co.za>
Message-ID: <1463431251.07.0.158605697058.issue25910@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> zope should be http://www.zope.org/

Isn't this is a different legal entity?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25910>
_______________________________________

From report at bugs.python.org  Mon May 16 17:29:52 2016
From: report at bugs.python.org (Aaron Meurer)
Date: Mon, 16 May 2016 21:29:52 +0000
Subject: [issue25453] Arithmetics with complex infinities is inconsistent with
 C/C++
In-Reply-To: <1445430043.57.0.625714416149.issue25453@psf.upfronthosting.co.za>
Message-ID: <1463434192.12.0.551354759235.issue25453@psf.upfronthosting.co.za>


Changes by Aaron Meurer <asmeurer at gmail.com>:


----------
nosy: +Aaron.Meurer

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25453>
_______________________________________

From report at bugs.python.org  Mon May 16 17:49:27 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Mon, 16 May 2016 21:49:27 +0000
Subject: [issue26909] Asyncio: Pipes and socket IO is very slow
In-Reply-To: <1462208793.52.0.483694752489.issue26909@psf.upfronthosting.co.za>
Message-ID: <1463435367.96.0.113139615349.issue26909@psf.upfronthosting.co.za>


Changes by ???? ????????? <socketpair at gmail.com>:


----------
title: Serious performance loss (10 times) when NOT using .drain() -> Asyncio: Pipes and socket IO is very slow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26909>
_______________________________________

From report at bugs.python.org  Mon May 16 17:50:16 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Mon, 16 May 2016 21:50:16 +0000
Subject: [issue27022] expose sendmmsg() syscall  in sockets API
In-Reply-To: <1463247542.08.0.661246316661.issue27022@psf.upfronthosting.co.za>
Message-ID: <1463435416.95.0.97632562505.issue27022@psf.upfronthosting.co.za>


???? ????????? added the comment:

This helps improve performance of asyncio datagram stream

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27022>
_______________________________________

From report at bugs.python.org  Mon May 16 17:52:31 2016
From: report at bugs.python.org (paul j3)
Date: Mon, 16 May 2016 21:52:31 +0000
Subject: [issue11588] Add "necessarily inclusive" groups to argparse
In-Reply-To: <1300377092.03.0.159307937388.issue11588@psf.upfronthosting.co.za>
Message-ID: <1463435551.62.0.36360526364.issue11588@psf.upfronthosting.co.za>


paul j3 added the comment:

So far I've proposed adding a 'hook' at the end of '_parse_known_args', that would give the user access to the 'seen_non_default_actions' variable.  This function could perform an almost arbitrarily complex set of logical co-occurrence tests on this set (or list) of Actions.

The rest of my proposed patches (nested groups, etc) are user interface components that attempt make this testing more user-friendly, both in specification and usage display.

It just occurred to me that an alternate stop-gap fix is to make 'seen_non_default_actions' available to the user for his own testing after parsing.  Adding it to the method return is not backward compatible.  But it could be added as an attribute to parser.

     self._seen_actions = seen_non_default_actions

It would be the first case of giving the parser a memory of past parsing actions, but I don't think that's a problem.

Another possibility is to conditionally add it to the 'namespace'. 

     if hasattr(namespace, 'seen_actions'):
        setattr(namespace, 'seen_actions', seen_non_default_actions)

The user could initial this attribute with a custom 'Namespace' object or with a 'set_defaults' call.

(I'm  proposing to save 'seen_non_default_actions' because in my earlier tests that seemed to be more useful than 'seen_actions'.  It's the one used by mutually_exclusive_group testing.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue11588>
_______________________________________

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: [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 19:01:28 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 May 2016 23:01:28 +0000
Subject: [issue27041] asyncio: Add loop.create_future method
In-Reply-To: <20160516194043.23169.49272.D14257C0@psf.io>
Message-ID: <CAMpsgwYEM4uTyQwubm8g5pSW8gmurBAeOYYxB2X0Yiyf3XLGUw@mail.gmail.com>


STINNER Victor added the comment:

> resolution:  -> fixed

Hum, it looks like the change is now documented in asyncio doc :-(

https://docs.python.org/dev/library/asyncio-eventloop.html#tasks

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27041>
_______________________________________

From report at bugs.python.org  Mon May 16 19:02:09 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 May 2016 23:02:09 +0000
Subject: [issue27040] asyncio: Add loop.get_exception_handler method
In-Reply-To: <20160516193232.88912.22520.D550E1B5@psf.io>
Message-ID: <CAMpsgwYX7VaPSn=212Qf3VsxxfTdES5Erw9kDUum2tsFgtY9pQ@mail.gmail.com>


STINNER Victor added the comment:

> resolution:  -> fixed

Hum, it looks like the new method is not documented :-(

https://docs.python.org/dev/library/asyncio-eventloop.html#error-handling-api

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27040>
_______________________________________

From report at bugs.python.org  Mon May 16 19:03:06 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 16 May 2016 23:03:06 +0000
Subject: [issue27040] asyncio: Add loop.get_exception_handler method
In-Reply-To: <1463426380.52.0.735203322245.issue27040@psf.upfronthosting.co.za>
Message-ID: <1463439786.06.0.688283426832.issue27040@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Give it some time ;)
https://hg.python.org/cpython/rev/83450939b106

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27040>
_______________________________________

From report at bugs.python.org  Mon May 16 19:11:24 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 16 May 2016 23:11:24 +0000
Subject: [issue27041] asyncio: Add loop.create_future method
In-Reply-To: <1463426494.21.0.869664306544.issue27041@psf.upfronthosting.co.za>
Message-ID: <1463440284.61.0.835342595968.issue27041@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27041>
_______________________________________

From report at bugs.python.org  Mon May 16 19:12:51 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 16 May 2016 23:12:51 +0000
Subject: [issue27041] asyncio: Add loop.create_future method
In-Reply-To: <1463426494.21.0.869664306544.issue27041@psf.upfronthosting.co.za>
Message-ID: <1463440371.33.0.938728706538.issue27041@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

https://hg.python.org/cpython/rev/9ea64c74a1fd

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27041>
_______________________________________

From report at bugs.python.org  Mon May 16 19:13:41 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 16 May 2016 23:13:41 +0000
Subject: [issue27041] asyncio: Add loop.create_future method
In-Reply-To: <1463426494.21.0.869664306544.issue27041@psf.upfronthosting.co.za>
Message-ID: <1463440421.85.0.575819140567.issue27041@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

here -> https://hg.python.org/cpython/rev/83450939b106

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27041>
_______________________________________

From report at bugs.python.org  Mon May 16 19:25:08 2016
From: report at bugs.python.org (Melissa Chang)
Date: Mon, 16 May 2016 23:25:08 +0000
Subject: [issue10496] Python startup should not require passwd entry
In-Reply-To: <1290398281.89.0.568058332092.issue10496@psf.upfronthosting.co.za>
Message-ID: <1463441108.93.0.965795324753.issue10496@psf.upfronthosting.co.za>


Changes by Melissa Chang <melchang at google.com>:


----------
nosy: +Melissa Chang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10496>
_______________________________________

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: =?utf-8?q?=5Bissue27043=5D_Describe_what_=E2=80=98inspect=2Ecleandoc?=
 =?utf-8?q?=E2=80=99_does_to_synopsis_line=2E?=
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:14:28 2016
From: report at bugs.python.org (Peter Inglesby)
Date: Tue, 17 May 2016 01:14:28 +0000
Subject: [issue22377] %Z in strptime doesn't match EST and others
In-Reply-To: <1410301455.57.0.912701656833.issue22377@psf.upfronthosting.co.za>
Message-ID: <1463447668.44.0.975496580984.issue22377@psf.upfronthosting.co.za>


Peter Inglesby added the comment:

Given the difference between the documented and the actual behaviours, and given that it's apparently not obvious what the correct fix should be, would a patch that updates the docs (to say that %Z only matched GMT and UTC) be welcome?

----------
nosy: +inglesp

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22377>
_______________________________________

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: [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: [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  Mon May 16 21:38:25 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Tue, 17 May 2016 01:38:25 +0000
Subject: [issue27045] Forward slashes in Windows paths
In-Reply-To: <1463448805.55.0.933820705649.issue27045@psf.upfronthosting.co.za>
Message-ID: <1463449105.34.0.461106552867.issue27045@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

Forward slashes work fine in Windows, for both the command line and PowerShell. Windows always displays backslahes, but accepts either (as well as any combination of both) in paths.

----------
assignee: docs at python -> 
nosy: +ebarry
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27045>
_______________________________________

From report at bugs.python.org  Mon May 16 21:48:34 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 17 May 2016 01:48:34 +0000
Subject: [issue27036] Mark up of references in different form
In-Reply-To: <1463387629.05.0.783453150634.issue27036@psf.upfronthosting.co.za>
Message-ID: <1463449714.71.0.69953228537.issue27036@psf.upfronthosting.co.za>


Martin Panter added the comment:

It _would_ be nice to sort out the SyntaxErrors problem as well, but don?t let that stop fixing the easier problems. I would be interested in other people?s thoughts.

My problem with things like :func:`evaluated <eval>` is that the meaning is less clear, and it is not obvious what the hyperlink is for. If you print the sentence out, or casually look in a browser, there is not much indication that the function eval() is specified. Ugly as it is, ?eval()uated? is more obvious.

Other options that I would be happier with, if you want to avoid the repeated ?evaluated with eval()?, etc:

Level values are passed through :func:`eval`
list of channels waited with select() or poll()
The ``args`` entry, after passing through :func:`eval`
and :meth:`~Thread.join` cannot be called on them [dummy threads]
Module objects now support :mod:`weakref`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27036>
_______________________________________

From report at bugs.python.org  Mon May 16 22:28:23 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 May 2016 02:28:23 +0000
Subject: [issue25747] test_idle failure in leaks searching mode
In-Reply-To: <1448647986.99.0.712792565134.issue25747@psf.upfronthosting.co.za>
Message-ID: <20160517022819.56055.7531.A0FA5274@psf.io>


Roundup Robot added the comment:

New changeset 9e1c859562bb by Terry Jan Reedy in branch '2.7':
Backports: #25747: remove bad test.  #27044: stop test_idle from leaking.
https://hg.python.org/cpython/rev/9e1c859562bb

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25747>
_______________________________________

From report at bugs.python.org  Mon May 16 22:28:23 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 May 2016 02:28:23 +0000
Subject: [issue27044] Stop test_idle memory leaks
In-Reply-To: <1463447928.95.0.827348262469.issue27044@psf.upfronthosting.co.za>
Message-ID: <20160517022819.56055.8586.612615A7@psf.io>


Roundup Robot added the comment:

New changeset 9e1c859562bb by Terry Jan Reedy in branch '2.7':
Backports: #25747: remove bad test.  #27044: stop test_idle from leaking.
https://hg.python.org/cpython/rev/9e1c859562bb

New changeset 6a33d8d5d208 by Terry Jan Reedy in branch '3.5':
Issue #27044: stop test_idle from leaking by deleting callbacks.
https://hg.python.org/cpython/rev/6a33d8d5d208

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27044>
_______________________________________

From report at bugs.python.org  Mon May 16 22:29:20 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 17 May 2016 02:29:20 +0000
Subject: [issue27044] Stop test_idle memory leaks
In-Reply-To: <1463447928.95.0.827348262469.issue27044@psf.upfronthosting.co.za>
Message-ID: <1463452160.53.0.755215402678.issue27044@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27044>
_______________________________________

From report at bugs.python.org  Mon May 16 22:48:34 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 17 May 2016 02:48:34 +0000
Subject: [issue21703] IDLE: Test UndoDelegator
In-Reply-To: <1402394911.48.0.416868265469.issue21703@psf.upfronthosting.co.za>
Message-ID: <1463453314.1.0.370464957449.issue21703@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Before looking at this, I ran the leak tests and found a worse problem in the test suite.  I opened #27044 and fixed the problem.

I did not get the 'theme changed' message (msg220243) when running the leak test in the console, but did when running it either the file or test_file as __main__.  In the former case, the process is started by test.regrtest, which ends up calling unittest.  This is how buildbots run.  In the latter case, the process is started by the idlelib file, which calls unittest.

----------
assignee:  -> terry.reedy
stage:  -> commit review
type:  -> enhancement
versions: +Python 3.6 -Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21703>
_______________________________________

From report at bugs.python.org  Mon May 16 22:55:21 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Tue, 17 May 2016 02:55:21 +0000
Subject: [issue26823] Shrink recursive tracebacks
In-Reply-To: <1461292585.22.0.159887337407.issue26823@psf.upfronthosting.co.za>
Message-ID: <1463453721.23.0.18150298864.issue26823@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

I realize that I haven't given any update on this since my last patch. I figured that trying to detect when an arbitrary number of functions call each other in a convoluted call chain isn't a very good idea.

Not only is it way beyond my abilities, but I think it'll overcomplicate the code too much. Furthermore, the way Python/traceback.c (and, coincidentally, Lib/traceback.py) is done - print each frame as they come and then throw it away - means that remembering more than the last frame needs a refactor of both files. This is way out of the scope of this issue, which aims to solve the common cases (a typo when messing around in the REPL, __getattribute__ and __getattr__ are what get me the most).

I think that if the idea of keeping a track of multiple frames still flies, it should be a separate issue - probably after yet another issue proposing to refactor the files for that, but I'm dropping the idea.

Except for the ambigous message, I haven't seen any comments on any of my patches, which I take as a very good thing. Is there anything else preventing this from being merged?

TL;DR - Ping

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26823>
_______________________________________

From report at bugs.python.org  Mon May 16 23:06:43 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 17 May 2016 03:06:43 +0000
Subject: [issue27041] asyncio: Add loop.create_future method
In-Reply-To: <1463426494.21.0.869664306544.issue27041@psf.upfronthosting.co.za>
Message-ID: <1463454403.34.0.0622485687387.issue27041@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Victor, the docs are now online. https://docs.python.org/3/library/asyncio-eventloop.html#asyncio.BaseEventLoop.create_future

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27041>
_______________________________________

From report at bugs.python.org  Mon May 16 23:18:37 2016
From: report at bugs.python.org (Eric Wieser)
Date: Tue, 17 May 2016 03:18:37 +0000
Subject: [issue27042] Incorrect grammar for function definitions
In-Reply-To: <1463436725.68.0.177476383596.issue27042@psf.upfronthosting.co.za>
Message-ID: <1463455117.17.0.43848511858.issue27042@psf.upfronthosting.co.za>


Eric Wieser added the comment:

The offending patch can be found at https://hg.python.org/cpython/rev/71ff2235bb4c

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27042>
_______________________________________

From report at bugs.python.org  Mon May 16 23:33:05 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 May 2016 03:33:05 +0000
Subject: [issue21703] IDLE: Test UndoDelegator
In-Reply-To: <1402394911.48.0.416868265469.issue21703@psf.upfronthosting.co.za>
Message-ID: <20160517033302.30682.97979.468E4E11@psf.io>


Roundup Robot added the comment:

New changeset ce1b14ed5445 by Terry Jan Reedy in branch '3.5':
Issue #21703: Add test for undo delegator.  Patch most by Saimadhav Heblikar .
https://hg.python.org/cpython/rev/ce1b14ed5445

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21703>
_______________________________________

From report at bugs.python.org  Mon May 16 23:35:36 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 17 May 2016 03:35:36 +0000
Subject: [issue21703] IDLE: Test UndoDelegator
In-Reply-To: <1402394911.48.0.416868265469.issue21703@psf.upfronthosting.co.za>
Message-ID: <1463456136.81.0.211218732446.issue21703@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Solved 'theme' problem by adding to end of tearDownClass
        del cls.percolator, cls.text, cls.root

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21703>
_______________________________________

From report at bugs.python.org  Mon May 16 23:46:01 2016
From: report at bugs.python.org (Eric Wieser)
Date: Tue, 17 May 2016 03:46:01 +0000
Subject: [issue27042] Incorrect grammar for function definitions
In-Reply-To: <1463436725.68.0.177476383596.issue27042@psf.upfronthosting.co.za>
Message-ID: <1463456761.21.0.223262164163.issue27042@psf.upfronthosting.co.za>


Eric Wieser added the comment:

The parent commit is also bad:

https://hg.python.org/cpython/rev/b65007ef59c0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27042>
_______________________________________

From report at bugs.python.org  Tue May 17 01:49:09 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 May 2016 05:49:09 +0000
Subject: [issue27041] asyncio: Add loop.create_future method
In-Reply-To: <1463454403.34.0.0622485687387.issue27041@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbB_0wa9_d3DCy3BHmJB+eMsfZRMJHeYPH6GmTc7VMngg@mail.gmail.com>


STINNER Victor added the comment:

Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27041>
_______________________________________

From report at bugs.python.org  Tue May 17 01:54:33 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 May 2016 05:54:33 +0000
Subject: [issue26991] Possible reference leak in MAKE_FUNCTION
In-Reply-To: <1462878017.45.0.401291205212.issue26991@psf.upfronthosting.co.za>
Message-ID: <20160517055429.17726.69312.C9A2EF46@psf.io>


Roundup Robot added the comment:

New changeset eaa3a71a6f62 by Benjamin Peterson in branch '3.5':
fix possible refleak in MAKE_FUNCTION (closes #26991)
https://hg.python.org/cpython/rev/eaa3a71a6f62

New changeset 7270701cf5bc by Benjamin Peterson in branch 'default':
merge 3.5 (#26991)
https://hg.python.org/cpython/rev/7270701cf5bc

----------
nosy: +python-dev
resolution:  -> fixed
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26991>
_______________________________________

From report at bugs.python.org  Tue May 17 01:58:03 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 17 May 2016 05:58:03 +0000
Subject: [issue27042] Incorrect grammar for function definitions
In-Reply-To: <1463436725.68.0.177476383596.issue27042@psf.upfronthosting.co.za>
Message-ID: <1463464683.82.0.313546507413.issue27042@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <senthil at uthcode.com>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27042>
_______________________________________

From report at bugs.python.org  Tue May 17 02:20:48 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 May 2016 06:20:48 +0000
Subject: [issue27042] Incorrect grammar for function definitions
In-Reply-To: <1463436725.68.0.177476383596.issue27042@psf.upfronthosting.co.za>
Message-ID: <20160517062039.18014.28655.0D7982E7@psf.io>


Roundup Robot added the comment:

New changeset 451dd29ebae3 by Benjamin Peterson in branch '3.5':
Backed out changeset 71ff2235bb4c (closes #27042)
https://hg.python.org/cpython/rev/451dd29ebae3

New changeset d13999a6be8c by Benjamin Peterson in branch '3.5':
class definitions only get argument lists (closes #27042)
https://hg.python.org/cpython/rev/d13999a6be8c

New changeset d384bf58f5f8 by Benjamin Peterson in branch 'default':
merge 3.5 (#27042)
https://hg.python.org/cpython/rev/d384bf58f5f8

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27042>
_______________________________________

From report at bugs.python.org  Tue May 17 03:13:32 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 May 2016 07:13:32 +0000
Subject: [issue27036] Mark up of references in different form
In-Reply-To: <1463387629.05.0.783453150634.issue27036@psf.upfronthosting.co.za>
Message-ID: <1463469212.25.0.589124541614.issue27036@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think you make an accent on wrong thing. All these sentences look correct to me if remove any hyperlinks. Hyperlinks are optional. In the phrase "Level values are evaluated" the reference is to the term "evaluating", not to the eval() function. But since this term is not in glossary and is explained only in eval() description, the reference points to the eval() function. The same is for "weakly referencable" and "joining". It would be more correct ton add explicit labels "evaluating", "weak reference" and "join" and use they in references (":ref:`evaluated <evaluating>`"). This would create links without changing the style of the text.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27036>
_______________________________________

From report at bugs.python.org  Tue May 17 03:36:50 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 May 2016 07:36:50 +0000
Subject: [issue27036] Mark up of references in different form
In-Reply-To: <1463387629.05.0.783453150634.issue27036@psf.upfronthosting.co.za>
Message-ID: <1463470610.76.0.505910898588.issue27036@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Georg, is it possible to refer to function without changing a style? Something like :ref:`evaluated <func:eval>`?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27036>
_______________________________________

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: [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 04:00:42 2016
From: report at bugs.python.org (vishvajit pathak)
Date: Tue, 17 May 2016 08:00:42 +0000
Subject: [issue27046] Emoji support in Pie Chart legend with matplotlib
In-Reply-To: <1463471974.35.0.410853070824.issue27046@psf.upfronthosting.co.za>
Message-ID: <1463472042.44.0.247191276414.issue27046@psf.upfronthosting.co.za>


vishvajit pathak added the comment:

I am unable to find this support for showing emoji in legend while drawing the pie chart with matplotlib.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27046>
_______________________________________

From report at bugs.python.org  Tue May 17 04:07:17 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 17 May 2016 08:07:17 +0000
Subject: [issue27046] Emoji support in Pie Chart legend with matplotlib
In-Reply-To: <1463471974.35.0.410853070824.issue27046@psf.upfronthosting.co.za>
Message-ID: <1463472437.74.0.580166249529.issue27046@psf.upfronthosting.co.za>


Berker Peksag added the comment:

matplotlib is not part of the Python standard library. You can find my more information at http://matplotlib.org/

----------
nosy: +berker.peksag
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27046>
_______________________________________

From report at bugs.python.org  Tue May 17 06:55:19 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 17 May 2016 10:55:19 +0000
Subject: [issue23275] Can assign [] = (), but not () = []
In-Reply-To: <1421694347.87.0.147201508367.issue23275@psf.upfronthosting.co.za>
Message-ID: <1463482519.28.0.964810474734.issue23275@psf.upfronthosting.co.za>


Martin Panter added the comment:

Hi Berker. I updated your patch according to my comments in the documentation. I hope you don?t mind.

I reverted all the changes about subscripting and slicing an iterable, since this bug is only about assigning to a ?target list?.

Actually it is true (despite the current documentation) that you can often assign

sequence[slice] = iterable

But I think that is a separate problem.

----------
Added file: http://bugs.python.org/file42878/issue23275_v4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23275>
_______________________________________

From report at bugs.python.org  Tue May 17 07:03:14 2016
From: report at bugs.python.org (Charalampos Stratakis)
Date: Tue, 17 May 2016 11:03:14 +0000
Subject: [issue23420] python -m cProfile -s fails with non informative message
In-Reply-To: <1423483542.47.0.873331461969.issue23420@psf.upfronthosting.co.za>
Message-ID: <1463482994.53.0.79697678435.issue23420@psf.upfronthosting.co.za>


Charalampos Stratakis added the comment:

Any info regarding that? Patch seems good and it actually works.

----------
nosy: +cstratak

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23420>
_______________________________________

From report at bugs.python.org  Tue May 17 08:37:05 2016
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 17 May 2016 12:37:05 +0000
Subject: [issue1222585] C++ compilation support for distutils
Message-ID: <1463488625.92.0.159959118492.issue1222585@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan at bytereef.org>:


----------
nosy: +skrah
versions: +Python 3.5, Python 3.6 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1222585>
_______________________________________

From report at bugs.python.org  Tue May 17 09:58:20 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 17 May 2016 13:58:20 +0000
Subject: [issue25910] Fixing links in documentation
In-Reply-To: <1463431251.07.0.158605697058.issue25910@psf.upfronthosting.co.za>
Message-ID: <20160517135814.GA44955@K2047>


Senthil Kumaran added the comment:

On Mon, May 16, 2016 at 08:40:51PM +0000, Serhiy Storchaka wrote:
> > zope should be http://www.zope.org/
> 
> Isn't this is a different legal entity?

Is it? I don't know. I can find no references to zope.com being
different than zope.org in my google searches and from wikipedia
article.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25910>
_______________________________________

From report at bugs.python.org  Tue May 17 11:34:09 2016
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 17 May 2016 15:34:09 +0000
Subject: [issue27036] Mark up of references in different form
In-Reply-To: <1463387629.05.0.783453150634.issue27036@psf.upfronthosting.co.za>
Message-ID: <1463499249.61.0.669833099164.issue27036@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Not really, no. You have to add a :ref: target label for the function. If it's only a few instances, that should be manageable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27036>
_______________________________________

From report at bugs.python.org  Tue May 17 12:07:56 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 17 May 2016 16:07:56 +0000
Subject: [issue22377] %Z in strptime doesn't match EST and others
In-Reply-To: <1410301455.57.0.912701656833.issue22377@psf.upfronthosting.co.za>
Message-ID: <1463501276.03.0.0776022619437.issue22377@psf.upfronthosting.co.za>


R. David Murray added the comment:

Peter: yes, that is what I've been saying this issue is for :)  Anything else is a new issue.

Note that it *does* also recognize the strings in time.tzname in addition to UTC and GMT.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22377>
_______________________________________

From report at bugs.python.org  Tue May 17 12:08:08 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 17 May 2016 16:08:08 +0000
Subject: [issue22377] %Z in strptime doesn't match EST and others
In-Reply-To: <1410301455.57.0.912701656833.issue22377@psf.upfronthosting.co.za>
Message-ID: <1463501288.75.0.0930431802228.issue22377@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
versions: +Python 3.5, Python 3.6 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22377>
_______________________________________

From report at bugs.python.org  Tue May 17 12:10:24 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 17 May 2016 16:10:24 +0000
Subject: [issue27045] Forward slashes in Windows paths
In-Reply-To: <1463448805.55.0.933820705649.issue27045@psf.upfronthosting.co.za>
Message-ID: <1463501424.07.0.422986543699.issue27045@psf.upfronthosting.co.za>


R. David Murray added the comment:

Since windows users expect them to be backslahes, though, what's the motivation for using forward slashes instead?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27045>
_______________________________________

From report at bugs.python.org  Tue May 17 12:19:47 2016
From: report at bugs.python.org (Tim Golden)
Date: Tue, 17 May 2016 16:19:47 +0000
Subject: [issue27045] Forward slashes in Windows paths
In-Reply-To: <1463501424.07.0.422986543699.issue27045@psf.upfronthosting.co.za>
Message-ID: <573B449A.4010304@timgolden.me.uk>


Tim Golden added the comment:

I haven't tested everywhere but some versions of Windows don't in fact 
accept forward slashes on the cmd.exe command line. Suggest changing to 
backslashes as there's no reason to do otherwise.

----------
nosy: +tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27045>
_______________________________________

From report at bugs.python.org  Tue May 17 12:25:27 2016
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 17 May 2016 16:25:27 +0000
Subject: [issue27045] Forward slashes in Windows paths
In-Reply-To: <1463448805.55.0.933820705649.issue27045@psf.upfronthosting.co.za>
Message-ID: <1463502327.09.0.00933466791243.issue27045@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
assignee:  -> docs at python
resolution: not a bug -> 
stage: resolved -> needs patch
status: closed -> open
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27045>
_______________________________________

From report at bugs.python.org  Tue May 17 12:29:18 2016
From: report at bugs.python.org (Tim Peters)
Date: Tue, 17 May 2016 16:29:18 +0000
Subject: [issue27045] Forward slashes in Windows paths
In-Reply-To: <1463448805.55.0.933820705649.issue27045@psf.upfronthosting.co.za>
Message-ID: <1463502558.39.0.441251755831.issue27045@psf.upfronthosting.co.za>


Tim Peters added the comment:

All versions of cmd.exe want backslashes in paths for the commands implemented _by_ cmd.exe - those interpret a forward slash as indicating an option.  For example, here on Win10 Pro:

C:\WINDOWS\system32>dir c:\Windows\System32\xwreg.dll
 Volume in drive C is OS
 Volume Serial Number is 5E8B-CFAC

 Directory of c:\Windows\System32

10/30/2015  02:17 AM           120,320 xwreg.dll
               1 File(s)        120,320 bytes
               0 Dir(s)  2,880,244,813,824 bytes free

`dir` is implemented by cmd.exe, so that example doesn't work with forward slashes:

C:\WINDOWS\system32>dir c:/Windows/System32/xwreg.dll
Parameter format not correct - "Windows".

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27045>
_______________________________________

From report at bugs.python.org  Tue May 17 12:35:06 2016
From: report at bugs.python.org (Tim Golden)
Date: Tue, 17 May 2016 16:35:06 +0000
Subject: [issue27045] Forward slashes in Windows paths
In-Reply-To: <1463502558.39.0.441251755831.issue27045@psf.upfronthosting.co.za>
Message-ID: <573B4832.4040206@timgolden.me.uk>


Tim Golden added the comment:

The key point here is that if I run the example as given on my Win 8.1 
box, it doesn't work. (The venv I'm using is called nw0).

d:\tim\.venvs>dir nw0\Scripts\activate.bat
  Volume in drive D is New Volume
  Volume Serial Number is 2639-22DA

  Directory of d:\tim\.venvs\nw0\Scripts

30/03/2016  07:45               547 activate.bat
                1 File(s)            547 bytes
                0 Dir(s)  458,354,536,448 bytes free

d:\tim\.venvs>
d:\tim\.venvs>nw0/Scripts/activate.bat
'nw0' is not recognized as an internal or external command,
operable program or batch file.

d:\tim\.venvs>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27045>
_______________________________________

From report at bugs.python.org  Tue May 17 15:41:41 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 17 May 2016 19:41:41 +0000
Subject: [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: [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 16:09:20 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Tue, 17 May 2016 20:09:20 +0000
Subject: [issue27048] Breakages in subprocess.Popen with non-ascii characters
 in environment
In-Reply-To: <1463515752.85.0.457941663559.issue27048@psf.upfronthosting.co.za>
Message-ID: <1463515760.56.0.592620163081.issue27048@psf.upfronthosting.co.za>


Changes by Emanuel Barry <barry at dadadata.net>:


Added file: http://bugs.python.org/file42881/subprocess_distutils_errors_1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27048>
_______________________________________

From report at bugs.python.org  Tue May 17 16:33:28 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 17 May 2016 20:33:28 +0000
Subject: [issue27048] Breakages in subprocess.Popen with non-ascii characters
 in environment
In-Reply-To: <1463515752.85.0.457941663559.issue27048@psf.upfronthosting.co.za>
Message-ID: <1463517208.24.0.0191760760114.issue27048@psf.upfronthosting.co.za>


R. David Murray added the comment:

I would not think errors=replace would be the right answer...that would lose information, wouldn't it?  What is the data being used for that causes the problem?  Normally in situations like this we'd use surrogateescape at the system boundary, but I don't know enough about distutils to know if that is the right answer.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27048>
_______________________________________

From report at bugs.python.org  Tue May 17 16:38:24 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Tue, 17 May 2016 20:38:24 +0000
Subject: [issue27048] Breakages in subprocess.Popen with non-ascii characters
 in environment
In-Reply-To: <1463515752.85.0.457941663559.issue27048@psf.upfronthosting.co.za>
Message-ID: <1463517504.91.0.66335851395.issue27048@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

The data that causes the issue is my name (?manuel), which is present in a couple of places in my environment. I also completely forgot about surrogateescape, my bad. Here are two new patches with the surrogateescape error handler instead of the replace one.

----------
Added file: http://bugs.python.org/file42882/subprocess_errors_simple_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27048>
_______________________________________

From report at bugs.python.org  Tue May 17 16:38:34 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Tue, 17 May 2016 20:38:34 +0000
Subject: [issue27048] Breakages in subprocess.Popen with non-ascii characters
 in environment
In-Reply-To: <1463515752.85.0.457941663559.issue27048@psf.upfronthosting.co.za>
Message-ID: <1463517514.7.0.939107413604.issue27048@psf.upfronthosting.co.za>


Changes by Emanuel Barry <barry at dadadata.net>:


Added file: http://bugs.python.org/file42883/subprocess_distutils_errors_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27048>
_______________________________________

From report at bugs.python.org  Tue May 17 17:15:55 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 17 May 2016 21:15:55 +0000
Subject: [issue18410] Idle: test SearchDialog.py
In-Reply-To: <1373338807.5.0.870375456877.issue18410@psf.upfronthosting.co.za>
Message-ID: <1463519755.79.0.629431581868.issue18410@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
assignee:  -> terry.reedy
versions: +Python 3.6 -Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18410>
_______________________________________

From report at bugs.python.org  Tue May 17 17:17:13 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 May 2016 21:17:13 +0000
Subject: [issue27048] Breakages in subprocess.Popen with non-ascii characters
 in environment
In-Reply-To: <1463515752.85.0.457941663559.issue27048@psf.upfronthosting.co.za>
Message-ID: <1463519833.22.0.868230735333.issue27048@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Hi,

> I got a random UnicodeDecodeError while trying to install a module with distutils.

Please provide more context to your issue:

* What is your operating system?
* What is your locale? (locale encoding on UNIX, ANSI and OEM code pages on Windows)
* Where does the data come from?
* etc.

> subprocess_errors_simple_1.patch 

I don't think that it's ok to change the *default* error handler in the subprocess module.

Adding encoding/errors parameters to subprocess.Popen is an old topic: see for example the issue #6135.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27048>
_______________________________________

From report at bugs.python.org  Tue May 17 17:27:48 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Tue, 17 May 2016 21:27:48 +0000
Subject: [issue27048] Breakages in subprocess.Popen with non-ascii characters
 in environment
In-Reply-To: <1463515752.85.0.457941663559.issue27048@psf.upfronthosting.co.za>
Message-ID: <1463520468.67.0.163026138325.issue27048@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

Oops, I thought I had written that - must have accidentally deleted it. I'm on Windows 7, my locale is fr-CA / cp1252, and the non-ascii data (my name =) comes from my environment.

I discussed a bit with R. David Murray off-issue, and in the end it seems that it would be better to have subprocess accept parameters, but not do anything by default, and then have distutils pass these parameters.

Here is a new patch.

----------
Added file: http://bugs.python.org/file42884/subprocess_distutils_errors_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27048>
_______________________________________

From report at bugs.python.org  Tue May 17 18:19:28 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 May 2016 22:19:28 +0000
Subject: [issue18410] Idle: test SearchDialog.py
In-Reply-To: <1373338807.5.0.870375456877.issue18410@psf.upfronthosting.co.za>
Message-ID: <20160517221915.116830.78492.3BB1F3EF@psf.io>


Roundup Robot added the comment:

New changeset 2aee50cb27d0 by Terry Jan Reedy in branch '3.5':
Issue #18410: Test IDLE's search dialog; original patch by Westley Mart?nez.
https://hg.python.org/cpython/rev/2aee50cb27d0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18410>
_______________________________________

From report at bugs.python.org  Tue May 17 18:22:45 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 17 May 2016 22:22:45 +0000
Subject: [issue18410] Idle: test SearchDialog.py
In-Reply-To: <1373338807.5.0.870375456877.issue18410@psf.upfronthosting.co.za>
Message-ID: <1463523765.21.0.845163090196.issue18410@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I only made two changes to the test class itself: 1. move "requires('gui')" to the top to quit as soon as possible.  2. add "del class.root" to prevent exit error message.

Westley is already in misc.ACKS.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18410>
_______________________________________

From report at bugs.python.org  Tue May 17 18:30:16 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 May 2016 22:30:16 +0000
Subject: [issue27048] Breakages in subprocess.Popen with non-ascii characters
 in environment
In-Reply-To: <1463515752.85.0.457941663559.issue27048@psf.upfronthosting.co.za>
Message-ID: <1463524216.45.0.223080915271.issue27048@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Copy of https://gist.github.com/Vgr255/67fc0245056454d6a68608790a9d417b

E:\LGP_Test\LGP-0.1>py setup.py install
running install
running build
running build_ext
building 'lgp' extension
Traceback (most recent call last):
  File "setup.py", line 10, in <module>
    Extension("lgp", ["src/lgpmodule.c"]),
  File "E:\Python\3.5.0\lib\distutils\core.py", line 148, in setup
    dist.run_commands()
  File "E:\Python\3.5.0\lib\distutils\dist.py", line 955, in run_commands
    self.run_command(cmd)
  File "E:\Python\3.5.0\lib\distutils\dist.py", line 974, in run_command
    cmd_obj.run()
  File "E:\Python\3.5.0\lib\distutils\command\install.py", line 539, in run
    self.run_command('build')
  File "E:\Python\3.5.0\lib\distutils\cmd.py", line 313, in run_command
    self.distribution.run_command(command)
  File "E:\Python\3.5.0\lib\distutils\dist.py", line 974, in run_command
    cmd_obj.run()
  File "E:\Python\3.5.0\lib\distutils\command\build.py", line 135, in run
    self.run_command(cmd_name)
  File "E:\Python\3.5.0\lib\distutils\cmd.py", line 313, in run_command
    self.distribution.run_command(command)
  File "E:\Python\3.5.0\lib\distutils\dist.py", line 974, in run_command
    cmd_obj.run()
  File "E:\Python\3.5.0\lib\distutils\command\build_ext.py", line 338, in run
    self.build_extensions()
  File "E:\Python\3.5.0\lib\distutils\command\build_ext.py", line 447, in build_
extensions
    self._build_extensions_serial()
  File "E:\Python\3.5.0\lib\distutils\command\build_ext.py", line 472, in _build
_extensions_serial
    self.build_extension(ext)
  File "E:\Python\3.5.0\lib\distutils\command\build_ext.py", line 532, in build_
extension
    depends=ext.depends)
  File "E:\Python\3.5.0\lib\distutils\_msvccompiler.py", line 317, in compile
    self.initialize()
  File "E:\Python\3.5.0\lib\distutils\_msvccompiler.py", line 210, in initialize

    vc_env = _get_vc_env(plat_spec)
  File "E:\Python\3.5.0\lib\distutils\_msvccompiler.py", line 92, in _get_vc_env

    universal_newlines=True,
  File "E:\Python\3.5.0\lib\subprocess.py", line 629, in check_output
    **kwargs).stdout
  File "E:\Python\3.5.0\lib\subprocess.py", line 698, in run
    stdout, stderr = process.communicate(input, timeout=timeout)
  File "E:\Python\3.5.0\lib\subprocess.py", line 1055, in communicate
    stdout = self.stdout.read()
  File "E:\Python\3.5.0\lib\encodings\cp1252.py", line 23, in decode
    return codecs.charmap_decode(input,self.errors,decoding_table)[0]
UnicodeDecodeError: 'charmap' codec can't decode byte 0x90 in position 49: chara
cter maps to <undefined>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27048>
_______________________________________

From report at bugs.python.org  Tue May 17 18:35:52 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 May 2016 22:35:52 +0000
Subject: [issue18410] Idle: test SearchDialog.py
In-Reply-To: <1373338807.5.0.870375456877.issue18410@psf.upfronthosting.co.za>
Message-ID: <20160517223548.11491.56073.87F60C04@psf.io>


Roundup Robot added the comment:

New changeset a2cb99027646 by Terry Jan Reedy in branch '3.5':
Issue #18410: add missing parent argument.
https://hg.python.org/cpython/rev/a2cb99027646

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18410>
_______________________________________

From report at bugs.python.org  Tue May 17 18:37:48 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 May 2016 22:37:48 +0000
Subject: [issue27048] Breakages in subprocess.Popen with non-ascii characters
 in environment
In-Reply-To: <1463515752.85.0.457941663559.issue27048@psf.upfronthosting.co.za>
Message-ID: <1463524668.73.0.314246389098.issue27048@psf.upfronthosting.co.za>


STINNER Victor added the comment:

>  File "E:\Python\3.5.0\lib\distutils\_msvccompiler.py", line 92, in _get_vc_env
>    universal_newlines=True,

This function was added in Python 3.5 by the issue #23970: "Adds distutils._msvccompiler for new Visual Studio versions." (VS 2015, I guess). The module distutils._msvccompiler doesn't exist in Python 3.5.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27048>
_______________________________________

From report at bugs.python.org  Tue May 17 18:38:04 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 May 2016 22:38:04 +0000
Subject: [issue27048] Breakages in subprocess.Popen with non-ascii characters
 in environment
In-Reply-To: <1463515752.85.0.457941663559.issue27048@psf.upfronthosting.co.za>
Message-ID: <1463524684.03.0.126786425849.issue27048@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
components: +Distutils, Windows
nosy: +dstufft, eric.araujo, paul.moore, steve.dower, tim.golden, zach.ware
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27048>
_______________________________________

From report at bugs.python.org  Tue May 17 18:41:13 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 May 2016 22:41:13 +0000
Subject: [issue27048] Breakages in subprocess.Popen with non-ascii characters
 in environment
In-Reply-To: <1463515752.85.0.457941663559.issue27048@psf.upfronthosting.co.za>
Message-ID: <1463524873.07.0.615618111479.issue27048@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> The module distutils._msvccompiler doesn't exist in Python 3.5.

Oops, I mean: it *only* exists in Python 3.5 (and newer, it doesn't exist in Python 3.4).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27048>
_______________________________________

From report at bugs.python.org  Tue May 17 18:43:51 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 17 May 2016 22:43:51 +0000
Subject: [issue6135] subprocess seems to use local encoding and give no choice
In-Reply-To: <1243494524.57.0.870766192683.issue6135@psf.upfronthosting.co.za>
Message-ID: <1463525031.96.0.571691703392.issue6135@psf.upfronthosting.co.za>


Martin Panter added the comment:

This seems like a request for extra feature(s), rather than a bug report.

FWIW I agree with Victor?s hesitation in <https://bugs.python.org/issue6135#msg123024>. I doubt it is worth adding special support to have multiple pipes that all use text mode (universal_newlines=True) but with different encoding settings. If you really want this, just add an external TextIOWrapper, or string encoding:

process = Popen(command, stdin=PIPE, stdout=PIPE, ...)

# Manually wrap with TextIOWrapper. Probably risks deadlocking in the general case, due to buffering, so this is a bad idea IMO.
input_writer = io.TextIOWrapper(process.stdin, "iso-8859-1")
output_reader = io.TextIOWrapper(process.stdout, "utf-8")

# Better: use communicate(), or a custom select() loop or similar:
input_string = input_string.encode("iso-8859-1")
[output_string, _] = process.communicate(input_string)
output_string = output_string.decode("utf-8")

Also I?m not enthusiastic about adding encoding etc parameters for a single PIPE scenario. What is wrong with leaving it in binary mode in the Popen call, and encoding, decoding, or using TextIOWrapper as a separate step?

----------
type: behavior -> enhancement
versions: +Python 3.6 -Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6135>
_______________________________________

From report at bugs.python.org  Tue May 17 18:51:45 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 May 2016 22:51:45 +0000
Subject: [issue27048] Breakages in subprocess.Popen with non-ascii characters
 in environment
In-Reply-To: <1463515752.85.0.457941663559.issue27048@psf.upfronthosting.co.za>
Message-ID: <1463525505.92.0.126199728369.issue27048@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Python 3.4 has a similar function: query_vcvarsall() in Lib/distutils/msvc9compiler.py.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27048>
_______________________________________

From report at bugs.python.org  Tue May 17 19:04:01 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 17 May 2016 23:04:01 +0000
Subject: [issue27014] maximum recursion depth when using typing options
In-Reply-To: <1463144236.79.0.623590161328.issue27014@psf.upfronthosting.co.za>
Message-ID: <1463526241.33.0.236859580163.issue27014@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

See also https://github.com/python/mypy/issues/1546 -- possibly it's the same issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27014>
_______________________________________

From report at bugs.python.org  Tue May 17 19:07:38 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 17 May 2016 23:07:38 +0000
Subject: [issue27048] Breakages in subprocess.Popen with non-ascii characters
 in environment
In-Reply-To: <1463515752.85.0.457941663559.issue27048@psf.upfronthosting.co.za>
Message-ID: <1463526458.46.0.339830331521.issue27048@psf.upfronthosting.co.za>


Martin Panter added the comment:

IMO adding a Popen(errors=...) parameter would be a new feature for 3.6+ only. Also, the patch does not take the error handler into account when encoding and decoding multiple PIPEs in communicate().

I think it would be better to fix this bug in Lib/distutils/_msvccompiler.py only. The equivalent bug fix would look like:

out = subprocess.check_output(
    ...,
    stderr=subprocess.STDOUT,
    # No universal_newlines!
)
...
out = io.TextIOWrapper(io.BytesIO(out), errors="surrogateescape").read()

Or maybe a simpler version is sufficient: (I?m not familiar enough with the use case or Windows to say.)

out = out.decode("ascii", "surrogateescape")

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27048>
_______________________________________

From report at bugs.python.org  Tue May 17 19:14:52 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 17 May 2016 23:14:52 +0000
Subject: [issue27014] maximum recursion depth when using typing options
In-Reply-To: <1463144236.79.0.623590161328.issue27014@psf.upfronthosting.co.za>
Message-ID: <1463526892.09.0.0457407855106.issue27014@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Actually, see https://github.com/python/typing/issues/222 instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27014>
_______________________________________

From report at bugs.python.org  Tue May 17 19:20:30 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 May 2016 23:20:30 +0000
Subject: [issue27048] distutils._msvccompiler._get_vc_env() fails with
 UnicodeDecodeError if an env var is not encodable
In-Reply-To: <1463515752.85.0.457941663559.issue27048@psf.upfronthosting.co.za>
Message-ID: <1463527230.51.0.14242627675.issue27048@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
title: Breakages in subprocess.Popen with non-ascii characters in environment -> distutils._msvccompiler._get_vc_env() fails with UnicodeDecodeError if an env var is not encodable

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27048>
_______________________________________

From report at bugs.python.org  Tue May 17 19:21:38 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Tue, 17 May 2016 23:21:38 +0000
Subject: [issue27048] distutils._msvccompiler._get_vc_env() fails with
 UnicodeDecodeError if an env var is not encodable
In-Reply-To: <1463515752.85.0.457941663559.issue27048@psf.upfronthosting.co.za>
Message-ID: <1463527298.83.0.602423886117.issue27048@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

You are right Martin, this also fixes it, and it seems much less controversial :) Here you go.

----------
Added file: http://bugs.python.org/file42885/distutils_windows_non_ascii_1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27048>
_______________________________________

From report at bugs.python.org  Tue May 17 19:27:45 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 17 May 2016 23:27:45 +0000
Subject: [issue27048] distutils._msvccompiler._get_vc_env() fails with
 UnicodeDecodeError if an env var is not encodable
In-Reply-To: <1463515752.85.0.457941663559.issue27048@psf.upfronthosting.co.za>
Message-ID: <1463527665.57.0.994251478414.issue27048@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Ok, I now understood the issue: the distutils._msvccompiler._get_vc_env() functions runs the "C:\Program Files (x86)\Microsoft visual studio 14.0\VC\vcvarsall.bat" program in a shell and then run the "set" command in the same shell to retrieve environment variables set by the batch script.

Problem: The "set" program encodes Unicode environment variables to bytes to write them into stdout, but at least one environment variable is not encodable. (It's unclear to me which encoding is used: ANSI code page? OEM code page? It doesn't matter much.)

Windows provides a nice Unicode API to retrieve environment varaibles. Using the "set" program is the wrong approach to retrieve environment varaibles.

I suggest to replace the "set" program with a script Python script which dumps all environment variables as UTF-8. The script would use os.environ which uses the Windows Unicode API to retrieve environment variables directly as Unicode.

--

Using an error handler is the wrong option here. The root problem is that the "set" program replaces unencodable characters with junk. Trying to replace or ignore junk doesn't solve the problem. The Visual Studio environment variables can contains unencodable characters, we should be able to retrieve them as Unicode without using a very limited encoding like cp1252 codepage or any OEM code page.

--

Another option is to still use the set program, but completly skip variables which contain undecodable bytes. I dislike this option :-/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27048>
_______________________________________

From report at bugs.python.org  Tue May 17 19:58:35 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 17 May 2016 23:58:35 +0000
Subject: [issue21676] IDLE - Test Replace Dialog
In-Reply-To: <1402036595.31.0.93623743551.issue21676@psf.upfronthosting.co.za>
Message-ID: <20160517235831.28360.46137.3AC54956@psf.io>


Roundup Robot added the comment:

New changeset d8ed90a35505 by Terry Jan Reedy in branch '3.5':
Issue #21676: test IDLE replace dialog.  Original patch by Saimadhav Heblikar.
https://hg.python.org/cpython/rev/d8ed90a35505

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21676>
_______________________________________

From report at bugs.python.org  Tue May 17 19:58:56 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 17 May 2016 23:58:56 +0000
Subject: [issue6135] subprocess seems to use local encoding and give no choice
In-Reply-To: <1243494524.57.0.870766192683.issue6135@psf.upfronthosting.co.za>
Message-ID: <1463529536.63.0.793341853312.issue6135@psf.upfronthosting.co.za>


Martin Panter added the comment:

I added some review comments for Florian?s patches. Also, I suspect the code will not affect the text encoding when communicate() is used with multiple PIPE streams.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6135>
_______________________________________

From report at bugs.python.org  Tue May 17 20:05:51 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 18 May 2016 00:05:51 +0000
Subject: [issue21676] IDLE - Test Replace Dialog
In-Reply-To: <1402036595.31.0.93623743551.issue21676@psf.upfronthosting.co.za>
Message-ID: <1463529951.02.0.52898730159.issue21676@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The 'Theme changed' message is maddening.  I verified that is was not occurring without this patch.  I made sure all widgets were passed cls.root as master, and that all were delected.  Running the class with "def test_dummy(self): pass" and all other methods commented out did not result in the message.  So setup and teardown do not, in themselves, cause it.  Running the first test, test_simple up to the point where a replace function is caused did not trigger the message.  Running most any replace funcition does trigger.  The base dialog and search tests do not trigger, so merely creating an engine did not.  One new thing in replace test is tests using REs.

Anyway, pushed slightly modified files.  I am no longer backporting 'routine' patches to 2.7.

----------
assignee:  -> terry.reedy
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type:  -> enhancement
versions: +Python 3.6 -Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21676>
_______________________________________

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: [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  Tue May 17 21:46:31 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 May 2016 01:46:31 +0000
Subject: [issue27049] Typo in "The Python Language Reference" 7.11 --
 "individiual"
In-Reply-To: <1463533005.82.0.812822205208.issue27049@psf.upfronthosting.co.za>
Message-ID: <20160518014628.26077.99900.A82BB10A@psf.io>


Roundup Robot added the comment:

New changeset da67d32c2f74 by Ned Deily in branch '3.5':
Issue #27049: fix doc typo
https://hg.python.org/cpython/rev/da67d32c2f74

New changeset ba71905dd010 by Ned Deily in branch 'default':
Issue #27049: fix doc typo
https://hg.python.org/cpython/rev/ba71905dd010

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27049>
_______________________________________

From report at bugs.python.org  Tue May 17 21:48:30 2016
From: report at bugs.python.org (Ned Deily)
Date: Wed, 18 May 2016 01:48:30 +0000
Subject: [issue27049] Typo in "The Python Language Reference" 7.11 --
 "individiual"
In-Reply-To: <1463533005.82.0.812822205208.issue27049@psf.upfronthosting.co.za>
Message-ID: <1463536110.86.0.233039774468.issue27049@psf.upfronthosting.co.za>


Ned Deily added the comment:

Thanks for the report!  Fixed in 3.5 and later; Python 3.3 and 3.4 no longer receive documentation updates.

----------
nosy: +ned.deily
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type: behavior -> 
versions:  -Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27049>
_______________________________________

From report at bugs.python.org  Tue May 17 21:51:02 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 18 May 2016 01:51:02 +0000
Subject: [issue27047] O(1) deque indexing
In-Reply-To: <1463514100.28.0.824610562849.issue27047@psf.upfronthosting.co.za>
Message-ID: <1463536262.37.0.121322267514.issue27047@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Sorry Serhiy, I really don't want to do this.  Indexing is the least important part of the API and should not drive the overall structure.  This optimization is at odds with the design goal of a structure that is efficient at near end-points and is not intended to compete with lists which are supposed to be efficient for random access indexing.  The use cases for deques rarely use access by position anywhere are from the end-points, so in a way this is a false optimization that doesn't account for the intended use cases.  The core design has been stable for a very long time and I'm very happy with it as is.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27047>
_______________________________________

From report at bugs.python.org  Tue May 17 22:17:17 2016
From: report at bugs.python.org (Demur Rumed)
Date: Wed, 18 May 2016 02:17:17 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1463537837.53.0.694876680785.issue26647@psf.upfronthosting.co.za>


Changes by Demur Rumed <gunkmute at gmail.com>:


Removed file: http://bugs.python.org/file42835/wpy8.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Tue May 17 22:18:35 2016
From: report at bugs.python.org (Demur Rumed)
Date: Wed, 18 May 2016 02:18:35 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1463537915.35.0.146038760219.issue26647@psf.upfronthosting.co.za>


Demur Rumed added the comment:

I've replaced wpy8 which I uploaded a few days ago as the previous version had a blank line removed from dis.rst by accident

----------
Added file: http://bugs.python.org/file42886/wpy8.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Tue May 17 22:48:54 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 May 2016 02:48:54 +0000
Subject: [issue21939] IDLE - Test Percolator
In-Reply-To: <1404829186.29.0.812778916434.issue21939@psf.upfronthosting.co.za>
Message-ID: <20160518024850.26283.38035.F8378590@psf.io>


Roundup Robot added the comment:

New changeset eebccf05903e by Terry Jan Reedy in branch '3.5':
Issue #21939: Test IDLE percolator.  Original patch by Saimadhav Heblikar.
https://hg.python.org/cpython/rev/eebccf05903e

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21939>
_______________________________________

From report at bugs.python.org  Tue May 17 22:54:50 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 18 May 2016 02:54:50 +0000
Subject: [issue21939] IDLE - Test Percolator
In-Reply-To: <1404829186.29.0.812778916434.issue21939@psf.upfronthosting.co.za>
Message-ID: <1463540090.79.0.105606854176.issue21939@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Tal, thanks for the suggestions.  Saimadhav added tests for at least some of them.  Part of the difficulty in adding IDLE tests is that it is too easy to write tests to the code instead of the use of the code.  This is especially true when side-effects (changing a widget) are the main intended effect.  I plan to work more on the latter.

----------
assignee:  -> terry.reedy
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
type:  -> enhancement
versions: +Python 3.6 -Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21939>
_______________________________________

From report at bugs.python.org  Tue May 17 23:51:24 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 May 2016 03:51:24 +0000
Subject: [issue27045] Forward slashes in Windows paths
In-Reply-To: <1463448805.55.0.933820705649.issue27045@psf.upfronthosting.co.za>
Message-ID: <20160518035121.26085.87422.F9949422@psf.io>


Roundup Robot added the comment:

New changeset e6e35ff744fe by Senthil Kumaran in branch '3.5':
issue27045 - Use backslash in windows path to script file.
https://hg.python.org/cpython/rev/e6e35ff744fe

New changeset 2173063cbae8 by Senthil Kumaran in branch 'default':
merge from 3.5
https://hg.python.org/cpython/rev/2173063cbae8

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27045>
_______________________________________

From report at bugs.python.org  Tue May 17 23:53:15 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Wed, 18 May 2016 03:53:15 +0000
Subject: [issue27045] Forward slashes in Windows paths
In-Reply-To: <1463448805.55.0.933820705649.issue27045@psf.upfronthosting.co.za>
Message-ID: <1463543595.81.0.562102543128.issue27045@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

This is fixed and online docs will reflect it when they get built in their next build cycle. 

Thanks for the report.

----------
nosy: +orsenthil
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27045>
_______________________________________

From report at bugs.python.org  Wed May 18 00:52:42 2016
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 18 May 2016 04:52:42 +0000
Subject: [issue26331] Tokenizer: allow underscores for grouping in numeric
 literals
In-Reply-To: <1455126624.48.0.163167904941.issue26331@psf.upfronthosting.co.za>
Message-ID: <1463547162.8.0.563112603167.issue26331@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Thanks Eric!

Serhiy, do you want to do a review? The v6/v7 patches are based on your "strict" patch with the constructor changes adapted from v4.

New version v7 addresses the review comments from Stefan and Martin.

----------
Added file: http://bugs.python.org/file42887/numeric_underscores_final_v7.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26331>
_______________________________________

From report at bugs.python.org  Wed May 18 00:52:56 2016
From: report at bugs.python.org (Daniel Stokes)
Date: Wed, 18 May 2016 04:52:56 +0000
Subject: [issue26536] Add the SIO_LOOPBACK_FAST_PATH option to socket.ioctl
In-Reply-To: <1457666128.63.0.278319184112.issue26536@psf.upfronthosting.co.za>
Message-ID: <1463547176.21.0.376905721149.issue26536@psf.upfronthosting.co.za>


Daniel Stokes added the comment:

Thank you for the review. I have made the changes suggested in the code and I have uploaded a new patch.

----------
Added file: http://bugs.python.org/file42888/loopback_fast_path_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26536>
_______________________________________

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: [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:14:24 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 18 May 2016 05:14:24 +0000
Subject: [issue23342] run() - unified high-level interface for subprocess
In-Reply-To: <1422483218.99.0.771753896574.issue23342@psf.upfronthosting.co.za>
Message-ID: <1463548464.04.0.0817115442393.issue23342@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

This change has made the subprocess docs intimidating and unapproachable again - this is a *LOWER* level swiss-army knife API than the 3 high level convenience functions.

I've filed http://bugs.python.org/issue27050 to suggest changing the way this is documented to position run() as a mid-tier API that's more flexible than the high level API, but still more convenient than accessing subprocess.Popen directly.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23342>
_______________________________________

From report at bugs.python.org  Wed May 18 01:29:52 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 18 May 2016 05:29:52 +0000
Subject: [issue27050] Demote run() below the high level APIs in subprocess docs
In-Reply-To: <1463548305.72.0.232219818049.issue27050@psf.upfronthosting.co.za>
Message-ID: <1463549392.34.0.631952313047.issue27050@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Likely revised structure:

* Move the high level convenience API back to the first section under a subheading like "Common operations"

* Give the new run() function its own subheading like "Flexible command invocation"

* Move the exception definitions to the Exceptions subheading

* give the stream constants their own subheading after "Frequently Used Arguments"

* consider whether or not the "Using the subprocess module" heading level is worthwhile, or whether it makes more sense to pull all its subheading up one level

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
stage:  -> needs patch
type:  -> enhancement
versions: +Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27050>
_______________________________________

From report at bugs.python.org  Wed May 18 01:44:23 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 May 2016 05:44:23 +0000
Subject: [issue23275] Can assign [] = (), but not () = []
In-Reply-To: <1421694347.87.0.147201508367.issue23275@psf.upfronthosting.co.za>
Message-ID: <20160518054420.28522.76669.D0BD4EFC@psf.io>


Roundup Robot added the comment:

New changeset 8a0754fed986 by Berker Peksag in branch 'default':
Issue #23275: Allow () = iterable assignment syntax
https://hg.python.org/cpython/rev/8a0754fed986

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23275>
_______________________________________

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: [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 01:48:24 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 18 May 2016 05:48:24 +0000
Subject: [issue23275] Can assign [] = (), but not () = []
In-Reply-To: <1421694347.87.0.147201508367.issue23275@psf.upfronthosting.co.za>
Message-ID: <1463550504.87.0.516910644724.issue23275@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks Martin. Your edits look much better! :) I will be travelling for PyCon US later this week so I just committed issue23275_v4.diff with minor edits.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23275>
_______________________________________

From report at bugs.python.org  Wed May 18 02:08:56 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 18 May 2016 06:08:56 +0000
Subject: [issue6135] subprocess seems to use local encoding and give no choice
In-Reply-To: <1243494524.57.0.870766192683.issue6135@psf.upfronthosting.co.za>
Message-ID: <1463551736.76.0.456870656666.issue6135@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Since this issue was first filed, the "opener" parameter was added to the open() builtin: https://docs.python.org/3/library/functions.html#open

I mention that, as the problem there is similar to the problem here: wanting to construct a buffered text-mode interface, but with a different stream at the lowest layer (whatever "opener" returns for the builtin open(), the implicitly created pipes for the subprocess module).

To answer Martin's question about "Why not just wrap things manually?", the main issue with that is that it doesn't work for the check_output helper function - to get text out of that, currently your only option is to enable universal newlines and trust that the output is encoded as UTF-8 (which is fortunately often a valid assumption on modern systems).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6135>
_______________________________________

From report at bugs.python.org  Wed May 18 02:35:15 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 18 May 2016 06:35:15 +0000
Subject: [issue23420] python -m cProfile -s fails with non informative message
In-Reply-To: <1423483542.47.0.873331461969.issue23420@psf.upfronthosting.co.za>
Message-ID: <1463553315.87.0.0746260682638.issue23420@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Patch looks good to me, but we need a test case.

----------
type: enhancement -> behavior
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23420>
_______________________________________

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: [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 02:45:42 2016
From: report at bugs.python.org (Steven Barker)
Date: Wed, 18 May 2016 06:45:42 +0000
Subject: [issue12920] inspect.getsource only works for objects loaded from
 files, not interactive session
In-Reply-To: <1315334278.72.0.69534403863.issue12920@psf.upfronthosting.co.za>
Message-ID: <1463553942.36.0.456366811333.issue12920@psf.upfronthosting.co.za>


Steven Barker added the comment:

The problem being discussed here just came up on Stack Overflow today: http://stackoverflow.com/questions/37288135/inspect-module-for-python/

The cause of the incorrect error message is pretty clear. The relevant code from `inspect.getfile` should do something better when the object has a `__module__` attribute, but the module named (when looked up in `sys.modules`) does not have a `__file__` attribute. Currently it says the module is a builtin class, which is total nonsense.

A very basic fix would be to have an extra error case:

    if isclass(object):
        if hasattr(object, '__module__'):
            object = sys.modules.get(object.__module__)
            if hasattr(object, '__file__'):
                return object.__file__
            raise TypeError()              # need a relevant message here!!!
        raise TypeError('{!r} is a built-in class'.format(object))

It might be easier to make a meaningful message if the code after the first `if` didn't overwrite `object` with the module.

But, really, it would be nice to figure out a better fix, which would make the relevant inspect functions actually work for classes defined interactively in the `__main__` module.

----------
nosy: +Steven.Barker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12920>
_______________________________________

From report at bugs.python.org  Wed May 18 03:19:57 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 May 2016 07:19:57 +0000
Subject: [issue23275] Can assign [] = (), but not () = []
In-Reply-To: <1421694347.87.0.147201508367.issue23275@psf.upfronthosting.co.za>
Message-ID: <20160518071950.28362.17006.4FBD2A34@psf.io>


Roundup Robot added the comment:

New changeset d3a75daf61e1 by Martin Panter in branch 'default':
Issue #23275: Don?t think this made it into alpha 1
https://hg.python.org/cpython/rev/d3a75daf61e1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23275>
_______________________________________

From report at bugs.python.org  Wed May 18 03:22:20 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 18 May 2016 07:22:20 +0000
Subject: [issue23275] Can assign [] = (), but not () = []
In-Reply-To: <1421694347.87.0.147201508367.issue23275@psf.upfronthosting.co.za>
Message-ID: <1463556140.78.0.606713151605.issue23275@psf.upfronthosting.co.za>


Martin Panter added the comment:

I just moved the NEWS entry under the alpha 2 heading.

For patches I am going to commit myself, I usually write the NEWS beforehand and remember to adjust it when committing. But perhaps I shouldn?t have done that in this case :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23275>
_______________________________________

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: [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 03:48:10 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 18 May 2016 07:48:10 +0000
Subject: [issue27050] Demote run() below the high level APIs in subprocess docs
In-Reply-To: <1463548305.72.0.232219818049.issue27050@psf.upfronthosting.co.za>
Message-ID: <1463557690.38.0.216692400809.issue27050@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

FWIW i consider the whole subprocess module doc to be pretty unapproachable and in need of refactoring.  Your suggestions sound like good ones.  We should sit down and make it sane at pycon.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27050>
_______________________________________

From report at bugs.python.org  Wed May 18 04:08:41 2016
From: report at bugs.python.org (Thomas Kluyver)
Date: Wed, 18 May 2016 08:08:41 +0000
Subject: [issue27050] Demote run() below the high level APIs in subprocess docs
In-Reply-To: <1463548305.72.0.232219818049.issue27050@psf.upfronthosting.co.za>
Message-ID: <1463558921.57.0.714348440551.issue27050@psf.upfronthosting.co.za>


Thomas Kluyver added the comment:

I'm obviously biased, but I find the 'high level convenience API' less convenient than the run() function: there are three different functions for the same basic operation, they're not clearly named (check_output is nothing to do with checking output), and there are things that should be simple but they can only do awkwardly (i.e. capturing both output and the exit code).

Once I can depend on Python >= 3.5, I hope to never use call/check_call/check_output again. Using run() might make code slightly longer, but I think it also makes it clearer. I accept that the trio can probably never be removed, but this is why I demoted them a long way down the docs.

Unfortunately I won't be at PyCon this year to discuss this.

----------
nosy: +takluyver

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27050>
_______________________________________

From report at bugs.python.org  Wed May 18 04:21:05 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 May 2016 08:21:05 +0000
Subject: [issue26331] Tokenizer: allow underscores for grouping in numeric
 literals
In-Reply-To: <1455126624.48.0.163167904941.issue26331@psf.upfronthosting.co.za>
Message-ID: <1463559665.68.0.421428760115.issue26331@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Added comments on Rietveld.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26331>
_______________________________________

From report at bugs.python.org  Wed May 18 04:27:03 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 18 May 2016 08:27:03 +0000
Subject: [issue6135] subprocess seems to use local encoding and give no choice
In-Reply-To: <1243494524.57.0.870766192683.issue6135@psf.upfronthosting.co.za>
Message-ID: <1463560023.44.0.844871707607.issue6135@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is a tested illustration of how I would suggest to manually handle encoding with check_output():

>>> text_input = "?"
>>> args = ("iconv", "--from-code", "ISO_8859-1", "--to-code", "UTF-8")
>>> bytes_output = check_output(args, input=text_input.encode("iso-8859-1"))
>>> bytes_output
b'\xc2\xa9'
>>> bytes_output.decode("utf-8")
'?'

If you wanted actual universal newline translation (which is more than plain text encoding), it would be more complicated, but still possible.

But I am not hugely against adding new ?encoding? and ?errors? parameters. The reasons against are that I don?t see it as necessary, and there are already a lot of subprocess-specific options to wade through.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6135>
_______________________________________

From report at bugs.python.org  Wed May 18 06:34:26 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 18 May 2016 10:34:26 +0000
Subject: [issue26942] android: test_ctypes crashes on armv7
In-Reply-To: <1462290789.53.0.483745295219.issue26942@psf.upfronthosting.co.za>
Message-ID: <1463567666.82.0.181239544703.issue26942@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

The crash occurs at the same line that the crash reported in issue
#17786. Line 85 in ctypes/test/test_as_parameter.py was line 87 at changeset  ae5c4a9118b8a3f490f77f2084d46163ca229aef.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26942>
_______________________________________

From report at bugs.python.org  Wed May 18 06:55:36 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 May 2016 10:55:36 +0000
Subject: [issue27036] Mark up of references in different form
In-Reply-To: <1463387629.05.0.783453150634.issue27036@psf.upfronthosting.co.za>
Message-ID: <20160518105531.22475.90016.A213753F@psf.io>


Roundup Robot added the comment:

New changeset ef6d3a537cf5 by Serhiy Storchaka in branch '3.5':
Issue #27036: Fixed formatting references to "bytes-like object" in plural.
https://hg.python.org/cpython/rev/ef6d3a537cf5

New changeset d6b9a4c3f8ef by Serhiy Storchaka in branch 'default':
Issue #27036: Fixed formatting references to "bytes-like object" in plural.
https://hg.python.org/cpython/rev/d6b9a4c3f8ef

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27036>
_______________________________________

From report at bugs.python.org  Wed May 18 06:59:54 2016
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 18 May 2016 10:59:54 +0000
Subject: [issue26331] Tokenizer: allow underscores for grouping in numeric
 literals
In-Reply-To: <1455126624.48.0.163167904941.issue26331@psf.upfronthosting.co.za>
Message-ID: <1463569194.34.0.47345150169.issue26331@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Thanks, Georg! The decimal parts look good to me. I understand that
people wonder about the relaxed rules for Decimal -- we have discussed
that here:

    https://mail.python.org/pipermail/python-dev/2016-March/143557.html


I don't think that it will be a problem in practice.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26331>
_______________________________________

From report at bugs.python.org  Wed May 18 07:14:52 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 May 2016 11:14:52 +0000
Subject: [issue27036] Mark up of references in different form
In-Reply-To: <1463387629.05.0.783453150634.issue27036@psf.upfronthosting.co.za>
Message-ID: <1463570092.87.0.262496210007.issue27036@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Pushed a part about "bytes-like objects".

Here is a patch that adds explicit labels for referencing without changing the style.

----------
Added file: http://bugs.python.org/file42890/refs_forms3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27036>
_______________________________________

From report at bugs.python.org  Wed May 18 07:47:01 2016
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 18 May 2016 11:47:01 +0000
Subject: [issue26750] Mock autospec does not work with subclasses of property()
In-Reply-To: <1460585586.67.0.646853664072.issue26750@psf.upfronthosting.co.za>
Message-ID: <1463572021.94.0.609899520189.issue26750@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

Updated patch with review comments.

----------
Added file: http://bugs.python.org/file42891/mock-descriptor-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26750>
_______________________________________

From report at bugs.python.org  Wed May 18 07:49:07 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 18 May 2016 11:49:07 +0000
Subject: [issue26750] Mock autospec does not work with subclasses of property()
In-Reply-To: <1460585586.67.0.646853664072.issue26750@psf.upfronthosting.co.za>
Message-ID: <1463572147.65.0.317529592187.issue26750@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
assignee:  -> berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26750>
_______________________________________

From report at bugs.python.org  Wed May 18 09:02:24 2016
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 18 May 2016 13:02:24 +0000
Subject: [issue27052] Python2.7.11+ as in Debian testing and Ubuntu 16.04 LTS
 crashes with segfault
In-Reply-To: <1463553501.27.0.152340887562.issue27052@psf.upfronthosting.co.za>
Message-ID: <1463576544.73.0.546169730027.issue27052@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
nosy: +doko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27052>
_______________________________________

From report at bugs.python.org  Wed May 18 10:01:38 2016
From: report at bugs.python.org (Oscar Andres Alvarez Montero)
Date: Wed, 18 May 2016 14:01:38 +0000
Subject: [issue26049] Poor performance when reading large xmlrpc data
In-Reply-To: <1452260198.15.0.426497706706.issue26049@psf.upfronthosting.co.za>
Message-ID: <1463580098.16.0.837352233527.issue26049@psf.upfronthosting.co.za>


Changes by Oscar Andres Alvarez Montero <oscar.alvarez.montero at gmail.com>:


----------
nosy: +Oscar Andres Alvarez Montero

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26049>
_______________________________________

From report at bugs.python.org  Wed May 18 10:23:40 2016
From: report at bugs.python.org (R. David Murray)
Date: Wed, 18 May 2016 14:23:40 +0000
Subject: [issue27050] Demote run() below the high level APIs in subprocess docs
In-Reply-To: <1463548305.72.0.232219818049.issue27050@psf.upfronthosting.co.za>
Message-ID: <1463581420.21.0.59859503516.issue27050@psf.upfronthosting.co.za>


R. David Murray added the comment:

Just as a data point, I always found it confusing when viewing the subprocess docs that I had to page past the 'convenience functions' to get to what I consider to be the "real" docs, the docs for Popen.  I rarely use the convenience functions; I find it harder to remember how they work than just using Popen, and in any case I usually end up writing an application-specific 'cmd' function that uses Popen.  I haven't tried using run yet, so I don't really have an opinion on that.

I suppose its like carrying a swiss army knife in your pocket rather than carrying a steak knife, a pair of scissors, and a screwdriver.
If you were carrying a toolbox with *all* the tools, it might be different, but your choices are three tools or the swiss army knife, and to make matters worse those individual tools are really just the swiss army knife in disguise, but it looks different enough to be confusing.

Maybe having table of links at the start of the doc would be the most helpful, regardless of how the docs are re-organized.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27050>
_______________________________________

From report at bugs.python.org  Wed May 18 10:57:49 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 18 May 2016 14:57:49 +0000
Subject: [issue26942] android: test_ctypes crashes on armv7
In-Reply-To: <1462290789.53.0.483745295219.issue26942@psf.upfronthosting.co.za>
Message-ID: <1463583469.27.0.889745110533.issue26942@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Running the following interactive statements [1]:

>>> import unittest, ctypes.test.test_as_parameter
>>> unittest.main(module=ctypes.test.test_as_parameter, defaultTest='BasicWrapTestCase', verbosity=2)

The corresponding attached gdb session:

(gdb) continue
Continuing.

Program received signal SIGSEGV, Segmentation fault.
0xb6a181a0 in ?? ()
(gdb) bt 7
#0  0xb6a181a0 in ?? ()
#1  0xb605de7a in _testfunc_callback_i_if (value=-10, func=0xb6a181a0)
    at cpython/Modules/_ctypes/_ctypes_test.c:234
#2  0xb6072238 in ffi_call_SYSV ()
    at cpython/Modules/_ctypes/libffi/src/arm/sysv.S:188
#3  0xb6072a52 in ffi_call (cif=cif at entry=0xbe91ac04, 
    fn=fn at entry=0xb605de6d <_testfunc_callback_i_if>, rvalue=rvalue at entry=0xbe91ac88, 
    avalue=avalue at entry=0xbe91ac78)
    at cpython/Modules/_ctypes/libffi/src/arm/ffi.c:339
#4  0xb606e2a0 in _call_function_pointer (flags=flags at entry=-1240871416, 
    pProc=0xb605de6d <_testfunc_callback_i_if>, pProc at entry=0xb606956b <PyCFuncPtr_call+350>, 
    avalues=avalues at entry=0xbe91ac78, atypes=atypes at entry=0xbe91ac68, restype=0xb60db8e0, 
    resmem=resmem at entry=0xbe91ac88, argcount=argcount at entry=2)
    at cpython/Modules/_ctypes/callproc.c:811
#5  0xb606e894 in _ctypes_callproc (pProc=pProc at entry=0xb605de6d <_testfunc_callback_i_if>, 
    argtuple=argtuple at entry=(<AsParamPropertyWrapper(_param=-10) at remote 0xb5f012d8>, <AsParamPropertyWrapper(_param=<CFunctionType at remote 0xb5ef5c70>) at remote 0xb5ef1fc0>), 
    flags=<optimized out>, argtypes=argtypes at entry=0x0, restype=<optimized out>, 
    restype at entry=<_ctypes.PyCSimpleType at remote 0xb6097228>, checker=checker at entry=0x0)
    at cpython/Modules/_ctypes/callproc.c:1149
#6  0xb606956a in PyCFuncPtr_call (self=0xb5ef5e90, inargs=<optimized out>, kwds=<optimized out>)
    at cpython/Modules/_ctypes/_ctypes.c:3856
(More stack frames follow...)
(gdb) up
#1  0xb605de7a in _testfunc_callback_i_if (value=-10, func=0xb6a181a0)
    at cpython/Modules/_ctypes/_ctypes_test.c:234
234	        sum += func(value);
(gdb) list
229	
230	EXPORT(int) _testfunc_callback_i_if(int value, int (*func)(int))
231	{
232	    int sum = 0;
233	    while (value != 0) {
234	        sum += func(value);
235	        value /= 2;
236	    }
237	    return sum;
238	}
(gdb) p func
$2 = (int (*)(int)) 0xb6a181a0
(gdb) disassemble func
No function contains specified address.
(gdb)


[1] Gdb is attached after the import statement because gdb fails with SIGILL in __dl_notify_gdb_of_libraries both with arm and armv7, whenever a library is loaded. This is gdb from the Android ndk started by ndk-gdb.py from the r11c ndk. A workaround is to add the following lines in the gdbinit script:
    break __dl_rtld_db_dlactivity
    commands
    silent
    return
    sharedlibrary
    continue
    end

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26942>
_______________________________________

From report at bugs.python.org  Wed May 18 11:39:05 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 18 May 2016 15:39:05 +0000
Subject: [issue27014] maximum recursion depth when using typing options
In-Reply-To: <1463144236.79.0.623590161328.issue27014@psf.upfronthosting.co.za>
Message-ID: <20160518153856.107565.46633.6F46914C@psf.io>


Roundup Robot added the comment:

New changeset 79197e60e441 by Guido van Rossum in branch '3.5':
Fix #27014 -- infinite recursion using typing.py.
https://hg.python.org/cpython/rev/79197e60e441

New changeset a6c04626205f by Guido van Rossum in branch 'default':
Fix #27014 -- infinite recursion using typing.py. (Merge 3.5 -> 3.6.)
https://hg.python.org/cpython/rev/a6c04626205f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27014>
_______________________________________

From report at bugs.python.org  Wed May 18 11:40:13 2016
From: report at bugs.python.org (Guo, Jiahua)
Date: Wed, 18 May 2016 15:40:13 +0000
Subject: [issue26617] Assertion failed in gc with __del__ and weakref
In-Reply-To: <1458713339.87.0.171873505456.issue26617@psf.upfronthosting.co.za>
Message-ID: <1463586013.54.0.481292340903.issue26617@psf.upfronthosting.co.za>


Changes by Guo, Jiahua <gjhdgm at gmail.com>:


Added file: http://bugs.python.org/file42892/patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26617>
_______________________________________

From report at bugs.python.org  Wed May 18 11:46:14 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 18 May 2016 15:46:14 +0000
Subject: [issue27014] maximum recursion depth when using typing options
In-Reply-To: <1463144236.79.0.623590161328.issue27014@psf.upfronthosting.co.za>
Message-ID: <1463586374.12.0.583773524983.issue27014@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Thanks to Kalle Tuure for the fix!

----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27014>
_______________________________________

From report at bugs.python.org  Wed May 18 12:37:53 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 18 May 2016 16:37:53 +0000
Subject: [issue23958] compile warnings in libffi
In-Reply-To: <1429043048.03.0.90246390985.issue23958@psf.upfronthosting.co.za>
Message-ID: <1463589473.84.0.529469642449.issue23958@psf.upfronthosting.co.za>


Berker Peksag added the comment:

A slightly different version of the patch is now part of upstream libffi: https://github.com/libffi/libffi/commit/4a677a425c18eda4bc5357b2485da57f133f908d

Thanks for the report Steve.

----------
nosy: +berker.peksag
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23958>
_______________________________________

From report at bugs.python.org  Wed May 18 13:31:06 2016
From: report at bugs.python.org (Sriram Rajagopalan)
Date: Wed, 18 May 2016 17:31:06 +0000
Subject: [issue26779] pdb continue followed by an exception in the same frame
 shows incorrect frame linenumber
In-Reply-To: <1460812092.64.0.640871964672.issue26779@psf.upfronthosting.co.za>
Message-ID: <1463592666.74.0.138584389738.issue26779@psf.upfronthosting.co.za>


Sriram Rajagopalan added the comment:

ping

----------
nosy: +bglsriram

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26779>
_______________________________________

From report at bugs.python.org  Wed May 18 15:39:13 2016
From: report at bugs.python.org (Camilla Montonen)
Date: Wed, 18 May 2016 19:39:13 +0000
Subject: [issue26329] os.path.normpath("//") returns //
In-Reply-To: <1455116285.45.0.915370101527.issue26329@psf.upfronthosting.co.za>
Message-ID: <1463600353.69.0.149765359707.issue26329@psf.upfronthosting.co.za>


Changes by Camilla Montonen <camillamon at gmail.com>:


----------
nosy: +Winterflower

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26329>
_______________________________________

From report at bugs.python.org  Wed May 18 15:40:37 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 18 May 2016 19:40:37 +0000
Subject: [issue26549] co_stacksize is calculated from unoptimized code
In-Reply-To: <1457822745.22.0.972836245522.issue26549@psf.upfronthosting.co.za>
Message-ID: <1463600437.43.0.449477793618.issue26549@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
type:  -> performance

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26549>
_______________________________________

From report at bugs.python.org  Wed May 18 15:51:22 2016
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 18 May 2016 19:51:22 +0000
Subject: [issue27052] Python2.7.11+ as in Debian testing and Ubuntu 16.04 LTS
 crashes with segfault
In-Reply-To: <1463553501.27.0.152340887562.issue27052@psf.upfronthosting.co.za>
Message-ID: <1463601082.38.0.874864490967.issue27052@psf.upfronthosting.co.za>


Matthias Klose added the comment:

2.7.11+ translates to 20160330 from the 2.7 branch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27052>
_______________________________________

From report at bugs.python.org  Wed May 18 16:11:31 2016
From: report at bugs.python.org (Camilla Montonen)
Date: Wed, 18 May 2016 20:11:31 +0000
Subject: [issue25926] problems with "times" keyword in itertools.repeat
In-Reply-To: <1450806036.21.0.954073881918.issue25926@psf.upfronthosting.co.za>
Message-ID: <1463602291.59.0.965241440971.issue25926@psf.upfronthosting.co.za>


Camilla Montonen added the comment:

Should 'roughly equivalent to' be added as a note to the docs?

----------
nosy: +Winterflower

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25926>
_______________________________________

From report at bugs.python.org  Wed May 18 16:14:53 2016
From: report at bugs.python.org (lorenzogotuned)
Date: Wed, 18 May 2016 20:14:53 +0000
Subject: [issue27051] Create PIP gui
In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za>
Message-ID: <1463602493.84.0.0676089571447.issue27051@psf.upfronthosting.co.za>


Changes by lorenzogotuned <tunedconsulting at gmail.com>:


----------
nosy: +lorenzogotuned

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27051>
_______________________________________

From report at bugs.python.org  Wed May 18 16:17:00 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 18 May 2016 20:17:00 +0000
Subject: [issue25926] problems with "times" keyword in itertools.repeat
In-Reply-To: <1450806036.21.0.954073881918.issue25926@psf.upfronthosting.co.za>
Message-ID: <1463602620.24.0.955400055389.issue25926@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka at gmail.com>:


----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25926>
_______________________________________

From report at bugs.python.org  Wed May 18 16:18:05 2016
From: report at bugs.python.org (Camilla Montonen)
Date: Wed, 18 May 2016 20:18:05 +0000
Subject: [issue25548] Show the address in the repr for class objects
In-Reply-To: <1446576011.58.0.372024983976.issue25548@psf.upfronthosting.co.za>
Message-ID: <1463602685.58.0.85251895675.issue25548@psf.upfronthosting.co.za>


Changes by Camilla Montonen <camillamon at gmail.com>:


----------
nosy: +Winterflower

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25548>
_______________________________________

From report at bugs.python.org  Wed May 18 16:34:25 2016
From: report at bugs.python.org (Camilla Montonen)
Date: Wed, 18 May 2016 20:34:25 +0000
Subject: [issue25941] Add 'How to Review a Patch' section to devguide
In-Reply-To: <1450992057.28.0.358724589512.issue25941@psf.upfronthosting.co.za>
Message-ID: <1463603665.41.0.232010390624.issue25941@psf.upfronthosting.co.za>


Camilla Montonen added the comment:

Thank you very much for your comments. I have cleaned up the previous patch and merged it with the Lifecycle of a Patch article.

----------
Added file: http://bugs.python.org/file42893/patchreview18May.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25941>
_______________________________________

From report at bugs.python.org  Wed May 18 16:41:12 2016
From: report at bugs.python.org (Camilla Montonen)
Date: Wed, 18 May 2016 20:41:12 +0000
Subject: [issue26329] os.path.normpath("//") returns //
In-Reply-To: <1455116285.45.0.915370101527.issue26329@psf.upfronthosting.co.za>
Message-ID: <1463604072.69.0.950512425502.issue26329@psf.upfronthosting.co.za>


Camilla Montonen added the comment:

Should the comment with the link to specification be added to Lib/posixpath.py? or Lib/os.py?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26329>
_______________________________________

From report at bugs.python.org  Wed May 18 16:45:39 2016
From: report at bugs.python.org (Camilla Montonen)
Date: Wed, 18 May 2016 20:45:39 +0000
Subject: [issue19695] Clarify how to use various import-related locks
In-Reply-To: <1385133456.35.0.294583357802.issue19695@psf.upfronthosting.co.za>
Message-ID: <1463604339.86.0.856638714885.issue19695@psf.upfronthosting.co.za>


Changes by Camilla Montonen <camillamon at gmail.com>:


----------
nosy: +Winterflower

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19695>
_______________________________________

From report at bugs.python.org  Wed May 18 16:51:45 2016
From: report at bugs.python.org (Camilla Montonen)
Date: Wed, 18 May 2016 20:51:45 +0000
Subject: [issue20847] asyncio docs should call out that network logging is a
 no-no
In-Reply-To: <1393877540.32.0.826428021059.issue20847@psf.upfronthosting.co.za>
Message-ID: <1463604705.18.0.960935868493.issue20847@psf.upfronthosting.co.za>


Changes by Camilla Montonen <camillamon at gmail.com>:


----------
nosy: +Winterflower

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20847>
_______________________________________

From report at bugs.python.org  Wed May 18 17:02:29 2016
From: report at bugs.python.org (Camilla Montonen)
Date: Wed, 18 May 2016 21:02:29 +0000
Subject: [issue20041] TypeError when f_trace is None and tracing.
In-Reply-To: <1387634487.03.0.628100767515.issue20041@psf.upfronthosting.co.za>
Message-ID: <1463605349.78.0.529990840393.issue20041@psf.upfronthosting.co.za>


Changes by Camilla Montonen <camillamon at gmail.com>:


----------
nosy: +Winterflower

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20041>
_______________________________________

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: [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 19:50:29 2016
From: report at bugs.python.org (Ned Deily)
Date: Wed, 18 May 2016 23:50:29 +0000
Subject: [issue27054] Python installation problem: No module named 'encodings'
In-Reply-To: <45B64D1540141C4AA0F8F3974D714AEA64D3D93D@S197.admin.wpi.edu>
Message-ID: <1463615429.36.0.523932174319.issue27054@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
components: +Installation, Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
versions: +Python 3.5

_______________________________________
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: [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  Wed May 18 21:17:50 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 19 May 2016 01:17:50 +0000
Subject: [issue25926] problems with "times" keyword in itertools.repeat
In-Reply-To: <1450806036.21.0.954073881918.issue25926@psf.upfronthosting.co.za>
Message-ID: <1463620670.75.0.191985857044.issue25926@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I'm okay with changing the docs to "roughly equivalent to".  That will help prevent the occasional misreading as "precisely equivalent in every respect".

----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25926>
_______________________________________

From report at bugs.python.org  Wed May 18 21:36:51 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 19 May 2016 01:36:51 +0000
Subject: [issue27050] Demote run() below the high level APIs in subprocess docs
In-Reply-To: <1463548305.72.0.232219818049.issue27050@psf.upfronthosting.co.za>
Message-ID: <1463621811.03.0.321573194108.issue27050@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

For reference, http://bugs.python.org/issue13237 covers the original change to emphasise the convenience functions over the full flexibility of Popen. The intent behind that reorganisation was to make it straightforward to get started with the module without needing to first learn what a pipe is (or much of anything about command invocation other than the value of breaking things up into lists to ensure correct quoting). The direct link to the Popen docs in the introductory text was intended to make it easy for advanced users to skip directly to the full Popen docs.

In that context, the three convenience operations are "I don't really care if this works or not", "complain loudly if this doesn't work" and "capture the command output, while complaining loudly if it doesn't work". (Not coincidentally, these are roughly comparable to the operations supported by Perl's system() command and backtick expressions, only with exceptions taking the place of the "$?" magic variable)

Once a user understands what a pipe is well enough to have an opinion on the usefulness of operations other than the 3 basic ones, then I agree run() makes for a nice improvement over using Popen objects directly (thank you Thomas!), but it's still lower level than the convenience APIs (since you need more prior knowledge in order to use it effectively).

I do like David's suggestion of an introductory table providing quick links to the rest of the documentation. Something in the style of the itertools docs would likely be most suitable: https://docs.python.org/3/library/itertools.html

Also +1 on thrashing out the details at the PyCon US sprints, although I'll aim to put an initial draft together before then (so Thomas has a chance to comment on it)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27050>
_______________________________________

From report at bugs.python.org  Wed May 18 21:41:08 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 19 May 2016 01:41:08 +0000
Subject: [issue27050] Demote run() below the high level APIs in subprocess docs
In-Reply-To: <1463548305.72.0.232219818049.issue27050@psf.upfronthosting.co.za>
Message-ID: <1463622068.63.0.516238787264.issue27050@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

As long as I'm refactoring these docs, I may also take a look at adding some notes about text vs binary handling, since that's still problematic as described in http://bugs.python.org/issue6135

The default behaviour is binary pipes, and setting "universal_newlines=True" switches to UTF-8 encoded text pipes, but anything else involves using binary pipes with separate encoding and decoding steps.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27050>
_______________________________________

From report at bugs.python.org  Thu May 19 00:26:42 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 19 May 2016 04:26:42 +0000
Subject: [issue22570] Better stdlib support for Path objects
In-Reply-To: <1412609631.43.0.978086278536.issue22570@psf.upfronthosting.co.za>
Message-ID: <1463632002.97.0.570153352195.issue22570@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

PEP 519 is accepted now. We need to revert the commits from http://bugs.python.org/issue22570#msg257634

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22570>
_______________________________________

From report at bugs.python.org  Thu May 19 00:27:51 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 19 May 2016 04:27:51 +0000
Subject: [issue22570] Better stdlib support for Path objects
In-Reply-To: <1412609631.43.0.978086278536.issue22570@psf.upfronthosting.co.za>
Message-ID: <1463632071.07.0.23683910308.issue22570@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

And those from http://bugs.python.org/issue22570#msg257632 (these are the actual code -- the others were the docs).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22570>
_______________________________________

From report at bugs.python.org  Thu May 19 00:52:35 2016
From: report at bugs.python.org (Daniel Stokes)
Date: Thu, 19 May 2016 04:52:35 +0000
Subject: [issue26536] Add the SIO_LOOPBACK_FAST_PATH option to socket.ioctl
In-Reply-To: <1457666128.63.0.278319184112.issue26536@psf.upfronthosting.co.za>
Message-ID: <1463633555.09.0.512195529591.issue26536@psf.upfronthosting.co.za>


Daniel Stokes added the comment:

I have added a zip containing a simple server and client to test the patch with. With loopback fast path enabled, I get 3-5x more throughput on my Windows 10 computer with an AMD 900 series chipset.

----------
Added file: http://bugs.python.org/file42895/loopback_fast_path_test.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26536>
_______________________________________

From report at bugs.python.org  Thu May 19 01:01:24 2016
From: report at bugs.python.org (Nirbheek Chauhan)
Date: Thu, 19 May 2016 05:01:24 +0000
Subject: [issue22040] Add a "force" parameter to shutil.rmtree
In-Reply-To: <1406058870.67.0.270826115135.issue22040@psf.upfronthosting.co.za>
Message-ID: <1463634084.76.0.0235976137605.issue22040@psf.upfronthosting.co.za>


Nirbheek Chauhan added the comment:

> In other words, on unix shutil.rmtree is *already* 'rm -rf'.

This is not true. See:

  $ mkdir testdir && chmod 200 testdir && ls -lhd testdir
  d-w------- 2 nirbheek nirbheek 4.0K May 19 10:21 testdir

`rm -rf` works fine on this. But shutil.rmtree borks:

$ python3 -c 'import shutil; shutil.rmtree("testdir")'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib64/python3.5/shutil.py", line 470, in rmtree
    onerror(os.lstat, path, sys.exc_info())
  File "/usr/lib64/python3.5/shutil.py", line 468, in rmtree
    fd = os.open(path, os.O_RDONLY)
PermissionError: [Errno 13] Permission denied: 'testdir'

The -f option to `rm` ensures that it tries its hardest to resolve permissions problems and does not error out if it can't resolve them either. The latter is available via 'ignore_errors', but the former is a missing feature. A shutil.rmtree flag that 'resolves permissions' would be useful on all platforms. Not just Windows.

----------
nosy: +Nirbheek Chauhan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22040>
_______________________________________

From report at bugs.python.org  Thu May 19 01:36:02 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 19 May 2016 05:36:02 +0000
Subject: [issue26536] Add the SIO_LOOPBACK_FAST_PATH option to socket.ioctl
In-Reply-To: <1457666128.63.0.278319184112.issue26536@psf.upfronthosting.co.za>
Message-ID: <1463636162.33.0.41510807413.issue26536@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the test script. I left some minor comments about loopback_fast_path_v2.patch on Rietveld.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26536>
_______________________________________

From report at bugs.python.org  Thu May 19 01:53:05 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 May 2016 05:53:05 +0000
Subject: [issue27055] python fails to run zipapp when zip contains comments
In-Reply-To: <1463619864.57.0.781907137117.issue27055@psf.upfronthosting.co.za>
Message-ID: <1463637185.83.0.43866141388.issue27055@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is a duplicate of issue5950.

----------
nosy: +serhiy.storchaka
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Make zipimport work with zipfile containing comments

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27055>
_______________________________________

From report at bugs.python.org  Thu May 19 02:18:55 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 May 2016 06:18:55 +0000
Subject: [issue27037] Universal newline support for zipFile.ZipExtFile.read()
 is not working (deprecated?),
 and the missing functionality not documented
In-Reply-To: <1463410014.02.0.132222711737.issue27037@psf.upfronthosting.co.za>
Message-ID: <1463638735.62.0.072354229024.issue27037@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The support of the "U" mode will be removed in 3.6 (issue27029).

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27037>
_______________________________________

From report at bugs.python.org  Thu May 19 02:46:06 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 May 2016 06:46:06 +0000
Subject: [issue20699] Document that binary IO classes work with bytes-likes
 objects
In-Reply-To: <1392889792.36.0.922412998797.issue20699@psf.upfronthosting.co.za>
Message-ID: <1463640366.64.0.831493517524.issue20699@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Added few minor comments on Rietveld.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20699>
_______________________________________

From report at bugs.python.org  Thu May 19 04:14:10 2016
From: report at bugs.python.org (Palm Kevin)
Date: Thu, 19 May 2016 08:14:10 +0000
Subject: [issue17408] second python execution fails when embedding
In-Reply-To: <1363183794.27.0.643296851621.issue17408@psf.upfronthosting.co.za>
Message-ID: <1463645650.31.0.31815246051.issue17408@psf.upfronthosting.co.za>


Changes by Palm Kevin <kevin.palm at labsolution.lu>:


----------
nosy: +palm.kevin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17408>
_______________________________________

From report at bugs.python.org  Thu May 19 04:32:43 2016
From: report at bugs.python.org (Denny Weinberg)
Date: Thu, 19 May 2016 08:32:43 +0000
Subject: [issue17408] second python execution fails when embedding
In-Reply-To: <1363183794.27.0.643296851621.issue17408@psf.upfronthosting.co.za>
Message-ID: <1463646763.96.0.980759988256.issue17408@psf.upfronthosting.co.za>


Denny Weinberg added the comment:

Hi,

I think that the problem exists also in python 3.5.1

After calling Py_Finalize and Py_Initialize I get the message "attribute of type 'NoneType' is not callable" on the datetime.strptime method.

Example:
from datetime import datetime
s = '20160505 160000'
refdatim = datetime.strptime(s, '%Y%m%d %H%M%S')

The first call works find but it crashes after the re initialization.

Workaround:
from datetime import datetime
s = '20160505 160000'
try:
    refdatim = datetime.strptime(s, '%Y%m%d %H%M%S')
except TypeError:
    import time
    refdatim = datetime.fromtimestamp(time.mktime(time.strptime(s, '%Y%m%d %H%M%S')))

Can anyone confirm this bug? Can you tell me if this will be fixed for python 3.5/3.6/...?

All the other modules are working find after the re initialization but datetime.strptime.

----------
nosy: +Denny Weinberg
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17408>
_______________________________________

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: [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: [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 08:54:28 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 May 2016 12:54:28 +0000
Subject: [issue27057] os.set_inheritable(): fall back to fcntl() if ioctl()
 fails with EACCES
In-Reply-To: <1463660156.43.0.991763402804.issue27057@psf.upfronthosting.co.za>
Message-ID: <1463662468.55.0.286852576207.issue27057@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Hum, I'm surprised that SELinux blocks such safe function. Maybe the SELinux policy should be completed to allow it?

Detect when ioctl() fails with EACCESS and fallback to fnctl() sounds like a good option. But do you expect ioctl() to always fail with EACCESS? Or only fail sometimes, or only on some file descriptors? Your patch remembers that ioctl() fails once and never retries.

About your patch: please add a comment explaining why you fallback with a reference to this issue ("Issue #27057").

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27057>
_______________________________________

From report at bugs.python.org  Thu May 19 09:15:00 2016
From: report at bugs.python.org (Hugh C. Lauer)
Date: Thu, 19 May 2016 13:15:00 +0000
Subject: [issue27054] Python installation problem: No module named 'encodings'
In-Reply-To: <1463615429.38.0.428225244543.issue27054@psf.upfronthosting.co.za>
Message-ID: <45B64D1540141C4AA0F8F3974D714AEA64D3F296@S197.admin.wpi.edu>


Hugh C. Lauer added the comment:

Upon further investigation, I find lots of encodings in the folder C:\Program Files\Python35\Lib\encodings\ and lots of compiled encodings in the subfolder __pycache__ .

Somehow, these are not being found by Python itself, or there is something missing from the installation.

I investigated the registry. A search for "encodings" turns up lots of registry entries but none associated with Python.

Regards,

Hugh C. Lauer
Worcester Polytechnic Institute

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27054>
_______________________________________

From report at bugs.python.org  Thu May 19 09:30:46 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 May 2016 13:30:46 +0000
Subject: [issue26814] [WIP] Add a new _PyObject_FastCall() function which
 avoids the creation of a tuple or dict for arguments
In-Reply-To: <1461229041.59.0.994194592206.issue26814@psf.upfronthosting.co.za>
Message-ID: <1463664646.25.0.773910000579.issue26814@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Hi,

I made progress on my FASTCALL branch. I removed tp_fastnew, tp_fastinit and
tp_fastnew fields from PyTypeObject to replace them with new type flags (ex:
Py_TPFLAGS_FASTNEW) to avoid code duplication and reduce the memory footprint.
Before, each function was simply duplicated.

This change introduces a backward incompatibility change: it's not more
possible to call directly tp_new, tp_init and tp_call. I don't know yet if such
change would be acceptable in Python 3.6, nor if it is worth it.

I spent a lot of ot time on the CPython benchmark suite to check for
performance regression. In fact, I spent most of my time to try to understand
why most benchmarks looked completly unstable. I now tuned correctly my
system and patched perf.py to get reliable benchmarks.

On the latest run of the benchmark suite, most benchmarks are faster! I have to investigate why 3 benchmarks are still slower. In the run, normal_startup was not significant, etree_parse was faster (instead of slower), but raytrace was already slower (but only 1.13x slower). It may be the "noise" of the PGO compilation. I already noticed that once: see the issue #27056 "pickle: constant propagation in _Unpickler_Read()".

Result of the benchmark suite:

slower (3):

* raytrace: 1.06x slower
* etree_parse: 1.03x slower
* normal_startup: 1.02x slower

faster (18):

* unpickle_list: 1.11x faster
* chameleon_v2: 1.09x faster
* etree_generate: 1.08x faster
* etree_process: 1.08x faster
* mako_v2: 1.06x faster
* call_method_unknown: 1.06x faster
* django_v3: 1.05x faster
* regex_compile: 1.05x faster
* etree_iterparse: 1.05x faster
* fastunpickle: 1.05x faster
* meteor_contest: 1.05x faster
* pickle_dict: 1.05x faster
* float: 1.04x faster
* pathlib: 1.04x faster
* silent_logging: 1.04x faster
* call_method: 1.03x faster
* json_dump_v2: 1.03x faster
* call_simple: 1.03x faster

not significant (21):

* 2to3
* call_method_slots
* chaos
* fannkuch
* fastpickle
* formatted_logging
* go
* json_load
* nbody
* nqueens
* pickle_list
* pidigits
* regex_effbot
* regex_v8
* richards
* simple_logging
* spectral_norm
* startup_nosite
* telco
* tornado_http
* unpack_sequence

I know that my patch is simply giant and cannot be merged like that.

Since the performance is still promising, I plan to split my giant
patch into smaller patches, easier to review. I will try to check that
individual patches don't make Python slower. This work will take time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26814>
_______________________________________

From report at bugs.python.org  Thu May 19 09:35:17 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 May 2016 13:35:17 +0000
Subject: [issue26814] [WIP] Add a new _PyObject_FastCall() function which
 avoids the creation of a tuple or dict for arguments
In-Reply-To: <1461229041.59.0.994194592206.issue26814@psf.upfronthosting.co.za>
Message-ID: <1463664917.86.0.0774856189493.issue26814@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


Added file: http://bugs.python.org/file42898/34456cce64bb.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26814>
_______________________________________

From report at bugs.python.org  Thu May 19 09:36:19 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 May 2016 13:36:19 +0000
Subject: [issue26814] [WIP] Add a new _PyObject_FastCall() function which
 avoids the creation of a tuple or dict for arguments
In-Reply-To: <1461229041.59.0.994194592206.issue26814@psf.upfronthosting.co.za>
Message-ID: <1463664979.38.0.020192630239.issue26814@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


Removed file: http://bugs.python.org/file42898/34456cce64bb.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26814>
_______________________________________

From report at bugs.python.org  Thu May 19 09:38:10 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 May 2016 13:38:10 +0000
Subject: [issue27056] pickle: constant propagation in _Unpickler_Read()
In-Reply-To: <1463659349.35.0.28600421781.issue27056@psf.upfronthosting.co.za>
Message-ID: <1463665090.83.0.130711387168.issue27056@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

+1. Similar optimization is used in marshal.

Added comments on Rietveld.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27056>
_______________________________________

From report at bugs.python.org  Thu May 19 09:38:19 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 May 2016 13:38:19 +0000
Subject: [issue26814] [WIP] Add a new _PyObject_FastCall() function which
 avoids the creation of a tuple or dict for arguments
In-Reply-To: <1461229041.59.0.994194592206.issue26814@psf.upfronthosting.co.za>
Message-ID: <1463665099.84.0.782491496974.issue26814@psf.upfronthosting.co.za>


STINNER Victor added the comment:

New patch: 34456cce64bb.patch

$ diffstat 34456cce64bb.patch 
 .hgignore                                     |    3 
 Makefile.pre.in                               |   37 
 b/Doc/includes/shoddy.c                       |    2 
 b/Include/Python.h                            |    1 
 b/Include/abstract.h                          |   17 
 b/Include/descrobject.h                       |   14 
 b/Include/funcobject.h                        |    6 
 b/Include/methodobject.h                      |    6 
 b/Include/modsupport.h                        |   20 
 b/Include/object.h                            |   28 
 b/Lib/json/encoder.py                         |    1 
 b/Lib/test/test_extcall.py                    |   19 
 b/Lib/test/test_sys.py                        |    6 
 b/Modules/_collectionsmodule.c                |   14 
 b/Modules/_csv.c                              |   15 
 b/Modules/_ctypes/_ctypes.c                   |   12 
 b/Modules/_ctypes/stgdict.c                   |    2 
 b/Modules/_datetimemodule.c                   |   47 
 b/Modules/_elementtree.c                      |   11 
 b/Modules/_functoolsmodule.c                  |  113 +-
 b/Modules/_io/clinic/_iomodule.c.h            |    8 
 b/Modules/_io/clinic/bufferedio.c.h           |   42 
 b/Modules/_io/clinic/bytesio.c.h              |   42 
 b/Modules/_io/clinic/fileio.c.h               |   26 
 b/Modules/_io/clinic/iobase.c.h               |   26 
 b/Modules/_io/clinic/stringio.c.h             |   34 
 b/Modules/_io/clinic/textio.c.h               |   40 
 b/Modules/_io/iobase.c                        |    4 
 b/Modules/_json.c                             |   24 
 b/Modules/_lsprof.c                           |    4 
 b/Modules/_operator.c                         |   11 
 b/Modules/_pickle.c                           |  106 -
 b/Modules/_posixsubprocess.c                  |   15 
 b/Modules/_sre.c                              |   11 
 b/Modules/_ssl.c                              |    9 
 b/Modules/_testbuffer.c                       |    4 
 b/Modules/_testcapimodule.c                   |    4 
 b/Modules/_threadmodule.c                     |   32 
 b/Modules/_tkinter.c                          |   11 
 b/Modules/arraymodule.c                       |   29 
 b/Modules/cjkcodecs/clinic/multibytecodec.c.h |   50 
 b/Modules/clinic/_bz2module.c.h               |    8 
 b/Modules/clinic/_codecsmodule.c.h            |  318 +++--
 b/Modules/clinic/_cryptmodule.c.h             |   10 
 b/Modules/clinic/_datetimemodule.c.h          |    8 
 b/Modules/clinic/_dbmmodule.c.h               |   26 
 b/Modules/clinic/_elementtree.c.h             |   86 -
 b/Modules/clinic/_gdbmmodule.c.h              |   26 
 b/Modules/clinic/_lzmamodule.c.h              |   16 
 b/Modules/clinic/_opcode.c.h                  |   10 
 b/Modules/clinic/_pickle.c.h                  |   34 
 b/Modules/clinic/_sre.c.h                     |  124 +-
 b/Modules/clinic/_ssl.c.h                     |   74 -
 b/Modules/clinic/_tkinter.c.h                 |   50 
 b/Modules/clinic/_winapi.c.h                  |  124 +-
 b/Modules/clinic/arraymodule.c.h              |   34 
 b/Modules/clinic/audioop.c.h                  |  210 ++-
 b/Modules/clinic/binascii.c.h                 |   36 
 b/Modules/clinic/cmathmodule.c.h              |   24 
 b/Modules/clinic/fcntlmodule.c.h              |   34 
 b/Modules/clinic/grpmodule.c.h                |   14 
 b/Modules/clinic/md5module.c.h                |    8 
 b/Modules/clinic/posixmodule.c.h              |  642 ++++++-----
 b/Modules/clinic/pyexpat.c.h                  |   32 
 b/Modules/clinic/sha1module.c.h               |    8 
 b/Modules/clinic/sha256module.c.h             |   14 
 b/Modules/clinic/sha512module.c.h             |   14 
 b/Modules/clinic/signalmodule.c.h             |   50 
 b/Modules/clinic/unicodedata.c.h              |   42 
 b/Modules/clinic/zlibmodule.c.h               |   68 -
 b/Modules/itertoolsmodule.c                   |   20 
 b/Modules/main.c                              |    2 
 b/Modules/pyexpat.c                           |    3 
 b/Modules/signalmodule.c                      |    9 
 b/Modules/xxsubtype.c                         |    4 
 b/Objects/abstract.c                          |  403 ++++---
 b/Objects/bytesobject.c                       |    2 
 b/Objects/classobject.c                       |   36 
 b/Objects/clinic/bytearrayobject.c.h          |   90 -
 b/Objects/clinic/bytesobject.c.h              |   66 -
 b/Objects/clinic/dictobject.c.h               |   10 
 b/Objects/clinic/unicodeobject.c.h            |   10 
 b/Objects/descrobject.c                       |  162 +-
 b/Objects/dictobject.c                        |   26 
 b/Objects/enumobject.c                        |    8 
 b/Objects/exceptions.c                        |   91 +
 b/Objects/fileobject.c                        |   29 
 b/Objects/floatobject.c                       |   25 
 b/Objects/funcobject.c                        |   77 -
 b/Objects/genobject.c                         |    2 
 b/Objects/iterobject.c                        |    6 
 b/Objects/listobject.c                        |   20 
 b/Objects/longobject.c                        |   40 
 b/Objects/methodobject.c                      |  139 ++
 b/Objects/object.c                            |    4 
 b/Objects/odictobject.c                       |    2 
 b/Objects/rangeobject.c                       |   12 
 b/Objects/tupleobject.c                       |   21 
 b/Objects/typeobject.c                        | 1463 +++++++++++++++++++-------
 b/Objects/unicodeobject.c                     |   58 -
 b/Objects/weakrefobject.c                     |   22 
 b/PC/clinic/msvcrtmodule.c.h                  |   42 
 b/PC/clinic/winreg.c.h                        |  128 +-
 b/PC/clinic/winsound.c.h                      |   26 
 b/PCbuild/pythoncore.vcxproj                  |    4 
 b/Parser/tokenizer.c                          |    7 
 b/Python/ast.c                                |   31 
 b/Python/bltinmodule.c                        |  173 +--
 b/Python/ceval.c                              |  591 +++++++++-
 b/Python/clinic/bltinmodule.c.h               |  104 +
 b/Python/clinic/import.c.h                    |   18 
 b/Python/codecs.c                             |   17 
 b/Python/errors.c                             |  105 -
 b/Python/getargs.c                            |  284 ++++-
 b/Python/import.c                             |   27 
 b/Python/modsupport.c                         |  244 +++-
 b/Python/pythonrun.c                          |   10 
 b/Python/sysmodule.c                          |   32 
 b/Tools/clinic/clinic.py                      |  115 +-
 pystack.c                                     |  288 +++++
 pystack.h                                     |   64 +
 121 files changed, 5420 insertions(+), 2802 deletions(-)

----------
Added file: http://bugs.python.org/file42899/34456cce64bb.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26814>
_______________________________________

From report at bugs.python.org  Thu May 19 09:38:54 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 May 2016 13:38:54 +0000
Subject: [issue26814] [WIP] Add a new _PyObject_FastCall() function which
 avoids the creation of a tuple or dict for arguments
In-Reply-To: <1461229041.59.0.994194592206.issue26814@psf.upfronthosting.co.za>
Message-ID: <1463665134.36.0.597995034169.issue26814@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Status of the my FASTCALL implementation (34456cce64bb.patch):

* Add METH_FASTCALL calling convention to C functions, similar
  to METH_VARARGS|METH_KEYWORDS
* Clinic uses METH_FASTCALL when possible (it may use METH_FASTCALL
  for all cases in the future)
* Add new C functions:

  - _PyObject_FastCall(func, stack, nargs, kwds): root of the FASTCALL branch
  - PyObject_CallNoArg(func)
  - PyObject_CallArg1(func, arg)

* Add new type flags changing the calling conventions of tp_new, tp_init and
  tp_call:

  - Py_TPFLAGS_FASTNEW
  - Py_TPFLAGS_FASTINIT
  - Py_TPFLAGS_FASTCALL

* Backward incompatible change of Py_TPFLAGS_FASTNEW and Py_TPFLAGS_FASTINIT
  flags: calling explicitly type->tp_new() and type->tp_init() is now a bug
  and is likely to crash, since the calling convention can now be FASTCALL.

* New _PyType_CallNew() and _PyType_CallInit() functions to call tp_new and
  tp_init of a type. Functions which called tp_new and tp_init directly were
  patched.

* New helpers function to parse functions functions:

  - PyArg_ParseStack()
  - PyArg_ParseStackAndKeywords()
  - PyArg_UnpackStack()

* New Py_Build functons:

  - Py_BuildStack()
  - Py_VaBuildStack()

* New _PyStack API to handle a stack:

  - _PyStack_Alloc(), _PyStack_Free(), _PyStack_Copy()
  - _PyStack_FromTuple()
  - _PyStack_FromBorrowedTuple()
  - _PyStack_AsTuple(), _PyStack_AsTupleSlice()
  - ...

* Many changes were done in the typeobject.c file to handle FASTCALL, new
  type flags, handle correctly flags when a new type is created, etc.

* ceval.c: add _PyFunction_FastCall() function (somehow, I only exposed
  existing code)

A large part of the patch changes existing code to use the new calling
convention in many functions of many modules. Some changes were generated
by the Argument Clinic. IMHO the best would be to use Argument Clinic in more
places, rather than patching manually the code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26814>
_______________________________________

From report at bugs.python.org  Thu May 19 10:01:34 2016
From: report at bugs.python.org (=?utf-8?q?Micha=C5=82_Bednarski?=)
Date: Thu, 19 May 2016 14:01:34 +0000
Subject: [issue27057] os.set_inheritable(): fall back to fcntl() if ioctl()
 fails with EACCES
In-Reply-To: <1463660156.43.0.991763402804.issue27057@psf.upfronthosting.co.za>
Message-ID: <1463666494.01.0.269153716342.issue27057@psf.upfronthosting.co.za>


Micha? Bednarski added the comment:

> Hum, I'm surprised that SELinux blocks such safe function. Maybe the SELinux policy should be completed to allow it?
The ioctl is blocked for given file type regardless of request argument. As I'm running Python on non-rooted Android updating policy is not really an option.

> But do you expect ioctl() to always fail with EACCESS? Or only fail sometimes, or only on some file descriptors? Your patch remembers that ioctl() fails once and never retries.
It will always fail for given file type (such as sockets), while it will work for others (such as regular files). I think that remembering that ioctl doesn't work may be okay, though I may be wrong. Either way if we are wrong whenever ioctl works we'll do one extra syscall.

> About your patch: please add a comment explaining why you fallback with a reference to this issue ("Issue #27057").
Attached

----------
Added file: http://bugs.python.org/file42900/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 10:38:11 2016
From: report at bugs.python.org (Hugh C. Lauer)
Date: Thu, 19 May 2016 14:38:11 +0000
Subject: [issue27054] Python installation problem: No module named 'encodings'
In-Reply-To: <45B64D1540141C4AA0F8F3974D714AEA64D3F296@S197.admin.wpi.edu>
Message-ID: <45B64D1540141C4AA0F8F3974D714AEA64D3F9C4@S197.admin.wpi.edu>


Hugh C. Lauer added the comment:

On a hunch, I uninstalled Python 3.5.1 and reinstalled it for the current user only, to see if it would make a difference in the association of the encodings in the Registry.

There was no difference. The original error message still appears.

Regards,

Hugh C. Lauer
Worcester Polytechnic Institute

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27054>
_______________________________________

From report at bugs.python.org  Thu May 19 10:49:58 2016
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 19 May 2016 14:49:58 +0000
Subject: [issue27054] Python installation problem: No module named 'encodings'
In-Reply-To: <45B64D1540141C4AA0F8F3974D714AEA64D3D93D@S197.admin.wpi.edu>
Message-ID: <1463669398.91.0.875145076547.issue27054@psf.upfronthosting.co.za>


Stefan Krah added the comment:

I can only comment on the Windows 10 issue: I think I did the install
with "Right-click -> Run as administrator" and then installed for
all users.  Encodings, pip and everything else works here.

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27054>
_______________________________________

From report at bugs.python.org  Thu May 19 10:50:04 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 May 2016 14:50:04 +0000
Subject: [issue27057] os.set_inheritable(): fall back to fcntl() if ioctl()
 fails with EACCES
In-Reply-To: <1463660156.43.0.991763402804.issue27057@psf.upfronthosting.co.za>
Message-ID: <20160519144952.10321.50455.5A6269DC@psf.io>


Roundup Robot added the comment:

New changeset 13c5135d8467 by Victor Stinner in branch '3.5':
Fix os.set_inheritable() on Android
https://hg.python.org/cpython/rev/13c5135d8467

New changeset 783c1b8cdddb by Victor Stinner in branch 'default':
Merge 3.5 (issue #27057)
https://hg.python.org/cpython/rev/783c1b8cdddb

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27057>
_______________________________________

From report at bugs.python.org  Thu May 19 10:52:45 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 May 2016 14:52:45 +0000
Subject: [issue27057] os.set_inheritable(): fall back to fcntl() if ioctl()
 fails with EACCES
In-Reply-To: <1463660156.43.0.991763402804.issue27057@psf.upfronthosting.co.za>
Message-ID: <1463669565.89.0.971098717822.issue27057@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> The ioctl is blocked for given file type regardless of request argument. As I'm running Python on non-rooted Android updating policy is not really an option.

Oh. Right :-) My intent was to suggest to report the SELinux issue upstream ;-)

> It will always fail for given file type (such as sockets), while it will work for others (such as regular files). I think that remembering that ioctl doesn't work may be okay, though I may be wrong. Either way if we are wrong whenever ioctl works we'll do one extra syscall.

The purpose of using ioctl() is to *reduce* the number of syscalls. If an application mostly use sockets, it will do 3 syscalls per socket (ioctl, fcntl get, fcntl set) instead of just 2 (fcntl get, fcntl set) :-/ So I like your patch ;-)

I applied your fix to Python 3.5 and 3.6. Thanks for your contribution.

You should now sign the PSF Contributor Agreement:
https://www.python.org/psf/contrib/contrib-form/

(Well, in fact it would be better to do that *before* merging your change, but well, your change is short enough ;-))

----------
resolution:  -> fixed
status: open -> closed
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27057>
_______________________________________

From report at bugs.python.org  Thu May 19 10:55:14 2016
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 19 May 2016 14:55:14 +0000
Subject: [issue27054] Python installation problem: No module named 'encodings'
In-Reply-To: <45B64D1540141C4AA0F8F3974D714AEA64D3D93D@S197.admin.wpi.edu>
Message-ID: <1463669714.1.0.374417318273.issue27054@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Hugh, could you check your environment and see if you have any PYTHON* variables set, particularly PYTHONHOME?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27054>
_______________________________________

From report at bugs.python.org  Thu May 19 10:55:50 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 May 2016 14:55:50 +0000
Subject: [issue27054] Python installation problem: No module named 'encodings'
In-Reply-To: <45B64D1540141C4AA0F8F3974D714AEA64D3D93D@S197.admin.wpi.edu>
Message-ID: <1463669750.81.0.23171176504.issue27054@psf.upfronthosting.co.za>


STINNER Victor added the comment:

To list environment variable, you can open cmd.exe and type the command "set".

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27054>
_______________________________________

From report at bugs.python.org  Thu May 19 10:57:41 2016
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 19 May 2016 14:57:41 +0000
Subject: [issue27054] Python installation problem: No module named 'encodings'
In-Reply-To: <45B64D1540141C4AA0F8F3974D714AEA64D3D93D@S197.admin.wpi.edu>
Message-ID: <1463669861.18.0.366623553553.issue27054@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Also, I suspect your pip issue on Windows 10 is due to the fact that you need to either specify the --user flag or run pip as administrator, since your user account can't write to the global site-packages under Program Files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27054>
_______________________________________

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: [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 11:17:00 2016
From: report at bugs.python.org (=?utf-8?q?Micha=C5=82_Bednarski?=)
Date: Thu, 19 May 2016 15:17:00 +0000
Subject: [issue27057] os.set_inheritable(): fall back to fcntl() if ioctl()
 fails with EACCES
In-Reply-To: <1463660156.43.0.991763402804.issue27057@psf.upfronthosting.co.za>
Message-ID: <1463671020.07.0.886497233668.issue27057@psf.upfronthosting.co.za>


Micha? Bednarski added the comment:

> You should now sign the PSF Contributor Agreement
Done.

> (Well, in fact it would be better to do that *before* merging your change, but well, your change is short enough ;-))
Well on https://docs.python.org/devguide/patch.html was said "For non-trivial changes".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27057>
_______________________________________

From report at bugs.python.org  Thu May 19 11:52:53 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 19 May 2016 15:52:53 +0000
Subject: [issue15913] PyBuffer_SizeFromFormat is missing
In-Reply-To: <1347312444.09.0.484126652005.issue15913@psf.upfronthosting.co.za>
Message-ID: <1463673173.25.0.580467029223.issue15913@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
stage:  -> needs patch
versions: +Python 3.6 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15913>
_______________________________________

From report at bugs.python.org  Thu May 19 11:56:04 2016
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 19 May 2016 15:56:04 +0000
Subject: [issue27054] Python installation problem: No module named 'encodings'
In-Reply-To: <45B64D1540141C4AA0F8F3974D714AEA64D3D93D@S197.admin.wpi.edu>
Message-ID: <1463673364.87.0.464630969517.issue27054@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Here's some pretty compelling evidence for a bad PYTHONHOME setting:

C:\>set PYTHONHOME=C:\path\not\here

C:\>py -3.5
Fatal Python error: Py_Initialize: unable to load the file system codec
ImportError: No module named 'encodings'

Current thread 0x00001db4 (most recent call first):

C:\>set PYTHONHOME=C:\Python27\

C:\>py -3.5
Fatal Python error: Py_Initialize: unable to load the file system codec
  File "C:\Python27\\lib\encodings\__init__.py", line 123
    raise CodecRegistryError,\
                            ^
SyntaxError: invalid syntax

Current thread 0x00000664 (most recent call first):

C:\>set PYTHONHOME=

C:\>py -3.5
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.
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27054>
_______________________________________

From report at bugs.python.org  Thu May 19 11:59:15 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 May 2016 15:59:15 +0000
Subject: [issue27058] Tkinter's canvas' dashed lines have incorrect segment
 lengths
In-Reply-To: <1463670778.9.0.698531599823.issue27058@psf.upfronthosting.co.za>
Message-ID: <1463673555.75.0.180910597455.issue27058@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could you please test pure Tcl/Tk example?

----------
nosy: +serhiy.storchaka
Added file: http://bugs.python.org/file42902/canvas_dash.tcl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27058>
_______________________________________

From report at bugs.python.org  Thu May 19 12:16:03 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 May 2016 16:16:03 +0000
Subject: [issue27057] os.set_inheritable(): fall back to fcntl() if ioctl()
 fails with EACCES
In-Reply-To: <1463671020.07.0.886497233668.issue27057@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwaKDpJV_1pWj9rNt5FJm0O4kBQO9vaVipC6Qsnj18N7ZA@mail.gmail.com>


STINNER Victor added the comment:

>> You should now sign the PSF Contributor Agreement
>Done.

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27057>
_______________________________________

From report at bugs.python.org  Thu May 19 12:23:59 2016
From: report at bugs.python.org (Ben Spiller)
Date: Thu, 19 May 2016 16:23:59 +0000
Subject: [issue26369] unicode.decode and str.encode are unnecessarily
 confusing for non-ascii
In-Reply-To: <1455623938.04.0.928922751587.issue26369@psf.upfronthosting.co.za>
Message-ID: <1463675039.37.0.0219371069809.issue26369@psf.upfronthosting.co.za>


Ben Spiller added the comment:

btw If anyone can find the place in the code (sorry I tried and failed!) where str.encode('utf-8', error=X) is resulting in an implicit call to the equivalent of decode(defaultencoding, errors=strict) (as suggested by the exception message) I think it'll be easier to discuss the details of fixing.

Thanks for your reply - yes I'm aware that theoretically you _could_ globally change python's default encoding from ascii, but the prevailing view I've heard from python developers seems to be that changing it is not a good idea and may cause lots of library code to break. Also it's probably not a good idea for individual libraries or modules to be changing global state that affects the entire python invocation, and it would be nice to find a less fragile and more out-of-the-box solution to this. You may well be using different encodings (not just utf-8) to be used in different parts of your program - so changing the globally-defined default encoding doesn't seem right, especially for a method like str.encode method that already takes an 'encoding' argument (used currently only for the encoding aspect, not the decoding aspect). 

I do think there's a strong case to be made for changing the str.encode (and also unicode.decode) behaviour so that str.encode('utf-8') behaves the same whether it's given ascii or non-ascii characters, and also similar to unicode.encode('utf-8'). Let me try to persuade you... :)

First, to address the point you made:

> If str.encode() raises a decoding exception, this is a programming bug. It would be bad to hide it.

I totally agree with the general principal of not hiding programming bugs. However if calling str.encode for codecs like utf8 (let's ignore base64 for now, which is a very different beast) was *consistently* treated as a 'programming bug' by python and always resulted in an exception that would be ok (suboptimal usability imho, but still ok), since programmers would quickly spot the problem and fix it. But that's not what happens - it *silently works* (is a no-op) as long as you happen to be using ASCII characters so this so-called 'programming bug' will go unnoticed by most programmers (and authors of third party library code you might be relying on!)... but the moment a non-ascii character get introduced suddenly you'll get an exception, maybe in some library code you rely on but can't fix. For this reason I don't think treating this as a programming bug is helping anyone write more robust python code - quite the reverse. Plus I think the behaviour of being a no-op is almost always 'what you would have wanted it to do' anyway, whereas the behaviour of throwing an exception almost never is. 

I think we'd agree that changing str.encode(utf8) to throw an exception in *all* cases wouldn't be a realistic option since it would certainly break backwards compatability in painful ways for many existing apps and library code. 

So, if we want to make the behaviour of this important built-in type a bit more consistent and less error-prone/fragile for this case then I think the only option is making str.encode be a no-op for non-ascii characters (at least, non-ascii characters that are valid in the specified encoding), just as it is for ascii characters. 

Here's why I think ditching the current behaviour would be a good idea:
- calling str.encode() and getting a DecodeError is confusing ("I asked you to encode this string, what are you decoding for?")
- calling str.encode('utf-8') and getting an exception about "ascii" is confusing as the only encoding I mentioned in the method call was utf-8
- calling encode(..., errors=ignore) and getting an exception is confusing and feels like a bug; I've explicitly specified that I do NOT want exceptions from calling this method, yet (because neither 'errors' nor 'encoding' argument gets passed to the implicit - and undocumented - decode operation), I get unexpected behaviour that is far more likely to break my program than a no-op
- the somewhat surprising behaviour we're talking about is not explicitly documented anywhere
- having str.encode throw on non-ascii but not ascii makes it very likely that code will be written and shipped (including library code you may have no control over) that *appears* to work under normal testing but has *hidden* bugs that surface only once non-ascii characters are used. 
- in every situation I can think of, having str.encode(encoding, errors=ignore) honour the encoding and errors arguments even for the implicit-decode operation is more useful than having it ignore those arguments and throw an exception
- a quick google shows lots of people in the Python community (from newbies to experts) are seeing this exception and being confused by it, therefore a lot of people's lives might be improved if we can somehow make the situation better :)
- even with the best of intentions (and with code written by senior python programmers who understand unicode issues well) it's very difficult in practice to write non-trivial python programs that always consistently use the 'unicode' string type throughout (especially when legacy code or third party libraries are involved), so most 'real' code needs to cope with a mix of str and unicode types in practice. So when you need to write a 'basestring' out to a file, you'd like to be able to simply call the s.encode(myencoding, errors=whatever) method that exists on both str and unicode types and have it 'work' whether it's a str already in that encoding or a unicode object that needs to be converted. This is a common use case and the behaviour I'm suggesting would really help with this case. The alternative is that every python programmer who cares about non-ascii characters has to write an pleasant and un-pythonic if clause to give different behaviour based on __type__, in every place they need a byte str:
	if isinstance(s, unicode): 
		f.write(s.encode('utf-8', errors='ignore'))
	else:
		f.write(s)

nb: Although I've used the example of str.encode above, unicode.decode has the exact same issues (and potential solution), and of course this isn't specific to utf-8 but to all codecs that convert between str and unicode (i.e. most of them except base64). 

I hope you'll consider this proposal - it's probably not a very big change, is very unlikely to break any existing/working code, and has the potential to help reduce fragility and difficult-to-resolve bugs in an area of Python that seems to cause pain and confusion to lots of people.

Thanks for considering!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26369>
_______________________________________

From report at bugs.python.org  Thu May 19 12:24:16 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 19 May 2016 16:24:16 +0000
Subject: [issue17408] second python execution fails when embedding
In-Reply-To: <1363183794.27.0.643296851621.issue17408@psf.upfronthosting.co.za>
Message-ID: <1463675056.41.0.775550565762.issue17408@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy:  -terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17408>
_______________________________________

From report at bugs.python.org  Thu May 19 12:26:56 2016
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 19 May 2016 16:26:56 +0000
Subject: [issue16468] argparse only supports iterable choices
In-Reply-To: <1352867539.71.0.970228461518.issue16468@psf.upfronthosting.co.za>
Message-ID: <1463675216.19.0.94362704611.issue16468@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag
versions: +Python 3.5, Python 3.6 -Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16468>
_______________________________________

From report at bugs.python.org  Thu May 19 12:35:03 2016
From: report at bugs.python.org (Steve Dower)
Date: Thu, 19 May 2016 16:35:03 +0000
Subject: [issue27053] Python Windows x86-64 embeddable zip file missing module
 encodings
In-Reply-To: <1463557391.11.0.911851091126.issue27053@psf.upfronthosting.co.za>
Message-ID: <1463675703.36.0.166201364197.issue27053@psf.upfronthosting.co.za>


Steve Dower added the comment:

The "python35.zip" file contains the standard library and it needs to be renamed "python36.zip".

Apparently I hardcoded this somewhere instead of inferring it from the current version... I'll fix.

----------
assignee:  -> steve.dower
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27053>
_______________________________________

From report at bugs.python.org  Thu May 19 12:38:53 2016
From: report at bugs.python.org (Wolfgang Langner)
Date: Thu, 19 May 2016 16:38:53 +0000
Subject: [issue27053] Python Windows x86-64 embeddable zip file missing module
 encodings
In-Reply-To: <1463557391.11.0.911851091126.issue27053@psf.upfronthosting.co.za>
Message-ID: <1463675933.4.0.557413792468.issue27053@psf.upfronthosting.co.za>


Wolfgang Langner added the comment:

Yes this is the cause. If it is renamed to python36.zip everything works fine.
For the test I have only extracted the distributed zip and executed python.exe. Had not looked further into the issue. So only the simple report something did not work.

Thanks for looking at it and fixing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27053>
_______________________________________

From report at bugs.python.org  Thu May 19 12:39:54 2016
From: report at bugs.python.org (Kevin)
Date: Thu, 19 May 2016 16:39:54 +0000
Subject: [issue27058] Tkinter's canvas' dashed lines have incorrect segment
 lengths
In-Reply-To: <1463670778.9.0.698531599823.issue27058@psf.upfronthosting.co.za>
Message-ID: <1463675994.69.0.630597115809.issue27058@psf.upfronthosting.co.za>


Kevin added the comment:

Ok, I've tried testing Serhiy's `canvas_dash.tcl` file, by running:

    import Tkinter
    root = Tkinter.Tk()
    root.tk.eval("source canvas_dash.tcl")
    root.mainloop()

(I'm not sure if this counts as "pure" Tcl/Tk. I don't have any experience in using Tcl/Tk outside of Python. If there's a way to execute `canvas_dash.tcl` straight from the command line, I'm willing to try, but after some cursory research I couldn't figure out how to do it.)

The result is the same as before: 18 pixel segments, 6 pixel gaps.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27058>
_______________________________________

From report at bugs.python.org  Thu May 19 13:23:02 2016
From: report at bugs.python.org (Kevin)
Date: Thu, 19 May 2016 17:23:02 +0000
Subject: [issue27058] Tkinter's canvas' dashed lines have incorrect segment
 lengths
In-Reply-To: <1463670778.9.0.698531599823.issue27058@psf.upfronthosting.co.za>
Message-ID: <1463678582.77.0.824628437301.issue27058@psf.upfronthosting.co.za>


Kevin added the comment:

This problem appears to go deeper than Python. On the TK bug tracker, under the issue "-dashofset option doesnt work on ms windows build" (https://core.tcl.tk/tk/tktview?name=1055974fff), a commenter mentions:

 > On Windows, only certain dash patterns and no dash offsets are supported.

Which implies that you can't create segments and gaps of arbitrary length ratios- you can only select from a limited collection of premade patterns. This comment from tkWinDraw.c (https://github.com/tcltk/tk/blob/master/win/tkWinDraw.c#L1188) supports this:

 > Below is a simple translation of serveral dash patterns to valid  windows pen types. Far from complete, but I don't know how to do it better.

The code goes on to invoke CreatePen (https://msdn.microsoft.com/en-us/library/windows/desktop/dd183509%28v=vs.85%29.aspx), which only allows for four different variations of dashed line styles.

Conclusions:
1) It isn't Python's fault.
2) The guy who wrote the Tk code was aware of the limitation at the time, so it's arguably not a bug.

So, this issue ought to be closed; not much we can do, except perhaps petition the popular Tkinter reference websites to put up a warning label on their descriptions of the `dash` keyword argument.

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27058>
_______________________________________

From report at bugs.python.org  Thu May 19 13:32:48 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Thu, 19 May 2016 17:32:48 +0000
Subject: [issue26369] unicode.decode and str.encode are unnecessarily
 confusing for non-ascii
In-Reply-To: <1455623938.04.0.928922751587.issue26369@psf.upfronthosting.co.za>
Message-ID: <1463679168.38.0.24077455536.issue26369@psf.upfronthosting.co.za>


Steven D'Aprano added the comment:

Ben, I'm sorry to see you have spent such a long time writing up reasons for changing this behaviour. I fear this is a total waste of your time, and ours to read it. Python 2.7 is under feature freeze, and changing the behaviour of str.encode and unicode.decode is a new feature. So it could only happen in 2.8, but there will never be a Python 2.8.

If you want more sensible behaviour, then upgrade to Python 3. If you want to improve the docs, then suggest some documentation improvements. But arguing for a change in behaviour of Python 2.7 str.encode and unicode.decode is, I fear, a waste of everyone's time.

If you still wish to champion this change, feel free to raise the issue on the Python-Dev mailing list where the senior developers, including Guido, hang out. I doubt it will do any good, but there is at least the theoretical possibility that if you convince them that this change will encourage people to migrate to Python 3 then you might get your wish.

Just don't hold your breath.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26369>
_______________________________________

From report at bugs.python.org  Thu May 19 13:54:55 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 May 2016 17:54:55 +0000
Subject: [issue26369] unicode.decode and str.encode are unnecessarily
 confusing for non-ascii
In-Reply-To: <1455623938.04.0.928922751587.issue26369@psf.upfronthosting.co.za>
Message-ID: <1463680495.68.0.412131044276.issue26369@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> btw If anyone can find the place in the code (sorry I tried and failed!) where str.encode('utf-8', error=X) is resulting in an implicit call to the equivalent of decode(defaultencoding, errors=strict) (as suggested by the exception message) I think it'll be easier to discuss the details of fixing.

There is no single place. Search lines "str = PyUnicode_FromObject(str);" in Modules/_codecsmodule.c.

> But that's not what happens - it *silently works* (is a no-op) as long as you happen to be using ASCII characters so this so-called 'programming bug' will go unnoticed by most programmers (and authors of third party library code you might be relying on!)... but the moment a non-ascii character get introduced suddenly you'll get an exception, maybe in some library code you rely on but can't fix.

The problem is that encoding ASCII str to UTF-8 is legal operation in some circumstances and is a programming bug in other. There is no way to distinguish these two cases automatically.

As non-English speaker I am familiar with the problems you described. This is a bug in the design of Python 2, and the only solution is using Python 3.

You can experiment with your idea, but I'm afraid that the patch will be more difficult than you expect and break the tests. I want to warn that even if your experiment is quite successful, there is not much chance to take it in 2.7. This is more like a new feature than a bug fix. Programs that depend on this feature will be incompatible with previous bugfix releases. It is unlikely to help the migration on Python 3, but rather would encourage writing code that is incompatible with Python 3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26369>
_______________________________________

From report at bugs.python.org  Thu May 19 14:00:48 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 19 May 2016 18:00:48 +0000
Subject: [issue27058] Tkinter's canvas' dashed lines have incorrect segment
 lengths
In-Reply-To: <1463670778.9.0.698531599823.issue27058@psf.upfronthosting.co.za>
Message-ID: <1463680848.88.0.993578675051.issue27058@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

"Not our fault. Try reporting this to the Tcl team" ;-)

In any case thank you for your report Kevin.

----------
resolution: not a bug -> third party
stage:  -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27058>
_______________________________________

From report at bugs.python.org  Thu May 19 14:37:25 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Thu, 19 May 2016 18:37:25 +0000
Subject: [issue26369] unicode.decode and str.encode are unnecessarily
 confusing for non-ascii
In-Reply-To: <1455623938.04.0.928922751587.issue26369@psf.upfronthosting.co.za>
Message-ID: <1463683045.87.0.664883378198.issue26369@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

Agree with Steven; the whole reason Python 3 changed from unicode and str to str and bytes was because having Py2 str be text sometimes, and binary data at other times is confusing. The existing behavior can't change in Py2 in any meaningful way without breaking existing code, introducing special cases for text->text encodings (where Python 3 supports them using the codecs module only), behaving in non-obvious ways in corner cases, etc. Silently treating str.encode("utf-8") to mean "decode as UTF-8 and throw away the result to verify that it's already UTF-8 bytes" is not particularly intuitive either.

It does seem like a doc fix would be useful though; right now, we have only "String methods" documented, with no distinction between str and unicode. It might be helpful to explicitly deprecate str.encode on str objects, and unicode.decode, with a note that while it's meaningful to use these methods in Python 2 for text<->text encoding/decoding, the methods don't exist at all in Python 3.

Otherwise, yes, if you want consistent text/binary types, that's what Python 3 is for. Python 2 has tons of flaws when it comes to handling unicode (e.g. csv module), and fixing any given single problem (creating backward compatibility headaches in the process) is not worth the trouble.

If you're concerned about excessive boilerplate, just write a function (or a type) that allows you to perform the tests/conversions you care about as a single call. For example, the following seems like it achieves your objectives (one line usage, handles str by verifying that it's legal in provided encoding in strict mode, dropping/replacing characters in ignore/replace mode, etc.):

def basestringencode(s, encoding=sys.getdefaultencoding(), errors="strict"):
    if isinstance(s, str):
        # Decode with provided rules, so a str with illegal characters
        # raises exception, replaces, ignores, etc. per arguments
        s = s.decode(encoding, errors)
    return s.encode(encoding, errors)

If you don't want to see UnicodeDecodeError, you either pass 'ignore' for errors, or wrap the s.decode step in a try/except and raise a different exception type.

The biggest change I could see happening code wise would be a textual change to the UnicodeDecodeError error str.encode raises, so str.encode specifically replaces the default error message (but not type, for back compat reasons) with something like "str.encode cannot perform implicit decode with sys.getdefaultencoding(); use .encode only with unicode objects"

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26369>
_______________________________________

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: [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 14:56:33 2016
From: report at bugs.python.org (ppperry)
Date: Thu, 19 May 2016 18:56:33 +0000
Subject: [issue27054] Python installation problem: No module named 'encodings'
In-Reply-To: <45B64D1540141C4AA0F8F3974D714AEA64D3D93D@S197.admin.wpi.edu>
Message-ID: <1463684193.64.0.125511500123.issue27054@psf.upfronthosting.co.za>


Changes by ppperry <mapreader at olum.org>:


----------
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27054>
_______________________________________

From report at bugs.python.org  Thu May 19 15:09:37 2016
From: report at bugs.python.org (ppperry)
Date: Thu, 19 May 2016 19:09:37 +0000
Subject: [issue25548] Show the address in the repr for class objects
In-Reply-To: <1446576011.58.0.372024983976.issue25548@psf.upfronthosting.co.za>
Message-ID: <1463684977.52.0.506376563289.issue25548@psf.upfronthosting.co.za>


ppperry added the comment:

I don't quite get why the memory address is helpful, but you could work around this using a custom metaclass:

    class IdMeta(type):
        def __repr__(cls):
            return super().__repr__()[:-1] + " at 0x%x>"%id(cls)
    class IdInRepr(metaclass=IdMeta):pass

`IdInRepr` and all its subclasses will then have the memory address in their representation:

  <class 'module.name' at address>

----------
nosy: +ppperry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25548>
_______________________________________

From report at bugs.python.org  Thu May 19 15:10:46 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 19 May 2016 19:10:46 +0000
Subject: [issue27053] Python Windows x86-64 embeddable zip file missing module
 encodings
In-Reply-To: <1463557391.11.0.911851091126.issue27053@psf.upfronthosting.co.za>
Message-ID: <20160519191041.673.59229.9A0BCDF9@psf.io>


Roundup Robot added the comment:

New changeset 12cb81e90479 by Steve Dower in branch '3.5':
Issue #27053: Updates make_zip.py to correctly generate library ZIP file.
https://hg.python.org/cpython/rev/12cb81e90479

New changeset a6473f7a8c55 by Steve Dower in branch 'default':
Issue #27053: Updates make_zip.py to correctly generate library ZIP file.
https://hg.python.org/cpython/rev/a6473f7a8c55

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27053>
_______________________________________

From report at bugs.python.org  Thu May 19 15:10:56 2016
From: report at bugs.python.org (Steve Dower)
Date: Thu, 19 May 2016 19:10:56 +0000
Subject: [issue27053] Python Windows x86-64 embeddable zip file missing module
 encodings
In-Reply-To: <1463557391.11.0.911851091126.issue27053@psf.upfronthosting.co.za>
Message-ID: <1463685056.4.0.217067392764.issue27053@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27053>
_______________________________________

From report at bugs.python.org  Thu May 19 15:33:10 2016
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 19 May 2016 19:33:10 +0000
Subject: [issue27059] find_spec and find_loader ignore package/path argument
In-Reply-To: <1463683793.33.0.38773604471.issue27059@psf.upfronthosting.co.za>
Message-ID: <1463686390.45.0.543175162916.issue27059@psf.upfronthosting.co.za>


Brett Cannon added the comment:

So there are 2 problems with your example. One, importlib.util.find_spec() doesn't take a path argument but a package argument which is a package name and not a file system location (https://docs.python.org/3/library/importlib.html#importlib.util.find_spec). Two, importlib.find_loader() takes a "path" as in "a package's path" which means __path__. What this means it is it expected to be an iterable of directories and not a string as it's iterated over (https://docs.python.org/3/library/importlib.html#importlib.find_loader).

If you think the docs aren't clear enough then please feel free to submit a patch to make them a bit clearer.

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27059>
_______________________________________

From report at bugs.python.org  Thu May 19 15:51:33 2016
From: report at bugs.python.org (Ilya Kulakov)
Date: Thu, 19 May 2016 19:51:33 +0000
Subject: [issue26969] ascynio should provide a policy to address
 pass-loop-everywhere problem
In-Reply-To: <1462517538.3.0.176027238089.issue26969@psf.upfronthosting.co.za>
Message-ID: <1463687493.89.0.50075483204.issue26969@psf.upfronthosting.co.za>


Ilya Kulakov added the comment:

Yury, as you suggested posted to python-ideas (https://groups.google.com/forum/#!topic/python-ideas/ABOe22Mib44)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26969>
_______________________________________

From report at bugs.python.org  Thu May 19 15:51:46 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 May 2016 19:51:46 +0000
Subject: [issue26814] [WIP] Add a new _PyObject_FastCall() function which
 avoids the creation of a tuple or dict for arguments
In-Reply-To: <1461229041.59.0.994194592206.issue26814@psf.upfronthosting.co.za>
Message-ID: <1463687506.5.0.808553170409.issue26814@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Result of the benchmark suite:
>
> slower (3):
>
> * raytrace: 1.06x slower
> * etree_parse: 1.03x slower
> * normal_startup: 1.02x slower

Hum, I recompiled the patched Python, again with PGO+LTO, and ran the same benchmark with the same command. In short, I replayed exaclty the same scenario. And... Only raytrace remains slower, etree_parse and normal_startup moved to the "not significant" list.

The difference in the benchmark result doesn't come from the benchmark. For example, I ran gain the normal_startup benchmark 3 times: I got the same result 3 times.

### normal_startup ###
Avg: 0.295168 +/- 0.000991 -> 0.294926 +/- 0.00048: 1.00x faster
Not significant

### normal_startup ###
Avg: 0.294871 +/- 0.000606 -> 0.294883 +/- 0.00072: 1.00x slower
Not significant

### normal_startup ###
Avg: 0.295096 +/- 0.000706 -> 0.294967 +/- 0.00068: 1.00x faster
Not significant

IMHO the difference comes from the data collected by PGO.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26814>
_______________________________________

From report at bugs.python.org  Thu May 19 16:02:32 2016
From: report at bugs.python.org (Vitaly)
Date: Thu, 19 May 2016 20:02:32 +0000
Subject: [issue17866] TestCase.assertItemsEqual exists in 2.7, not in 3.3
In-Reply-To: <1367222489.01.0.284119799467.issue17866@psf.upfronthosting.co.za>
Message-ID: <1463688152.67.0.827985855276.issue17866@psf.upfronthosting.co.za>


Vitaly added the comment:

Python 2.7 documentation is VERY misleading about the functionality of assertItemsEqual. It 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:

   .. 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.

----------
nosy: +vitaly

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17866>
_______________________________________

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: [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:05:23 2016
From: report at bugs.python.org (Vitaly)
Date: Thu, 19 May 2016 20:05:23 +0000
Subject: [issue27060] Documentation of assertItemsEqual in unittest is VERY
 misleading in 2.7
In-Reply-To: <1463688314.75.0.696545829281.issue27060@psf.upfronthosting.co.za>
Message-ID: <1463688323.76.0.83857908958.issue27060@psf.upfronthosting.co.za>


Changes by Vitaly <vitaly.krugl.numenta at gmail.com>:


----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27060>
_______________________________________

From report at bugs.python.org  Thu May 19 16:05:37 2016
From: report at bugs.python.org (Vitaly)
Date: Thu, 19 May 2016 20:05:37 +0000
Subject: [issue27060] Documentation of assertItemsEqual in unittest is VERY
 misleading in 2.7
In-Reply-To: <1463688314.75.0.696545829281.issue27060@psf.upfronthosting.co.za>
Message-ID: <1463688337.14.0.102379391279.issue27060@psf.upfronthosting.co.za>


Changes by Vitaly <vitaly.krugl.numenta at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27060>
_______________________________________

From report at bugs.python.org  Thu May 19 16:10:34 2016
From: report at bugs.python.org (Vitaly)
Date: Thu, 19 May 2016 20:10:34 +0000
Subject: [issue17866] TestCase.assertItemsEqual exists in 2.7, not in 3.3
In-Reply-To: <1367222489.01.0.284119799467.issue17866@psf.upfronthosting.co.za>
Message-ID: <1463688634.57.0.47933503053.issue17866@psf.upfronthosting.co.za>


Vitaly added the comment:

I opened http://bugs.python.org/issue27060 regarding the erroneous documentation of assertItemsEqual in python 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17866>
_______________________________________

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: [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:17:47 2016
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 19 May 2016 20:17:47 +0000
Subject: [issue27060] Documentation of assertItemsEqual in unittest is VERY
 misleading in 2.7
In-Reply-To: <1463688314.75.0.696545829281.issue27060@psf.upfronthosting.co.za>
Message-ID: <1463689067.67.0.724236131256.issue27060@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27060>
_______________________________________

From report at bugs.python.org  Thu May 19 16:18:47 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 19 May 2016 20:18:47 +0000
Subject: [issue22570] Better stdlib support for Path objects
In-Reply-To: <1412609631.43.0.978086278536.issue22570@psf.upfronthosting.co.za>
Message-ID: <1463689127.68.0.132242270038.issue22570@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Done. The revs are 90e58a77d386, 97198545e6c3, ade839421b8f.

----------
resolution: out of date -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22570>
_______________________________________

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: [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: [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 16:36:37 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 19 May 2016 20:36:37 +0000
Subject: [issue27062] `inspect` doesn't have `__all__`
In-Reply-To: <1463689783.23.0.292900715898.issue27062@psf.upfronthosting.co.za>
Message-ID: <1463690197.76.0.37151039242.issue27062@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

I refer again to https://bugs.python.org/issue26632 :)

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27062>
_______________________________________

From report at bugs.python.org  Thu May 19 17:03:51 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 19 May 2016 21:03:51 +0000
Subject: [issue26814] [WIP] Add a new _PyObject_FastCall() function which
 avoids the creation of a tuple or dict for arguments
In-Reply-To: <1461229041.59.0.994194592206.issue26814@psf.upfronthosting.co.za>
Message-ID: <1463691831.84.0.529018854959.issue26814@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> In short, I replayed exaclty the same scenario. And... Only raytrace remains slower, (...)

Oh, it looks like the reference binary calls the garbage collector less frequently than the patched python. In the patched Python, collections of the generation 2 are needed, whereas no collection of the generation 2 is needed on the reference binary.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26814>
_______________________________________

From report at bugs.python.org  Thu May 19 17:05:20 2016
From: report at bugs.python.org (Ned Deily)
Date: Thu, 19 May 2016 21:05:20 +0000
Subject: [issue24502] OS X installer provides flat sub-packages with no
 version numbers
In-Reply-To: <1435173121.58.0.153613185242.issue24502@psf.upfronthosting.co.za>
Message-ID: <1463691920.11.0.710929790567.issue24502@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
nosy: +Paul Bloch
priority: normal -> high
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24502>
_______________________________________

From report at bugs.python.org  Thu May 19 17:05:31 2016
From: report at bugs.python.org (Ned Deily)
Date: Thu, 19 May 2016 21:05:31 +0000
Subject: [issue27061] 2.7.11 OS X pkg doesn't put proper version in the
 receipts
In-Reply-To: <1463688727.6.0.20787305635.issue27061@psf.upfronthosting.co.za>
Message-ID: <1463691931.72.0.42608756625.issue27061@psf.upfronthosting.co.za>


Ned Deily added the comment:

This problem was brought up previously in Issue24052, which is still open.  I am closing this a duplicate add adding you to the nosy list there.

----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> OS X installer provides flat sub-packages with no version numbers

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27061>
_______________________________________

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: [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 18:16:17 2016
From: report at bugs.python.org (Steve Dower)
Date: Thu, 19 May 2016 22:16:17 +0000
Subject: [issue27064] Make py.exe default to Python 3 when used interactively
In-Reply-To: <1463693765.53.0.683202020216.issue27064@psf.upfronthosting.co.za>
Message-ID: <1463696177.85.0.947454947928.issue27064@psf.upfronthosting.co.za>


Steve Dower added the comment:

LGTM.

The launcher is in a bit of a funny place wrt versioning, as it is now somewhat independent from the Python version it is installed with:

* won't be downgraded by 3.5 (3.4 will still stomp over the file itself)
* has a separate entry in Programs & Features
* won't be uninstalled by the regular Python installer
* (theoretically can be installed separately, but since we don't link to the MSI... ;) )
* this includes alpha/beta releases of 3.6

So I wouldn't have an issue with this going into 3.5, in the same way that we will update the bundled setuptools/pip in minor releases, but since we don't have an official OK for that just putting it into 3.6 is fine.

----------

_______________________________________
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: [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: [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  Thu May 19 20:12:21 2016
From: report at bugs.python.org (ppperry)
Date: Fri, 20 May 2016 00:12:21 +0000
Subject: [issue27066] SystemError if custom opener returns -1
In-Reply-To: <1463701849.23.0.646090431797.issue27066@psf.upfronthosting.co.za>
Message-ID: <1463703141.48.0.397530649612.issue27066@psf.upfronthosting.co.za>


ppperry added the comment:

Also, `OSError [Errno 0] Error` isn't the most helpful error message.

----------
nosy: +ppperry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27066>
_______________________________________

From report at bugs.python.org  Thu May 19 20:15:03 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 20 May 2016 00:15:03 +0000
Subject: [issue27066] SystemError if custom opener returns -1
In-Reply-To: <1463703141.48.0.397530649612.issue27066@psf.upfronthosting.co.za>
Message-ID: <20160519201458.5b56f30f@subdivisions.wooz.org>


Barry A. Warsaw added the comment:

On May 20, 2016, at 12:12 AM, ppperry wrote:

>Also, `OSError [Errno 0] Error` isn't the most helpful error message.

No, definitely not. ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27066>
_______________________________________

From report at bugs.python.org  Thu May 19 21:01:50 2016
From: report at bugs.python.org (Yoni Lavi)
Date: Fri, 20 May 2016 01:01:50 +0000
Subject: [issue22558] Missing doc links to source code
In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za>
Message-ID: <1463706110.72.0.467442027324.issue22558@psf.upfronthosting.co.za>


Yoni Lavi added the comment:

Friendly ping

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22558>
_______________________________________

From report at bugs.python.org  Thu May 19 21:14:45 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 20 May 2016 01:14:45 +0000
Subject: [issue27066] SystemError if custom opener returns -1
In-Reply-To: <1463701849.23.0.646090431797.issue27066@psf.upfronthosting.co.za>
Message-ID: <1463706885.0.0.98350296949.issue27066@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

Here's a proposed fix.

----------
assignee:  -> barry
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file42907/27066-1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27066>
_______________________________________

From report at bugs.python.org  Thu May 19 21:53:26 2016
From: report at bugs.python.org (Daniel Stokes)
Date: Fri, 20 May 2016 01:53:26 +0000
Subject: [issue26536] Add the SIO_LOOPBACK_FAST_PATH option to socket.ioctl
In-Reply-To: <1457666128.63.0.278319184112.issue26536@psf.upfronthosting.co.za>
Message-ID: <1463709206.44.0.46903837946.issue26536@psf.upfronthosting.co.za>


Daniel Stokes added the comment:

I have uploaded a new patch with the suggested changes, thanks for the review.

----------
Added file: http://bugs.python.org/file42908/loopback_fast_path_v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26536>
_______________________________________

From report at bugs.python.org  Thu May 19 22:03:05 2016
From: report at bugs.python.org (Hugh C. Lauer)
Date: Fri, 20 May 2016 02:03:05 +0000
Subject: [issue27054] Python installation problem: No module named 'encodings'
In-Reply-To: <45B64D1540141C4AA0F8F3974D714AEA64D3D93D@S197.admin.wpi.edu>
Message-ID: <feaaa561-8602-44e4-afe2-21f0e42859e7@email.android.com>


Hugh C. Lauer added the comment:

Thanks, I will try it when I get out of airports.

Hugh Lauer

On May 19, 2016 11:56 AM, Zachary Ware <report at bugs.python.org> wrote:

>

>
> Zachary Ware added the comment:
>
> Here's some pretty compelling evidence for a bad PYTHONHOME setting:
>
> C:\>set PYTHONHOME=C:\path\not\here
>
> C:\>py -3.5
> Fatal Python error: Py_Initialize: unable to load the file system codec
> ImportError: No module named 'encodings'
>
> Current thread 0x00001db4 (most recent call first):
>
> C:\>set PYTHONHOME=C:\Python27\
>
> C:\>py -3.5
> Fatal Python error: Py_Initialize: unable to load the file system codec
>   File "C:\Python27\\lib\encodings\__init__.py", line 123
>     raise CodecRegistryError,\
>                             ^
> SyntaxError: invalid syntax
>
> Current thread 0x00000664 (most recent call first):
>
> C:\>set PYTHONHOME=
>
> C:\>py -3.5
> 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.
> >>>
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue27054>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27054>
_______________________________________

From report at bugs.python.org  Fri May 20 00:38:14 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 May 2016 04:38:14 +0000
Subject: [issue27066] SystemError if custom opener returns -1
In-Reply-To: <1463701849.23.0.646090431797.issue27066@psf.upfronthosting.co.za>
Message-ID: <1463719094.09.0.420510500441.issue27066@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Added comments on Rietveld.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27066>
_______________________________________

From report at bugs.python.org  Fri May 20 02:55:28 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 20 May 2016 06:55:28 +0000
Subject: [issue27065] robotparser user agent considered hostile by
 mod_security rules.
In-Reply-To: <1463700108.4.0.745938506232.issue27065@psf.upfronthosting.co.za>
Message-ID: <1463727328.72.0.788666280952.issue27065@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the report. This is a duplicate of issue 15851.

----------
nosy: +berker.peksag
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> Lib/robotparser.py doesn't accept setting a user agent string, instead it uses the default.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27065>
_______________________________________

From report at bugs.python.org  Fri May 20 03:02:49 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 20 May 2016 07:02:49 +0000
Subject: [issue26632] __all__ decorator
In-Reply-To: <1458786797.31.0.0749407715279.issue26632@psf.upfronthosting.co.za>
Message-ID: <1463727769.02.0.111712900279.issue26632@psf.upfronthosting.co.za>


Berker Peksag added the comment:

+1 for the idea. I saw a lot of different 'all' or 'public' decorators in the wild. It would be nice to have a complete solution in Python. It would be good to add a note to Doc/whatsnew/3.6.rst.

----------
components: +Interpreter Core
nosy: +berker.peksag
stage:  -> patch review
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26632>
_______________________________________

From report at bugs.python.org  Fri May 20 03:07:58 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 May 2016 07:07:58 +0000
Subject: [issue26632] __all__ decorator
In-Reply-To: <1458786797.31.0.0749407715279.issue26632@psf.upfronthosting.co.za>
Message-ID: <1463728078.63.0.547258908918.issue26632@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy:  -serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26632>
_______________________________________

From report at bugs.python.org  Fri May 20 03:21:42 2016
From: report at bugs.python.org (Franklin? Lee)
Date: Fri, 20 May 2016 07:21:42 +0000
Subject: [issue26632] __all__ decorator
In-Reply-To: <1458786797.31.0.0749407715279.issue26632@psf.upfronthosting.co.za>
Message-ID: <1463728902.04.0.1418816847.issue26632@psf.upfronthosting.co.za>


Franklin? Lee added the comment:

I like how ``@public`` keeps the declaration close to the definition.

I am iffy about using ``public`` to define other values. That part might be considered unpythonic.


Implementation issues:
    - ``__module__`` is not reliable. ``functools.wraps`` changes it. (Why does it do that, though?)
    - If `__all__` isn't a list, you'd have to make it a list before you mess with it. (Is this possible?)


> > On the down side, you know somebody is going to @public a class' method --
> > how do we check for that?
>
> Do we need to?  Consenting adults and __all__.

It's a silent error waiting to happen. If you never use ``import *`` on it (e.g. because it's your main file), you won't get the error message. Things will work "as expected" (your methods are class-public!) until you give a method the same name as a builtin or something you imported or defined earlier. When that happens, the error message will have nothing to do with the problem.

It might be detectable using ``thing.__qualname__ != thing.__name__``, but this disallows functions decorated without updating __qualname__, and static/class methods exposed in a module's interface.

It might be detectable by checking, on the callstack, whether you're in a module load or a class definition.


Bikeshed
========


How many public module values aren't enum-type constants? It could be useful to be able to dump an enum into a module's space. I mean, a canonical way. With that, maybe maintaining module-level constants in __all__ isn't that big a deal.

    # Rather than:
    globals().update(MyEnum.__members__)
    __all__.extend(MyEnum.__members__)
    # Perhaps allow:
    enum.dump_namespace(MyEnum, globals())


About the cost paid at every load:
    - Should tools update __all__ for you, and comment out the ``@public``s?
        - If so, how would they deal with public non-callable values?
    - When compiling to .pyc, should the compiler remove ``@public`` calls and explicitly add the values to __all__?


API:
    - Alternative syntax for constants, requiring less frame hackery:
        public(globals(), x=1, y=2, z=3)
    - Naming: Is it really "public"? Some names might be public but not in __all__.


P.S. Typo in the ReadTheDocs. ``py_install`` should be a function call, right?

    >>> from public import py_install
    >>> py_install


P.S.: Would OrderedSet (which doesn't exist) be the ideal type for __all__? I mean, if you had to use someone else's __all__, not if you had to maintain it.

----------
nosy: +leewz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26632>
_______________________________________

From report at bugs.python.org  Fri May 20 03:58:42 2016
From: report at bugs.python.org (Paul Moore)
Date: Fri, 20 May 2016 07:58:42 +0000
Subject: [issue27064] Make py.exe default to Python 3 when used interactively
In-Reply-To: <1463693765.53.0.683202020216.issue27064@psf.upfronthosting.co.za>
Message-ID: <1463731122.87.0.842794180011.issue27064@psf.upfronthosting.co.za>


Paul Moore added the comment:

Thanks Steve. I wasn't sure over versioning, which is why I decided to be conservative. Also, it's probably not good to change the default behaviour on people when they just install a patch release of 3.5.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27064>
_______________________________________

From report at bugs.python.org  Fri May 20 04:01:11 2016
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 20 May 2016 08:01:11 +0000
Subject: [issue26369] unicode.decode and str.encode are unnecessarily
 confusing for non-ascii
In-Reply-To: <1455623938.04.0.928922751587.issue26369@psf.upfronthosting.co.za>
Message-ID: <1463731271.39.0.897765908373.issue26369@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

Ben, the methods on stings and Unicode objects in Python 2.x are direct interfaces to the underlying codecs. The codecs can handle any number of input and output types, so there are some which only work on 8-bit strings (bytes) and others which take Unicode as input.

As a result, you sometimes see errors due to the conversion of an 8-bit string to Unicode (in the case, where the codec expects a Unicode input).

As example, take the UTF-8 codec. This expects a Unicode input when decoding, so when you pass in an 8-bit string, Python will convert this to Unicode using the default encoding (which is normally set to 'ascii') and then applies the codec operation.

When the 8-bit string is plain ASCII this works great. If not, chances are high that you'll run into a Unicode error.

Now, in Python 2.x you can change the default encoding to either make this work by assuming that all your 8-bit strings are UTF-8 (set it to 'utf-8' in sitecustomize.py), or you can disable the automatic conversion altogether by setting the default encoding to 'unknown', which is a codec specifically created for this purpose. The latter will also raise an exception when attempting to convert an 8-bit string to Unicode - similar to what Python 3 does, except that the error type is different.

Hope that helps.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26369>
_______________________________________

From report at bugs.python.org  Fri May 20 04:02:37 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 May 2016 08:02:37 +0000
Subject: [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 04:50:27 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 20 May 2016 08:50:27 +0000
Subject: [issue27027] add is_android in test.support to detect Android platform
In-Reply-To: <1463307075.8.0.646834682003.issue27027@psf.upfronthosting.co.za>
Message-ID: <1463734227.18.0.594268525219.issue27027@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

The patch adds a dependency to issue #26855.

----------
keywords: +patch
Added file: http://bugs.python.org/file42910/is_android.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27027>
_______________________________________

From report at bugs.python.org  Fri May 20 05:08:50 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 20 May 2016 09:08:50 +0000
Subject: [issue26919] android: test_cmd_line fails
In-Reply-To: <1462267115.39.0.594600458307.issue26919@psf.upfronthosting.co.za>
Message-ID: <1463735330.64.0.263531921624.issue26919@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

This new patch adds a dependency to issue #27027.

----------
Added file: http://bugs.python.org/file42911/retrofit_osx_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26919>
_______________________________________

From report at bugs.python.org  Fri May 20 05:10:51 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 May 2016 09:10:51 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1463735451.93.0.00227555579885.issue26647@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Added new comments on Rietveld.

----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Fri May 20 05:15:21 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 May 2016 09:15:21 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1463735721.28.0.893048338052.issue26647@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


Added file: http://bugs.python.org/file42912/wpy8.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Fri May 20 05:16:04 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 May 2016 09:16:04 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1463735764.67.0.983412716318.issue26647@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I regenerated wpy8.patch with Mercurial. I had to fix a minor conflict in Lib/importlib/_bootstrap_external.py. (I didn't read the patch.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Fri May 20 05:22:48 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 20 May 2016 09:22:48 +0000
Subject: [issue26856] android does not have pwd.getpwall()
In-Reply-To: <1461677345.21.0.582848799296.issue26856@psf.upfronthosting.co.za>
Message-ID: <1463736168.37.0.20091451569.issue26856@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

This new patch adds a dependency to issue #27027.

----------
Added file: http://bugs.python.org/file42913/pwd_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26856>
_______________________________________

From report at bugs.python.org  Fri May 20 05:26:27 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 May 2016 09:26:27 +0000
Subject: [issue27056] pickle: constant propagation in _Unpickler_Read()
In-Reply-To: <1463659349.35.0.28600421781.issue27056@psf.upfronthosting.co.za>
Message-ID: <1463736387.08.0.992899282388.issue27056@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Updated patch 2 to address Serhiy's comments.

----------
Added file: http://bugs.python.org/file42914/unpickle_read-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27056>
_______________________________________

From report at bugs.python.org  Fri May 20 05:29:08 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 20 May 2016 09:29:08 +0000
Subject: [issue19695] Clarify how to use various import-related locks
In-Reply-To: <1385133456.35.0.294583357802.issue19695@psf.upfronthosting.co.za>
Message-ID: <1463736548.61.0.878815373652.issue19695@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue19695>
_______________________________________

From report at bugs.python.org  Fri May 20 05:34:40 2016
From: report at bugs.python.org (Ben Spiller)
Date: Fri, 20 May 2016 09:34:40 +0000
Subject: [issue26369] unicode.decode and str.encode are unnecessarily
 confusing for non-ascii
In-Reply-To: <1455623938.04.0.928922751587.issue26369@psf.upfronthosting.co.za>
Message-ID: <1463736880.1.0.322259459495.issue26369@psf.upfronthosting.co.za>


Ben Spiller added the comment:

Thanks for considering this, anyway. I'll admit I'm disappointed we couldn't fix this on the 2.7 train, as to me fixing a method that takes an errors='ignore' argument and then throws an exception anyway seems a little more like a bug than a feature (and changing it would likely not affect behaviour in any existing non-broken programs), but if that's the decision then fine. Of course I'm aware (as I mentioned earlier on the thread) that the radically different unicode handling in python 3 solves this entirely and only wish it was practical to move our existing (enormous) codebase and customers over to it, but we're stuck with Python 2.7 - I believe lots of people are in the same situation unfortunately. 

As Josh suggested, perhaps we can at least add something to the doc for the str/unicode encode and decode methods so users are aware of the behaviour without trial and error. I'll update the component of this bug to reflect it's now considered a doc issue. 

Based on the inputs from Terry, and what seem to be the key info that would have been helpful to me and those who are hitting the same issues for the first time, I'd propose the following text (feel free to adjust as you see fit):

For encode:
"For most encodings, the return type is a byte str regardless of whether it is called on a str or unicode object. For example, call encode on a unicode object with "utf-8" to return a byte str object, or call encode on a str object with "base64" to return a base64-encoded str object.

It is _not_ recommended to use call this method on "str" objects when using codecs such as utf-8 that convert betweens str and unicode objects, as any characters not supported by python's default encoding (usually 7-bit ascii) will result in a UnicodeDecodeError exception, even if errors='ignore' was specified. For such conversions the str.decode and unicode.encode methods should be used. If you need to produce an encoded version of a string that could be either a str or unicode object, only call the encode() method after checking it is a unicode object not a str object, using isinstance(s, unicode)."

and for decode:
"The return type may be either str or unicode, depending on which encoding is used and whether the method is called on a str or unicode object. For example, call decode on a str object with "utf-8" to return a unicode object, or call decode on a unicode or str object with "base64" to return a base64-decoded str object.

It is _not_ recommended to use call this method on "unicode" objects when using codecs such as utf-8 that convert betweens str and unicode objects, as any characters not supported by python's default encoding (usually 7-bit ascii) will result in a UnicodeEncodeError exception, even if errors='ignore' was specified. For such conversions the str.decode and unicode.encode methods should be used. If you need to produce a decoded version of a string that could be either a str or unicode object, only call the decode() method after checking it is a str object not a unicode object, using isinstance(s, str)."

----------
components: +Documentation -Interpreter Core

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26369>
_______________________________________

From report at bugs.python.org  Fri May 20 05:37:27 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 May 2016 09:37:27 +0000
Subject: [issue27056] pickle: constant propagation in _Unpickler_Read()
In-Reply-To: <1463659349.35.0.28600421781.issue27056@psf.upfronthosting.co.za>
Message-ID: <1463737047.78.0.10310566341.issue27056@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I forgot to note that the comment before _Unpickler_Read() becomes not correct, but you already addressed this in the second patch. unpickle_read-2.patch LGTM.

Few months ago I tried to optimize reading in pickle, but didn't see significant benefit. After committing your patch I'm going to revive my patch.

----------
assignee:  -> haypo
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27056>
_______________________________________

From report at bugs.python.org  Fri May 20 05:38:13 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 May 2016 09:38:13 +0000
Subject: [issue26948] Simplify PyImport_ImportModuleLevelObject: avoid
 temporary tuple of str.partition/rpartition
In-Reply-To: <1462366096.99.0.505486204929.issue26948@psf.upfronthosting.co.za>
Message-ID: <1463737093.61.0.25399551603.issue26948@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I modified my patch to address Serhiy's comments. Thanks for the your review Serhiy.

changeset:   101442:779563dd701c
tag:         tip
user:        Victor Stinner <victor.stinner at gmail.com>
date:        Fri May 20 11:36:13 2016 +0200
files:       Python/import.c
description:
Cleanup import.c

* Replace PyUnicode_RPartition() with PyUnicode_FindChar() and
  PyUnicode_Substring() to avoid the creation of a temporary tuple.
* Use PyUnicode_FromFormat() to build a string and avoid the single_dot ('.')
  singleton

Thanks Serhiy Storchaka for your review.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26948>
_______________________________________

From report at bugs.python.org  Fri May 20 05:41:59 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 20 May 2016 09:41:59 +0000
Subject: [issue26931] android: test_distutils fails
In-Reply-To: <1462285501.44.0.0195995288955.issue26931@psf.upfronthosting.co.za>
Message-ID: <1463737319.09.0.388544655756.issue26931@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

This new patch adds a dependency to issue #27027.

----------
Added file: http://bugs.python.org/file42915/android-sh-path_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26931>
_______________________________________

From report at bugs.python.org  Fri May 20 05:44:03 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 May 2016 09:44:03 +0000
Subject: [issue27056] pickle: constant propagation in _Unpickler_Read()
In-Reply-To: <1463659349.35.0.28600421781.issue27056@psf.upfronthosting.co.za>
Message-ID: <20160520094400.10766.58651.27CA607B@psf.io>


Roundup Robot added the comment:

New changeset f9b85b47f9c8 by Victor Stinner in branch 'default':
Optimize pickle.load() and pickle.loads()
https://hg.python.org/cpython/rev/f9b85b47f9c8

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27056>
_______________________________________

From report at bugs.python.org  Fri May 20 05:45:57 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 May 2016 09:45:57 +0000
Subject: [issue27056] pickle: constant propagation in _Unpickler_Read()
In-Reply-To: <1463659349.35.0.28600421781.issue27056@psf.upfronthosting.co.za>
Message-ID: <1463737557.15.0.527741792189.issue27056@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Serhiy Storchaka: "I forgot to note that the comment before _Unpickler_Read() becomes not correct, but you already addressed this in the second patch. unpickle_read-2.patch LGTM."

Cool, pushed.

"Few months ago I tried to optimize reading in pickle, but didn't see significant benefit. After committing your patch I'm going to revive my patch."

Cool too, keep me in touch.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27056>
_______________________________________

From report at bugs.python.org  Fri May 20 05:46:46 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 May 2016 09:46:46 +0000
Subject: [issue26850] PyMem_RawMalloc(): update also sys.getallocatedblocks()
 in debug mode
In-Reply-To: <1461670523.49.0.555580906198.issue26850@psf.upfronthosting.co.za>
Message-ID: <1463737606.95.0.879133598419.issue26850@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I'm not convinced myself by this change, it may make detection of memory leaks much more tricky for a little gain. I prefer to reject my own issue ;-)

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26850>
_______________________________________

From report at bugs.python.org  Fri May 20 06:11:57 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Fri, 20 May 2016 10:11:57 +0000
Subject: [issue26858] android: setting SO_REUSEPORT fails
In-Reply-To: <1461677842.81.0.574068471289.issue26858@psf.upfronthosting.co.za>
Message-ID: <1463739117.69.0.766452563821.issue26858@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Should use boolean 'is_android' being added to module test.support by issue #27027, instead of platform.android_ver()[0].

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26858>
_______________________________________

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: [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 06:20:22 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 May 2016 10:20:22 +0000
Subject: [issue27068] Add a detach() method to subprocess.Popen
In-Reply-To: <1463739584.18.0.0161123331788.issue27068@psf.upfronthosting.co.za>
Message-ID: <1463739622.25.0.283547821287.issue27068@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27068>
_______________________________________

From report at bugs.python.org  Fri May 20 06:48:09 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 May 2016 10:48:09 +0000
Subject: [issue26741] subprocess.Popen should emit a ResourceWarning in
 destructor if the process is still running
In-Reply-To: <1460501347.41.0.70782898945.issue26741@psf.upfronthosting.co.za>
Message-ID: <20160520104807.10774.9680.08923AD7@psf.io>


Roundup Robot added the comment:

New changeset b122011b139e by Victor Stinner in branch 'default':
Use "with popen:" in test_subprocess
https://hg.python.org/cpython/rev/b122011b139e

New changeset 4c02b983bd5f by Victor Stinner in branch 'default':
Issue #26741: POSIX implementation of subprocess.Popen._execute_child() now
https://hg.python.org/cpython/rev/4c02b983bd5f

New changeset b7f3494deb2c by Victor Stinner in branch 'default':
subprocess now emits a ResourceWarning warning
https://hg.python.org/cpython/rev/b7f3494deb2c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26741>
_______________________________________

From report at bugs.python.org  Fri May 20 06:49:12 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 May 2016 10:49:12 +0000
Subject: [issue26741] subprocess.Popen should emit a ResourceWarning in
 destructor if the process is still running
In-Reply-To: <1460501347.41.0.70782898945.issue26741@psf.upfronthosting.co.za>
Message-ID: <1463741352.76.0.104476014407.issue26741@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Martin Panter:
> I think the basic idea of adding the warning is good.

Cool.

I pushed an enhanced version of my patch:

* I fixed _execute_child() to set correctly the returncode attribute
* I splitted the patch into multiple commits and I documented the doc
* I fixed test_subprocess on Windows


Me:
> TODO: fix also the Windows implementation of _execute_child().

subprocess.py on Windows is correct, but I had to fix more unit tests specific to Windows in test_subproces.py.


Martin Panter:
> One potential problem is how to provide for people who really want to let the child continue to run in the background or as a daemon without waiting for it, even if the parent exits. Perhaps a special method proc.detach() or whatever?

While I'm not convinced that the use case exists nor that it's safe to delegate the management of the subprocess to a different object after the Popen object is destroyed, I opened the issue #27068 to discuss this feature enhancement.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26741>
_______________________________________

From report at bugs.python.org  Fri May 20 06:52:36 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 May 2016 10:52:36 +0000
Subject: [issue26530] tracemalloc: add C API to manually track/untrack memory
 allocations
In-Reply-To: <1457619430.68.0.0968942184372.issue26530@psf.upfronthosting.co.za>
Message-ID: <1463741556.89.0.830308680717.issue26530@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Nathaniel, Antoine: ping again? No reaction to the new shiny C API of tracemalloc that *you* requested? :-p

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26530>
_______________________________________

From report at bugs.python.org  Fri May 20 07:09:03 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 May 2016 11:09:03 +0000
Subject: [issue26741] subprocess.Popen should emit a ResourceWarning in
 destructor if the process is still running
In-Reply-To: <1460501347.41.0.70782898945.issue26741@psf.upfronthosting.co.za>
Message-ID: <20160520110900.25871.46858.9AD917BD@psf.io>


Roundup Robot added the comment:

New changeset 72946937536e by Victor Stinner in branch '3.5':
asyncio: fix ResourceWarning related to subprocesses
https://hg.python.org/cpython/rev/72946937536e

New changeset 911f398c6396 by Victor Stinner in branch 'default':
Merge 3.5 (issue #26741)
https://hg.python.org/cpython/rev/911f398c6396

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26741>
_______________________________________

From report at bugs.python.org  Fri May 20 07:12:20 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 May 2016 11:12:20 +0000
Subject: [issue27068] Add a detach() method to subprocess.Popen
In-Reply-To: <1463739584.18.0.0161123331788.issue27068@psf.upfronthosting.co.za>
Message-ID: <1463742740.9.0.453336615306.issue27068@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Hum, I had to patch asyncio to avoid a ResourceWarning because asyncio polls the status of the child process using a child watcher, whereas the Popen object is not aware of the child watcher:

New changeset 72946937536e by Victor Stinner in branch '3.5':
asyncio: fix ResourceWarning related to subprocesses
https://hg.python.org/cpython/rev/72946937536e

The asyncio child watcher uses os.waitpid() on a specific pid or wait for the exit of any child process depending on the chosen implemetation. The fast watcher implementations uses a signal handler on the signal SIGCHLD.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27068>
_______________________________________

From report at bugs.python.org  Fri May 20 07:42:05 2016
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 20 May 2016 11:42:05 +0000
Subject: [issue26970] Replace OpenSSL's CPRNG with system entropy source
In-Reply-To: <1462525827.05.0.33480267606.issue26970@psf.upfronthosting.co.za>
Message-ID: <1463744525.34.0.172173856576.issue26970@psf.upfronthosting.co.za>


Christian Heimes added the comment:

My remark was ambiguous. I meant that I have to create an second implementation of _PyOS_URandom and use it in _ssl_osrandom_bytes.

Let's discuss the details on IRC after PyCon. I'm busy with preparations.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26970>
_______________________________________

From report at bugs.python.org  Fri May 20 07:42:12 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 May 2016 11:42:12 +0000
Subject: [issue25285] regrtest: run tests in subprocesses with -j1 on buildbots
In-Reply-To: <1443645362.81.0.234212686686.issue25285@psf.upfronthosting.co.za>
Message-ID: <1463744532.42.0.646342711579.issue25285@psf.upfronthosting.co.za>


STINNER Victor added the comment:

changeset:   101449:6f7e5b51c8fb
user:        Victor Stinner <victor.stinner at gmail.com>
date:        Fri May 20 13:15:55 2016 +0200
files:       Lib/test/libregrtest/cmdline.py Misc/NEWS Tools/buildbot/test.bat
description:
regrtest doesn't ignore -j1 anymore

* regrtest now uses subprocesses when the -j1 command line option
  is used: each test file runs in a fresh child process. Before, the -j1 option
  was ignored.
* Tools/buildbot/test.bat script now uses -j1 by default to run
  each test file in fresh child process.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25285>
_______________________________________

From report at bugs.python.org  Fri May 20 08:03:10 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 20 May 2016 12:03:10 +0000
Subject: [issue26741] subprocess.Popen should emit a ResourceWarning in
 destructor if the process is still running
In-Reply-To: <1460501347.41.0.70782898945.issue26741@psf.upfronthosting.co.za>
Message-ID: <1463745790.66.0.504352481545.issue26741@psf.upfronthosting.co.za>


Martin Panter added the comment:

I tried out your code on the webbrowser module, and it does raise a warning:

>>> import webbrowser
>>> b = webbrowser.get("chromium")
>>> b.open("https://bugs.python.org/issue26741")
/home/proj/python/cpython/Lib/subprocess.py:1011: ResourceWarning: running subprocess <subprocess.Popen object at 0x7f1ef31c90c0>
  source=self)
True

At this point, the Python interpreter has a child process ?chromium? which is left as a zombie when it exits. I guess the easiest solution (at least for Unix) would be to spawn an intermediate launcher process that exited after launching the web browser process.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26741>
_______________________________________

From report at bugs.python.org  Fri May 20 08:03:50 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 May 2016 12:03:50 +0000
Subject: [issue26741] subprocess.Popen should emit a ResourceWarning in
 destructor if the process is still running
In-Reply-To: <1460501347.41.0.70782898945.issue26741@psf.upfronthosting.co.za>
Message-ID: <1463745830.79.0.0784477327119.issue26741@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26741>
_______________________________________

From report at bugs.python.org  Fri May 20 08:05:27 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 May 2016 12:05:27 +0000
Subject: [issue26814] [WIP] Add a new _PyObject_FastCall() function which
 avoids the creation of a tuple or dict for arguments
In-Reply-To: <1461229041.59.0.994194592206.issue26814@psf.upfronthosting.co.za>
Message-ID: <1463745927.18.0.00474360242086.issue26814@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> unpickle_list: 1.11x faster

This result was unfair: my fastcall branch contained the optimization of the issue #27056. I just pushed this optimization into the default branch.

I ran again the benchmark: the result is now "not significant", as expected, since the benchmark is a microbenchmark testing C functions of Modules/_pickle.c, it doesn't really rely on the performance of (C or Python) functions calls.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26814>
_______________________________________

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: [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 08:24:37 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 May 2016 12:24:37 +0000
Subject: [issue26741] subprocess.Popen should emit a ResourceWarning in
 destructor if the process is still running
In-Reply-To: <1460501347.41.0.70782898945.issue26741@psf.upfronthosting.co.za>
Message-ID: <1463747077.46.0.412679700806.issue26741@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> At this point, the Python interpreter has a child process ?chromium? which is left as a zombie when it exits.

The new ResourceWarning is the confirmation that there is an issue. Creating a zombi process is not a good idea :-)

I opened the issue #27069 to fix this bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26741>
_______________________________________

From report at bugs.python.org  Fri May 20 08:54:50 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 20 May 2016 12:54:50 +0000
Subject: [issue27068] Add a detach() method to subprocess.Popen
In-Reply-To: <1463739584.18.0.0161123331788.issue27068@psf.upfronthosting.co.za>
Message-ID: <1463748890.65.0.675189792439.issue27068@psf.upfronthosting.co.za>


Martin Panter added the comment:

One potential way to fix Issue 27069 (leave a webbrowser running in the background) might be to use a detach() method. Pseudocode:

launcher = """\
import subprocess, sys
proc = subprocess.Popen(sys.argv)

# Popen object gives up ?ownership? of child.
# Caller exits straight afterwards, letting the OS take care of monitoring the child.
proc.detach()
"""

def open_firefox(url):
    cmd = (sys.executable, "-c", launcher, "firefox", url)
    subprocess.check_call(cmd)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27068>
_______________________________________

From report at bugs.python.org  Fri May 20 09:13:44 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 May 2016 13:13:44 +0000
Subject: [issue27068] Add a detach() method to subprocess.Popen
In-Reply-To: <1463748890.65.0.675189792439.issue27068@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZePmF=D3QhdQCgAxuy3wq5vtcHJuQaPpaST6WQ_cdJzg@mail.gmail.com>


STINNER Victor added the comment:

Martin Panter:
> One potential way to fix Issue 27069 (leave a webbrowser running in the background) might be to use a detach() method. Pseudocode:

Your code is a workaround to hide the warning, it doesn't fix the bug
(creating a zombi process).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27068>
_______________________________________

From report at bugs.python.org  Fri May 20 09:20:54 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 20 May 2016 13:20:54 +0000
Subject: [issue27068] Add a detach() method to subprocess.Popen
In-Reply-To: <1463739584.18.0.0161123331788.issue27068@psf.upfronthosting.co.za>
Message-ID: <1463750454.94.0.837932718241.issue27068@psf.upfronthosting.co.za>


Martin Panter added the comment:

In this example, I think we want to drop the zombie so the ?init? process will call wait() on it. My pseudocode is similar to your fork() suggestion in Issue 27069. Fork returns the child?s PID, but we would ignore the PID and exit the intermediate parent process instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27068>
_______________________________________

From report at bugs.python.org  Fri May 20 09:33:10 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 May 2016 13:33:10 +0000
Subject: [issue27069] webbrowser creates zombi processes in the background mode
In-Reply-To: <1463746997.46.0.620771266968.issue27069@psf.upfronthosting.co.za>
Message-ID: <1463751190.61.0.246272876037.issue27069@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I checked how "xdg-open http://www.python.org/" works. It looks like the command works as webbrowser: create a child process "firefox URL", but then it waits until the command completes.

In fact, "firefox URL" exits quickly. So we can try "background = False" for firefox. Well, at least with my Firefox 46.0.1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27069>
_______________________________________

From report at bugs.python.org  Fri May 20 10:07:35 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 20 May 2016 14:07:35 +0000
Subject: [issue27069] webbrowser creates zombi processes in the background mode
In-Reply-To: <1463746997.46.0.620771266968.issue27069@psf.upfronthosting.co.za>
Message-ID: <1463753255.31.0.152205065469.issue27069@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think the Firefox command will exit immediately if it just signals an existing Firefox process and window, but becomes the main Firefox process if there isn?t already one running.

Background = False sounds like it won?t help. Don?t we want the opposite?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27069>
_______________________________________

From report at bugs.python.org  Fri May 20 10:07:49 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 May 2016 14:07:49 +0000
Subject: [issue27056] pickle: constant propagation in _Unpickler_Read()
In-Reply-To: <1463659349.35.0.28600421781.issue27056@psf.upfronthosting.co.za>
Message-ID: <1463753269.69.0.834606005526.issue27056@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think that integer overflow in _Unpickler_Read() is possible. n is read from file and can be arbitrary (up to PY_SSIZE_T_MAX). This likely cause raising an exception later, but integer overflow itself causes undefined behavior, and we should avoid it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27056>
_______________________________________

From report at bugs.python.org  Fri May 20 10:23:24 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 20 May 2016 14:23:24 +0000
Subject: [issue25533] Make pkgutil.iter_modules() yield built-in modules
In-Reply-To: <1446462853.43.0.928344730721.issue25533@psf.upfronthosting.co.za>
Message-ID: <1463754204.82.0.756888758301.issue25533@psf.upfronthosting.co.za>


Martin Panter added the comment:

iter-builtins-flag.patch has support for built-in modules via the builtins=True flag, but I removed the support for frozen modules.

----------
stage:  -> patch review
Added file: http://bugs.python.org/file42916/iter-builtins-flag.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25533>
_______________________________________

From report at bugs.python.org  Fri May 20 12:48:02 2016
From: report at bugs.python.org (Steve Dower)
Date: Fri, 20 May 2016 16:48:02 +0000
Subject: [issue27064] Make py.exe default to Python 3 when used interactively
In-Reply-To: <1463693765.53.0.683202020216.issue27064@psf.upfronthosting.co.za>
Message-ID: <1463762882.91.0.915772343094.issue27064@psf.upfronthosting.co.za>


Steve Dower added the comment:

It'll change their default behavior if they get an alpha release of 3.6 though, and uninstalling the alpha won't revert it.

That said, I don't really feel like the launcher is an "alpha" product, even if the core Python engine is in that state. Possibly the RM has an opinion here?

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27064>
_______________________________________

From report at bugs.python.org  Fri May 20 13:13:15 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 20 May 2016 17:13:15 +0000
Subject: [issue24398] Update test_capi to use test.support.script_helper
In-Reply-To: <1433614432.33.0.0607159967244.issue24398@psf.upfronthosting.co.za>
Message-ID: <1463764395.23.0.357912099777.issue24398@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
components: +Tests
keywords: +easy
stage:  -> needs patch
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24398>
_______________________________________

From report at bugs.python.org  Fri May 20 13:16:04 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 20 May 2016 17:16:04 +0000
Subject: [issue9517] Make test.script_helper more comprehensive,
 and use it in the test suite
In-Reply-To: <1280962247.74.0.724550733964.issue9517@psf.upfronthosting.co.za>
Message-ID: <1463764564.63.0.00115782216053.issue9517@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
dependencies: +Update test_base64 to use test.support.script_helper, Update test_capi to use test.support.script_helper

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9517>
_______________________________________

From report at bugs.python.org  Fri May 20 13:28:24 2016
From: report at bugs.python.org (Paul Moore)
Date: Fri, 20 May 2016 17:28:24 +0000
Subject: [issue27064] Make py.exe default to Python 3 when used interactively
In-Reply-To: <1463693765.53.0.683202020216.issue27064@psf.upfronthosting.co.za>
Message-ID: <1463765304.06.0.0974971030008.issue27064@psf.upfronthosting.co.za>


Paul Moore added the comment:

Because of the nature of the launcher, there's not much we can do about that IMO. And there was no real objection to changing the default on the python-ideas thread (at least for interactive use).

But I'll wait to see if Ned has anything to add.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27064>
_______________________________________

From report at bugs.python.org  Fri May 20 14:20:34 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Fri, 20 May 2016 18:20:34 +0000
Subject: [issue9517] Make test.script_helper more comprehensive,
 and use it in the test suite
In-Reply-To: <1280962247.74.0.724550733964.issue9517@psf.upfronthosting.co.za>
Message-ID: <1463768434.42.0.143704934096.issue9517@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9517>
_______________________________________

From report at bugs.python.org  Fri May 20 14:26:03 2016
From: report at bugs.python.org (Mike Taylor)
Date: Fri, 20 May 2016 18:26:03 +0000
Subject: [issue24712] Docs page's sidebar vibrates on mouse wheel scroll on
 Chrome.
In-Reply-To: <1437780127.19.0.0270083299372.issue24712@psf.upfronthosting.co.za>
Message-ID: <1463768763.16.0.30032516296.issue24712@psf.upfronthosting.co.za>


Mike Taylor added the comment:

OK, so uh, somehow a few months escaped me before I could get to this. >_>

(I've also just signed the Contributor Agreement with the PSF)

----------
keywords: +patch
Added file: http://bugs.python.org/file42917/docs-sidebar.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24712>
_______________________________________

From report at bugs.python.org  Fri May 20 14:29:17 2016
From: report at bugs.python.org (Mike Taylor)
Date: Fri, 20 May 2016 18:29:17 +0000
Subject: [issue24712] Docs page's sidebar vibrates on mouse wheel scroll on
 Chrome.
In-Reply-To: <1437780127.19.0.0270083299372.issue24712@psf.upfronthosting.co.za>
Message-ID: <1463768957.32.0.362938391871.issue24712@psf.upfronthosting.co.za>


Mike Taylor added the comment:

The bug for Chrome to ship support of position: sticky is here: https://bugs.chromium.org/p/chromium/issues/detail?id=231752 -- it's in active development.

But this patch fixes the jerky sidebar in Firefox as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24712>
_______________________________________

From report at bugs.python.org  Fri May 20 15:17:50 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 May 2016 19:17:50 +0000
Subject: [issue27056] pickle: constant propagation in _Unpickler_Read()
In-Reply-To: <1463659349.35.0.28600421781.issue27056@psf.upfronthosting.co.za>
Message-ID: <20160520191746.47736.22608.F2B6422A@psf.io>


Roundup Robot added the comment:

New changeset 3d7b7aa89437 by Victor Stinner in branch 'default':
Issue #27056: Fix _Unpickler_Read() to avoid integer overflow
https://hg.python.org/cpython/rev/3d7b7aa89437

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27056>
_______________________________________

From report at bugs.python.org  Fri May 20 15:19:20 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 20 May 2016 19:19:20 +0000
Subject: [issue27056] pickle: constant propagation in _Unpickler_Read()
In-Reply-To: <1463753269.69.0.834606005526.issue27056@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwb__qHtFq4wpZk_Dme=a-23h_ZuEFCys7t5MHDy3f1ziA@mail.gmail.com>


STINNER Victor added the comment:

Serhiy Storchaka:
> I think that integer overflow in _Unpickler_Read() is possible. n is read from file and can be arbitrary (up to PY_SSIZE_T_MAX). This likely cause raising an exception later, but integer overflow itself causes undefined behavior, and we should avoid it.

Hum, I understood that it's ok since numbers should be signed, but in
fact I'm not confident that n is always signed. You are right, it's
better to use your code to avoid the integer overflow. I pushed a fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27056>
_______________________________________

From report at bugs.python.org  Fri May 20 15:32:26 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 May 2016 19:32:26 +0000
Subject: [issue26168] Py_BuildValue may leak 'N' arguments on PyTuple_New
 failure
In-Reply-To: <1453314385.46.0.703497250236.issue26168@psf.upfronthosting.co.za>
Message-ID: <20160520193220.123138.11862.120D81B9@psf.io>


Roundup Robot added the comment:

New changeset 4e605f809551 by Serhiy Storchaka in branch '3.5':
Issue #26168: Fixed possible refleaks in failing Py_BuildValue() with the "N"
https://hg.python.org/cpython/rev/4e605f809551

New changeset 0285173d81b4 by Serhiy Storchaka in branch '2.7':
Issue #26168: Fixed possible refleaks in failing Py_BuildValue() with the "N"
https://hg.python.org/cpython/rev/0285173d81b4

New changeset 03b32f854680 by Serhiy Storchaka in branch 'default':
Issue #26168: Fixed possible refleaks in failing Py_BuildValue() with the "N"
https://hg.python.org/cpython/rev/03b32f854680

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26168>
_______________________________________

From report at bugs.python.org  Fri May 20 15:33:34 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 May 2016 19:33:34 +0000
Subject: [issue26168] Py_BuildValue may leak 'N' arguments on PyTuple_New
 failure
In-Reply-To: <1453314385.46.0.703497250236.issue26168@psf.upfronthosting.co.za>
Message-ID: <1463772814.41.0.336312722177.issue26168@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your review Martin.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26168>
_______________________________________

From report at bugs.python.org  Fri May 20 15:33:43 2016
From: report at bugs.python.org (Ned Deily)
Date: Fri, 20 May 2016 19:33:43 +0000
Subject: [issue27064] Make py.exe default to Python 3 when used interactively
In-Reply-To: <1463693765.53.0.683202020216.issue27064@psf.upfronthosting.co.za>
Message-ID: <1463772823.54.0.489842887669.issue27064@psf.upfronthosting.co.za>


Ned Deily added the comment:

I don't have a strong opinion one way on the matter since I don't have any experience with the launcher.  I think I understand the issue of the Windows installer providing "release-independent" components (and, FTR, the OS X installer has a somewhat similar issue although the launcher there is believed to not be used much at all).  Whether we should change the defaults for future releases of 2.7.x and/or 3.5.x is probably ultimately up to the 2.7 and 3.6 release managers though I expect they would go along with whatever you all recommend.  If it does make sense to modify py.exe for 2.7.x and 3.5.x, then perhaps the corresponding change for 3.6 could be deferred until after 2.7.11 and 3.5.2 are released, which should be before 3.6.0a3, and all have consistent documentation of the changed behavior?  It's not perfect but at least all of the most recent binary releases would be consistent.

A somewhat unrelated comment on the patch:  will it be clear to users what is meant by "latest version installed"?  That is, what is meant by "latest version" in each of these cases: (scenario 1) install 2.7. then 3.5, then 3.6'; (scenario 2) install 3.5, 3.6, then 2.7; (scenario 3) install 3.6, 3.5, then 2.7; (scenario 4) install 3.6, 2.7, then 3.5.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27064>
_______________________________________

From report at bugs.python.org  Fri May 20 16:04:57 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 20 May 2016 20:04:57 +0000
Subject: [issue27063] Some unittest loader tests are silently skipped by
 mistake
In-Reply-To: <1463689872.02.0.411561520769.issue27063@psf.upfronthosting.co.za>
Message-ID: <1463774697.13.0.49163914213.issue27063@psf.upfronthosting.co.za>


Berker Peksag added the comment:

LGTM. Just curious, did you find it by reading code or by using some tool?

----------
nosy: +berker.peksag
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27063>
_______________________________________

From report at bugs.python.org  Fri May 20 16:06:57 2016
From: report at bugs.python.org (Robert Collins)
Date: Fri, 20 May 2016 20:06:57 +0000
Subject: [issue27063] Some unittest loader tests are silently skipped by
 mistake
In-Reply-To: <1463689872.02.0.411561520769.issue27063@psf.upfronthosting.co.za>
Message-ID: <1463774817.52.0.216362275097.issue27063@psf.upfronthosting.co.za>


Robert Collins added the comment:

LGTM too

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27063>
_______________________________________

From report at bugs.python.org  Fri May 20 16:30:14 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 20 May 2016 20:30:14 +0000
Subject: [issue27063] Some unittest loader tests are silently skipped by
 mistake
In-Reply-To: <1463689872.02.0.411561520769.issue27063@psf.upfronthosting.co.za>
Message-ID: <20160520203008.123142.34695.AA3FEC72@psf.io>


Roundup Robot added the comment:

New changeset e715ffd2d938 by Serhiy Storchaka in branch '3.5':
Issue #27063: Some unittest loader tests were silently skipped.
https://hg.python.org/cpython/rev/e715ffd2d938

New changeset f4f615edb6b1 by Serhiy Storchaka in branch 'default':
Issue #27063: Some unittest loader tests were silently skipped.
https://hg.python.org/cpython/rev/f4f615edb6b1

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27063>
_______________________________________

From report at bugs.python.org  Fri May 20 16:55:49 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 20 May 2016 20:55:49 +0000
Subject: [issue27063] Some unittest loader tests are silently skipped by
 mistake
In-Reply-To: <1463689872.02.0.411561520769.issue27063@psf.upfronthosting.co.za>
Message-ID: <1463777749.58.0.90741722349.issue27063@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for review.

I found this when wrote patches for removing deprecated features.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27063>
_______________________________________

From report at bugs.python.org  Fri May 20 16:55:55 2016
From: report at bugs.python.org (Paul Moore)
Date: Fri, 20 May 2016 20:55:55 +0000
Subject: [issue27064] Make py.exe default to Python 3 when used interactively
In-Reply-To: <1463693765.53.0.683202020216.issue27064@psf.upfronthosting.co.za>
Message-ID: <1463777755.32.0.989603296969.issue27064@psf.upfronthosting.co.za>


Paul Moore added the comment:

Thanks Ned. Personally, I'm still inclined *not* to add this to 2.7/3.5. People will get it when the install the 3.6 alphas, sure, but that seems to me to be a relatively obvious consequence of installing an alpha that includes a component that's used for all Python versions installed.

It seems to me that there will be the following categories of people:

1. No Python installed - this will just do the right thing (as would the old version).
2. Only 3.x installed - same as above.
3. Only 2.x installed - having the newly installed 3.6 become the default for the launcher seems like the expected behaviour.
4. Both 2.x and 3.x installed, and no py.ini setting the default - currently 2.x will be the default, and it will switch to 3.6. This is basically the point of the change. And it's an easy fix to add a py.ini reverting the default to 2.x.

People with a default set up in py.ini will be totally unaffected regardless.

To clarify things further for users in category (4), I've added a Misc/NEWS entry (which I should have done anyway) and an entry for "What's new".

As for the documentation using the term "latest Python version", I see what you're getting at, but I couldn't think of a better way of putting it without making the whole thing too convoluted for what is, after all, a pretty simple feature. (It's actually the *old* behaviour that's more complicated to describe). I'm happy to change it if someone can suggest a better wording, though.

----------
Added file: http://bugs.python.org/file42918/launcher2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27064>
_______________________________________

From report at bugs.python.org  Fri May 20 17:04:34 2016
From: report at bugs.python.org (Berker Peksag)
Date: Fri, 20 May 2016 21:04:34 +0000
Subject: [issue27067] Improve curses tests
In-Reply-To: <1463731355.86.0.176847535381.issue27067@psf.upfronthosting.co.za>
Message-ID: <1463778274.17.0.219552635506.issue27067@psf.upfronthosting.co.za>


Berker Peksag added the comment:

LGTM. I left some comments on Rietveld.

----------
nosy: +berker.peksag
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27067>
_______________________________________

From report at bugs.python.org  Fri May 20 17:04:53 2016
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 20 May 2016 21:04:53 +0000
Subject: [issue26865] Meta-issue: support of the android platform
In-Reply-To: <1461685011.99.0.617135447086.issue26865@psf.upfronthosting.co.za>
Message-ID: <1463778293.82.0.918455410278.issue26865@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Xavier: It's been long enough that I don't remember whether regular Users can adjust Dependencies, but since you didn't do it yourself I assume they can't.  I've just given you the Developer role, so you can now :)

----------
nosy: +zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26865>
_______________________________________

From report at bugs.python.org  Fri May 20 17:27:25 2016
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 20 May 2016 21:27:25 +0000
Subject: [issue27064] Make py.exe default to Python 3 when used interactively
In-Reply-To: <1463693765.53.0.683202020216.issue27064@psf.upfronthosting.co.za>
Message-ID: <1463779645.4.0.850020190819.issue27064@psf.upfronthosting.co.za>


Zachary Ware added the comment:

I'm very much +1 on the patch.

A couple thoughts:
- Note that 2.7 doesn't come with a launcher.

- As I understand it, the 3.5+ installer won't overwrite a newer launcher than what it would install, but the 3.4- installer will.  So the only really confusing (to my mind) thing that could happen would be someone installing 3.4 after 2.7 and 3.6, and the newly installed old 3.4 launcher reverts to defaulting to 2.x.  There's not much we can do about that, though: there will be no more 3.3 or 3.4 installers, so an update to the launcher in those branches would never see the light of day anyway.  I think this is an uncommon-enough situation that it can be ignored, but one possible way to work around it would be to install a pro-3 py.ini along with the launcher in 3.6+ (if it wouldn't be overwriting an existing py.ini).  Probably more effort than it's worth, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27064>
_______________________________________

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: [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 17:57:01 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Fri, 20 May 2016 21:57:01 +0000
Subject: [issue16858] tarfile silently hides errors
In-Reply-To: <1357286028.6.0.98597292825.issue16858@psf.upfronthosting.co.za>
Message-ID: <1463781421.77.0.86425034743.issue16858@psf.upfronthosting.co.za>


???? ????????? added the comment:

Can not reproduce in Linux. Will reopen if reproduced on MacOS X or BSD.

#!/usr/bin/python3.5

import os
import signal


p = os.getpid()

if os.fork() == 0:
    while True:
        try:
            os.kill(p, signal.SIGCHLD)
        except (ProcessLookupError, KeyboardInterrupt):
            break
    os._exit(0)

qwe = open('qwe.dat', 'w+b')
qwe.seek(2*1024*1024*1024*1024)
qwe.write(b'0')
qwe.flush()
qwe.seek(0)
while True:
    d = qwe.read(65536 * 32)
    if len(d) != 65536 * 32:
        raise Exception('!')

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16858>
_______________________________________

From report at bugs.python.org  Fri May 20 17:58:04 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Fri, 20 May 2016 21:58:04 +0000
Subject: [issue16858] tarfile silently hides errors
In-Reply-To: <1357286028.6.0.98597292825.issue16858@psf.upfronthosting.co.za>
Message-ID: <1463781484.77.0.61799669533.issue16858@psf.upfronthosting.co.za>


???? ????????? added the comment:

OOPS, closed wrong task, reopening.

----------
resolution: wont fix -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16858>
_______________________________________

From report at bugs.python.org  Fri May 20 17:58:30 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Fri, 20 May 2016 21:58:30 +0000
Subject: [issue26877] tarfile use wrong code when read from fileobj
In-Reply-To: <1461879882.57.0.719679075431.issue26877@psf.upfronthosting.co.za>
Message-ID: <1463781510.51.0.158856240611.issue26877@psf.upfronthosting.co.za>


???? ????????? added the comment:

Can not reproduce in Linux. Will reopen if reproduced on MacOS X or BSD.

#!/usr/bin/python3.5

import os
import signal


p = os.getpid()

if os.fork() == 0:
    while True:
        try:
            os.kill(p, signal.SIGCHLD)
        except (ProcessLookupError, KeyboardInterrupt):
            break
    os._exit(0)

qwe = open('qwe.dat', 'w+b')
qwe.seek(2*1024*1024*1024*1024)
qwe.write(b'0')
qwe.flush()
qwe.seek(0)
while True:
    d = qwe.read(65536 * 32)
    if len(d) != 65536 * 32:
        raise Exception('!')

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26877>
_______________________________________

From report at bugs.python.org  Fri May 20 18:30:14 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 May 2016 22:30:14 +0000
Subject: [issue27060] Documentation of assertItemsEqual in unittest is VERY
 misleading in 2.7
In-Reply-To: <1463688314.75.0.696545829281.issue27060@psf.upfronthosting.co.za>
Message-ID: <1463783414.93.0.0936679975382.issue27060@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Note: 2.7 doc says that this is renamed assertCountEqual in 3.x.  It was added in 2.7 and 3.2.  The 3.x doc is essentially the same, but with this instead: "Equivalent to: assertEqual(Counter(list(first)), Counter(list(second))) ...".

If the method misfunctions, then it should be fixed, not have the bug documented.  But you need to provide specific evidence and example.  The unittest in 3.x has this test with same number, different elements.
        self.assertRaises(self.failureException, self.assertCountEqual,
                          [1, 2] + [3] * 100, [1] * 100 + [2, 3])

I ran following test with same number, different items.
FAIL: test_Count (__main__.Test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "F:\Python\mypy\tem.py", line 4, in test_Count
    self.assertItemsEqual([1,2,3], [1,2,4])
AssertionError: Element counts were not equal:
First has 1, Second has 0:  3
First has 0, Second has 1:  4
 
This also fails in 3.5 with name change.

----------
components: +Library (Lib) -Documentation
nosy: +terry.reedy
stage:  -> test needed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27060>
_______________________________________

From report at bugs.python.org  Fri May 20 18:31:54 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 May 2016 22:31:54 +0000
Subject: [issue27060] Documentation of assertItemsEqual in unittest is VERY
 misleading in 2.7
In-Reply-To: <1463688314.75.0.696545829281.issue27060@psf.upfronthosting.co.za>
Message-ID: <1463783514.15.0.0394559618636.issue27060@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Here is the specific test code so you can replace my lists with examples that you think malfunction.

import unittest as u
class Test(u.TestCase):
    def test_Count(self):
        self.assertItemsEqual([1,2,3], [1,2,4])
u.main()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27060>
_______________________________________

From report at bugs.python.org  Fri May 20 18:41:10 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 May 2016 22:41:10 +0000
Subject: [issue27064] Make py.exe default to Python 3 when used interactively
In-Reply-To: <1463693765.53.0.683202020216.issue27064@psf.upfronthosting.co.za>
Message-ID: <1463784070.57.0.170167325974.issue27064@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

+1 By 'interactive use', I presume you mean at console command line
path\to\somewhere>py...

When I installed 3.4.4, I wondered if it would overwrite py with older version.  Great that 3.5.x does not.  I think each installer should have latest version of py.exe.  Really great if it could detect what version of py.exe is present, if any, and adjust option accordingly.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27064>
_______________________________________

From report at bugs.python.org  Fri May 20 19:05:36 2016
From: report at bugs.python.org (ppperry)
Date: Fri, 20 May 2016 23:05:36 +0000
Subject: [issue27070] Add ability to freeze (seal) mutable objects
In-Reply-To: <1463781153.76.0.520759085036.issue27070@psf.upfronthosting.co.za>
Message-ID: <1463785536.23.0.248028322761.issue27070@psf.upfronthosting.co.za>


ppperry added the comment:

Use tuples, frozensets, and bytes for the first three cases instead. I don't quite see what the benefit of this is. It seems arbitrarily restrictive.

----------
nosy: +ppperry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27070>
_______________________________________

From report at bugs.python.org  Fri May 20 19:13:15 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Fri, 20 May 2016 23:13:15 +0000
Subject: [issue27070] Add ability to freeze (seal) mutable objects
In-Reply-To: <1463781153.76.0.520759085036.issue27070@psf.upfronthosting.co.za>
Message-ID: <1463785995.65.0.938866146213.issue27070@psf.upfronthosting.co.za>


???? ????????? added the comment:

making tuples (from lists), fronzensets(from sets) and bytes (from bytearray) requires memory copying. Especially for bytearrays.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27070>
_______________________________________

From report at bugs.python.org  Fri May 20 19:21:55 2016
From: report at bugs.python.org (ppperry)
Date: Fri, 20 May 2016 23:21:55 +0000
Subject: [issue27070] Add ability to freeze (seal) mutable objects
In-Reply-To: <1463781153.76.0.520759085036.issue27070@psf.upfronthosting.co.za>
Message-ID: <1463786515.83.0.578598687269.issue27070@psf.upfronthosting.co.za>


ppperry added the comment:

Python is not the type of language in which one applies such memory micro-optimizations. In any case, if you really need to do this, use a custom class that subclasses `list` and overrides the modification methods to add a check.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27070>
_______________________________________

From report at bugs.python.org  Fri May 20 19:22:17 2016
From: report at bugs.python.org (Vitaly)
Date: Fri, 20 May 2016 23:22:17 +0000
Subject: [issue27060] Documentation of assertItemsEqual in unittest is VERY
 misleading in 2.7
In-Reply-To: <1463688314.75.0.696545829281.issue27060@psf.upfronthosting.co.za>
Message-ID: <1463786537.21.0.131559826359.issue27060@psf.upfronthosting.co.za>


Vitaly added the comment:

According to comment http://bugs.python.org/issue17866#msg188052 in #17866, the maintainers renamed `assertItemsEqual` to `assertCountEqual` somewhere in the 3.x development timeframe. They apparently latched on to the implementation of `assertItemsEqual` in 2.7.x, which compares counts only, rather than its documentation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27060>
_______________________________________

From report at bugs.python.org  Fri May 20 19:25:48 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 20 May 2016 23:25:48 +0000
Subject: [issue27070] Add ability to freeze (seal) mutable objects
In-Reply-To: <1463781153.76.0.520759085036.issue27070@psf.upfronthosting.co.za>
Message-ID: <1463786748.98.0.165551055215.issue27070@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

See the rejected PEP 351: https://www.python.org/dev/peps/pep-0351/

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27070>
_______________________________________

From report at bugs.python.org  Fri May 20 19:37:59 2016
From: report at bugs.python.org (Vitaly)
Date: Fri, 20 May 2016 23:37:59 +0000
Subject: [issue27060] Documentation of assertItemsEqual in unittest is VERY
 misleading in 2.7
In-Reply-To: <1463688314.75.0.696545829281.issue27060@psf.upfronthosting.co.za>
Message-ID: <1463787479.81.0.99120597078.issue27060@psf.upfronthosting.co.za>


Vitaly added the comment:

Thanks Terry, your assessment is correct. The maintainers appear to have drawn the wrong conclusion in #17866, which mislead me about the existing assertItemsEqual in 2.7, which appears to work correctly after all!

import unittest as u
class Test(u.TestCase):
    def test_equal_count_of_same_elements(self):
        self.assertItemsEqual([1,2,3], [1,2,3])

    def test_equal_count_of_different_elements(self):
        self.assertItemsEqual([1,2,3], [1,2,4])

    def test_different_count(self):
        self.assertItemsEqual([1,2,3], [1,2,3,4])
u.main()


$ python assert_items_equal_test.py --verbose
test_different_count (__main__.Test) ... FAIL
test_equal_count_of_different_elements (__main__.Test) ... FAIL
test_equal_count_of_same_elements (__main__.Test) ... ok

======================================================================
FAIL: test_different_count (__main__.Test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "assert_items_equal_test.py", line 12, in test_different_count
    self.assertItemsEqual([1,2,3], [1,2,3,4])
AssertionError: Element counts were not equal:
First has 0, Second has 1:  4

======================================================================
FAIL: test_equal_count_of_different_elements (__main__.Test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "assert_items_equal_test.py", line 8, in test_equal_count_of_different_elements
    self.assertItemsEqual([1,2,3], [1,2,4])
AssertionError: Element counts were not equal:
First has 1, Second has 0:  3
First has 0, Second has 1:  4

----------------------------------------------------------------------
Ran 3 tests in 0.001s

FAILED (failures=2)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27060>
_______________________________________

From report at bugs.python.org  Fri May 20 19:46:14 2016
From: report at bugs.python.org (Vitaly)
Date: Fri, 20 May 2016 23:46:14 +0000
Subject: [issue27060] Documentation of assertItemsEqual in unittest is VERY
 misleading in 2.7
In-Reply-To: <1463688314.75.0.696545829281.issue27060@psf.upfronthosting.co.za>
Message-ID: <1463787974.38.0.993804191588.issue27060@psf.upfronthosting.co.za>


Vitaly added the comment:

I think that we can close this as not a bug, as concerning 2.7. However, I think that 3.x made the wrong decision when it renamed assertItemsEqual with assertCountEqual, which now misleads users into thinking that it compares counts.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27060>
_______________________________________

From report at bugs.python.org  Fri May 20 19:50:16 2016
From: report at bugs.python.org (Vitaly)
Date: Fri, 20 May 2016 23:50:16 +0000
Subject: [issue17866] TestCase.assertItemsEqual exists in 2.7, not in 3.3
In-Reply-To: <1367222489.01.0.284119799467.issue17866@psf.upfronthosting.co.za>
Message-ID: <1463788216.96.0.787117618458.issue17866@psf.upfronthosting.co.za>


Vitaly added the comment:

Folks, assertCountEqual sounds like a really bad name. 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 better and more meaningful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17866>
_______________________________________

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: [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  Fri May 20 19:55:47 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 20 May 2016 23:55:47 +0000
Subject: [issue27060] Documentation of assertItemsEqual in unittest is VERY
 misleading in 2.7
In-Reply-To: <1463688314.75.0.696545829281.issue27060@psf.upfronthosting.co.za>
Message-ID: <1463788547.56.0.699295913313.issue27060@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

It compares element by element counts, as indicated by "Equivalent to: assertEqual(Counter(list(first)), Counter(list(second))) ..." and the failure messages.  Since I understand Counter equality, I ignore the rest.

----------
resolution:  -> not a bug
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27060>
_______________________________________

From report at bugs.python.org  Fri May 20 20:05:51 2016
From: report at bugs.python.org (Vitaly)
Date: Sat, 21 May 2016 00:05:51 +0000
Subject: [issue27060] Documentation of assertItemsEqual in unittest is VERY
 misleading in 2.7
In-Reply-To: <1463688314.75.0.696545829281.issue27060@psf.upfronthosting.co.za>
Message-ID: <1463789151.96.0.0275112185434.issue27060@psf.upfronthosting.co.za>


Vitaly added the comment:

Yes, this caused me to examine Counter, which I had not used before, and now I understand it, too. However, the new name by itself does not sufficiently reflect the subtlety of element-by-element counts, which does a disservice to the readability of test code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27060>
_______________________________________

From report at bugs.python.org  Fri May 20 20:06:25 2016
From: report at bugs.python.org (Vitaly)
Date: Sat, 21 May 2016 00:06:25 +0000
Subject: [issue27060] Documentation of assertItemsEqual in unittest is VERY
 misleading in 2.7
In-Reply-To: <1463688314.75.0.696545829281.issue27060@psf.upfronthosting.co.za>
Message-ID: <1463789185.27.0.877501183806.issue27060@psf.upfronthosting.co.za>


Vitaly added the comment:

... and an unnecessary incompatibility between 2.7 and 3.x

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27060>
_______________________________________

From report at bugs.python.org  Fri May 20 20:08:25 2016
From: report at bugs.python.org (Vitaly)
Date: Sat, 21 May 2016 00:08:25 +0000
Subject: [issue27071] unittest.TestCase.assertCountEqual is a very misleading
 name
In-Reply-To: <1463788380.52.0.782790370377.issue27071@psf.upfronthosting.co.za>
Message-ID: <1463789305.49.0.775790080381.issue27071@psf.upfronthosting.co.za>


Vitaly added the comment:

The new name by itself does not sufficiently reflect the subtlety of element-by-element counts, which does a disservice to the readability of test code. And it's also an unnecessary incompatibility between 2.7 and 3.x.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27071>
_______________________________________

From report at bugs.python.org  Sat May 21 00:34:46 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Sat, 21 May 2016 04:34:46 +0000
Subject: [issue27070] Add ability to freeze (seal) mutable objects
In-Reply-To: <1463781153.76.0.520759085036.issue27070@psf.upfronthosting.co.za>
Message-ID: <1463805286.24.0.322306214899.issue27070@psf.upfronthosting.co.za>


???? ????????? added the comment:

Great. Do you have information why this PEP was rejected? This was exactly what I want.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27070>
_______________________________________

From report at bugs.python.org  Sat May 21 01:11:04 2016
From: report at bugs.python.org (Gerrit Ansmann)
Date: Sat, 21 May 2016 05:11:04 +0000
Subject: [issue27059] find_spec and find_loader ignore package/path argument
In-Reply-To: <1463683793.33.0.38773604471.issue27059@psf.upfronthosting.co.za>
Message-ID: <1463807464.17.0.325708400942.issue27059@psf.upfronthosting.co.za>


Gerrit Ansmann added the comment:

> If you think the docs aren't clear enough then please feel free to submit a patch to make them a bit clearer.

I intend to do that. However, before I do so: Given that `find_loader` shall be superseded by `find_spec`, how would I use the latter to find the specs of a module that is not located in the current path, i.e., what is the current, non-deprecated way of doing `find_loader("spam", ["/foo/bar/"])`?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27059>
_______________________________________

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: [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 02:23:08 2016
From: report at bugs.python.org (SilentGhost)
Date: Sat, 21 May 2016 06:23:08 +0000
Subject: [issue27072] random.getrandbits is limited to 2**31-1 bits on 64-bit
 Windows
In-Reply-To: <1463810870.39.0.980113200971.issue27072@psf.upfronthosting.co.za>
Message-ID: <1463811788.96.0.206916762853.issue27072@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
components: +Extension Modules, Windows -Library (Lib)
nosy: +mark.dickinson, paul.moore, rhettinger, steve.dower, tim.golden, zach.ware
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27072>
_______________________________________

From report at bugs.python.org  Sat May 21 02:25:26 2016
From: report at bugs.python.org (SilentGhost)
Date: Sat, 21 May 2016 06:25:26 +0000
Subject: [issue27071] unittest.TestCase.assertCountEqual is a very misleading
 name
In-Reply-To: <1463788380.52.0.782790370377.issue27071@psf.upfronthosting.co.za>
Message-ID: <1463811926.06.0.987299889467.issue27071@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +ezio.melotti, michael.foord, rbcollins
type:  -> behavior
versions:  -Python 3.3, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27071>
_______________________________________

From report at bugs.python.org  Sat May 21 02:52:21 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 21 May 2016 06:52:21 +0000
Subject: [issue27027] add is_android in test.support to detect Android platform
In-Reply-To: <1463307075.8.0.646834682003.issue27027@psf.upfronthosting.co.za>
Message-ID: <1463813541.84.0.2731325535.issue27027@psf.upfronthosting.co.za>


Changes by Xavier de Gaye <xdegaye at gmail.com>:


----------
dependencies: +android: add platform.android_ver()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27027>
_______________________________________

From report at bugs.python.org  Sat May 21 02:55:00 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 21 May 2016 06:55:00 +0000
Subject: [issue26919] android: test_cmd_line fails
In-Reply-To: <1462267115.39.0.594600458307.issue26919@psf.upfronthosting.co.za>
Message-ID: <1463813700.52.0.266832282409.issue26919@psf.upfronthosting.co.za>


Changes by Xavier de Gaye <xdegaye at gmail.com>:


----------
dependencies: +add is_android in test.support to detect Android platform

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26919>
_______________________________________

From report at bugs.python.org  Sat May 21 02:56:37 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 21 May 2016 06:56:37 +0000
Subject: [issue26856] android does not have pwd.getpwall()
In-Reply-To: <1461677345.21.0.582848799296.issue26856@psf.upfronthosting.co.za>
Message-ID: <1463813797.09.0.821621434735.issue26856@psf.upfronthosting.co.za>


Changes by Xavier de Gaye <xdegaye at gmail.com>:


----------
dependencies: +add is_android in test.support to detect Android platform

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26856>
_______________________________________

From report at bugs.python.org  Sat May 21 02:58:00 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 21 May 2016 06:58:00 +0000
Subject: [issue26931] android: test_distutils fails
In-Reply-To: <1462285501.44.0.0195995288955.issue26931@psf.upfronthosting.co.za>
Message-ID: <1463813880.95.0.97612316024.issue26931@psf.upfronthosting.co.za>


Changes by Xavier de Gaye <xdegaye at gmail.com>:


----------
dependencies: +add is_android in test.support to detect Android platform

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26931>
_______________________________________

From report at bugs.python.org  Sat May 21 03:06:39 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 21 May 2016 07:06:39 +0000
Subject: [issue26865] Meta-issue: support of the android platform
In-Reply-To: <1461685011.99.0.617135447086.issue26865@psf.upfronthosting.co.za>
Message-ID: <1463814399.9.0.936182055909.issue26865@psf.upfronthosting.co.za>


Changes by Xavier de Gaye <xdegaye at gmail.com>:


----------
dependencies: +Large files are not supported on Android, RTLD_* macros are not defined on Android, add is_android in test.support to detect Android platform, android: test_cmd_line fails, android: test_concurrent_futures fails, android: test_concurrent_futures hangs on armv7, android: test_ctypes crashes on armv7, android: test_distutils fails, android: test_faulthandler fails, android: test_functools hangs on armv7, android: test_importlib hangs on armv7, android: test_mmap fails, android: test_multiprocessing_main_handling fails, android: test_os fails, android: test_pipes fails, android: test_posix fails, android: test_posixpath fails, android: test_site fails, android: test_socket fails, android: test_strptime fails, android: test_sys fails, android: test_tarfile fails, android: test_threading hangs on armv7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26865>
_______________________________________

From report at bugs.python.org  Sat May 21 03:09:58 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 21 May 2016 07:09:58 +0000
Subject: [issue26865] Meta-issue: support of the android platform
In-Reply-To: <1461685011.99.0.617135447086.issue26865@psf.upfronthosting.co.za>
Message-ID: <1463814598.89.0.485725792632.issue26865@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

No, regular users can't adjust dependencies, but I can now. Thanks Zachary.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26865>
_______________________________________

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: [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:42:24 2016
From: report at bugs.python.org (Oren Milman)
Date: Sat, 21 May 2016 07:42:24 +0000
Subject: [issue27073] redundant checks in long_add and long_sub
In-Reply-To: <1463816500.87.0.013124059613.issue27073@psf.upfronthosting.co.za>
Message-ID: <1463816544.09.0.154280666566.issue27073@psf.upfronthosting.co.za>


Changes by Oren Milman <orenmn at gmail.com>:


Added file: http://bugs.python.org/file42921/CPythonTestOutput.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27073>
_______________________________________

From report at bugs.python.org  Sat May 21 03:43:00 2016
From: report at bugs.python.org (Oren Milman)
Date: Sat, 21 May 2016 07:43:00 +0000
Subject: [issue27073] redundant checks in long_add and long_sub
In-Reply-To: <1463816500.87.0.013124059613.issue27073@psf.upfronthosting.co.za>
Message-ID: <1463816580.37.0.793830587413.issue27073@psf.upfronthosting.co.za>


Changes by Oren Milman <orenmn at gmail.com>:


Added file: http://bugs.python.org/file42922/patchedCPythonTestOutput.txt

_______________________________________
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: [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:08:08 2016
From: report at bugs.python.org (SilentGhost)
Date: Sat, 21 May 2016 08:08:08 +0000
Subject: [issue27073] redundant checks in long_add and long_sub
In-Reply-To: <1463816500.87.0.013124059613.issue27073@psf.upfronthosting.co.za>
Message-ID: <1463818088.49.0.750412083906.issue27073@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +haypo, serhiy.storchaka, yselivanov
stage:  -> patch review
type:  -> behavior
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27073>
_______________________________________

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: [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:22 2016
From: report at bugs.python.org (=?utf-8?q?Ville_Skytt=C3=A4?=)
Date: Sat, 21 May 2016 08:31:22 +0000
Subject: [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 04:44:47 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 21 May 2016 08:44:47 +0000
Subject: [issue27070] Add ability to freeze (seal) mutable objects
In-Reply-To: <1463781153.76.0.520759085036.issue27070@psf.upfronthosting.co.za>
Message-ID: <1463820287.22.0.696844828358.issue27070@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

There's a link in the PEP to the discussion on why it was rejected. There's a lot to read in the thread (I just spent 30 minutes re-reading it!).

I'm going to close this. If you'd like to re-open the discussion with new insights, I'd suggest posting to python-ideas. But, given the existing discussion referenced by the PEP, I don't have high hopes, unless you have a compelling use case (which is always possible, of course).

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27070>
_______________________________________

From report at bugs.python.org  Sat May 21 07:56:35 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 21 May 2016 11:56:35 +0000
Subject: [issue27075] Link to StreamReader/Writer from codecs.getreader/writer
In-Reply-To: <1463819173.18.0.0746227587463.issue27075@psf.upfronthosting.co.za>
Message-ID: <20160521115631.29804.24594.4231DF01@psf.io>


Roundup Robot added the comment:

New changeset c1628c1162a4 by Berker Peksag in branch '3.5':
Issue #27075: Link to StreamReader and StreamWriter docs
https://hg.python.org/cpython/rev/c1628c1162a4

New changeset b11b71aaf864 by Berker Peksag in branch 'default':
Issue #27075: Link to StreamReader and StreamWriter docs
https://hg.python.org/cpython/rev/b11b71aaf864

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27075>
_______________________________________

From report at bugs.python.org  Sat May 21 07:57:08 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 21 May 2016 11:57:08 +0000
Subject: [issue27075] Link to StreamReader/Writer from codecs.getreader/writer
In-Reply-To: <1463819173.18.0.0746227587463.issue27075@psf.upfronthosting.co.za>
Message-ID: <1463831828.31.0.797884486755.issue27075@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks, Ville.

----------
nosy: +berker.peksag
resolution:  -> fixed
stage:  -> resolved
status: open -> closed
versions: +Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27075>
_______________________________________

From report at bugs.python.org  Sat May 21 08:16:07 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 21 May 2016 12:16:07 +0000
Subject: [issue27076] Doc and comment spelling fixes
In-Reply-To: <1463819479.86.0.838684690734.issue27076@psf.upfronthosting.co.za>
Message-ID: <1463832967.32.0.225935146013.issue27076@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks Ville for this. It mostly looks good. I left some comments regarding ?heterogenous?.

I extended the patch with related fixes, mainly outside the Doc/ and Lib/ directories. Whoever commits this should also regenerate importlib, the configure script, and Arg Clinic code (not included in patches).

I?m not too sure about the Lib/msilib/schema.py file because it looks like generated code. But I see that other people have fixed it, so maybe that is okay.

----------
nosy: +martin.panter
stage:  -> patch review
versions: +Python 2.7, Python 3.5, Python 3.6
Added file: http://bugs.python.org/file42925/docs.v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27076>
_______________________________________

From report at bugs.python.org  Sat May 21 08:17:05 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 21 May 2016 12:17:05 +0000
Subject: [issue27067] Improve curses tests
In-Reply-To: <1463731355.86.0.176847535381.issue27067@psf.upfronthosting.co.za>
Message-ID: <1463833025.14.0.961233454387.issue27067@psf.upfronthosting.co.za>


Martin Panter added the comment:

I guess this might help Issue 12669 (running the test on buildbots)? I had assumed a real terminal was required, but it looks like you are substituting a temporary file.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27067>
_______________________________________

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: [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 08:32:03 2016
From: report at bugs.python.org (Paul Moore)
Date: Sat, 21 May 2016 12:32:03 +0000
Subject: [issue27064] Make py.exe default to Python 3 when used interactively
In-Reply-To: <1463693765.53.0.683202020216.issue27064@psf.upfronthosting.co.za>
Message-ID: <1463833923.13.0.251556634057.issue27064@psf.upfronthosting.co.za>


Paul Moore added the comment:

Terry: Correct.

As 3.4 is in security fix mode, and 2.7 doesn't come with the launcher (which I hadn't realised - thanks for pointing this out Zach!) the only real backport candidate is 3.5, so I definitely don't think it's worth backporting just for that.

Maybe it would be worth making a link available to the latest version of the installer, though, for people who want to upgrade. What do you think, Steve? From what you said I get the impression it's already there, just needs adding to the download page.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27064>
_______________________________________

From report at bugs.python.org  Sat May 21 09:30:41 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 21 May 2016 13:30:41 +0000
Subject: [issue22558] Missing doc links to source code
In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za>
Message-ID: <1463837441.68.0.495752974815.issue22558@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, Yoni. Like Guido said in msg257586, we only want to add links for pure Python modules. Can you update your patch to remove C modules please?

I'd prefer keep curses docs untouched. Lib/curses/* is basically a wrapper to _cursesmodule.c with some utility functions (sqlite3 is another example of this).

Another candidates for removal are distutils.core, wsgiref, ensurepip, formatted (it's deprecated), test (Lib/test is basically the test suite of CPython) modules.

----------
nosy: +berker.peksag
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22558>
_______________________________________

From report at bugs.python.org  Sat May 21 10:01:52 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 21 May 2016 14:01:52 +0000
Subject: [issue27073] redundant checks in long_add and long_sub
In-Reply-To: <1463816500.87.0.013124059613.issue27073@psf.upfronthosting.co.za>
Message-ID: <1463839312.94.0.374613869211.issue27073@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Your analysis and patch look good to me.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27073>
_______________________________________

From report at bugs.python.org  Sat May 21 10:48:25 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 21 May 2016 14:48:25 +0000
Subject: [issue27073] redundant checks in long_add and long_sub
In-Reply-To: <1463816500.87.0.013124059613.issue27073@psf.upfronthosting.co.za>
Message-ID: <1463842105.34.0.899502059288.issue27073@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Sorry, I didn't check if the change is valid or not, but:

>  issue.diff 

Please keep the check but as an assertion (Put it in the if block).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27073>
_______________________________________

From report at bugs.python.org  Sat May 21 10:52:40 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 21 May 2016 14:52:40 +0000
Subject: [issue5187] distutils upload should prompt for the user/password too
In-Reply-To: <1234128468.86.0.0554273106388.issue5187@psf.upfronthosting.co.za>
Message-ID: <1463842360.5.0.034925707636.issue5187@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Issue 18454 is a duplicate of this, but I'm going to close this one (there are patches for 2.7 and 3.5 in issue 18454).

----------
nosy: +berker.peksag
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder:  -> distutils crashes when uploading to PyPI having only the username (no pw) defined

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5187>
_______________________________________

From report at bugs.python.org  Sat May 21 11:07:58 2016
From: report at bugs.python.org (Oren Milman)
Date: Sat, 21 May 2016 15:07:58 +0000
Subject: [issue27073] redundant checks in long_add and long_sub
In-Reply-To: <1463816500.87.0.013124059613.issue27073@psf.upfronthosting.co.za>
Message-ID: <1463843278.54.0.236381418963.issue27073@psf.upfronthosting.co.za>


Oren Milman added the comment:

Thanks for the reviews!

I added an assert in long_add (in long_sub it might be that the result is 0).
The updated diff file is attached.

----------
Added file: http://bugs.python.org/file42926/issue27073.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27073>
_______________________________________

From report at bugs.python.org  Sat May 21 11:14:21 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 21 May 2016 15:14:21 +0000
Subject: [issue13615] setup.py register fails with -r argument
In-Reply-To: <1324070497.95.0.248126770194.issue13615@psf.upfronthosting.co.za>
Message-ID: <1463843661.44.0.968828608079.issue13615@psf.upfronthosting.co.za>


Berker Peksag added the comment:

The repository URL has been changed to https://pypi.python.org/pypi in 2b5cd6d4d149. I'm -1 on making https://pypi.python.org/ a special case.

----------
nosy: +berker.peksag
resolution:  -> out of date
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue13615>
_______________________________________

From report at bugs.python.org  Sat May 21 11:25:42 2016
From: report at bugs.python.org (Upendra Kumar)
Date: Sat, 21 May 2016 15:25:42 +0000
Subject: [issue27051] Create PIP gui
In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za>
Message-ID: <1463844342.55.0.712545302976.issue27051@psf.upfronthosting.co.za>


Upendra Kumar added the comment:

I have uploaded my first iteration of design process for Tkinter. In the uploaded document "Design_notes_v1.docx", we have tried to identify different use cases and tasks to be fulfilled by the PIP GUI.

If there are any suggestions regarding further changes or possible use cases, please let me know. I will upload design of different page layouts for the GUI soon.

----------
Added file: http://bugs.python.org/file42927/Design_notes_v1.docx

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27051>
_______________________________________

From report at bugs.python.org  Sat May 21 12:23:28 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 21 May 2016 16:23:28 +0000
Subject: [issue26928] _bootlocale imports locale at startup on Android
In-Reply-To: <1462284365.5.0.819379627022.issue26928@psf.upfronthosting.co.za>
Message-ID: <1463847807.99.0.894396357929.issue26928@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Sorry for the confusion, the file system encoding is not the locale encoding.

In issue #9548, Antoine proposed a patch that avoids the import of the re, collections and functools modules by the _io module on startup, by refactoring and moving code from locale to _bootlocale. The attached refactor_locale.patch does that for python 3.6. The reasons for why Antoine patch has not been pushed still apply to this patch :(

The patch does fix the problem for Android though.

----------
keywords: +patch
title: android: test_site fails -> _bootlocale imports locale at startup on Android
Added file: http://bugs.python.org/file42928/refactor_locale.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26928>
_______________________________________

From report at bugs.python.org  Sat May 21 12:28:31 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sat, 21 May 2016 16:28:31 +0000
Subject: [issue26928] _bootlocale imports locale at startup on Android
In-Reply-To: <1462284365.5.0.819379627022.issue26928@psf.upfronthosting.co.za>
Message-ID: <1463848111.9.0.65000879489.issue26928@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

An improvement to Python startup time on Android (Android does not have nl_langinfo()) is to have _bootlocale.getpreferredencoding() return 'ascii' without importing locale, when none of the locale environment variables is set. With patch no-locale-envvar.patch, test_site runs ok on android-21-x86 emulator when the locale environment variables are not set.

Committing this patch while leaving the current issue open would also allow removing this issue from the dependencies of the Android meta-issue #26865.

----------
Added file: http://bugs.python.org/file42929/no-locale-envvar.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26928>
_______________________________________

From report at bugs.python.org  Sat May 21 12:38:23 2016
From: report at bugs.python.org (Steve Dower)
Date: Sat, 21 May 2016 16:38:23 +0000
Subject: [issue27064] Make py.exe default to Python 3 when used interactively
In-Reply-To: <1463693765.53.0.683202020216.issue27064@psf.upfronthosting.co.za>
Message-ID: <1463848703.86.0.848903751128.issue27064@psf.upfronthosting.co.za>


Steve Dower added the comment:

Unfortunately, the current MSI for the launcher doesn't have a great interface when used separately from the main installer. It happens to be more functional than the rest (i.e. double-clicking it will give you a very quick per-user install, whereas the other MSIs that make up the installer will fail), but it's not at a point where I'd be comfortable to link directly to it.

Could I get it there? Absolutely. Not a real high priority though - there are some weird upgrade/modify edge cases that I'd rather figure out first.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27064>
_______________________________________

From report at bugs.python.org  Sat May 21 12:41:48 2016
From: report at bugs.python.org (lorenzogotuned)
Date: Sat, 21 May 2016 16:41:48 +0000
Subject: [issue27051] Create PIP gui
In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za>
Message-ID: <1463848908.55.0.737436068645.issue27051@psf.upfronthosting.co.za>


lorenzogotuned added the comment:

Ok Upendra. Nice summary. 

In the next days:
- Explain each *top task* (install, unistall, update) and in detail the way the underlying pip commands work (underline mandatory and optional parameters, requests performed to servers, filesystem storage and anything involved)
- Map your natural explanation into different *page views* (each page view conrainig well defined UI components and structures)
- Design and *sketch* each page (upload image files. I saw you had started doing it in the previous issue; make them much more explicative, name or assign a number to each view and UI component)
- Simplify and optimize each task flow and page (get familiar and be precise with the vocabulary needed to describe the UI)
- write at least one user case for command (install: user search the xyz string in a package in the input box, user clicks on a item in the ywz panel, the user clicks the abc button, etc) in the shape of ordered lists or better flow charts.

This will complete the first design iteration.

After receiving feedback and adjusting the sketches, I think we can dive into tkinter to find the right objects/patterns to start coding.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27051>
_______________________________________

From report at bugs.python.org  Sat May 21 14:22:40 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 21 May 2016 18:22:40 +0000
Subject: [issue23551] IDLE to provide menu link to PIP gui.
In-Reply-To: <1425155752.55.0.0736033483828.issue23551@psf.upfronthosting.co.za>
Message-ID: <1463854960.38.0.16846498387.issue23551@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Upendra Kumar's GSOC pip-gui proposal has been accepted.  It is issue #27051 and progress can be followed there.  I leave this issue open, at least for now, for invoking the gui from IDLE.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23551>
_______________________________________

From report at bugs.python.org  Sat May 21 14:41:30 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 21 May 2016 18:41:30 +0000
Subject: [issue27067] Improve curses tests
In-Reply-To: <1463731355.86.0.176847535381.issue27067@psf.upfronthosting.co.za>
Message-ID: <20160521184128.27161.57885.3028047F@psf.io>


Roundup Robot added the comment:

New changeset 55852de7d032 by Serhiy Storchaka in branch '3.5':
Issue #27067: Improved curses tests.
https://hg.python.org/cpython/rev/55852de7d032

New changeset 2917a3ce988e by Serhiy Storchaka in branch 'default':
Issue #27067: Improved curses tests.
https://hg.python.org/cpython/rev/2917a3ce988e

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27067>
_______________________________________

From report at bugs.python.org  Sat May 21 14:42:56 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 May 2016 18:42:56 +0000
Subject: [issue27067] Improve curses tests
In-Reply-To: <1463731355.86.0.176847535381.issue27067@psf.upfronthosting.co.za>
Message-ID: <1463856176.16.0.626793458743.issue27067@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your review Berker.

----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27067>
_______________________________________

From report at bugs.python.org  Sat May 21 14:56:50 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 21 May 2016 18:56:50 +0000
Subject: [issue27051] Create PIP gui
In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za>
Message-ID: <1463857010.39.0.432219619412.issue27051@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I posted notice of this issue on #23551.

I did some research on simulating user interaction for testing.  The results are exemplified in the attached tk.generate_event.py with test setups and assertions.

Events are generated, to fire event handlers, with
  widget.generate_event(event, **kwds)
where keywords are used to set event attributes.  The uploaded file has examples.  The method is briefly described in
  http://infohost.nmt.edu/tcc/help/pubs/tkinter/web/universal.html
This reference has a more extensive coverage of events in a separate chapter.

The above does not mention the need to update the widget first.  I learned this from Stackoverflow answers to 'How to make generate_event work?" questions.  The tcl/tk doc, tcl.tk/man/tcl8.6/TkCmd/event.htm, adds the fact that text widgets require focus.

Even though button commands fire when releasing the 'main' button, event '<ButtonRelease-1>' does not work to fire commands.  Instead, use 'button.invoke()'.

----------
stage:  -> test needed
versions: +Python 3.6
Added file: http://bugs.python.org/file42930/tk_generate_event.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27051>
_______________________________________

From report at bugs.python.org  Sat May 21 15:16:07 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 21 May 2016 19:16:07 +0000
Subject: [issue27051] Create PIP gui
In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za>
Message-ID: <1463858167.46.0.834219371867.issue27051@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

My main concern is that the project produce something good enough, even if not 'perfect' and 'complete', to commit before 3.6.0 beta 1, scheduled 09-07 https://www.python.org/dev/peps/pep-0494/.  I would actually like to have a preliminary version in alpha 4 (08-08) or even alpha 3 (07-11).  It would be good to get user feedback before the summer is over.  I will try to document the GUI in such a way that the detailed layout and operation are not locked in, but can be amended and augmented.

For style, follow PEP 8.  Ask any questions about alternatives and ambiguities here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27051>
_______________________________________

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: [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 15:22:45 2016
From: report at bugs.python.org (Ned Deily)
Date: Sat, 21 May 2016 19:22:45 +0000
Subject: [issue27078] Make f'' strings faster than .format: BUILD_STRING
 opcode?
In-Reply-To: <1463858316.54.0.292581402272.issue27078@psf.upfronthosting.co.za>
Message-ID: <1463858565.51.0.338411818683.issue27078@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27078>
_______________________________________

From report at bugs.python.org  Sat May 21 15:40:44 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 21 May 2016 19:40:44 +0000
Subject: [issue27077] test_port_parameter_types fails with BytesWarning
In-Reply-To: <1463833629.03.0.694431281551.issue27077@psf.upfronthosting.co.za>
Message-ID: <1463859644.19.0.150240950409.issue27077@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

I really can't figure out what's going on. I can't reproduce this, and the exception doesn't make any sense :(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27077>
_______________________________________

From report at bugs.python.org  Sat May 21 15:44:44 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 21 May 2016 19:44:44 +0000
Subject: [issue27078] Make f'' strings faster than .format: BUILD_STRING
 opcode?
In-Reply-To: <1463858316.54.0.292581402272.issue27078@psf.upfronthosting.co.za>
Message-ID: <1463859884.32.0.525122010335.issue27078@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
assignee:  -> eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27078>
_______________________________________

From report at bugs.python.org  Sat May 21 15:56:01 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 21 May 2016 19:56:01 +0000
Subject: [issue27077] test_port_parameter_types fails with BytesWarning
In-Reply-To: <1463833629.03.0.694431281551.issue27077@psf.upfronthosting.co.za>
Message-ID: <1463860561.27.0.0909732491549.issue27077@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Alright, I think I know what's going on here -- this seems to be a bug of functools.lrucache.  Serhiy, would you be able to look into this?

Testcase:

test.py:

    import functools

    @functools.lru_cache()
    def foo(a):
        return

    foo('')
    foo(b'')

$ python3.5 -bb test.py
Traceback (most recent call last):
  File "test.py", line 8, in <module>
    foo(b'')
BytesWarning: Comparison between bytes and string

----------
nosy: +haypo, rhettinger, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27077>
_______________________________________

From report at bugs.python.org  Sat May 21 15:59:40 2016
From: report at bugs.python.org (Paul Moore)
Date: Sat, 21 May 2016 19:59:40 +0000
Subject: [issue27064] Make py.exe default to Python 3 when used interactively
In-Reply-To: <1463693765.53.0.683202020216.issue27064@psf.upfronthosting.co.za>
Message-ID: <1463860780.64.0.260482535482.issue27064@psf.upfronthosting.co.za>


Paul Moore added the comment:

OK, no problem. Like you say, not a high priority.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27064>
_______________________________________

From report at bugs.python.org  Sat May 21 16:10:00 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 May 2016 20:10:00 +0000
Subject: [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:15:28 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 21 May 2016 20:15:28 +0000
Subject: [issue27078] Make f'' strings faster than .format: BUILD_STRING
 opcode?
In-Reply-To: <1463858316.54.0.292581402272.issue27078@psf.upfronthosting.co.za>
Message-ID: <1463861728.34.0.240646145732.issue27078@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

I considered doing this, and have some of it implemented. I discussed it with Larry Hastings and Mark Shannon at PyCon Ireland, and we decided to just use ''.format() and the new FORMAT_VALUE opcode, since that was the simplest way to fix the previous implementation's faults. That doesn't mean I've given up on improving it, of course.

The speed increase would indeed come from avoiding the LOAD_ATTR lookup, not building list, and not calling a function.

I'm curious about your benchmarks. Can you share them? I've found f-strings to be typically faster than .format(). But I can't say my benchmarks are particularly awesome.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27078>
_______________________________________

From report at bugs.python.org  Sat May 21 16:37:53 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 21 May 2016 20:37:53 +0000
Subject: [issue27077] test_port_parameter_types fails with BytesWarning
In-Reply-To: <1463833629.03.0.694431281551.issue27077@psf.upfronthosting.co.za>
Message-ID: <1463863073.07.0.793586402814.issue27077@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The workaround is using lru_cache(typed=True).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27077>
_______________________________________

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: [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 16:38:30 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 21 May 2016 20:38:30 +0000
Subject: [issue26331] Tokenizer: allow underscores for grouping in numeric
 literals
In-Reply-To: <1455126624.48.0.163167904941.issue26331@psf.upfronthosting.co.za>
Message-ID: <1463863110.15.0.0884167208328.issue26331@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

I've created issue 27080 to track the formatting part of this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26331>
_______________________________________

From report at bugs.python.org  Sat May 21 16:39:00 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 21 May 2016 20:39:00 +0000
Subject: [issue27080] Implement the formatting part of PEP 515,
 '_' in numeric literals.
In-Reply-To: <1463863089.86.0.119019547094.issue27080@psf.upfronthosting.co.za>
Message-ID: <1463863140.95.0.420120853158.issue27080@psf.upfronthosting.co.za>


Changes by Eric V. Smith <eric at trueblade.com>:


----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27080>
_______________________________________

From report at bugs.python.org  Sat May 21 16:40:22 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 21 May 2016 20:40:22 +0000
Subject: [issue27077] test_port_parameter_types fails with BytesWarning
In-Reply-To: <1463833629.03.0.694431281551.issue27077@psf.upfronthosting.co.za>
Message-ID: <1463863222.77.0.298728730321.issue27077@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> The workaround is using lru_cache(typed=True).

Yes, seems to be working! Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27077>
_______________________________________

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: [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 17:04:59 2016
From: report at bugs.python.org (ppperry)
Date: Sat, 21 May 2016 21:04:59 +0000
Subject: [issue27081] Multiprocessing is not robust against sys.stderr changes
In-Reply-To: <1463864673.26.0.0758761622573.issue27081@psf.upfronthosting.co.za>
Message-ID: <1463864699.04.0.445676522042.issue27081@psf.upfronthosting.co.za>


Changes by ppperry <mapreader at olum.org>:


----------
nosy: +jnoller, sbt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27081>
_______________________________________

From report at bugs.python.org  Sat May 21 17:12:13 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Sat, 21 May 2016 21:12:13 +0000
Subject: [issue27077] test_port_parameter_types fails with BytesWarning
In-Reply-To: <1463833629.03.0.694431281551.issue27077@psf.upfronthosting.co.za>
Message-ID: <1463865133.69.0.469231214289.issue27077@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

Berker, it should be fixed now in https://hg.python.org/cpython/rev/bdfb15aa3ac5 (sorry, I forgot to reference the issue in the commit message)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27077>
_______________________________________

From report at bugs.python.org  Sat May 21 17:12:27 2016
From: report at bugs.python.org (ppperry)
Date: Sat, 21 May 2016 21:12:27 +0000
Subject: [issue27081] Multiprocessing is not robust against sys.stderr changes
In-Reply-To: <1463864673.26.0.0758761622573.issue27081@psf.upfronthosting.co.za>
Message-ID: <1463865147.56.0.523435184171.issue27081@psf.upfronthosting.co.za>


ppperry added the comment:

Replacing the first line with `queue = multiprocessing.SimpleQueue()` fixes this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27081>
_______________________________________

From report at bugs.python.org  Sat May 21 17:16:36 2016
From: report at bugs.python.org (ppperry)
Date: Sat, 21 May 2016 21:16:36 +0000
Subject: [issue26928] _bootlocale imports locale at startup on Android,
 causing test_site to fail
In-Reply-To: <1462284365.5.0.819379627022.issue26928@psf.upfronthosting.co.za>
Message-ID: <1463865396.21.0.994907369884.issue26928@psf.upfronthosting.co.za>


Changes by ppperry <mapreader at olum.org>:


----------
title: _bootlocale imports locale at startup on Android -> _bootlocale imports locale at startup on Android, causing test_site to fail

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26928>
_______________________________________

From report at bugs.python.org  Sat May 21 17:17:26 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 21 May 2016 21:17:26 +0000
Subject: [issue27077] test_port_parameter_types fails with BytesWarning
In-Reply-To: <1463833629.03.0.694431281551.issue27077@psf.upfronthosting.co.za>
Message-ID: <1463865446.82.0.808955760596.issue27077@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Yes, buildbots look happy now. Thanks!

----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27077>
_______________________________________

From report at bugs.python.org  Sat May 21 17:21:17 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 21 May 2016 21:21:17 +0000
Subject: [issue27077] test_port_parameter_types fails with BytesWarning
In-Reply-To: <1463833629.03.0.694431281551.issue27077@psf.upfronthosting.co.za>
Message-ID: <1463865677.61.0.478047631986.issue27077@psf.upfronthosting.co.za>


STINNER Victor added the comment:

On Python 3, comparison between str and bytes raises a BytesWarning exception if python3 is started with -bb. But sometimes, you really want to compare str with bytes. For example, os.get_exec_path() changes temporarely the BytesWarning warning for that!

    # {b'PATH': ...}.get('PATH') and {'PATH': ...}.get(b'PATH') emit a
    # BytesWarning when using python -b or python -bb: ignore the warning
    with warnings.catch_warnings():
        warnings.simplefilter("ignore", BytesWarning)
        ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27077>
_______________________________________

From report at bugs.python.org  Sat May 21 18:12:17 2016
From: report at bugs.python.org (Martijn Pieters)
Date: Sat, 21 May 2016 22:12:17 +0000
Subject: [issue27078] Make f'' strings faster than .format: BUILD_STRING
 opcode?
In-Reply-To: <1463858316.54.0.292581402272.issue27078@psf.upfronthosting.co.za>
Message-ID: <1463868737.81.0.606595742666.issue27078@psf.upfronthosting.co.za>


Changes by Martijn Pieters <mj at python.org>:


----------
nosy: +mjpieters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27078>
_______________________________________

From report at bugs.python.org  Sat May 21 18:16:07 2016
From: report at bugs.python.org (Martijn Pieters)
Date: Sat, 21 May 2016 22:16:07 +0000
Subject: [issue27078] Make f'' strings faster than .format: BUILD_STRING
 opcode?
In-Reply-To: <1463858316.54.0.292581402272.issue27078@psf.upfronthosting.co.za>
Message-ID: <1463868967.24.0.691012820942.issue27078@psf.upfronthosting.co.za>


Martijn Pieters added the comment:

The catalyst for this question was a Stack Overflow question I answered: 

    https://stackoverflow.com/questions/37365311/why-are-python-3-6-literal-formatted-strings-so-slow

Compared the `str.format()` the BUILD_LIST is the bottleneck here; dropping the LOAD_ATTR and CALL_FUNCTION opcodes are nice bonuses.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27078>
_______________________________________

From report at bugs.python.org  Sat May 21 18:24:17 2016
From: report at bugs.python.org (Ned Deily)
Date: Sat, 21 May 2016 22:24:17 +0000
Subject: [issue27081] Multiprocessing is not robust against sys.stderr changes
In-Reply-To: <1463864673.26.0.0758761622573.issue27081@psf.upfronthosting.co.za>
Message-ID: <1463869457.59.0.397856418859.issue27081@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
nosy: +davin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27081>
_______________________________________

From report at bugs.python.org  Sat May 21 18:31:48 2016
From: report at bugs.python.org (Joshua Jay Herman)
Date: Sat, 21 May 2016 22:31:48 +0000
Subject: [issue24459] Mention PYTHONFAULTHANDLER in the man page
In-Reply-To: <1434487895.85.0.561507121326.issue24459@psf.upfronthosting.co.za>
Message-ID: <1463869908.44.0.795413473334.issue24459@psf.upfronthosting.co.za>


Joshua Jay Herman added the comment:

Hi, I have alphabetized and added the missing Environment Variables according to Section 1.2 https://docs.python.org/3.6/using/cmdline.html#environment-variables . I also added the missing environment variables from that documentation section.

Should Section 1.2 also be alphabetized? I noticed it wasn't.

This is my first contribution to python (I also just filled out the contributor forms) any comments and criticism is appreciated.

----------
keywords: +patch
nosy: +zitterbewegung
Added file: http://bugs.python.org/file42932/addMissingEnvVarsAndAlphabetize.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24459>
_______________________________________

From report at bugs.python.org  Sat May 21 19:27:00 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 21 May 2016 23:27:00 +0000
Subject: [issue27067] Improve curses tests
In-Reply-To: <1463731355.86.0.176847535381.issue27067@psf.upfronthosting.co.za>
Message-ID: <1463873220.48.0.610215046372.issue27067@psf.upfronthosting.co.za>


Martin Panter added the comment:

A couple buildbots don?t look happy with this change, e.g.

http://buildbot.python.org/all/builders/x86%20Ubuntu%20Shared%203.5/builds/903/steps/test/logs/stdio

======================================================================
ERROR: test_colors_funcs (test.test_curses.TestCurses)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.5.bolen-ubuntu/build/Lib/test/test_curses.py", line 66, in setUp
    curses.savetty()
_curses.error: savetty() returned ERR

(more failures follow)

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27067>
_______________________________________

From report at bugs.python.org  Sat May 21 19:30:01 2016
From: report at bugs.python.org (Campbell Barton)
Date: Sat, 21 May 2016 23:30:01 +0000
Subject: [issue27072] random.getrandbits is limited to 2**31-1 bits on 64-bit
 Windows
In-Reply-To: <1463810870.39.0.980113200971.issue27072@psf.upfronthosting.co.za>
Message-ID: <1463873401.85.0.788169649868.issue27072@psf.upfronthosting.co.za>


Campbell Barton added the comment:

> This probably isn't an issue on non-Windows or 64-bit systems.

In fact it is, the limitation applies to 64bit Linux too. (tested in CPython 3.5.1)

----------
nosy: +ideasman42

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27072>
_______________________________________

From report at bugs.python.org  Sat May 21 20:34:29 2016
From: report at bugs.python.org (Yoni Lavi)
Date: Sun, 22 May 2016 00:34:29 +0000
Subject: [issue22558] Missing doc links to source code
In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za>
Message-ID: <1463877269.05.0.263160801677.issue22558@psf.upfronthosting.co.za>


Yoni Lavi added the comment:

Thank you for the review, Berker.
I removed source code links from all the modules you specifically mentioned, and all links to C code, including stat.rst which already had such a link before.

But I have to say that I don't quite understand the rationale here and (as a user) would personally prefer easy access to all source code, both C and Python. It is my opinion that a handy link to the source would help promote the conversion of library users to contributors.

----------
Added file: http://bugs.python.org/file42933/mywork2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22558>
_______________________________________

From report at bugs.python.org  Sat May 21 20:37:34 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 22 May 2016 00:37:34 +0000
Subject: [issue27072] random.getrandbits is limited to 2**31-1 bits on 64-bit
 Windows
In-Reply-To: <1463810870.39.0.980113200971.issue27072@psf.upfronthosting.co.za>
Message-ID: <1463877454.78.0.618829378481.issue27072@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27072>
_______________________________________

From report at bugs.python.org  Sat May 21 20:40:53 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 22 May 2016 00:40:53 +0000
Subject: [issue27072] random.getrandbits is limited to 2**31-1 bits on 64-bit
 Windows
In-Reply-To: <1463810870.39.0.980113200971.issue27072@psf.upfronthosting.co.za>
Message-ID: <1463877653.14.0.935042135294.issue27072@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27072>
_______________________________________

From report at bugs.python.org  Sat May 21 21:21:09 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 22 May 2016 01:21:09 +0000
Subject: [issue27072] random.getrandbits is limited to 2**31-1 bits on 64-bit
 Windows
In-Reply-To: <1463810870.39.0.980113200971.issue27072@psf.upfronthosting.co.za>
Message-ID: <1463880069.28.0.920000986238.issue27072@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Since the downstream calls to PyMem_Malloc and _PyLong_FromByteArray both accept size_t for their sizing, there isn't a problem there.

That said, I think the current limitation nicely protects us from harm.  If you were to run getrandbits(2**60) it would take a long time, eat all your memory, trigger swaps until your harddrive was full, and you wouldn't be able to break out of the tight loop with a keyboard interrupt.

Even with the current limit, the resultant int object is ridiculously big in a way that is awkward to manipulate after it is created (don't bother trying to print it, jsonify it, or doing any interesting math it).

Also, if a person wants a lot of bits, it is effortless to make repeated calls getrandbits() using the current API.  Doing so would likely improve their code and be a better design (consuming bits as generated rather than creating them all at once and extracting them later).

In short, just because we can do it, doesn't mean we should.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27072>
_______________________________________

From report at bugs.python.org  Sat May 21 21:24:06 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 22 May 2016 01:24:06 +0000
Subject: [issue24550] maxint on 64 bit platforms breaks os.read
In-Reply-To: <1435814869.69.0.586441983811.issue24550@psf.upfronthosting.co.za>
Message-ID: <1463880246.25.0.548078208448.issue24550@psf.upfronthosting.co.za>


Martin Panter added the comment:

Sorry in Python 3.5 the change was actually Issue 21932 (not Arg Clinic). But Victor said that change shouldn?t go into Python 2.

BTW Issue 21199 is about Python 2?s file.read() method, not os.read().

----------
resolution: duplicate -> wont fix
superseder:  -> os.read() must use Py_ssize_t for the size parameter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24550>
_______________________________________

From report at bugs.python.org  Sat May 21 21:27:30 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 22 May 2016 01:27:30 +0000
Subject: [issue25548] Show the address in the repr for class objects
In-Reply-To: <1446576011.58.0.372024983976.issue25548@psf.upfronthosting.co.za>
Message-ID: <1463880450.93.0.0935011481729.issue25548@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> I don't quite get why the memory address is helpful

For the same reason that we've found the address to helpful in other reprs, it helps people understand that classes are objects just like anything else and to know which objects are distinct.

My instructors have found that this matters when teaching Python and more than one of them immediately noticed the loss of information when switching from teaching Python 2 to Python 3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25548>
_______________________________________

From report at bugs.python.org  Sat May 21 21:40:46 2016
From: report at bugs.python.org (Campbell Barton)
Date: Sun, 22 May 2016 01:40:46 +0000
Subject: [issue27072] random.getrandbits is limited to 2**31-1 bits on 64-bit
 Windows
In-Reply-To: <1463810870.39.0.980113200971.issue27072@psf.upfronthosting.co.za>
Message-ID: <1463881246.71.0.0523547464645.issue27072@psf.upfronthosting.co.za>


Campbell Barton added the comment:

@rhettinger, agree that very large ints in this case aren't going to give very usable results.

On the other hand, this limit isn't imposed elsewhere (you can power-of operator to create bigger numbers).

Nevertheless this isn't going to give good/usable performance.

----

Might having a method added to `randome.Random` that returns random bits (as os.urandom does), be something Python project would consider accepting?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27072>
_______________________________________

From report at bugs.python.org  Sat May 21 21:42:23 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 22 May 2016 01:42:23 +0000
Subject: [issue18100] socket.sendall() cannot send buffers of 2GB or more
In-Reply-To: <1369918582.13.0.605373457603.issue18100@psf.upfronthosting.co.za>
Message-ID: <1463881343.46.0.37851261549.issue18100@psf.upfronthosting.co.za>


Martin Panter added the comment:

Looks like this was fixed in 3.1 and 3.2 by r84150.

----------
nosy: +martin.panter
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18100>
_______________________________________

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: [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  Sat May 21 21:47:21 2016
From: report at bugs.python.org (Tim Peters)
Date: Sun, 22 May 2016 01:47:21 +0000
Subject: [issue27082] IDLE seriously degrades during and after printing large
 single line strings
In-Reply-To: <1463881383.42.0.876902574545.issue27082@psf.upfronthosting.co.za>
Message-ID: <1463881641.53.0.265704734408.issue27082@psf.upfronthosting.co.za>


Tim Peters added the comment:

Ya, this annoyance has been there forever.  As I recall, the source of the problem is the Tk text widget (which slows horribly when displaying long lines).

----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27082>
_______________________________________

From report at bugs.python.org  Sat May 21 22:10:00 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 22 May 2016 02:10:00 +0000
Subject: [issue20699] Document that binary IO classes work with bytes-likes
 objects
In-Reply-To: <1392889792.36.0.922412998797.issue20699@psf.upfronthosting.co.za>
Message-ID: <1463883000.87.0.857377265128.issue20699@psf.upfronthosting.co.za>


Martin Panter added the comment:

I updated my patch thanks to Serhiy?s comments. Also omitted Arg Clinic generated code in this version to avoid future merge conflicts with the hashes.

----------
versions: +Python 3.6 -Python 3.4
Added file: http://bugs.python.org/file42934/bytes-like-param.v6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20699>
_______________________________________

From report at bugs.python.org  Sat May 21 22:12:16 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 22 May 2016 02:12:16 +0000
Subject: [issue27072] random.getrandbits is limited to 2**31-1 bits on 64-bit
 Windows
In-Reply-To: <1463810870.39.0.980113200971.issue27072@psf.upfronthosting.co.za>
Message-ID: <1463883136.45.0.621872241252.issue27072@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

> On the other hand, this limit isn't imposed elsewhere.

There are a number of places in the language with these limits.  In general, we're opening them up to wider limits if there are valid use cases and if it doesn't immediately shoot you in the foot like it does here.

Practicality is a reasonable design consideration.  Mitigation of harm is also reasonable design consideration.  Foolish consistently is, well, you know how the saying goes :-)

> Might having a method added to `randome.Random` that returns 
> random bits (as os.urandom does), be something Python project
> would consider accepting?

It isn't needed.  As far as I know, there has never been a user request for this functionality nor a presentation of use cases that benefit it.  The API is already bloated and we already have one way to do it with int.to_bytes().  Also, we should keep this tracker entry focused on the OP's report and not meander.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27072>
_______________________________________

From report at bugs.python.org  Sat May 21 22:52:47 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 22 May 2016 02:52:47 +0000
Subject: [issue27072] random.getrandbits is limited to 2**31-1 bits on 64-bit
 Windows
In-Reply-To: <1463810870.39.0.980113200971.issue27072@psf.upfronthosting.co.za>
Message-ID: <1463885567.67.0.672537820928.issue27072@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27072>
_______________________________________

From report at bugs.python.org  Sat May 21 23:39:32 2016
From: report at bugs.python.org (Demur Rumed)
Date: Sun, 22 May 2016 03:39:32 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1463888372.3.0.820381586623.issue26647@psf.upfronthosting.co.za>


Demur Rumed added the comment:

Based on serhiy's LGTM I'm uploading hopefully final touches based on his feedback

New in this are changes to Makefile.pre & PCbuild files. I can't really test PCbuild but I did test that make followed by modifying wordcode_helpers.h followed by make rebuilds peephole & compile. There's now also modification of PC/launcher.c to include 3370 as 3.6

Doc/library/dis.rst: I've reverted changes to HAVE_ARGUMENT description since most of my 'pedantic' changes to differentiate between using arguments & ignoring arguments have been reverted

----------
Added file: http://bugs.python.org/file42935/wpy9.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Sun May 22 00:18:59 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 22 May 2016 04:18:59 +0000
Subject: [issue27082] IDLE seriously degrades during and after printing large
 single line strings
In-Reply-To: <1463881383.42.0.876902574545.issue27082@psf.upfronthosting.co.za>
Message-ID: <1463890739.87.0.0900865708464.issue27082@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> IDLE shell window gets very slow when displaying long lines

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27082>
_______________________________________

From report at bugs.python.org  Sun May 22 00:39:52 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 May 2016 04:39:52 +0000
Subject: [issue27067] Improve curses tests
In-Reply-To: <1463731355.86.0.176847535381.issue27067@psf.upfronthosting.co.za>
Message-ID: <1463891992.87.0.282141994657.issue27067@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

My bad. I tested only with stdout redirected, the test fail if both stdout and stderr are redirected.

Proposed patch fixes this.

----------
Added file: http://bugs.python.org/file42936/test_curses_no_atty.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27067>
_______________________________________

From report at bugs.python.org  Sun May 22 00:41:16 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 22 May 2016 04:41:16 +0000
Subject: [issue18383] test_warnings modifies warnings.filters when running
 with "-W default"
In-Reply-To: <1373117774.47.0.846306714059.issue18383@psf.upfronthosting.co.za>
Message-ID: <1463892076.06.0.405942380795.issue18383@psf.upfronthosting.co.za>


Martin Panter added the comment:

I am inclined to go with Alex?s patch. I am uploading a new version of it, issue18383_avoid_dups_3.diff, which resolves conflicts with recent changes.

----------
versions:  -Python 3.4
Added file: http://bugs.python.org/file42937/issue18383_avoid_dups_3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18383>
_______________________________________

From report at bugs.python.org  Sun May 22 00:42:01 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 22 May 2016 04:42:01 +0000
Subject: [issue26742] imports in test_warnings changes warnings.filters
In-Reply-To: <1460508695.22.0.184623410488.issue26742@psf.upfronthosting.co.za>
Message-ID: <1463892121.77.0.701059880081.issue26742@psf.upfronthosting.co.za>


Martin Panter added the comment:

I suggest to use the patch from Issue 18383.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> test_warnings modifies warnings.filters when running with "-W default"

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26742>
_______________________________________

From report at bugs.python.org  Sun May 22 00:45:20 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 22 May 2016 04:45:20 +0000
Subject: [issue18383] test_warnings modifies warnings.filters when running
 with "-W default"
In-Reply-To: <1373117774.47.0.846306714059.issue18383@psf.upfronthosting.co.za>
Message-ID: <1463892320.73.0.715749467651.issue18383@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


Removed file: http://bugs.python.org/file42937/issue18383_avoid_dups_3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18383>
_______________________________________

From report at bugs.python.org  Sun May 22 00:46:28 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 22 May 2016 04:46:28 +0000
Subject: [issue18383] test_warnings modifies warnings.filters when running
 with "-W default"
In-Reply-To: <1373117774.47.0.846306714059.issue18383@psf.upfronthosting.co.za>
Message-ID: <1463892388.19.0.887759434469.issue18383@psf.upfronthosting.co.za>


Martin Panter added the comment:

Forgot to refresh my patch

----------
Added file: http://bugs.python.org/file42938/issue18383_avoid_dups_3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18383>
_______________________________________

From report at bugs.python.org  Sun May 22 01:15:20 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 22 May 2016 05:15:20 +0000
Subject: [issue17599] mingw: detect REPARSE_DATA_BUFFER
In-Reply-To: <1364759977.57.0.233975454494.issue17599@psf.upfronthosting.co.za>
Message-ID: <1463894120.96.0.376107266303.issue17599@psf.upfronthosting.co.za>


Martin Panter added the comment:

Would it be better to define all the things in "winreparse.h" with names that are less likely to conflict, say Py_REPARSE_DATA_BUFFER etc? This would be a more general way to avoid conflicts, and also avoid hacking the configure script.

Also, is the ?#ifndef MAXIMUM_REPARSE_DATA_BUFFER_SIZE? condition necessary?

----------
components: +Windows -Cross-Build
nosy: +martin.panter, paul.moore, steve.dower, tim.golden, zach.ware
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17599>
_______________________________________

From report at bugs.python.org  Sun May 22 01:30:24 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 22 May 2016 05:30:24 +0000
Subject: [issue22636] avoid using a shell in ctypes.util: replace os.popen
 with subprocess
In-Reply-To: <1413325975.89.0.175884398711.issue22636@psf.upfronthosting.co.za>
Message-ID: <1463895024.6.0.205373505004.issue22636@psf.upfronthosting.co.za>


Martin Panter added the comment:

FTR the Python 2.3 compatibility restriction was lifted; see <https://mail.python.org/pipermail/python-dev/2016-May/144502.html>.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22636>
_______________________________________

From report at bugs.python.org  Sun May 22 01:48:05 2016
From: report at bugs.python.org (Ned Deily)
Date: Sun, 22 May 2016 05:48:05 +0000
Subject: [issue26955] Implement equivalent to `pip.locations.distutils_scheme`
 in distutils
In-Reply-To: <1462378664.68.0.201238634465.issue26955@psf.upfronthosting.co.za>
Message-ID: <1463896085.39.0.209827832407.issue26955@psf.upfronthosting.co.za>


Ned Deily added the comment:

"When installing a python package that has `headers`, these headers are usually installed under the main python include directory".  Can you give some specific examples of packages and platforms where that is the case?  Just taking a quick look at some packages I happen to have installed, like lxml and cffi using a vanilla pip with a vanilla Unix-y Python 3.5.1, their header files get installed in the site-packages directory by default (using pip), not the main Python include directory.  And various distributors of Python have their own preferences where to install things, for example, the locations you cite are those used by Homebrew on OS X and differ from other OS X Pythons.  I'm not sure that there is a general solution as things stand now; I think there is probably a lot of variability among packages (e.g. their setup.py) and Python distributions.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26955>
_______________________________________

From report at bugs.python.org  Sun May 22 01:52:48 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 May 2016 05:52:48 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1463896368.42.0.346239388741.issue26647@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

wpy9.patch looks mostly good to me, but there compiler warnings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Sun May 22 02:29:18 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 May 2016 06:29:18 +0000
Subject: [issue27072] random.getrandbits is limited to 2**31-1 bits on 64-bit
 Windows
In-Reply-To: <1463810870.39.0.980113200971.issue27072@psf.upfronthosting.co.za>
Message-ID: <1463898558.26.0.0135914630769.issue27072@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The only case I know that would benefit is generating random data for tests. On my computer generating 2*28 bits with getrandbits() takes 2 sec (including 1 sec for converting from bytes to int), plus 1.4 sec for converting from int to bytes. Special API would speed up generating random bytes by 3.4 times. I would request for this functionality, but I don't want to clutter the API.

As for getrandbits.diff, I think that we should follow the principle "we're all consenting adults here".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27072>
_______________________________________

From report at bugs.python.org  Sun May 22 02:35:27 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 May 2016 06:35:27 +0000
Subject: [issue20699] Document that binary IO classes work with bytes-likes
 objects
In-Reply-To: <1392889792.36.0.922412998797.issue20699@psf.upfronthosting.co.za>
Message-ID: <1463898927.34.0.349042148904.issue20699@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

bytes-like-param.v6.patch LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20699>
_______________________________________

From report at bugs.python.org  Sun May 22 02:44:13 2016
From: report at bugs.python.org (Ned Deily)
Date: Sun, 22 May 2016 06:44:13 +0000
Subject: [issue26971] python v3.5.1: sys.paths not respecting DESTDIRS and
 DESTSHARED
In-Reply-To: <1462628482.0.0.926875224828.issue26971@psf.upfronthosting.co.za>
Message-ID: <1463899453.02.0.666639420158.issue26971@psf.upfronthosting.co.za>


Ned Deily added the comment:

Sorry, I'm not able to reproduce your results on a vanilla Debian system.  Building from scratch with ./configure --prefix=/usr and make steps results in:

$ /usr/bin/python3.5
Python 3.5.1 (default, May 22 2016, 02:26:09)
[GCC 4.9.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import base64
>>> import sys, _struct
>>> _struct.__file__
'/usr/lib/python3.5/lib-dynload/_struct.cpython-35m-x86_64-linux-gnu.so'
>>> sys.path
['', '/usr/lib/python35.zip', '/usr/lib/python3.5', '/usr/lib/python3.5/plat-linux', '/usr/lib/python3.5/lib-dynload', '/home/sysadmin/.local/lib/python3.5/site-packages', '/usr/lib/python3.5/site-packages']
>>>

Is it possible you had a virtual environment in effect?  Try repeating with "/usr/bin/python3.5" and verifying the build timestamp.  As far as I know, an unpatched Python 3.5 will not attempt to install anything into /usr/lib64 by default.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26971>
_______________________________________

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: [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 02:53:47 2016
From: report at bugs.python.org (Ned Deily)
Date: Sun, 22 May 2016 06:53:47 +0000
Subject: [issue26980] The path argument of
 asyncio.BaseEventLoop.create_unix_connection is not documented
In-Reply-To: <1462743548.86.0.976035936413.issue26980@psf.upfronthosting.co.za>
Message-ID: <1463900027.74.0.194356444299.issue26980@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
components: +asyncio
nosy: +gvanrossum, haypo, yselivanov
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26980>
_______________________________________

From report at bugs.python.org  Sun May 22 03:35:48 2016
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 22 May 2016 07:35:48 +0000
Subject: [issue26331] Tokenizer: allow underscores for grouping in numeric
 literals
In-Reply-To: <1455126624.48.0.163167904941.issue26331@psf.upfronthosting.co.za>
Message-ID: <1463902548.97.0.777390240891.issue26331@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Thanks for the detailed review, Serhiy! Next try incoming.

----------
Added file: http://bugs.python.org/file42939/numeric_underscores_final_v8.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26331>
_______________________________________

From report at bugs.python.org  Sun May 22 03:50:25 2016
From: report at bugs.python.org (Sylvain Corlay)
Date: Sun, 22 May 2016 07:50:25 +0000
Subject: [issue26955] Implement equivalent to `pip.locations.distutils_scheme`
 in distutils
In-Reply-To: <1462378664.68.0.201238634465.issue26955@psf.upfronthosting.co.za>
Message-ID: <1463903425.41.0.370385446461.issue26955@psf.upfronthosting.co.za>


Sylvain Corlay added the comment:

Ned, that is because these packages (lxml, cffi) have header files as `package_data`, instead of `headers`. This is why they are being copied into site-packages. People willing to include them must either rely on knowledge of their location, or a python functions returning if (like numpy's get_include)

Distutils provides a standard way of distributing headers. These are passed to the setup function via the `headers` keyword argument, which triggers the `install_headers` command.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26955>
_______________________________________

From report at bugs.python.org  Sun May 22 04:23:12 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 May 2016 08:23:12 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1463905392.21.0.655330136406.issue26647@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

test_importlib and test_trace are failed with wpy9.patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Sun May 22 04:24:57 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 22 May 2016 08:24:57 +0000
Subject: [issue26858] android: setting SO_REUSEPORT fails
In-Reply-To: <1461677842.81.0.574068471289.issue26858@psf.upfronthosting.co.za>
Message-ID: <1463905497.44.0.0810090802404.issue26858@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

New patch test.asyncio_2.patch uses test.support.is_android and adds a dependency to issue #27027.

----------
dependencies: +add is_android in test.support to detect Android platform
Added file: http://bugs.python.org/file42940/test.asyncio_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26858>
_______________________________________

From report at bugs.python.org  Sun May 22 05:18:54 2016
From: report at bugs.python.org (Eryk Sun)
Date: Sun, 22 May 2016 09:18:54 +0000
Subject: [issue27048] distutils._msvccompiler._get_vc_env() fails with
 UnicodeDecodeError if an env var is not encodable
In-Reply-To: <1463515752.85.0.457941663559.issue27048@psf.upfronthosting.co.za>
Message-ID: <1463908734.71.0.287308006039.issue27048@psf.upfronthosting.co.za>


Eryk Sun added the comment:

When writing to a file or pipe, cmd's internal commands default to either the current codepage of the attached console or, for a detached process, the system locale codepage. It uses a best-fit encoding that tries to map characters to similar characters in the codepage. For example:

    >>> win_unicode_console.enable()
    >>> os.environ['TEST?'] = '?'
    >>> out = subprocess.check_output('cmd /c set test')
    >>> out.decode(sys.__stdout__.encoding).strip()
    'TESTc=r'

You can force it to use Unicode (UTF-16LE) with the /u option:

    >>> out = subprocess.check_output('cmd /u /c set test')
    >>> out.decode('utf-16le').strip()
    'TEST?=?'

subprocess could use "/u /c" instead of "/c". This would only affect the output of internal shell commands such as "dir" and "set".

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27048>
_______________________________________

From report at bugs.python.org  Sun May 22 05:28:11 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 22 May 2016 09:28:11 +0000
Subject: [issue26926] Large files are not supported on Android
In-Reply-To: <1462283737.14.0.888848894928.issue26926@psf.upfronthosting.co.za>
Message-ID: <1463909291.53.0.50206646258.issue26926@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Size of off_t is also 4 when building on API 23 with or without
'-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE=1 -D_LARGEFILE64_SOURCE=1'
added to the CC envt variable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26926>
_______________________________________

From report at bugs.python.org  Sun May 22 05:44:27 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 22 May 2016 09:44:27 +0000
Subject: [issue26926] Large files are not supported on Android
In-Reply-To: <1462283737.14.0.888848894928.issue26926@psf.upfronthosting.co.za>
Message-ID: <1463910267.19.0.942341185616.issue26926@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

This patch skips the large file support test.

----------
dependencies: +add is_android in test.support to detect Android platform
Added file: http://bugs.python.org/file42941/skip-large-file.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26926>
_______________________________________

From report at bugs.python.org  Sun May 22 06:14:58 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 22 May 2016 10:14:58 +0000
Subject: [issue26927] test_mmap does not handle ValueError when no large file
 support
In-Reply-To: <1462284033.57.0.466364918672.issue26927@psf.upfronthosting.co.za>
Message-ID: <1463912098.54.0.360739510111.issue26927@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

f.seek(number) raises ValueError (ValueError: cannot fit 'int' into an offset-sized integer) when 'number' is greater than the size allowed by off_t. ValueError is not handled in test_mmap to detect that large file is not supported.

With this patch, test_large_filesize and test_large_offset are skipped as expected on an Android emulator.

----------
keywords: +patch
resolution: duplicate -> 
status: closed -> open
title: android: test_mmap fails -> test_mmap does not handle ValueError when no large file support
Added file: http://bugs.python.org/file42942/value-error.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26927>
_______________________________________

From report at bugs.python.org  Sun May 22 06:16:45 2016
From: report at bugs.python.org (Odcar)
Date: Sun, 22 May 2016 10:16:45 +0000
Subject: [issue26673] Tkinter error when opening IDLE configuration menu
 (Tcl/Tk 8.6)
In-Reply-To: <1459351920.73.0.899924616631.issue26673@psf.upfronthosting.co.za>
Message-ID: <1463912205.35.0.777737190758.issue26673@psf.upfronthosting.co.za>


Odcar added the comment:

Terry J. Reedy: That fixes the problem for me!
Xubuntu 16.04, Python 2.7.11+, Tk 8.6.5. I have not tried it in Idle for Python 3 though.

----------
nosy: +Odcar

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26673>
_______________________________________

From report at bugs.python.org  Sun May 22 07:27:41 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 May 2016 11:27:41 +0000
Subject: [issue26927] test_mmap does not handle ValueError when no large file
 support
In-Reply-To: <1462284033.57.0.466364918672.issue26927@psf.upfronthosting.co.za>
Message-ID: <1463916461.13.0.110077172946.issue26927@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I'm wondering in what cases other exceptions (OSError, OverflowError) can be raised? Initial test was added in issue4681.

----------
nosy: +pitrou, rosslagerwall

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26927>
_______________________________________

From report at bugs.python.org  Sun May 22 07:30:53 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 22 May 2016 11:30:53 +0000
Subject: [issue25077] Compiler warnings: initialization from incompatible
 pointer type
In-Reply-To: <1442042610.13.0.957335882034.issue25077@psf.upfronthosting.co.za>
Message-ID: <1463916653.72.0.598146928193.issue25077@psf.upfronthosting.co.za>


Berker Peksag added the comment:

libffi warnings have already been fixed in upstream libffi. See issue 23085 for updating our libffi copy.

----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25077>
_______________________________________

From report at bugs.python.org  Sun May 22 07:35:01 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 May 2016 11:35:01 +0000
Subject: [issue27064] Make py.exe default to Python 3 when used interactively
In-Reply-To: <1463693765.53.0.683202020216.issue27064@psf.upfronthosting.co.za>
Message-ID: <20160522113457.28670.90109.7709A282@psf.io>


Roundup Robot added the comment:

New changeset 26c1e3dab624 by Paul Moore in branch 'default':
Issue #27064: The py.exe launcher now defaults to Python 3.
https://hg.python.org/cpython/rev/26c1e3dab624

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27064>
_______________________________________

From report at bugs.python.org  Sun May 22 07:35:51 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 22 May 2016 11:35:51 +0000
Subject: [issue25413] ctypes (libffi) fails to compile on Solaris X86
In-Reply-To: <1444919626.01.0.242398686702.issue25413@psf.upfronthosting.co.za>
Message-ID: <1463916951.96.0.0203016316453.issue25413@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +doko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25413>
_______________________________________

From report at bugs.python.org  Sun May 22 07:40:19 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 22 May 2016 11:40:19 +0000
Subject: [issue26944] android: test_posix fails
In-Reply-To: <1462348873.26.0.373017977506.issue26944@psf.upfronthosting.co.za>
Message-ID: <1463917219.49.0.9984195609.issue26944@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

test_getgroups is ok on an android emulator running API 23 with the attached patch, and the test is skipped when running API 21.

----------
dependencies: +add is_android in test.support to detect Android platform -android: add platform.android_ver()
keywords: +patch
Added file: http://bugs.python.org/file42943/test_getgroups.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26944>
_______________________________________

From report at bugs.python.org  Sun May 22 08:18:32 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 22 May 2016 12:18:32 +0000
Subject: [issue27048] distutils._msvccompiler._get_vc_env() fails with
 UnicodeDecodeError if an env var is not encodable
In-Reply-To: <1463908734.71.0.287308006039.issue27048@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwaGckWtGtLE8J4TuSPXRpS8H2C+Fg4=5WFA9Zhy_com5A@mail.gmail.com>


STINNER Victor added the comment:

2016-05-22 11:18 GMT+02:00 Eryk Sun <report at bugs.python.org>:
> subprocess could use "/u /c" instead of "/c". This would only affect the output of internal shell commands such as "dir" and "set".

Oh, I didn't know the interesting "cmd /u" command. It looks like a
short and working fix for the "set" issue.

As a side project, we can also evaluate using "cmd /u" by default when
shell=True is used with subprocess on Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27048>
_______________________________________

From report at bugs.python.org  Sun May 22 08:22:40 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 22 May 2016 12:22:40 +0000
Subject: [issue26927] test_mmap does not handle ValueError when no large file
 support
In-Reply-To: <1462284033.57.0.466364918672.issue26927@psf.upfronthosting.co.za>
Message-ID: <1463919760.45.0.799256464998.issue26927@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

On linux with large file support, OSError is raised when the file system limit is exceeded, here with ext4:

>>> f.seek(2**44 - 2**11)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 22] Invalid argument
>>> f.seek(2**44 - 2**12)
17592186040320
>>> f.write(b'A' * 2**11)
2048
>>> f.write(b'A' * 2**11)
2048
>>> f.tell()
17592186044416
>>> f.write(b'A' * 2**11)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 27] File too large


On the Android emulator (no large file support):

>>> f.seek(2**31)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: cannot fit 'int' into an offset-sized integer
>>> f.seek(2**31 - 1)
2147483647
>>> f.write(b'A')
1
>>> f.tell()
-2147483648
>>> f.flush()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: [Errno 75] Value too large for defined data type


Surprisingly f.write(b'A') does not raise an exception.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26927>
_______________________________________

From report at bugs.python.org  Sun May 22 08:36:10 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 22 May 2016 12:36:10 +0000
Subject: [issue27067] Improve curses tests
In-Reply-To: <1463731355.86.0.176847535381.issue27067@psf.upfronthosting.co.za>
Message-ID: <1463920570.85.0.741246195946.issue27067@psf.upfronthosting.co.za>


STINNER Victor added the comment:

test_curses_no_atty.patch doesn't work for me using -j1 regrtest option :-/

haypo at smithers$ ./python -m test -u curses -j1 test_curses
Run tests in parallel using 1 child processes
Total duration: 0:00:01
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/home/haypo/prog/python/default/Lib/threading.py", line 916, in _bootstrap_inner
    self.run()
  File "/home/haypo/prog/python/default/Lib/test/libregrtest/runtest_mp.py", line 147, in run
    stop = self._runtest()
  File "/home/haypo/prog/python/default/Lib/test/libregrtest/runtest_mp.py", line 138, in _runtest
    result = json.loads(result)
  File "/home/haypo/prog/python/default/Lib/json/__init__.py", line 319, in loads
    return _default_decoder.decode(s)
  File "/home/haypo/prog/python/default/Lib/json/decoder.py", line 339, in decode
    obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File "/home/haypo/prog/python/default/Lib/json/decoder.py", line 357, in raw_decode
    raise JSONDecodeError("Expecting value", s, err.value) from None
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27067>
_______________________________________

From report at bugs.python.org  Sun May 22 08:39:30 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 22 May 2016 12:39:30 +0000
Subject: [issue27067] Improve curses tests
In-Reply-To: <1463731355.86.0.176847535381.issue27067@psf.upfronthosting.co.za>
Message-ID: <1463920770.43.0.870887294462.issue27067@psf.upfronthosting.co.za>


STINNER Victor added the comment:

By the way, all buildbots now use -j1 option and so stdout and stderr are no more TTY on all buildbots: see issue #25285.

So test_curses are not fully tested by buildbots anymore.

Maybe we should have at least one buildbot testing test_curses with a TTY?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27067>
_______________________________________

From report at bugs.python.org  Sun May 22 08:45:21 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 22 May 2016 12:45:21 +0000
Subject: [issue26865] Meta-issue: support of the android platform
In-Reply-To: <1461685011.99.0.617135447086.issue26865@psf.upfronthosting.co.za>
Message-ID: <1463921121.06.0.898456780571.issue26865@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

issue #22747: Interpreter fails in initialize on systems where HAVE_LANGINFO_H is undefined

----------
dependencies: +Interpreter fails in initialize on systems where HAVE_LANGINFO_H is undefined

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26865>
_______________________________________

From report at bugs.python.org  Sun May 22 09:06:35 2016
From: report at bugs.python.org (ppperry)
Date: Sun, 22 May 2016 13:06:35 +0000
Subject: [issue27081] Multiprocessing is not robust against sys.stderr changes
 involving queues
In-Reply-To: <1463864673.26.0.0758761622573.issue27081@psf.upfronthosting.co.za>
Message-ID: <1463922395.26.0.283622487826.issue27081@psf.upfronthosting.co.za>


Changes by ppperry <mapreader at olum.org>:


----------
title: Multiprocessing is not robust against sys.stderr changes -> Multiprocessing is not robust against sys.stderr changes involving queues

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27081>
_______________________________________

From report at bugs.python.org  Sun May 22 09:10:23 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sun, 22 May 2016 13:10:23 +0000
Subject: [issue18383] test_warnings modifies warnings.filters when running
 with "-W default"
In-Reply-To: <1373117774.47.0.846306714059.issue18383@psf.upfronthosting.co.za>
Message-ID: <1463922623.76.0.816413287263.issue18383@psf.upfronthosting.co.za>


Berker Peksag added the comment:

LGTM

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18383>
_______________________________________

From report at bugs.python.org  Sun May 22 09:36:24 2016
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 22 May 2016 13:36:24 +0000
Subject: [issue26857] gethostbyname_r() is broken on android
In-Reply-To: <1461677599.23.0.153884294057.issue26857@psf.upfronthosting.co.za>
Message-ID: <1463924184.0.0.564771130143.issue26857@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Okay thanks, let's assume api-level >= 21 for now. I've moved the include into pyport.h in order to save a little space everywhere. Could you check if that works?

----------
Added file: http://bugs.python.org/file42944/issue26857.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26857>
_______________________________________

From report at bugs.python.org  Sun May 22 09:42:24 2016
From: report at bugs.python.org (Demur Rumed)
Date: Sun, 22 May 2016 13:42:24 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1463924544.67.0.26637454543.issue26647@psf.upfronthosting.co.za>


Demur Rumed added the comment:

Compiler warnings can be fixed by using h instead of j in case RETURN_VALUE & casting CONST_LEN() to unsigned is safe

As for the failing tests: I've finally figured out how to use Tools/freeze to fix __phello__ et al. I've brought up the trace test failure a few times, essentially

return (1,
2,
3)

compiles to LOAD_CONST (1,2,3) being on separate line than the RETURN_VALUE whereas previously it did not. This issue does not occur for

return """1,
2,
3"""

Leading me to believe peephole has missed some detail in ltotab handling

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Sun May 22 10:50:26 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 22 May 2016 14:50:26 +0000
Subject: [issue26857] gethostbyname_r() is broken on android
In-Reply-To: <1461677599.23.0.153884294057.issue26857@psf.upfronthosting.co.za>
Message-ID: <1463928626.96.0.952609484835.issue26857@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

> I've moved the include into pyport.h

and also fixed the error in my patch, thanks :)

With issue26857.diff, importing the socket module does not fail both with an API 21 emulator and an API 23 emulator.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26857>
_______________________________________

From report at bugs.python.org  Sun May 22 11:20:17 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 May 2016 15:20:17 +0000
Subject: [issue27067] Improve curses tests
In-Reply-To: <1463731355.86.0.176847535381.issue27067@psf.upfronthosting.co.za>
Message-ID: <20160522152014.54562.99215.3B74DA0E@psf.io>


Roundup Robot added the comment:

New changeset 433839643bbb by Serhiy Storchaka in branch '3.5':
Temporary skip curses tests on non-tty (issue #27067).
https://hg.python.org/cpython/rev/433839643bbb

New changeset debe693c62b4 by Serhiy Storchaka in branch 'default':
Temporary skip curses tests on non-tty (issue #27067).
https://hg.python.org/cpython/rev/debe693c62b4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27067>
_______________________________________

From report at bugs.python.org  Sun May 22 11:22:30 2016
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 22 May 2016 15:22:30 +0000
Subject: [issue27067] Improve curses tests
In-Reply-To: <1463920770.43.0.870887294462.issue27067@psf.upfronthosting.co.za>
Message-ID: <CAKJDb-MAHta724notanFbMKM6=N20AsrO2PramddbSKGgn_JxQ@mail.gmail.com>


Zachary Ware added the comment:

> Maybe we should have at least one buildbot testing test_curses with a TTY?

My non-debug and installed Gentoo bot does run the tests with a PTY, so you
can use its custom builders for experimentation (assuming it can complete a
clone).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27067>
_______________________________________

From report at bugs.python.org  Sun May 22 11:36:16 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 May 2016 15:36:16 +0000
Subject: [issue26857] gethostbyname_r() is broken on android
In-Reply-To: <1461677599.23.0.153884294057.issue26857@psf.upfronthosting.co.za>
Message-ID: <20160522153613.28304.99444.D0532BF3@psf.io>


Roundup Robot added the comment:

New changeset 09af54099973 by Stefan Krah in branch 'default':
Issue #26857: The gethostbyaddr_r() workaround is no longer needed with
https://hg.python.org/cpython/rev/09af54099973

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26857>
_______________________________________

From report at bugs.python.org  Sun May 22 11:37:26 2016
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 22 May 2016 15:37:26 +0000
Subject: [issue26857] gethostbyname_r() is broken on android
In-Reply-To: <1461677599.23.0.153884294057.issue26857@psf.upfronthosting.co.za>
Message-ID: <1463931446.51.0.470690153821.issue26857@psf.upfronthosting.co.za>


Stefan Krah added the comment:

Thanks! Closing again.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26857>
_______________________________________

From report at bugs.python.org  Sun May 22 11:51:10 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 22 May 2016 15:51:10 +0000
Subject: [issue16255] subrocess.Popen needs /bin/sh but Android only has
 /system/bin/sh
In-Reply-To: <1350421202.49.0.905467284446.issue16255@psf.upfronthosting.co.za>
Message-ID: <1463932270.89.0.660563922063.issue16255@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

The list of locations where '/bin/sh' is hard coded in the standard library:

Lib/distutils/tests/test_build_scripts.py|68 col 31| ("#!/bin/sh\n"
Lib/distutils/tests/test_install_scripts.py|57 col 38| write_script("shell.sh", ("#!/bin/sh\n"
Lib/distutils/tests/test_spawn.py|34 col 37| self.write_file(exe, '#!/bin/sh\nexit 1')
Lib/distutils/tests/test_spawn.py|45 col 37| self.write_file(exe, '#!/bin/sh\nexit 0')
Lib/subprocess.py|611 col 24| >>> check_output(["/bin/sh", "-c",
Lib/subprocess.py|1450 col 26| args = ["/bin/sh", "-c"] + args
Lib/test/test__osx_support.py|46 col 24| f.write("#!/bin/sh\n/bin/echo OK\n")
Lib/test/test__osx_support.py|58 col 24| f.write("#!/bin/sh\n/bin/echo ExpectedOutput\n")
Lib/test/test__osx_support.py|149 col 28| f.write("#!/bin/sh\n/bin/echo " + c_output)
Lib/test/test__osx_support.py|205 col 24| f.write("#!/bin/sh\nexit 255")
Lib/test/test_os.py|673 col 42| @unittest.skipUnless(os.path.exists('/bin/sh'), 'requires /bin/sh')
Lib/test/test_os.py|677 col 24| with os.popen("/bin/sh -c 'echo $HELLO'") as popen:
Lib/test/test_os.py|681 col 42| @unittest.skipUnless(os.path.exists('/bin/sh'), 'requires /bin/sh')
Lib/test/test_os.py|684 col 14| "/bin/sh -c 'echo \"line1\nline2\nline3\"'") as popen:
Lib/test/test_subprocess.py|1563 col 31| fobj.write("#!/bin/sh\n")
Lib/test/test_subprocess.py|1611 col 31| fobj.write("#!/bin/sh\n")
Lib/test/test_subprocess.py|1629 col 15| sh = '/bin/sh'

----------
nosy: +xdegaye

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16255>
_______________________________________

From report at bugs.python.org  Sun May 22 11:58:14 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 22 May 2016 15:58:14 +0000
Subject: [issue26865] Meta-issue: support of the android platform
In-Reply-To: <1461685011.99.0.617135447086.issue26865@psf.upfronthosting.co.za>
Message-ID: <1463932694.38.0.092242013579.issue26865@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

issue #16255: subrocess.Popen needs /bin/sh but Android only has /system/bin/sh
issue #16353: add function to os module for getting path to default shell

----------
dependencies: +subrocess.Popen needs /bin/sh but Android only has /system/bin/sh

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26865>
_______________________________________

From report at bugs.python.org  Sun May 22 12:10:09 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 May 2016 16:10:09 +0000
Subject: [issue27067] Improve curses tests
In-Reply-To: <1463731355.86.0.176847535381.issue27067@psf.upfronthosting.co.za>
Message-ID: <1463933409.84.0.654030520594.issue27067@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Updated patch makes test_curses working with -jN. But it spoils a screen when run with -jN on a terminal (shouldn't be a problem for buildbots).

----------
Added file: http://bugs.python.org/file42945/test_curses_no_atty2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27067>
_______________________________________

From report at bugs.python.org  Sun May 22 12:17:00 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 May 2016 16:17:00 +0000
Subject: [issue18383] test_warnings modifies warnings.filters when running
 with "-W default"
In-Reply-To: <1373117774.47.0.846306714059.issue18383@psf.upfronthosting.co.za>
Message-ID: <1463933820.25.0.255801506388.issue18383@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

$ ./python -We::UserWarning -m test.regrtest test_warnings
Run tests sequentially
0:00:00 [1/1] test_warnings
/home/serhiy/py/cpython/Lib/test/test_warnings/__init__.py:108: UserWarning: FilterTests.test_ignore_after_default
  self.module.warn(message, UserWarning)
/home/serhiy/py/cpython/Lib/test/test_warnings/__init__.py:108: UserWarning: FilterTests.test_ignore_after_default
  self.module.warn(message, UserWarning)
test test_warnings failed -- multiple errors occurred; run in verbose mode for details
test_warnings failed
1 test failed:
    test_warnings
Total duration: 0:00:02

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18383>
_______________________________________

From report at bugs.python.org  Sun May 22 12:28:55 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 May 2016 16:28:55 +0000
Subject: [issue26927] test_mmap does not handle ValueError when no large file
 support
In-Reply-To: <1462284033.57.0.466364918672.issue26927@psf.upfronthosting.co.za>
Message-ID: <1463934535.19.0.413051683014.issue26927@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

When OverflowError is raised? Shouldn't it be replaced with ValueError?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26927>
_______________________________________

From report at bugs.python.org  Sun May 22 12:30:05 2016
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 22 May 2016 16:30:05 +0000
Subject: [issue16255] subrocess.Popen needs /bin/sh but Android only has
 /system/bin/sh
In-Reply-To: <1350421202.49.0.905467284446.issue16255@psf.upfronthosting.co.za>
Message-ID: <1463934605.2.0.0146126872308.issue16255@psf.upfronthosting.co.za>


Stefan Krah added the comment:

I've also opened a feature request here:

https://code.google.com/p/android/issues/detail?id=210812

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16255>
_______________________________________

From report at bugs.python.org  Sun May 22 12:43:29 2016
From: report at bugs.python.org (Demur Rumed)
Date: Sun, 22 May 2016 16:43:29 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1463935409.42.0.584481121552.issue26647@psf.upfronthosting.co.za>


Demur Rumed added the comment:

I've tracked down the lnotab issue after modifying master/wpy to not vacuum NOPs. Old code puts LOAD_CONST at after NOPs, on the same line as return op, whereas new code is putting LOAD_CONST before NOPs, on it's own line

I've attached a fix along with addressing compiler warnings & __phello__ & adding some asserts that make sure we aren't passing indices that point inside instructions to peephole's helper functions

----------
Added file: http://bugs.python.org/file42946/wpyA.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Sun May 22 12:56:50 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 May 2016 16:56:50 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1463936210.75.0.226334403864.issue26647@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


Added file: http://bugs.python.org/file42947/wpyA.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

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: [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 13:59:02 2016
From: report at bugs.python.org (Demur Rumed)
Date: Sun, 22 May 2016 17:59:02 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1463939942.86.0.0398410696509.issue26647@psf.upfronthosting.co.za>


Demur Rumed added the comment:

Sorry for the nuisance of uploading another patch so soon. wpyB modifies test_ctypes now that __phello__ is smaller, & fixes a typo in a comment I made & removes a blank line I had added in when adding in if(0) logic

----------
Added file: http://bugs.python.org/file42948/wpyB.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Sun May 22 14:01:13 2016
From: report at bugs.python.org (Evgeny Kapun)
Date: Sun, 22 May 2016 18:01:13 +0000
Subject: [issue25996] Add support of file descriptor in os.scandir()
In-Reply-To: <1451758238.49.0.729670752807.issue25996@psf.upfronthosting.co.za>
Message-ID: <1463940073.35.0.061969178326.issue25996@psf.upfronthosting.co.za>


Changes by Evgeny Kapun <abacabadabacaba at gmail.com>:


----------
nosy: +abacabadabacaba

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25996>
_______________________________________

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: [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:14:54 2016
From: report at bugs.python.org (Paul Moore)
Date: Sun, 22 May 2016 18:14:54 +0000
Subject: [issue27064] Make py.exe default to Python 3 when used interactively
In-Reply-To: <1463693765.53.0.683202020216.issue27064@psf.upfronthosting.co.za>
Message-ID: <1463940894.24.0.95759408372.issue27064@psf.upfronthosting.co.za>


Changes by Paul Moore <p.f.moore at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27064>
_______________________________________

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: [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 14:15:34 2016
From: report at bugs.python.org (Zachary Ware)
Date: Sun, 22 May 2016 18:15:34 +0000
Subject: [issue27064] Make py.exe default to Python 3 when used interactively
In-Reply-To: <1463693765.53.0.683202020216.issue27064@psf.upfronthosting.co.za>
Message-ID: <1463940934.33.0.40469052201.issue27064@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
stage: patch review -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27064>
_______________________________________

From report at bugs.python.org  Sun May 22 14:36:06 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 22 May 2016 18:36:06 +0000
Subject: [issue26673] Tkinter error when opening IDLE configuration menu
 (Tcl/Tk 8.6)
In-Reply-To: <1459351920.73.0.899924616631.issue26673@psf.upfronthosting.co.za>
Message-ID: <20160522183603.29798.59399.3098DB2F@psf.io>


Roundup Robot added the comment:

New changeset a873265366ba by Terry Jan Reedy in branch '2.7':
Issue #26673: Protect IDLE from Linux fonts with reported default size 0.
https://hg.python.org/cpython/rev/a873265366ba

New changeset 1464df337152 by Terry Jan Reedy in branch '3.5':
Issue #26673: Protect IDLE from Linux fonts with reported default size 0.
https://hg.python.org/cpython/rev/1464df337152

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26673>
_______________________________________

From report at bugs.python.org  Sun May 22 14:42:35 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 May 2016 18:42:35 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1463942555.97.0.361195008817.issue26647@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Warnings still emitted in debug build.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Sun May 22 14:48:19 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 May 2016 18:48:19 +0000
Subject: [issue27086] Add closefd argument to os.listdir
In-Reply-To: <1463940932.93.0.542961773489.issue27086@psf.upfronthosting.co.za>
Message-ID: <1463942899.98.0.98607120618.issue27086@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

What is the problem with closing a file descriptor after calling os.listdir()?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27086>
_______________________________________

From report at bugs.python.org  Sun May 22 14:52:36 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 May 2016 18:52:36 +0000
Subject: [issue27085] Make it possible to select return type for os.listdir
In-Reply-To: <1463940504.88.0.721320439319.issue27085@psf.upfronthosting.co.za>
Message-ID: <1463943156.59.0.264469591035.issue27085@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

You can just convert os.listdir() argument or result.

os.listdir(os.fsencode(strpath))
os.listdir(os.fsdecode(bytespath))
list(map(os.fsencode, os.listdir(strpath)))
list(map(os.fsdecode, os.listdir(bytespath)))

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27085>
_______________________________________

From report at bugs.python.org  Sun May 22 14:59:49 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 May 2016 18:59:49 +0000
Subject: [issue27084] Add dir_fd and follow_symlinks kwargs to os.listdir and
 os.scandir
In-Reply-To: <1463939606.34.0.914282319382.issue27084@psf.upfronthosting.co.za>
Message-ID: <1463943589.44.0.585801929309.issue27084@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

os.listdir() with dir_fd:

    fd = os.open(path, os.O_RDONLY, dir_fd=dir_fd)
    try:
        result = os.listdir(fd)
    finally:
        os.close(fd)

What meaning of follow_symlinks for os.listdir()?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27084>
_______________________________________

From report at bugs.python.org  Sun May 22 15:02:26 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 22 May 2016 19:02:26 +0000
Subject: [issue26673] Tkinter error when opening IDLE configuration menu
 (Tcl/Tk 8.6)
In-Reply-To: <1459351920.73.0.899924616631.issue26673@psf.upfronthosting.co.za>
Message-ID: <1463943746.57.0.157382746954.issue26673@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I would like to change the code a bit more (like using IntVar for size everywhere), but I don't want to do so without tests.  The problem is that tk variables and font functions require a root window and none of the linux buildbots allow that.  (They all run 'headless'.)

----------
resolution:  -> fixed
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26673>
_______________________________________

From report at bugs.python.org  Sun May 22 15:07:38 2016
From: report at bugs.python.org (Demur Rumed)
Date: Sun, 22 May 2016 19:07:38 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1463944057.92.0.560491791503.issue26647@psf.upfronthosting.co.za>


Demur Rumed added the comment:

I have verified that wpyC does not produce signed/unsigned warnings with make DEBUG=1

----------
Added file: http://bugs.python.org/file42949/wpyC.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

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: [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 16:12:58 2016
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 22 May 2016 20:12:58 +0000
Subject: [issue27087] unable to use socket send and sendall due to type error
In-Reply-To: <1463947733.27.0.680379704915.issue27087@psf.upfronthosting.co.za>
Message-ID: <1463947978.61.0.0934694726482.issue27087@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

You'll need to convert the string to bytes first, by using .encode().

----------
nosy: +eric.smith
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27087>
_______________________________________

From report at bugs.python.org  Sun May 22 16:22:47 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 22 May 2016 20:22:47 +0000
Subject: [issue27067] Improve curses tests
In-Reply-To: <1463933409.84.0.654030520594.issue27067@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwY2WNXV4-pm2rFYCn28=zKdTfrCAOhqyLWHkd6XdZ9Pnw@mail.gmail.com>


STINNER Victor added the comment:

Zachary Ware added the comment:
>> Maybe we should have at least one buildbot testing test_curses with a TTY?
> My non-debug and installed Gentoo bot does run the tests with a PTY, ...

This one? http://buildbot.python.org/all/builders/x86%20Gentoo%20Non-Debug%20with%20X%203.x/builds/1003/steps/test/logs/stdio

"Run tests in parallel using 1 child processes": test_curses stdout is
also redirected.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27067>
_______________________________________

From report at bugs.python.org  Sun May 22 16:35:57 2016
From: report at bugs.python.org (Evgeny Kapun)
Date: Sun, 22 May 2016 20:35:57 +0000
Subject: [issue27084] Add dir_fd and follow_symlinks kwargs to os.listdir and
 os.scandir
In-Reply-To: <1463939606.34.0.914282319382.issue27084@psf.upfronthosting.co.za>
Message-ID: <1463949357.81.0.582068121875.issue27084@psf.upfronthosting.co.za>


Evgeny Kapun added the comment:

1. Yes, it's possible to emulate dir_fd this way, so this is just for convenience.
2. If follow_symlinks is False, O_NOFOLLOW is passed to the underlying open(2) syscall. Of course, this doesn't make sense if a file descriptor is passed already.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27084>
_______________________________________

From report at bugs.python.org  Sun May 22 16:45:47 2016
From: report at bugs.python.org (Evgeny Kapun)
Date: Sun, 22 May 2016 20:45:47 +0000
Subject: [issue27086] Add closefd argument to os.listdir
In-Reply-To: <1463940932.93.0.542961773489.issue27086@psf.upfronthosting.co.za>
Message-ID: <1463949947.19.0.00365609762991.issue27086@psf.upfronthosting.co.za>


Evgeny Kapun added the comment:

Not a problem, just two unnecessary syscalls. Also, I think that many of those who pass a file descriptor to os.listdir don't need it afterwards, because after you fstat() a file descriptor (to discover that it points to a directory) and read the directory contents, there are few things you can use it for.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27086>
_______________________________________

From report at bugs.python.org  Sun May 22 16:59:23 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 22 May 2016 20:59:23 +0000
Subject: [issue26632] __all__ decorator
In-Reply-To: <1463728902.04.0.1418816847.issue26632@psf.upfronthosting.co.za>
Message-ID: <20160522165919.21a72cea@subdivisions.wooz.org>


Barry A. Warsaw added the comment:

On May 20, 2016, at 07:21 AM, Franklin? Lee wrote:

>I am iffy about using ``public`` to define other values. That part might be
>considered unpythonic.

It's a bit of a stretch.  I like it for the convenience, and the
implementation is simple, but if e.g. Guido disliked this part of it, I'd be
okay dropping it.  I think the use on non-__name__'d things is rare enough
that a little inconvenience wouldn't be a fatal flaw.

>    - ``__module__`` is not reliable. ``functools.wraps`` changes it. (Why
>    - does it do that, though?)

I don't know, but what practical effect will this have?  I.e. under what
conditions would you @public wrap a @functools.wraps function and want it to
show up in __all__?  Do you have a specific use case?

Also note that this is a subtle difference between the C and Python
implementations.  I actually expect that if this were adopted for Python 3.6,
we'd pretty much only use the C version.  In the standalone package, I'm
including the Python versions mostly just for convenience in environments
without a compiler (though maybe a built wheel for some platforms would be
useful).

>    - If `__all__` isn't a list, you'd have to make it a list before you mess
>    - with it. (Is this possible?)

It would be possible.  I'd just do the equivalent of::

    __all__ = list(__all__)

But I actually think that best practice would be not to set __all__ explicitly
if you're going to use @public.  If you really want it to be immutable, you'd
put the following at the bottom of your module:

    __all__ = tuple(__all__)

For now I've added some usage caveats that describe these points.

>> > On the down side, you know somebody is going to @public a class' method --
>> > how do we check for that?  
>>
>> Do we need to?  Consenting adults and __all__.  
>
>It's a silent error waiting to happen. If you never use ``import *`` on it
>(e.g. because it's your main file), you won't get the error message. Things
>will work "as expected" (your methods are class-public!) until you give a
>method the same name as a builtin or something you imported or defined
>earlier. When that happens, the error message will have nothing to do with
>the problem.
>
>It might be detectable using ``thing.__qualname__ != thing.__name__``, but
>this disallows functions decorated without updating __qualname__, and
>static/class methods exposed in a module's interface.
>
>It might be detectable by checking, on the callstack, whether you're in a
>module load or a class definition.

Sure, we could probably add some heuristics, but I still don't see the need
for the extra complexity.  The error will be far from the declaration, but the
exception should make it relatively obvious what's going on.  I also really
don't think folks would naturally be inclined to put @public on anything but a
top-level definition.  You wouldn't ever put such a thing in your __all__ so
why would you decorate it with @public?

In any case, I've added a usage caveat for this case too.

>How many public module values aren't enum-type constants?

These days I bet they are quite a bit more common than enum-types, although I
agree that enums are great and we should use more of them!  Just historically
speaking I don't know how many packages have converted all their constants
over to enums.

Also, I know that I have several cases where constants are actually
instances.  They could be marker objects like::

    MARKER = object()

or system globals::

    configuration = Configuration()

I'd want both of those in __all__.

>It could be useful to be able to dump an enum into a module's space. I mean,
>a canonical way. With that, maybe maintaining module-level constants in
>__all__ isn't that big a deal.
>
>    # Rather than:
>    globals().update(MyEnum.__members__)
>    __all__.extend(MyEnum.__members__)
>    # Perhaps allow:
>    enum.dump_namespace(MyEnum, globals())

It's an interesting thought.

>About the cost paid at every load:
>    - Should tools update __all__ for you, and comment out the ``@public``s?
>        - If so, how would they deal with public non-callable values?
>    - When compiling to .pyc, should the compiler remove ``@public`` calls
>    and explicitly add the values to __all__?

Why?  Aren't those one-time costs only borne when the module is originally
imported?

>API:
>    - Alternative syntax for constants, requiring less frame hackery:
>        public(globals(), x=1, y=2, z=3)

Possibly.  Since this is really only relevant for the pure-Python
implementation, I'm not as keen on the extra cruft.

>    - Naming: Is it really "public"? Some names might be public but not in
>    - __all__.

What does it mean for a name to be "public but not in __all__"?

I'll also note that since the basic API has been independently invented at
least three times, and all of them use @public, it seems like the obvious
choice. ;)

>P.S. Typo in the ReadTheDocs. ``py_install`` should be a function call, right?
>
>    >>> from public import py_install
>    >>> py_install  

Fixed, thanks!

>P.S.: Would OrderedSet (which doesn't exist) be the ideal type for __all__? I
>mean, if you had to use someone else's __all__, not if you had to maintain
>it.

It's an interesting thought, but I don't know if it's enough of a use case to
add collections.OrderedSet.  Traditionally __all__ has been a list, with some
relatively recent moves to making it a tuple.

Thanks for the interesting and useful feedback!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26632>
_______________________________________

From report at bugs.python.org  Sun May 22 16:59:44 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 22 May 2016 20:59:44 +0000
Subject: [issue26632] __all__ decorator
In-Reply-To: <1463727769.02.0.111712900279.issue26632@psf.upfronthosting.co.za>
Message-ID: <20160522165941.5635cafa@subdivisions.wooz.org>


Barry A. Warsaw added the comment:

On May 20, 2016, at 07:02 AM, Berker Peksag wrote:

>+1 for the idea. I saw a lot of different 'all' or 'public' decorators in the
>wild. It would be nice to have a complete solution in Python. It would be
>good to add a note to Doc/whatsnew/3.6.rst.

Is that a pronouncement? :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26632>
_______________________________________

From report at bugs.python.org  Sun May 22 17:14:33 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 May 2016 21:14:33 +0000
Subject: [issue27084] Add dir_fd and follow_symlinks kwargs to os.listdir and
 os.scandir
In-Reply-To: <1463939606.34.0.914282319382.issue27084@psf.upfronthosting.co.za>
Message-ID: <1463951673.44.0.112314190757.issue27084@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

But why you want to pass O_NOFOLLOW to the underlying open(2) syscall?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27084>
_______________________________________

From report at bugs.python.org  Sun May 22 17:38:23 2016
From: report at bugs.python.org (Demur Rumed)
Date: Sun, 22 May 2016 21:38:23 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1463953103.41.0.436137000443.issue26647@psf.upfronthosting.co.za>


Demur Rumed added the comment:

Removes 0 <= unsigned assertion & fixes j < 0 check to avoid overflow bug

----------
Added file: http://bugs.python.org/file42950/wpyD.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Sun May 22 17:53:34 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 22 May 2016 21:53:34 +0000
Subject: [issue26980] The path argument of
 asyncio.BaseEventLoop.create_unix_connection is not documented
In-Reply-To: <1462743548.86.0.976035936413.issue26980@psf.upfronthosting.co.za>
Message-ID: <1463954014.34.0.577529168849.issue26980@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

It's the name of the UNIX domain socket.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26980>
_______________________________________

From report at bugs.python.org  Sun May 22 18:04:08 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 22 May 2016 22:04:08 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1463954648.7.0.740619138244.issue26647@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM. If no one has more comments, I'm going to commit the patch.

----------
assignee:  -> serhiy.storchaka
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Sun May 22 18:25:35 2016
From: report at bugs.python.org (Evgeny Kapun)
Date: Sun, 22 May 2016 22:25:35 +0000
Subject: [issue27084] Add dir_fd and follow_symlinks kwargs to os.listdir and
 os.scandir
In-Reply-To: <1463939606.34.0.914282319382.issue27084@psf.upfronthosting.co.za>
Message-ID: <1463955935.15.0.408794135664.issue27084@psf.upfronthosting.co.za>


Evgeny Kapun added the comment:

Mostly for consistency with other functions. Also, this provides an easy way to walk a directory tree recursively: just call listdir on every member, and if it doesn't raise OSError, that member must be a directory. With follow_symlinks=False, this method wouldn't follow symlinks, unlike os.walk and os.fwalk, which always follow symlinks at least to differentiate between symlinks to directories and other symlinks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27084>
_______________________________________

From report at bugs.python.org  Sun May 22 18:28:27 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 22 May 2016 22:28:27 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1463956107.14.0.023194858222.issue26647@psf.upfronthosting.co.za>


STINNER Victor added the comment:

wpyD.patch LGTM, go ahead! We can still polish it later and discuss how to implement the 16-bit fetch ;-)

It would be nice to add a short comment in Python/wordcode_helpers.h explaining that it contains code shared by the compiler and the peephole optimizer. It can be done later.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Sun May 22 19:03:20 2016
From: report at bugs.python.org (Robert Collins)
Date: Sun, 22 May 2016 23:03:20 +0000
Subject: [issue27071] unittest.TestCase.assertCountEqual is a very misleading
 name
In-Reply-To: <1463788380.52.0.782790370377.issue27071@psf.upfronthosting.co.za>
Message-ID: <1463958200.54.0.829619422513.issue27071@psf.upfronthosting.co.za>


Robert Collins added the comment:

I don't particularly like either name FWIW :) - but sure, we can add a different name and deprecate assertCountEqual - but before we do anything lets look up the previous issue where the rename was done.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27071>
_______________________________________

From report at bugs.python.org  Sun May 22 19:06:39 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 22 May 2016 23:06:39 +0000
Subject: [issue24225] Idlelib: changing file names
In-Reply-To: <1431934587.56.0.38760352205.issue24225@psf.upfronthosting.co.za>
Message-ID: <1463958399.08.0.552134784876.issue24225@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Attached are my current renames, with just a few changes from before  Most are lower case versions of the current names, perhaps shortened.  I expect names with '_' to disappear in future file merges.  I may change 'outwin' before 3.6 is released.

The biggest changes are the 3 xyzBindings files.  In tk, bind methods connect an event to an event handler.  Bindings.py defines the menu of the main windows, and the associated pseudoevents, but not the event bindings.  Hence, 'mainmenu'.  (I considered just 'menu', but 'menu' is used as a local name in multiple places.)  The other two may have bindings, but that is a fairly trivial implementatin detail and I would rather have name that reflect what the files do or implement.  If 'iomenu' is expanded to implement more of the file menu, I may rename it 'filemenu' or 'files'.

I have an independent clone of 3.6 with no connection to my normal working repositories.  We can discuss squashing commits or not when I am ready to push.

Al's 'idle_updating_imports.patch' missed a couple of renames in comments, but its code changes seem complete and correct as of a year ago.  (The main change is replacing some code with the new help.py.) It will be very useful.  I replaced his new names with mine with a short program and expect only a couple of chunks to fail.

----------
Added file: http://bugs.python.org/file42951/i3rename.bat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24225>
_______________________________________

From report at bugs.python.org  Sun May 22 19:30:53 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 22 May 2016 23:30:53 +0000
Subject: [issue26632] __all__ decorator
In-Reply-To: <1458786797.31.0.0749407715279.issue26632@psf.upfronthosting.co.za>
Message-ID: <1463959853.58.0.880895157152.issue26632@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here are two examples where publicly-documented module attributes are intentionally omitted from __all__:

* Issue 26234: typing.re and typing.io
* Issue 23439: HTTP status codes like http.client.NOT_FOUND

Despite these, I think @public is a reasonable name. But I may be biased, because I personally think everything should be included in __all__. Otherwise pydoc does not pick it up.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26632>
_______________________________________

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: [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  Sun May 22 19:46:04 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 22 May 2016 23:46:04 +0000
Subject: [issue27067] Improve curses tests
In-Reply-To: <1463731355.86.0.176847535381.issue27067@psf.upfronthosting.co.za>
Message-ID: <1463960764.56.0.736143336626.issue27067@psf.upfronthosting.co.za>


Martin Panter added the comment:

I?m not 100% following this, but it is sounding like a terminal may be required for proper testing. Perhaps I could try and help by creating a pseudo-terminal in the Python test code, as I hinted at <https://bugs.python.org/issue12669#msg265663>.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27067>
_______________________________________

From report at bugs.python.org  Sun May 22 20:50:41 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 23 May 2016 00:50:41 +0000
Subject: [issue26632] __all__ decorator
In-Reply-To: <1463959853.58.0.880895157152.issue26632@psf.upfronthosting.co.za>
Message-ID: <20160522205035.2376e515@subdivisions.wooz.org>


Barry A. Warsaw added the comment:

On May 22, 2016, at 11:30 PM, Martin Panter wrote:

>Here are two examples where publicly-documented module attributes are
>intentionally omitted from __all__:
>
>* Issue 26234: typing.re and typing.io
>* Issue 23439: HTTP status codes like http.client.NOT_FOUND

Wild.

>Despite these, I think @public is a reasonable name. But I may be biased,
>because I personally think everything should be included in
>__all__. Otherwise pydoc does not pick it up.

I think it's pretty reasonable, and pretty well-established despite some
exceptions, that __all__ names a module's public symbols.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26632>
_______________________________________

From report at bugs.python.org  Mon May 23 01:31:54 2016
From: report at bugs.python.org (Vitaly)
Date: Mon, 23 May 2016 05:31:54 +0000
Subject: [issue27071] unittest.TestCase.assertCountEqual is a very misleading
 name
In-Reply-To: <1463788380.52.0.782790370377.issue27071@psf.upfronthosting.co.za>
Message-ID: <1463981514.0.0.691929266875.issue27071@psf.upfronthosting.co.za>


Vitaly added the comment:

As far as I can tell, issue #10242 deals with the renaming. I think that the arguments for the new name are flawed (sorry to be so blunt, but I don't know how else to express it).

Regardless of whether it's Count or Counts, to most people it sounds like it's going to compare just the simple counts of the elements (i.e., lengths of the sequences). Ask yourself the questions: 1. What is the element count in sequence S? Reasonable answer: len(S).  2. What are the element counts of sequences Q and S? Reasonable answer len(Q) and len(S). Those are the most straightforward, non-nuanced answers you would get from most people IMHO.

With ambiguous names like these, readability of the code is greatly diminished. When I review code, a name like assertCountEqual tells me (and likely most other reviewers) that it's comparing lengths of the sequences, and I have no reason to resort to the documentation. A well-named function should do what its name says, and its name should say what it does. assertCountEqual doesn't pass that test, unless you read the documentation, and apply the nuanced interpretation that is biased by the documentation. assertElementCountsEqual is in the same category, I am afraid :) The straightforward interpretation of these names is misleading at worst and ambiguous at best.

I think that the authors of the new name assertCountEqual were thinking along the lines of "assert frequency counts equal", which might lead to the arguably unambiguous name assertFrequencyCountsEqual, but but all that sounds more complicated than it needs to be.

Personally, something like assertElementsEqual seems to me to capture the spirit of the assertion better and is easier for most people to grasp. It doesn't imply order as it emphasizes the elements (vs. assertSequenceEqual, which emphasizes sequence), and it doesn't imply uniqueness. I like assertElementsEqual more than assertItemsEqual, but then again, assertElementsEqual is not sufficiently better than assertItemsEqual to warrant a backward-incompatible name change in my opinion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27071>
_______________________________________

From report at bugs.python.org  Mon May 23 01:42:31 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 23 May 2016 05:42:31 +0000
Subject: [issue26927] test_mmap does not handle ValueError when no large file
 support
In-Reply-To: <1462284033.57.0.466364918672.issue26927@psf.upfronthosting.co.za>
Message-ID: <20160523054227.19660.88847.F19E623E@psf.io>


Roundup Robot added the comment:

New changeset bca81ea8f898 by Serhiy Storchaka in branch '3.5':
Issue #26927: Fixed test_mmap on platforms with 32-bit off_t (like Android).
https://hg.python.org/cpython/rev/bca81ea8f898

New changeset 6147a2c99db0 by Serhiy Storchaka in branch 'default':
Issue #26927: Fixed test_mmap on platforms with 32-bit off_t (like Android).
https://hg.python.org/cpython/rev/6147a2c99db0

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26927>
_______________________________________

From report at bugs.python.org  Mon May 23 02:01:21 2016
From: report at bugs.python.org (Vitaly)
Date: Mon, 23 May 2016 06:01:21 +0000
Subject: [issue27071] unittest.TestCase.assertCountEqual is a very misleading
 name
In-Reply-To: <1463788380.52.0.782790370377.issue27071@psf.upfronthosting.co.za>
Message-ID: <1463983281.14.0.314613310113.issue27071@psf.upfronthosting.co.za>


Vitaly added the comment:

If there really is a good systemic reason why names like assertItemsEqual and assertElementsEqual are flawed, then assertFrequencyCountsEqual might be a less-ambiguous alternative.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27071>
_______________________________________

From report at bugs.python.org  Mon May 23 02:02:47 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 May 2016 06:02:47 +0000
Subject: [issue16182] readline: Wrong tab completion scope indices in Unicode
 terminals
In-Reply-To: <1349813384.06.0.615857426211.issue16182@psf.upfronthosting.co.za>
Message-ID: <1463983367.37.0.631877574355.issue16182@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Yes, the readline module is broken in Python 3. Underlying C library operates C strings and use locale-depended C functions to split it on Unicode characters. The Python wrapper always uses the UTF-8 encoding for converting between Python strings and C strings. It works only on UTF-8 locales. get_begidx() and get_endidx() don't correctly work at all for non-ASCII data. We should use locale encoding for converting.

Proposed patch makes the readline module to use locale depending coding functions instead of default UTF-8. It also corrects indices for get_begidx() and get_endidx().

----------
nosy: +martin.panter
versions: +Python 3.6 -Python 3.4
Added file: http://bugs.python.org/file42952/readline_locale.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16182>
_______________________________________

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: [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 04:17:52 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 23 May 2016 08:17:52 +0000
Subject: [issue27089] I think this is a small bug in urlparse.py
In-Reply-To: <1463990790.48.0.380768478643.issue27089@psf.upfronthosting.co.za>
Message-ID: <1463991472.18.0.566700197273.issue27089@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Why? I think this is the right behaviour. According to the rfc[1], square brackets are used and only used to refer IPv6 address in URI. Square brackets are reserved characters and the URI you give is not correct.

1. http://tools.ietf.org/html/rfc3986#section-3

----------
nosy: +xiang.zhang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27089>
_______________________________________

From report at bugs.python.org  Mon May 23 04:51:45 2016
From: report at bugs.python.org (Feng A)
Date: Mon, 23 May 2016 08:51:45 +0000
Subject: [issue27089] I think this is a small bug in urlparse.py
In-Reply-To: <1463990790.48.0.380768478643.issue27089@psf.upfronthosting.co.za>
Message-ID: <1463993505.32.0.0768392268604.issue27089@psf.upfronthosting.co.za>


Feng A added the comment:

I wish you could think twice if you hadn't use urlparse.py in practical project.  

1. Do you like the module to raise an exception?
2. The href in webpage is always standard format?
3. Should the parse module verify the ipv6 url format? If so, did the module really make it?

4. Personally, Given a wrong formated url, It is the responsibility of the module to correct it ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27089>
_______________________________________

From report at bugs.python.org  Mon May 23 05:03:35 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 23 May 2016 09:03:35 +0000
Subject: [issue27089] I think this is a small bug in urlparse.py
In-Reply-To: <1463990790.48.0.380768478643.issue27089@psf.upfronthosting.co.za>
Message-ID: <1463994215.04.0.636790834101.issue27089@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

As a general purpose library for url parsing, I think conforming to the existing standard is a good choice.

'http://google.com]' is a malformed URI according to the standard and then I think raising an exception is quite suitable. Of course there are always malformed links in webpages but how to correct them is quite objective. I think catch the exception in application and correct them in your own logic is what you should do.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27089>
_______________________________________

From report at bugs.python.org  Mon May 23 05:04:27 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 23 May 2016 09:04:27 +0000
Subject: [issue27089] I think this is a small bug in urlparse.py
In-Reply-To: <1463990790.48.0.380768478643.issue27089@psf.upfronthosting.co.za>
Message-ID: <1463994267.97.0.767996893894.issue27089@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Ohh, not objective, but subjective. Sorry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27089>
_______________________________________

From report at bugs.python.org  Mon May 23 05:20:01 2016
From: report at bugs.python.org (Antti Haapala)
Date: Mon, 23 May 2016 09:20:01 +0000
Subject: [issue27089] I think this is a small bug in urlparse.py
In-Reply-To: <1463990790.48.0.380768478643.issue27089@psf.upfronthosting.co.za>
Message-ID: <1463995201.84.0.897157848441.issue27089@psf.upfronthosting.co.za>


Antti Haapala added the comment:

This behaviour exists exactly because the return value also contains the `.hostname`, which for the IPv6 addresses is *without* brackets:

    >>> urlparse('http://[::1]:80/').hostname
    '::1'

There is no way to get a proper parsing result from such a broken URI.

----------
nosy: +ztane

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27089>
_______________________________________

From report at bugs.python.org  Mon May 23 05:30:40 2016
From: report at bugs.python.org (Berker Peksag)
Date: Mon, 23 May 2016 09:30:40 +0000
Subject: [issue27089] I think this is a small bug in urlparse.py
In-Reply-To: <1463990790.48.0.380768478643.issue27089@psf.upfronthosting.co.za>
Message-ID: <1463995840.86.0.0856793667513.issue27089@psf.upfronthosting.co.za>


Berker Peksag added the comment:

> 4. Personally, Given a wrong formated url, It is the responsibility of the module to correct it ?

It's not the responsibility of the library to correct (or make a guess on) user input.

----------
nosy: +berker.peksag
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27089>
_______________________________________

From report at bugs.python.org  Mon May 23 05:43:55 2016
From: report at bugs.python.org (aixtools)
Date: Mon, 23 May 2016 09:43:55 +0000
Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not
 available (e.g., AIX)
In-Reply-To: <1463100359.28.0.83634743721.issue26439@psf.upfronthosting.co.za>
Message-ID: <98da3931-de2a-ab87-5f6a-0bbae43a23c9@gmail.com>


aixtools added the comment:

See below between points.

On 12-May-16 17:45, Martin Panter wrote:
> Martin Panter added the comment:
>
> Thanks for trying to move the directory in the new patch, but it does not seem to have been picked up by Rietveld. I have only seen patches generated with Mercurial and Git work, but I don?t exactly know _why_ they work :)
>
> Here is a summary of what I would be comfortable adding to Python:
>
> 1. Add ctypes.RTLD_MEMBER constant (new API, so 3.6+ only)
Understood. Should also add RTLD_NOW as it is referenced in comments, 
and used in the _global.c (imho).
> 2. Basic ctypes.util.find_library("crypto") implementation for AIX. But cases like find_library("libintl.so") should fail. I think your earlier patches were closer to this implementation than the later ones.
>
> I am a bit hesitant about the automatic behaviour of CDLL("libcrypto.a(libcrypto.so.1.0.0)") using RTLD_MEMBER. IMO it may be better to let the caller specify RTLD_MEMBER explicitly. If a shared library file literally called ?/usr/lib/libcrypto.a(libcrypto.so.1.0.0)? existed, i.e. not inside an archive, would dlopen("libcrypto.a(libcrypto.so.1.0.0)", RTLD_NOW) succeed? I admit this is an unlikely scenario, but it seems bad to reduce the domain of a low-level API.
>
> I understand it would be good to have the return value of find_library() consistent with the name accepted by CDLL(). Perhaps a new parameter format would help, such as a tuple (archive, member).
I would expect a new tuple would be seen as new API (like 
_ctypes.RTLD_MEMBER), so it would never help in Python-2.7, which is 
still where I see most people asking for support with AIX.
My guidance was: find_library("m") is legal, as is 
find_library("libm.so"), as is CDLL("libcrypt.so").

These are all dependencies, at a low-level of how the system is 
configured, i.e., it is not uncommon for a GNU/Linux installation to 
have many symbolic links to resolve multiple names, and programmers use 
one, or more of those conventions. The find_library() and CDLL() calls 
work because of these conventions.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Thu May 19 02:53:48 2016 from xxx.yyy.zzz.net 
<http://76-217-205-93.lightspeed.sndgca.sbcglobal.net>
root at x066:~# python -m ctypes.util
libm.so.6
libc.so.6
libbz2.so.1.0
<CDLL 'libm.so', handle f7c0f5e0 at 104493d0>
<CDLL 'libcrypt.so', handle 1045b2d8 at 104493d0>
libcrypt.so.1

Looking at filesystem level:
root at x066:~# cd /lib64
root at x066:/lib64# ls -l libcrypt.*
lrwxrwxrwx 1 root root 16 Feb 22  2015 libcrypt.so.1 -> libcrypt-2.13.so 
<http://libcrypt-2.13.so>
root at x066:/lib64# cd /usr/lib64
root at x066:/usr/lib64# ls -l libcrypt.*
-rw-r--r-- 1 root root 62108 Feb 22  2015 libcrypt.a
lrwxrwxrwx 1 root root    20 Feb 22  2015 libcrypt.so -> 
/lib64/libcrypt.so.1

So, CDLL.dlopen() finds /usr/lib64/libcrypt.so that is a symbolic link 
to /lib64/libcrypt.so.1 that is a symbolic link to 
/lib64/libcrypt-2.13.so <http://libcrypt-2.13.so>. I see libcrypt.so as 
a "shorthand" for whatever is installed. As a porgrammer/user of 
CDLL.dlopen() I do not care what it finally resolves to.

Linux has it's conventions: one important one I observe when porting OSS 
packages is that "installation" and updates of libraries (or API's) 
provide "shortnames" in the form of libFOO.so  that are symbolic names 
to the final object. Unfortunately, there are exceptions - especially 
look at "libc.so"

root at x066:/usr/lib64# ls -l libc.so*
-rw-r--r-- 1 root root 243 Feb 22  2015 libc.so

root at x066:/usr/lib64# cd /lib64
root at x066:/lib64# ls -l libc.so*
lrwxrwxrwx 1 root root 12 Feb 22  2015 libc.so.6 -> libc-2.13.so
root at x066:/lib64# ls -l libc-2.13.so
-rwxr-xr-x 1 root root 1758016 Feb 22  2015 libc-2.13.so

Obviously, using shorthand for libc.so on Debian is not returning 
anything equivalent to libc.so.6 (look at the different sizes). So, a 
program that looks specifically for libc.so.6 will succeed on Debian, 
and fail on AIX (as it does not exist in that form) - and my expectation 
is that existing programs that code libc.so.6 will fail on AIX. However, 
I have extreme doubts that anyone actually codes the test - as (at least 
on AIX) libc is already loaded.

AIX:
root at x071:[/root]ldd /opt/bin/python
/opt/bin/python needs:
          /usr/lib/libc.a(shr.o)
          /usr/lib/libpthreads.a(shr_xpg5.o)
          /usr/lib/libpthreads.a(shr_comm.o)
          /usr/lib/libdl.a(shr.o)
          /unix
          /usr/lib/libcrypt.a(shr.o)

And, it seems, libc is also already loaded on Debian:
root at x066:/lib64# ldd /usr/bin/python
         linux-vdso32.so.1 =>  (0x00100000)
         libpthread.so.0 => /lib/powerpc-linux-gnu/libpthread.so.0 
(0x0ffc5000)
         libdl.so.2 => /lib/powerpc-linux-gnu/libdl.so.2 (0x0ffa1000)
         libutil.so.1 => /lib/powerpc-linux-gnu/libutil.so.1 (0x0ff7e000)
         libz.so.1 => /lib/powerpc-linux-gnu/libz.so.1 (0x0ff47000)
         libm.so.6 => /lib/powerpc-linux-gnu/libm.so.6 (0x0fe79000)
         libc.so.6 => /lib/powerpc-linux-gnu/libc.so.6 (0x0fce0000)
         /lib/ld.so.1 (0x20231000)

So back to my thoughts as I developed this "behavior" patch for 
ctypes/util aka ctypes/cdll:
a) to be transparent - mask (but not hide) AIX "internals" that are 
(probably) a level of detail programmers are not interested in. That is 
what I imagined the original design goal of the Lib addition.
b) to support existing code ASIS (the first two python packages I looked 
at being cloud-init and salt-stack)
c) as a bonus: potentially resolve any performance "bugs" caused by the 
lack of /bin/ldconfig

AIX has it's conventions - the main one being to look in archives (.a 
files) for members. To signify that it is an archive member an 
additional dlopen() mode is used. Without this flag, dlopen() looks for 
a file - just like other "posix" platforms - period.

re: your objections/concerns
a) I am shooting myself for being so visible - as I have done a lot of 
porting and, in particular, "intl" aka libintl.so support is important 
for programmers that are expecting GNU gettext support for multiple 
languages.
These seems pointless on a generic Debian install - because while 
gettext is available, there is no "libintl" to be found (using either 
gcc or ldconfig -p to search), e.g.:

root at x066:/lib64# ldconfig -p | grep intl
root at x066:/lib64# gettext --version
gettext (GNU gettext-runtime) 0.18.1

The tests re: libcrypto I added because behavior re: libssl and 
libcrypto is important. Many applications need that. (libcrypt is not 
"SSL" support).

So, back to what I think are your objections:
a) seeing a name ending in ")" as being the AIX "native" format and 
adding RTLD_MEMBER without any further test of it being a file.
b) expanding a "generic" name ending in .so to a latest version IF it 
does not exist as .so in an archive, or as a file.

re: a) a test could be added to verify that a file with a name ending 
with ")") does not exist before adding the RTLD_MEMBER mode - this is 
only being considered on AIX (that condition must be determined first 
anyway) and, as you say - it is unlikely to be the case. So, a test 
could be added - that would probably always fail - slowing calls down.

re: b) I consider it better practice (and maybe this is my arrogance of 
35 years + of supporting multiple platforms in libraries (now API) 
transparently. I am the weirdo who likes to dive into low-level, 
bit-level "idiosyncrasies" of different os systems and/or levels. 
"Normal" people do not care a #$%! - they just want it to work.

Again, imho a key issue that needs to be addressed is to get as much 
code to work ASIS - as much as possible - rather than the current 
situation (without my proposed patch) the requires many changes must be 
made to AIX, as root, and these must also be maintained (performed 
again) after any update to the OS - at least controlled. This is not 
facilitate using python, better python acceptance (on AIX) - and seems 
conducive to security breaches.

Sincerely,
Michael
> I am not comfortable with other aspects. I think I would have to see more discussion with other people to change my opinion:
>
> 1. CDLL("libintl.so") should not load ?libintl.a(libintl.so.1)?. I understand you want this to help code written for Gnu or Linux automatically work on AIX, but it doesn?t feel correct and robust to me. Perhaps moving this sort of thing to a separate function or package would be better.
>
> 2. find_library("libintl.so") -> "libintl.a(libintl.so.1)". I would expect it to look for a shared library installed in something like "/usr/lib/liblibintl.so.a", unless I have misunderstood how compile-time linking (cc -llibintl.so) works.
See above - again, shooting myself for having included these additional 
"behavior" examples.

> 3. find_library() should not set the LIBPATH environment variable.
This was a convenience. It may be better to have the default search path 
hard-coded using a -Wl,blibpath link flag. As the discussion re: Linux 
support was to not include it (or was it remove it after it had been 
added) . shall follow and "Will remove" to be compareable.
> ----------
>
> _______________________________________
> Python tracker<report at bugs.python.org> <mailto:report at bugs.python.org>
> <http://bugs.python.org/issue26439> <http://bugs.python.org/issue26439>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26439>
_______________________________________

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: [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 06:14:18 2016
From: report at bugs.python.org (Richard Penman)
Date: Mon, 23 May 2016 10:14:18 +0000
Subject: [issue27090] Python 3 import error after installation
In-Reply-To: <1463998249.7.0.0539436508645.issue27090@psf.upfronthosting.co.za>
Message-ID: <1463998458.13.0.885507182161.issue27090@psf.upfronthosting.co.za>


Richard Penman added the comment:

The full error log:

$ python3
Failed to import the site module
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/site-packages/site.py", line 75, in <module>
    __boot()
  File "/usr/local/lib/python2.7/site-packages/site.py", line 23, in __boot
    loader.load_module('site')
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site.py", line 563, in <module>
    main()
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site.py", line 549, in main
    known_paths = addusersitepackages(known_paths)
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site.py", line 281, in addusersitepackages
    user_site = getusersitepackages()
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site.py", line 257, in getusersitepackages
    user_base = getuserbase() # this will also set USER_BASE
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site.py", line 247, in getuserbase
    USER_BASE = get_config_var('userbase')
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/sysconfig.py", line 582, in get_config_var
    return get_config_vars().get(name)
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/sysconfig.py", line 561, in get_config_vars
    import _osx_support
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/_osx_support.py", line 4, in <module>
    import re
  File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/re.py", line 335, in <module>
    import copyreg
  File "/usr/local/lib/python2.7/site-packages/copyreg/__init__.py", line 7, in <module>
    raise ImportError('This package should not be accessible on Python 3. '
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.

What needs to be changed to avoid importing Python 2 modules?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27090>
_______________________________________

From report at bugs.python.org  Mon May 23 06:17:44 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Mon, 23 May 2016 10:17:44 +0000
Subject: [issue16353] add function to os module for getting path to default
 shell
In-Reply-To: <1351473560.4.0.147895276383.issue16353@psf.upfronthosting.co.za>
Message-ID: <1463998664.47.0.122281052822.issue16353@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Following Serhiy suggestion at msg224477, this tentative patch adds the is_android attribute to the posix module and the default_shell attribute to the os module. No documentation for the moment. No test case is needed I think, as the changes in issue 16255 will test any solution found here.

An alternative to posix.is_android is sys.platform set to 'linux-android' on Android. These are the locations in the standard library that do not test for "if sys.platform.startswith('linux')":

Lib/distutils/tests/test_dist.py|386 col 16| if sys.platform in ('linux', 'darwin'):
Lib/test/test_logging.py|527 col 12| if sys.platform in ('linux', 'darwin'):
Lib/test/test_resource.py|135 col 26| @unittest.skipUnless(sys.platform == 'linux', 'test requires Linux')
Lib/test/test_socket.py|898 col 16| or sys.platform in ('linux', 'darwin')):
Lib/test/test_socket.py|2256 col 23| @skipWithClientIf(sys.platform not in {"linux"},
Lib/test/test_socket.py|4508 col 22| @unittest.skipUnless(sys.platform == 'linux', 'Linux specific test')
Lib/test/test_sysconfig.py|388 col 26| @unittest.skipUnless(sys.platform == 'linux', 'Linux-specific test')

----------
nosy: +xdegaye
Added file: http://bugs.python.org/file42953/default_shell.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16353>
_______________________________________

From report at bugs.python.org  Mon May 23 06:19:02 2016
From: report at bugs.python.org (Richard Penman)
Date: Mon, 23 May 2016 10:19:02 +0000
Subject: [issue27090] Python 3 import error after installation
In-Reply-To: <1463998249.7.0.0539436508645.issue27090@psf.upfronthosting.co.za>
Message-ID: <1463998742.64.0.114881948524.issue27090@psf.upfronthosting.co.za>


Richard Penman added the comment:

Apparently "The PYTHONPATH variable is used by all versions of Python 2 and Python 3, so you should not permanently configure this variable unless it only includes code that is compatible with all of your installed Python versions."

That seems crazy...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27090>
_______________________________________

From report at bugs.python.org  Mon May 23 06:53:39 2016
From: report at bugs.python.org (Clement Rouault)
Date: Mon, 23 May 2016 10:53:39 +0000
Subject: [issue23026] Winreg module doesn't support REG_QWORD,
 small DWORD doc update
In-Reply-To: <1418242433.97.0.849861872047.issue23026@psf.upfronthosting.co.za>
Message-ID: <1464000819.94.0.865644884594.issue23026@psf.upfronthosting.co.za>


Changes by Clement Rouault <python at hakril.net>:


----------
nosy: +hakril

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23026>
_______________________________________

From report at bugs.python.org  Mon May 23 07:15:45 2016
From: report at bugs.python.org (Clement Rouault)
Date: Mon, 23 May 2016 11:15:45 +0000
Subject: [issue23026] Winreg module doesn't support REG_QWORD,
 small DWORD doc update
In-Reply-To: <1418242433.97.0.849861872047.issue23026@psf.upfronthosting.co.za>
Message-ID: <1464002145.78.0.890383559449.issue23026@psf.upfronthosting.co.za>


Clement Rouault added the comment:

I also stumbled on this issue when playing with the winreg module.
I will try to make the discussion go forward by submitting a new patch.
I added a test and tried everything (test included on 3.5) on my own computer (windows 8.1 64b)
There are two points that might be 'sensitive' and I would like to have someone's opinion:
    * I am using `DWORD64` as an unsigned 64bit value as `QWORD` is not defined in <windows.h>
    * I changed one line of the previous implementation for REG_DWORD:
        * `PyLong_FromUnsignedLong(*(int *)retDataBuf);` became `PyLong_FromUnsignedLong(*(DWORD *)retDataBuf);`
        * I don't think it is a problem, but better ask than break something

----------
versions: +Python 3.5 -Python 3.4
Added file: http://bugs.python.org/file42954/winreg_qword_patch_with_test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23026>
_______________________________________

From report at bugs.python.org  Mon May 23 08:40:04 2016
From: report at bugs.python.org (Christian Kleineidam)
Date: Mon, 23 May 2016 12:40:04 +0000
Subject: =?utf-8?q?=5Bissue27091=5D_Python_IDLE_doesn=27t_like_=F0=9F=92=99?=
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:42:37 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 May 2016 12:42:37 +0000
Subject: [issue26927] test_mmap does not handle ValueError when no large file
 support
In-Reply-To: <1462284033.57.0.466364918672.issue26927@psf.upfronthosting.co.za>
Message-ID: <1464007357.81.0.256170257775.issue26927@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> When OverflowError is raised? Shouldn't it be replaced with ValueError?

At least Python implementation of io.FileIO can raise OverflowError (from os.lseek()). Thus OverflowError should be kept.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26927>
_______________________________________

From report at bugs.python.org  Mon May 23 08:43:59 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 May 2016 12:43:59 +0000
Subject: =?utf-8?q?=5Bissue27091=5D_Python_IDLE_doesn=27t_like_=F0=9F=92=99?=
In-Reply-To: <1464007203.98.0.542395550852.issue27091@psf.upfronthosting.co.za>
Message-ID: <1464007439.41.0.743833197713.issue27091@psf.upfronthosting.co.za>


STINNER Victor added the comment:

What is your OS? Windows?

What is the full Python version (see the IDLE window title)?

Note: I cannot reproduce the issue on Linux with Python 3.4.3: pasting a string which contains ? do nothing, whereas pasting pure ASCII string works well.

I recall the TCL doesn't have a full support of Unicode, usually it only supports BMP (U+0000-U+ffff).

? is a non-BMP character: U+1f499.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27091>
_______________________________________

From report at bugs.python.org  Mon May 23 08:49:41 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 23 May 2016 12:49:41 +0000
Subject: [issue27090] Python 3 import error after installation
In-Reply-To: <1463998249.7.0.0539436508645.issue27090@psf.upfronthosting.co.za>
Message-ID: <1464007781.9.0.128468362129.issue27090@psf.upfronthosting.co.za>


Steven D'Aprano added the comment:

It looks like your Python 3 is somehow using your Python 2 site directory. What does your PYTHONPATH contain?

Try running this:

python3 -E -S -c "import sys; print(sys.path)"

and see what it says.

----------
nosy: +steven.daprano
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27090>
_______________________________________

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: [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:03:00 2016
From: report at bugs.python.org (Christoph Wruck)
Date: Mon, 23 May 2016 13:03:00 +0000
Subject: [issue27092] ord() raises TypeError in string input
In-Reply-To: <1464008039.38.0.432855281585.issue27092@psf.upfronthosting.co.za>
Message-ID: <1464008580.57.0.0443701578704.issue27092@psf.upfronthosting.co.za>


Changes by Christoph Wruck <christoph.wruck at gmail.com>:


----------
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27092>
_______________________________________

From report at bugs.python.org  Mon May 23 09:03:38 2016
From: report at bugs.python.org (Christoph Wruck)
Date: Mon, 23 May 2016 13:03:38 +0000
Subject: [issue27092] ord() raises TypeError in string input
In-Reply-To: <1464008039.38.0.432855281585.issue27092@psf.upfronthosting.co.za>
Message-ID: <1464008618.7.0.963807522684.issue27092@psf.upfronthosting.co.za>


Changes by Christoph Wruck <christoph.wruck at gmail.com>:


----------
type: enhancement -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27092>
_______________________________________

From report at bugs.python.org  Mon May 23 09:11:38 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 23 May 2016 13:11:38 +0000
Subject: [issue17866] TestCase.assertItemsEqual exists in 2.7, not in 3.3
In-Reply-To: <1367222489.01.0.284119799467.issue17866@psf.upfronthosting.co.za>
Message-ID: <1464009098.22.0.845270634342.issue17866@psf.upfronthosting.co.za>


R. David Murray added the comment:

At the time I wanted it to be named assertCountsEqual, which is better (IMO) than either assertItemsEqual or assertCountEqual.  I lost that naming contest, though :(.  On the third hand, I don't think there exists a good two word name for what the function does.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17866>
_______________________________________

From report at bugs.python.org  Mon May 23 09:14:42 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 23 May 2016 13:14:42 +0000
Subject: [issue27092] ord() raises TypeError in string input
In-Reply-To: <1464008039.38.0.432855281585.issue27092@psf.upfronthosting.co.za>
Message-ID: <1464009282.11.0.643400014744.issue27092@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Once I also mentioned about this in another thread, issue27008, I created and Serhiy gave me a response. You can have a look at that.

----------
nosy: +xiang.zhang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27092>
_______________________________________

From report at bugs.python.org  Mon May 23 09:19:39 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 23 May 2016 13:19:39 +0000
Subject: =?utf-8?q?=5Bissue27091=5D_Python_IDLE_doesn=27t_like_=F0=9F=92=99?=
In-Reply-To: <1464007203.98.0.542395550852.issue27091@psf.upfronthosting.co.za>
Message-ID: <1464009579.71.0.862660754459.issue27091@psf.upfronthosting.co.za>


Martin Panter added the comment:

Is this the same as Issue 13153?

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27091>
_______________________________________

From report at bugs.python.org  Mon May 23 09:27:05 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 23 May 2016 13:27:05 +0000
Subject: [issue27092] ord() raises TypeError in string input
In-Reply-To: <1464008039.38.0.432855281585.issue27092@psf.upfronthosting.co.za>
Message-ID: <1464010025.26.0.887207517821.issue27092@psf.upfronthosting.co.za>


Changes by Xiang Zhang <angwerzx at 126.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27092>
_______________________________________

From report at bugs.python.org  Mon May 23 09:39:28 2016
From: report at bugs.python.org (Vincent Michel)
Date: Mon, 23 May 2016 13:39:28 +0000
Subject: [issue26969] ascynio should provide a policy to address
 pass-loop-everywhere problem
In-Reply-To: <1462517538.3.0.176027238089.issue26969@psf.upfronthosting.co.za>
Message-ID: <1464010768.15.0.26960598097.issue26969@psf.upfronthosting.co.za>


Vincent Michel added the comment:

I agree with Yury's ideas about the implementation of this feature. However, it is a bit confusing to have `asyncio.get_event_loop` defined as:

def get_event_loop():
    policy = get_event_loop_policy()
    return policy.get_running_loop() or policy.get_event_loop()

One would expect `asyncio.get_event_loop` to simply work as a shortcut for:

    get_event_loop_policy().get_event_loop()

The root of the problem is that we're trying to define 3 concepts with only 2 wordings. I think it is possible to solve this issue quite easily by renaming `AbstractLoopPolicy.get_event_loop` with `AbstractLoopPolicy.get_default_loop`. We'd end up with the following definitions:

- default_loop: current default loop as defined in the policy
- running_loop: current running loop (thread-wise) if any 
- event_loop: running loop if any, default_loop otherwise

Changing the API is always annoying, but in this case it would only affect the event loop policies. This is a pretty specific use case, and they'll have to be updated anyway in order to implement `set_running_loop`. asyncio.set_event_loop might be affected too, although it could be kept or deprecated.

Do you think it's worth the trouble?

----------
nosy: +vxgmichel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26969>
_______________________________________

From report at bugs.python.org  Mon May 23 09:41:26 2016
From: report at bugs.python.org (Christoph Wruck)
Date: Mon, 23 May 2016 13:41:26 +0000
Subject: [issue27092] ord() raises TypeError on string/bytes input
In-Reply-To: <1464008039.38.0.432855281585.issue27092@psf.upfronthosting.co.za>
Message-ID: <1464010886.75.0.993054108757.issue27092@psf.upfronthosting.co.za>


Christoph Wruck added the comment:

closed as redundant to:

http://bugs.python.org/issue27008

----------
resolution:  -> not a bug
status: open -> closed
title: ord() raises TypeError in string input -> ord() raises TypeError on string/bytes input

_______________________________________
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: [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 09:46:51 2016
From: report at bugs.python.org (=?utf-8?q?Ionel_Cristian_M=C4=83rie=C8=99?=)
Date: Mon, 23 May 2016 13:46:51 +0000
Subject: [issue23990] Callable builtin doesn't respect descriptors
In-Reply-To: <1429538905.44.0.864865200854.issue23990@psf.upfronthosting.co.za>
Message-ID: <CANkHFr-Y2utSAPfwOEPPWYyPr-J7ohGSxuHZyqhG8_hE497B7A@mail.gmail.com>


Ionel Cristian M?rie? added the comment:

On Mon, Apr 20, 2015 at 5:08 PM, Eric Snow <report at bugs.python.org> wrote:

> FYI, I'll re-iterate something I said before, there is a different
> approach you can take here if this is just an issue of proxying.  Use two
> different proxy types depending on if the proxied object is callable or not:
>
>
> class Proxy:
>     # all the proxy stuff...
>
>
> class CallableProxy(Proxy):
>     def __call__(self, *args, **kwargs):
>         ...
>
>
> def proxy(obj):
>     if callable(obj):
>         return CallableProxy(obj)
>     else:
>         return Proxy(obj)
>
>
> If that isn't a viable alternative then please explain your use case in
> more detail.  I'm sure we can find a solution that works for you.
>

?This does not work if I need to resolve the `obj` at a later time (way
later than the time I create the Proxy object). Unfortunately, I need
exactly that. Not sure how that wasn't clear from all the examples I posted
...?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23990>
_______________________________________

From report at bugs.python.org  Mon May 23 09:58:38 2016
From: report at bugs.python.org (Jim Jewett)
Date: Mon, 23 May 2016 13:58:38 +0000
Subject: [issue27032] Remove deprecated html.parser.HTMLParser.unescape()
In-Reply-To: <1463339146.08.0.655083281356.issue27032@psf.upfronthosting.co.za>
Message-ID: <1464011918.93.0.299432687851.issue27032@psf.upfronthosting.co.za>


Jim Jewett added the comment:

Looks Good To Me

----------
nosy: +Jim.Jewett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27032>
_______________________________________

From report at bugs.python.org  Mon May 23 10:13:43 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 23 May 2016 14:13:43 +0000
Subject: [issue26915] Test identity first in membership operation of ItemsView, 
 ValuesView and Sequence in collections.abc
In-Reply-To: <1462256356.96.0.954300432794.issue26915@psf.upfronthosting.co.za>
Message-ID: <1464012823.08.0.296625905163.issue26915@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Reopen this since the solution is not complete pointed out by Serhiy and the new patch has already been attached(s2).

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26915>
_______________________________________

From report at bugs.python.org  Mon May 23 10:37:29 2016
From: report at bugs.python.org (Jim Jewett)
Date: Mon, 23 May 2016 14:37:29 +0000
Subject: [issue27038] Make os.DirEntry exist
In-Reply-To: <1463413415.02.0.145090656269.issue27038@psf.upfronthosting.co.za>
Message-ID: <1464014249.19.0.404898818026.issue27038@psf.upfronthosting.co.za>


Changes by Jim Jewett <jimjjewett at gmail.com>:


----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27038>
_______________________________________

From report at bugs.python.org  Mon May 23 10:38:29 2016
From: report at bugs.python.org (Jim Jewett)
Date: Mon, 23 May 2016 14:38:29 +0000
Subject: [issue27021] It is not documented that os.writev() suffer from
 SC_IOV_MAX
In-Reply-To: <1463247246.11.0.121733863987.issue27021@psf.upfronthosting.co.za>
Message-ID: <1464014309.82.0.790891458936.issue27021@psf.upfronthosting.co.za>


Changes by Jim Jewett <jimjjewett at gmail.com>:


----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27021>
_______________________________________

From report at bugs.python.org  Mon May 23 10:43:17 2016
From: report at bugs.python.org (Franklin? Lee)
Date: Mon, 23 May 2016 14:43:17 +0000
Subject: [issue26632] __all__ decorator
In-Reply-To: <1458786797.31.0.0749407715279.issue26632@psf.upfronthosting.co.za>
Message-ID: <1464014597.92.0.235484432229.issue26632@psf.upfronthosting.co.za>


Franklin? Lee added the comment:

>I don't know, but what practical effect will this have?  I.e. under what
>conditions would you @public wrap a @functools.wraps function and want it to
>show up in __all__?  Do you have a specific use case?

I sometimes wrap functions that return iterators to make functions that return lists, because I work on the interpreter a lot. From there, it's not much of a stretch to imagine functions which are implemented as decorated versions of other functions.

If @public were only to be used as a decorator, it would not be possible to have `public` called on a function outside of its definition. But someone might call `public(some_decorator(some_function))`.

(@public is really a macro, if you think about it.)

>It would be possible.

(I meant, is it possible for someone to have a non-list __all__?)

If the `.append` fails, I think there should be a meaningful error. Perhaps "'__all__' is not a list."

>Sure, we could probably add some heuristics, but I still don't see the need
>for the extra complexity.  The error will be far from the declaration, but the
>exception should make it relatively obvious what's going on.  I also really
>don't think folks would naturally be inclined to put @public on anything but a
>top-level definition.  You wouldn't ever put such a thing in your __all__ so
>why would you decorate it with @public?

I'm thinking of the people who don't read docs and are coming from other languages. They'd put `@public` over their method, and one day they'd `import *` from that file (whereas they used to only import explicitly), getting an error about a name not being defined in their module. "But why would that name need to be defined? It's a method."

Or worse, the name of the method just happens to be the same as something in some other file, so they'll focus on why that NAME is being expected in THIS file.

>Also, I know that I have several cases where constants are actually
>instances.  They could be marker objects like::
>
>    MARKER = object()

(Here's food for thought: A MARKER could be a one-element enum, both conceptually and by implementation. Just like how the "bool enum" is {True,False} and the "None enum" is {None}.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26632>
_______________________________________

From report at bugs.python.org  Mon May 23 10:49:03 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 23 May 2016 14:49:03 +0000
Subject: [issue27071] unittest.TestCase.assertCountEqual is a very misleading
 name
In-Reply-To: <1463788380.52.0.782790370377.issue27071@psf.upfronthosting.co.za>
Message-ID: <1464014943.92.0.839578487375.issue27071@psf.upfronthosting.co.za>


R. David Murray added the comment:

Personally I don't see any difference between assertCountsEqual and assertFrequencyCountsEqual.  The logic for assertCountsEqual is that it is asserting that some counts are equal in this sequence.  What could we be counting?  The only obvious thing is the length of the collections of equal elements.  'Count' was chosen because it references itertools.count, which it can be defined in terms of, as indicated in the docs.  The presence of absence of the s doesn't affect that rationale for the name.

The flaw in assertItems(Elements)Equal is that it implies that each pair of element is equal, implying that the *orders* are the same, which is exactly the opposite of the intent.

This is the kind of bikeshed that can go on for weeks on a mailing list.  I say leave well enough alone unless someone comes up with a simply brilliant better name.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27071>
_______________________________________

From report at bugs.python.org  Mon May 23 11:02:58 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 23 May 2016 15:02:58 +0000
Subject: [issue27085] Make it possible to select return type for os.listdir
In-Reply-To: <1463940504.88.0.721320439319.issue27085@psf.upfronthosting.co.za>
Message-ID: <1464015778.15.0.168655543049.issue27085@psf.upfronthosting.co.za>


R. David Murray added the comment:

The API for selecting the output type is to pass in the corresponding input type.  This is true for many functions in the python3 standard library.

----------
nosy: +r.david.murray
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27085>
_______________________________________

From report at bugs.python.org  Mon May 23 11:06:20 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 23 May 2016 15:06:20 +0000
Subject: [issue27086] Add closefd argument to os.listdir
In-Reply-To: <1463940932.93.0.542961773489.issue27086@psf.upfronthosting.co.za>
Message-ID: <1464015980.77.0.976916071308.issue27086@psf.upfronthosting.co.za>


R. David Murray added the comment:

This proposal doesn't feel to me like it matches the general APIs we have in the standard library.  I would think the python style for this would be to use a context manager when opening the fd.  So, I'm -1 on this proposal.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27086>
_______________________________________

From report at bugs.python.org  Mon May 23 11:12:25 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 23 May 2016 15:12:25 +0000
Subject: [issue27066] SystemError if custom opener returns -1
In-Reply-To: <1463701849.23.0.646090431797.issue27066@psf.upfronthosting.co.za>
Message-ID: <1464016345.33.0.723947555323.issue27066@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


Added file: http://bugs.python.org/file42956/27066-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27066>
_______________________________________

From report at bugs.python.org  Mon May 23 11:24:13 2016
From: report at bugs.python.org (Evgeny Kapun)
Date: Mon, 23 May 2016 15:24:13 +0000
Subject: [issue27085] Make it possible to select return type for os.listdir
In-Reply-To: <1463940504.88.0.721320439319.issue27085@psf.upfronthosting.co.za>
Message-ID: <1464017053.54.0.0455861248046.issue27085@psf.upfronthosting.co.za>


Evgeny Kapun added the comment:

Unfortunately, this doesn't work if I pass a file descriptor.

----------
resolution: rejected -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27085>
_______________________________________

From report at bugs.python.org  Mon May 23 11:28:00 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 23 May 2016 15:28:00 +0000
Subject: [issue27085] Make it possible to select return type for os.listdir
In-Reply-To: <1463940504.88.0.721320439319.issue27085@psf.upfronthosting.co.za>
Message-ID: <1464017280.03.0.851415511615.issue27085@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> Unfortunately, this doesn't work if I pass a file descriptor.

I strongly suggest you to handle filenames as Unicode ;-) It helps a lot on Windows, it's more convenient, etc.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27085>
_______________________________________

From report at bugs.python.org  Mon May 23 11:38:13 2016
From: report at bugs.python.org (Evgeny Kapun)
Date: Mon, 23 May 2016 15:38:13 +0000
Subject: [issue27085] Make it possible to select return type for os.listdir
In-Reply-To: <1463940504.88.0.721320439319.issue27085@psf.upfronthosting.co.za>
Message-ID: <1464017893.53.0.469282698161.issue27085@psf.upfronthosting.co.za>


Evgeny Kapun added the comment:

Unfortunately, on Linux, handling names as Unicode can cause some problems. For example, merely print()-ing such a name can cause UnicodeEncodeError.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27085>
_______________________________________

From report at bugs.python.org  Mon May 23 11:39:37 2016
From: report at bugs.python.org (=?utf-8?q?Ionel_Cristian_M=C4=83rie=C8=99?=)
Date: Mon, 23 May 2016 15:39:37 +0000
Subject: [issue23990] Callable builtin doesn't respect descriptors
In-Reply-To: <1429296768.81.0.194105997153.issue23990@psf.upfronthosting.co.za>
Message-ID: <1464017977.9.0.277556421403.issue23990@psf.upfronthosting.co.za>


Changes by Ionel Cristian M?rie? <contact at ionelmc.ro>:


Added file: http://bugs.python.org/file42957/callable2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23990>
_______________________________________

From report at bugs.python.org  Mon May 23 11:52:19 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 23 May 2016 15:52:19 +0000
Subject: [issue26632] __all__ decorator
In-Reply-To: <1464014597.92.0.235484432229.issue26632@psf.upfronthosting.co.za>
Message-ID: <20160523115216.27c728dd@subdivisions.wooz.org>


Barry A. Warsaw added the comment:

On May 23, 2016, at 02:43 PM, Franklin? Lee wrote:

>I sometimes wrap functions that return iterators to make functions that
>return lists, because I work on the interpreter a lot. From there, it's not
>much of a stretch to imagine functions which are implemented as decorated
>versions of other functions.
>
>If @public were only to be used as a decorator, it would not be possible to
>have `public` called on a function outside of its definition. But someone
>might call `public(some_decorator(some_function))`.

Do you mean, they'd call this is some module other than the one some_function
was defined in?  I don't know that this is a use case we even want to support.

>(@public is really a macro, if you think about it.)

That's true in a sense.  It doesn't change the decorated thing at all.  I
think it's important to keep in mind that @public isn't the only way to add to
__all__.

>
>>It would be possible.  
>
>(I meant, is it possible for someone to have a non-list __all__?)

Yes.  I've seen existing code where __all__ is assigned to a tuple.

>If the `.append` fails, I think there should be a meaningful error. Perhaps
>"'__all__' is not a list."

You should get something like:

AttributeError: 'tuple' object has no attribute 'append'

which seems pretty obvious.

>I'm thinking of the people who don't read docs and are coming from other
>languages. They'd put `@public` over their method, and one day they'd `import
>*` from that file (whereas they used to only import explicitly), getting an
>error about a name not being defined in their module. "But why would that
>name need to be defined? It's a method."
>
>Or worse, the name of the method just happens to be the same as something in
>some other file, so they'll focus on why that NAME is being expected in THIS
>file.

Well, consenting adults and all.  I'm not sure we need to protect ourselves so
strictly against people who don't read the docs and don't understand Python
(i.e. random cargo-culters).

>>Also, I know that I have several cases where constants are actually
>>instances.  They could be marker objects like::
>>
>>    MARKER = object()  
>
>(Here's food for thought: A MARKER could be a one-element enum, both
>conceptually and by implementation. Just like how the "bool enum" is
>{True,False} and the "None enum" is {None}.)

Sure.  I don't think that changes anything here though.  Down the line, it
might be an interesting idiom to experiment with (you can probably start with
the standalone enum34 module).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26632>
_______________________________________

From report at bugs.python.org  Mon May 23 12:03:40 2016
From: report at bugs.python.org (Michael Foord)
Date: Mon, 23 May 2016 16:03:40 +0000
Subject: [issue27071] unittest.TestCase.assertCountEqual is a very misleading
 name
In-Reply-To: <1463788380.52.0.782790370377.issue27071@psf.upfronthosting.co.za>
Message-ID: <1464019420.36.0.971886602591.issue27071@psf.upfronthosting.co.za>


Michael Foord added the comment:

I agree with David, I don't like the name but it is at least accurate (if you already understand what it does). assertItemsEqual was better but misleading. In the absence of a *dramatically* better name leave it alone.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27071>
_______________________________________

From report at bugs.python.org  Mon May 23 12:19:47 2016
From: report at bugs.python.org (Zachary Ware)
Date: Mon, 23 May 2016 16:19:47 +0000
Subject: [issue27090] Python 3 import error after installation
In-Reply-To: <1463998249.7.0.0539436508645.issue27090@psf.upfronthosting.co.za>
Message-ID: <1464020387.49.0.210340090967.issue27090@psf.upfronthosting.co.za>


Zachary Ware added the comment:

> That seems crazy...

What's crazy about it?  There are very very few legitimate situations where you need to permanently set any PYTHON* variable, particularly PYTHONPATH and PYTHONHOME.  Adding site-packages to sys.path via PYTHONPATH is completely unnecessary anyway since site.py will do that for you in a much safer manner.

This looks like a local configuration issue; closing.

----------
nosy: +zach.ware
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27090>
_______________________________________

From report at bugs.python.org  Mon May 23 12:24:17 2016
From: report at bugs.python.org (Ned Deily)
Date: Mon, 23 May 2016 16:24:17 +0000
Subject: [issue27090] Python 3 import error after installation
In-Reply-To: <1463998249.7.0.0539436508645.issue27090@psf.upfronthosting.co.za>
Message-ID: <1464020657.82.0.704535585325.issue27090@psf.upfronthosting.co.za>


Ned Deily added the comment:

To add to Zach's comment, there have been extended discussions in the past about whether there should be a separate set of environment variables for Python 3 vs Python 2 interpreters; see, for instance, Issue2375 and http://comments.gmane.org/gmane.comp.python.devel/109797.  In the latter, Guido pronounced on the matter: no separate values for PYTHONPATH since PYTHONPATH is not intended to be used on permanent basis.  Either install distribution packages normally (to site-packages) or use a virtual environment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27090>
_______________________________________

From report at bugs.python.org  Mon May 23 12:36:17 2016
From: report at bugs.python.org (Steve Dower)
Date: Mon, 23 May 2016 16:36:17 +0000
Subject: [issue23026] Winreg module doesn't support REG_QWORD,
 small DWORD doc update
In-Reply-To: <1418242433.97.0.849861872047.issue23026@psf.upfronthosting.co.za>
Message-ID: <1464021377.33.0.132950252037.issue23026@psf.upfronthosting.co.za>


Steve Dower added the comment:

Looks good to me. (In case someone else applies the patch, there are a few mixed tab/spaces that should be fixed.)

I'm personally okay with adding this to 3.5, but technically I think it's a new feature and should be in 3.6 only. Anyone else have an opinion here?

----------
nosy: +paul.moore
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23026>
_______________________________________

From report at bugs.python.org  Mon May 23 12:39:45 2016
From: report at bugs.python.org (Vitaly)
Date: Mon, 23 May 2016 16:39:45 +0000
Subject: [issue27071] unittest.TestCase.assertCountEqual is a very misleading
 name
In-Reply-To: <1463788380.52.0.782790370377.issue27071@psf.upfronthosting.co.za>
Message-ID: <1464021585.8.0.419391995233.issue27071@psf.upfronthosting.co.za>


Vitaly added the comment:

Gentlemen, the point is that the name of a function should be all that is necessary to unambiguously understand what this method does without having to know that it's implemented in terms of collections.Counter or any other internal detail like that. That's not a good strategy for picking names in computer programming. The name of a function should certainly not be tied to an internal implementation detail (use Counter to implement, so let's name it "Count"?). Something that asserts the equality of two collections of elements is not rocket science and does not deserve an ambiguous name. "Count" is simply too ambiguous in this case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27071>
_______________________________________

From report at bugs.python.org  Mon May 23 12:58:21 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 23 May 2016 16:58:21 +0000
Subject: [issue27085] Make it possible to select return type for os.listdir
In-Reply-To: <1463940504.88.0.721320439319.issue27085@psf.upfronthosting.co.za>
Message-ID: <1464022701.9.0.712233728326.issue27085@psf.upfronthosting.co.za>


R. David Murray added the comment:

The issue of passing an fd is a fair point.

However, converting the filenames to bytes isn't going to help you print them, you'll just get decoding errors when converting them to strings instead of encoding errors.  You could use the surrogateescape error handler on stdout via PYTHONIONENCODING if you want to get the bytes out, but in that case you don't need to encode them to bytes yourself, your program can just handle them as strings and let the python IO machinery deal with the bytes.

If you really want bytes filenames from listdir with an fd, you can just apply os.fsencode to the results:  map(os.fsencode, listdir(fd))

So, I'm still -1 on this proposal.

(Note: there is an existing open issue about surrogateescape and subprocess binary streams, so that is a known problem we haven't solved yet, and represents a more general problem than this issue.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27085>
_______________________________________

From report at bugs.python.org  Mon May 23 13:02:22 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 23 May 2016 17:02:22 +0000
Subject: [issue27071] unittest.TestCase.assertCountEqual is a very misleading
 name
In-Reply-To: <1463788380.52.0.782790370377.issue27071@psf.upfronthosting.co.za>
Message-ID: <1464022942.76.0.0118682975883.issue27071@psf.upfronthosting.co.za>


R. David Murray added the comment:

Vitaly: if you can come up with a name we agree is more descriptive than the current one by a non-trivial margin, we will be happy to listen.  assertFrequencyCountsEqual is not sufficiently better.  (Personally, I would not know what that function did by reading the name.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27071>
_______________________________________

From report at bugs.python.org  Mon May 23 13:19:36 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 May 2016 17:19:36 +0000
Subject: [issue27071] unittest.TestCase.assertCountEqual is a very misleading
 name
In-Reply-To: <1463788380.52.0.782790370377.issue27071@psf.upfronthosting.co.za>
Message-ID: <1464023976.64.0.43263533578.issue27071@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

My first expectation for this function was assertUnorderedEqual, but I want to avoid problems with renaming (and coexisting of three names of for the same function), and I vote for status quo.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27071>
_______________________________________

From report at bugs.python.org  Mon May 23 13:31:21 2016
From: report at bugs.python.org (Paul Moore)
Date: Mon, 23 May 2016 17:31:21 +0000
Subject: [issue23026] Winreg module doesn't support REG_QWORD,
 small DWORD doc update
In-Reply-To: <1418242433.97.0.849861872047.issue23026@psf.upfronthosting.co.za>
Message-ID: <1464024681.14.0.610751266366.issue23026@psf.upfronthosting.co.za>


Paul Moore added the comment:

My instinct is that this should only go into 3.6. It's a remote possibility, but someone could otherwise write code that uses REG_DWORD64 and say that it "works on 3.5" because they tested on 3.5.x, only to have it fail on 3.5.1.

But if someone with a better feel for the implications wants to say it's OK, I wouldn't object.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23026>
_______________________________________

From report at bugs.python.org  Mon May 23 13:39:07 2016
From: report at bugs.python.org (Mark Grandi)
Date: Mon, 23 May 2016 17:39:07 +0000
Subject: [issue23026] Winreg module doesn't support REG_QWORD,
 small DWORD doc update
In-Reply-To: <1418242433.97.0.849861872047.issue23026@psf.upfronthosting.co.za>
Message-ID: <1464025147.89.0.869834461781.issue23026@psf.upfronthosting.co.za>


Mark Grandi added the comment:

why do you say that QWORD is not present in windows.h? 

I found it here: https://msdn.microsoft.com/en-us/library/windows/desktop/aa383751%28v=vs.85%29.aspx

typedef unsigned __int64 QWORD;

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23026>
_______________________________________

From report at bugs.python.org  Mon May 23 13:55:39 2016
From: report at bugs.python.org (Sriram Rajagopalan)
Date: Mon, 23 May 2016 17:55:39 +0000
Subject: [issue26779] pdb continue followed by an exception in the same frame
 shows incorrect frame linenumber
In-Reply-To: <1460812092.64.0.640871964672.issue26779@psf.upfronthosting.co.za>
Message-ID: <1464026139.48.0.232881039177.issue26779@psf.upfronthosting.co.za>


Sriram Rajagopalan added the comment:

ping.

Gentle reminder to review the patch

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26779>
_______________________________________

From report at bugs.python.org  Mon May 23 14:30:57 2016
From: report at bugs.python.org (Clement Rouault)
Date: Mon, 23 May 2016 18:30:57 +0000
Subject: [issue23026] Winreg module doesn't support REG_QWORD,
 small DWORD doc update
In-Reply-To: <1418242433.97.0.849861872047.issue23026@psf.upfronthosting.co.za>
Message-ID: <1464028256.99.0.971046872685.issue23026@psf.upfronthosting.co.za>


Clement Rouault added the comment:

Because `QWORD` is not defined in any file included by CPython. The main file for basic sized type definition in Windows is:

    basetsd.h: Type definitions for the basic sized types.

which contains the definition of `DWORD64`: `typedef unsigned __int64 DWORD64, *PDWORD64;`
but no reference to `QWORD`. Furthemore the code did not compile with the use of `QWORD`.
So, I am pretty sure it is not defined by the standard includes

Other people complain in your link:

    > "Apparently, QWORD isn't defined in any of the windows header files for MSVC 2010."

Finally, the only files where I could find a typedef for `QWORD` are:

    * Include\shared\Sspi.h (Security Support Provider Interface. Prototypes and structure definitions)
    * Include\um\WinDNS.h (Domain Name System (DNS). DNS definitions and DNS API.)
    * Include\um\wmcodecdsp.h (COM interface -> generated code)
    * Include\um\wmnetsourcecreator.h (COM interface -> generated code)
    * Include\um\wmnetsourcecreator.idl (MIDL Interface Definition File)
    * Include\um\wmsdkidl.h (COM interface -> generated code)
    * Include\um\wmsdkidl.idl (MIDL Interface Definition File)
    * Include\um\mfobjects.h (COM interface -> generated code)
    * Include\um\Mfobjects.idl (MIDL Interface Definition File)


It seems to be in pretty obscure files that should not be included by CPython (In my opinion)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23026>
_______________________________________

From report at bugs.python.org  Mon May 23 14:34:18 2016
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 23 May 2016 18:34:18 +0000
Subject: [issue23990] Callable builtin doesn't respect descriptors
In-Reply-To: <1429296768.81.0.194105997153.issue23990@psf.upfronthosting.co.za>
Message-ID: <1464028458.4.0.426910538028.issue23990@psf.upfronthosting.co.za>


Ethan Furman added the comment:

To change this behavior at this point will require a PEP.  The PEP should be something along the lines of "Add proxy support to builtins" and should address such things as callable, issubclass, and whatever else is is appropriate.

As for working around your problem now I see a few options:

- write your own `is_proxy_callable` function
- add a `.callable` method to your proxy class
- a `resolve_proxy` function/method which can change the proxy class
  type to whatever is needed to mirror the actual object

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23990>
_______________________________________

From report at bugs.python.org  Mon May 23 14:53:10 2016
From: report at bugs.python.org (Vitaly)
Date: Mon, 23 May 2016 18:53:10 +0000
Subject: [issue27071] unittest.TestCase.assertCountEqual is a very misleading
 name
In-Reply-To: <1463788380.52.0.782790370377.issue27071@psf.upfronthosting.co.za>
Message-ID: <1464029590.59.0.874696770668.issue27071@psf.upfronthosting.co.za>


Vitaly added the comment:

By leaps and bounds, I like assertUnorderedEqual versus assertCountEqual, which is terribly misleading. The first, and simplest, thing that comes to my mind from the word Count by itself is the count of all elements in a sequence (i.e., its length), certainly not frequency count.

I am also happy with the status quo of assertItemsEqual, but I have to agree that assertUnorderedEqual removes any ambiguity that assertItemsEqual purportedly suffers from. Thank you for suggesting assertUnorderedEqual.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27071>
_______________________________________

From report at bugs.python.org  Mon May 23 15:02:23 2016
From: report at bugs.python.org (Steve Dower)
Date: Mon, 23 May 2016 19:02:23 +0000
Subject: [issue23026] Winreg module doesn't support REG_QWORD,
 small DWORD doc update
In-Reply-To: <1418242433.97.0.849861872047.issue23026@psf.upfronthosting.co.za>
Message-ID: <1464030143.38.0.168995154745.issue23026@psf.upfronthosting.co.za>


Steve Dower added the comment:

IIRC, the preferred typedef is ULONGLONG, but it's not really a big deal. Avoiding new header files is a good enough reason.

I think Paul's right about 3.6 only. We shouldn't encourage code that won't work downlevel within the same version, and there is a ctypes workaround available.

----------
versions:  -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23026>
_______________________________________

From report at bugs.python.org  Mon May 23 15:12:21 2016
From: report at bugs.python.org (Mark Grandi)
Date: Mon, 23 May 2016 19:12:21 +0000
Subject: [issue23026] Winreg module doesn't support REG_QWORD,
 small DWORD doc update
In-Reply-To: <1418242433.97.0.849861872047.issue23026@psf.upfronthosting.co.za>
Message-ID: <1464030741.67.0.161434006076.issue23026@psf.upfronthosting.co.za>


Mark Grandi added the comment:

@hakril: ok, that makes sense, I'm not a windows/win32 programmer by any means so I was mostly going on the microsoft web docs

also the patch by hakril includes the documentation from my patch, so that patch should be the one considered (as a FYI)

----------
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23026>
_______________________________________

From report at bugs.python.org  Mon May 23 15:23:28 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 May 2016 19:23:28 +0000
Subject: [issue27071] unittest.TestCase.assertCountEqual is a very misleading
 name
In-Reply-To: <1463788380.52.0.782790370377.issue27071@psf.upfronthosting.co.za>
Message-ID: <1464031408.7.0.312333815221.issue27071@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +georg.brandl, gregory.p.smith, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27071>
_______________________________________

From report at bugs.python.org  Mon May 23 15:33:59 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 May 2016 19:33:59 +0000
Subject: [issue27066] SystemError if custom opener returns -1
In-Reply-To: <1463701849.23.0.646090431797.issue27066@psf.upfronthosting.co.za>
Message-ID: <1464032039.26.0.63535565771.issue27066@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

In general LGTM, but I left style comment on Rietveld. And you can use assertRaisesRegex in tests if you prefers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27066>
_______________________________________

From report at bugs.python.org  Mon May 23 15:49:27 2016
From: report at bugs.python.org (=?utf-8?q?Ionel_Cristian_M=C4=83rie=C8=99?=)
Date: Mon, 23 May 2016 19:49:27 +0000
Subject: [issue23990] Callable builtin doesn't respect descriptors
In-Reply-To: <1464028458.4.0.426910538028.issue23990@psf.upfronthosting.co.za>
Message-ID: <CANkHFr8-vN+LdYB-qJM_WxVLPu8n3iwymsfOg1qZzLireKhfrQ@mail.gmail.com>


Ionel Cristian M?rie? added the comment:

On Mon, May 23, 2016 at 9:34 PM, Ethan Furman <report at bugs.python.org>
wrote:

> "Add proxy support to builtins" and should address such things as
> callable, issubclass, and whatever else is is appropriate.

?As previously stated this builtin is the only one not doing the right
thing. If you think otherwise, please provide proof. I provided plenty of
supporting examples.

Your "working around" is basically saying "don't use? callable or don't
solve your problem". Not an option.

Let me restate the problem: I want to implement a "proxy that resolves the
target at a later time". That means I can't juggle classes ahead of time
(no `resolve_proxy` or whatever) and I can't tell users "don't use
callable" (what's the point of having a proxy then?).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23990>
_______________________________________

From report at bugs.python.org  Mon May 23 15:50:30 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 May 2016 19:50:30 +0000
Subject: [issue27029] Remove support of deprecated mode 'U' in zipfile
In-Reply-To: <1463336602.94.0.363644818568.issue27029@psf.upfronthosting.co.za>
Message-ID: <1464033030.09.0.150007751175.issue27029@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Updated patch addresses Jim's comments.

----------
Added file: http://bugs.python.org/file42958/zipfile_remove_deprecated2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27029>
_______________________________________

From report at bugs.python.org  Mon May 23 16:04:35 2016
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 23 May 2016 20:04:35 +0000
Subject: [issue23990] Callable builtin doesn't respect descriptors
In-Reply-To: <1429296768.81.0.194105997153.issue23990@psf.upfronthosting.co.za>
Message-ID: <1464033875.83.0.325239558553.issue23990@psf.upfronthosting.co.za>


Ethan Furman added the comment:

`issubclass` doesn't "do the right thing", as evidenced by another dev.

Continued complaining to this issue is not going to get you what you want, but writing a PEP to address the issue might.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23990>
_______________________________________

From report at bugs.python.org  Mon May 23 16:15:36 2016
From: report at bugs.python.org (=?utf-8?q?Ionel_Cristian_M=C4=83rie=C8=99?=)
Date: Mon, 23 May 2016 20:15:36 +0000
Subject: [issue23990] Callable builtin doesn't respect descriptors
In-Reply-To: <1464033875.83.0.325239558553.issue23990@psf.upfronthosting.co.za>
Message-ID: <CANkHFr__5Z1oaTbf_-VOWfsTr_vBdzNBycY5UxkFu5JqKxy-jg@mail.gmail.com>


Ionel Cristian M?rie? added the comment:

On Mon, May 23, 2016 at 11:04 PM, Ethan Furman <report at bugs.python.org>
wrote:

> `issubclass` doesn't "do the right thing", as evidenced by another dev.
>

Hmmm. Technically, in that case, the problem is in
collections.abc.Iterable, not issubclass. I can extent the patch to fix
that too.

Continued complaining to this issue is not going to get you what you want,
> but writing a PEP to address the issue might.
>

Not sure what you're going at here. Are you hinting that you'd support
these changes if there would be a PEP??

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23990>
_______________________________________

From report at bugs.python.org  Mon May 23 16:21:49 2016
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 23 May 2016 20:21:49 +0000
Subject: [issue23990] Callable builtin doesn't respect descriptors
In-Reply-To: <1429296768.81.0.194105997153.issue23990@psf.upfronthosting.co.za>
Message-ID: <1464034909.19.0.563815820922.issue23990@psf.upfronthosting.co.za>


Ethan Furman added the comment:

I'm not against them, but there are many diverse opinions.

A PEP will:

- broaden discussion, so all (or at least most) pros and cons can be
  considered

- highlight any other pieces of Python that would need to change to
  properly support proxies

- get a pronouncement by the BDFL (or a delegate)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23990>
_______________________________________

From report at bugs.python.org  Mon May 23 16:40:08 2016
From: report at bugs.python.org (=?utf-8?q?Ionel_Cristian_M=C4=83rie=C8=99?=)
Date: Mon, 23 May 2016 20:40:08 +0000
Subject: [issue23990] Callable builtin doesn't respect descriptors
In-Reply-To: <1429296768.81.0.194105997153.issue23990@psf.upfronthosting.co.za>
Message-ID: <1464036008.29.0.100009187206.issue23990@psf.upfronthosting.co.za>


Ionel Cristian M?rie? added the comment:

Okay ... is anyone interested in helping with this (reviewing drafts)? Who would be the BDFL?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23990>
_______________________________________

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: [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 16:45:16 2016
From: report at bugs.python.org (Seth Norton)
Date: Mon, 23 May 2016 20:45:16 +0000
Subject: [issue27094] Floating Point Printing Error with 2+.8553 or 3+.8553
In-Reply-To: <1464036253.1.0.85205428645.issue27094@psf.upfronthosting.co.za>
Message-ID: <1464036316.62.0.534130163379.issue27094@psf.upfronthosting.co.za>


Changes by Seth Norton <snorton140 at gmail.com>:


----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27094>
_______________________________________

From report at bugs.python.org  Mon May 23 16:49:25 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 23 May 2016 20:49:25 +0000
Subject: [issue27071] unittest.TestCase.assertCountEqual is a very misleading
 name
In-Reply-To: <1463788380.52.0.782790370377.issue27071@psf.upfronthosting.co.za>
Message-ID: <1464036565.54.0.783670753737.issue27071@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

I'm not against adding a new name if it makes glorious sense, but we should not remove the old names from unittest as that causes unnecessary pain (based on past experience).

assertCountEqual does make sense in terms of the "equivalent to" context from the docs.  Thought I agree with you, its meaning is generally not obvious and must be looked up to be understood. https://docs.python.org/3/library/unittest.html#unittest.TestCase.assertCountEqual

assertUnorderedEqual is a reasonable name, but I don't find significantly better than assertCountEqual from a "never read the docs, just reading the code" understandability point of view.  It makes me wonder "unordered what?"

that's a vote of -0 for the status quo.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27071>
_______________________________________

From report at bugs.python.org  Mon May 23 17:13:50 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 23 May 2016 21:13:50 +0000
Subject: [issue27094] Floating Point Printing Error with 2+.8553 or 3+.8553
In-Reply-To: <1464036253.1.0.85205428645.issue27094@psf.upfronthosting.co.za>
Message-ID: <1464038030.24.0.760569127071.issue27094@psf.upfronthosting.co.za>


R. David Murray added the comment:

https://docs.python.org/3/tutorial/floatingpoint.html

----------
nosy: +r.david.murray
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27094>
_______________________________________

From report at bugs.python.org  Mon May 23 17:25:53 2016
From: report at bugs.python.org (Vitaly)
Date: Mon, 23 May 2016 21:25:53 +0000
Subject: [issue27071] unittest.TestCase.assertCountEqual is a very misleading
 name
In-Reply-To: <1463788380.52.0.782790370377.issue27071@psf.upfronthosting.co.za>
Message-ID: <1464038753.2.0.24307784237.issue27071@psf.upfronthosting.co.za>


Vitaly added the comment:

When I read "Unordered", it makes me think of collections, including sequences and sets.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27071>
_______________________________________

From report at bugs.python.org  Mon May 23 17:26:23 2016
From: report at bugs.python.org (Demur Rumed)
Date: Mon, 23 May 2016 21:26:23 +0000
Subject: [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 17:26:28 2016
From: report at bugs.python.org (Demur Rumed)
Date: Mon, 23 May 2016 21:26:28 +0000
Subject: [issue27095] Simplify MAKE_FUNCTION
In-Reply-To: <1464038780.83.0.81155899453.issue27095@psf.upfronthosting.co.za>
Message-ID: <1464038788.59.0.566005544153.issue27095@psf.upfronthosting.co.za>


Changes by Demur Rumed <gunkmute at gmail.com>:


----------
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27095>
_______________________________________

From report at bugs.python.org  Mon May 23 17:29:50 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 23 May 2016 21:29:50 +0000
Subject: [issue27071] unittest.TestCase.assertCountEqual is a very misleading
 name
In-Reply-To: <1463788380.52.0.782790370377.issue27071@psf.upfronthosting.co.za>
Message-ID: <1464038990.73.0.669831146587.issue27071@psf.upfronthosting.co.za>


R. David Murray added the comment:

Heh.  We could call it 'assertQuotientSetEqual', but most people would have to look that up (I did, to find it). 'assertEquivalenceClassesEqual' is a bit better, but probably still not clear without looking it up (or being a mathematician).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27071>
_______________________________________

From report at bugs.python.org  Mon May 23 17:30:53 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 23 May 2016 21:30:53 +0000
Subject: [issue27071] unittest.TestCase.assertCountEqual is a very misleading
 name
In-Reply-To: <1463788380.52.0.782790370377.issue27071@psf.upfronthosting.co.za>
Message-ID: <1464039053.82.0.741654359722.issue27071@psf.upfronthosting.co.za>


R. David Murray added the comment:

And it suffers the same problem as 'unordered', or even more so, as it implies sets, but we aren't dealing with python sets.

See why this is so tough? :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27071>
_______________________________________

From report at bugs.python.org  Mon May 23 17:36:15 2016
From: report at bugs.python.org (Vitaly)
Date: Mon, 23 May 2016 21:36:15 +0000
Subject: [issue27071] unittest.TestCase.assertCountEqual is a very misleading
 name
In-Reply-To: <1463788380.52.0.782790370377.issue27071@psf.upfronthosting.co.za>
Message-ID: <1464039375.61.0.406505027082.issue27071@psf.upfronthosting.co.za>


Vitaly added the comment:

Why do you say that "we aren't dealing with python sets"? Try:

import unittest as u
class Test(u.TestCase):
    def test_equal_count_of_same_elements(self):
        self.assertItemsEqual(set([1,2,3]), set([1,2,3]))


    def test_equal_count_of_different_elements(self):
        self.assertItemsEqual(set([1,2,3]), set([1,2,4]))


    def test_different_count(self):
        self.assertItemsEqual(set([1,2,3]), set([1,2,3,4]))
u.main()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27071>
_______________________________________

From report at bugs.python.org  Mon May 23 17:39:37 2016
From: report at bugs.python.org (Vitaly)
Date: Mon, 23 May 2016 21:39:37 +0000
Subject: [issue27071] unittest.TestCase.assertCountEqual is a very misleading
 name
In-Reply-To: <1463788380.52.0.782790370377.issue27071@psf.upfronthosting.co.za>
Message-ID: <1464039577.78.0.279500232431.issue27071@psf.upfronthosting.co.za>


Vitaly added the comment:

$ python assert_items_equal_test.py 
FF.
======================================================================
FAIL: test_different_count (__main__.Test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "assert_items_equal_test.py", line 12, in test_different_count
    self.assertItemsEqual(set([1,2,3]), set([1,2,3,4]))
AssertionError: Element counts were not equal:
First has 0, Second has 1:  4

======================================================================
FAIL: test_equal_count_of_different_elements (__main__.Test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "assert_items_equal_test.py", line 8, in test_equal_count_of_different_elements
    self.assertItemsEqual(set([1,2,3]), set([1,2,4]))
AssertionError: Element counts were not equal:
First has 1, Second has 0:  3
First has 0, Second has 1:  4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27071>
_______________________________________

From report at bugs.python.org  Mon May 23 17:40:49 2016
From: report at bugs.python.org (Vitaly)
Date: Mon, 23 May 2016 21:40:49 +0000
Subject: [issue27071] unittest.TestCase.assertCountEqual is a very misleading
 name
In-Reply-To: <1463788380.52.0.782790370377.issue27071@psf.upfronthosting.co.za>
Message-ID: <1464039649.53.0.223332835537.issue27071@psf.upfronthosting.co.za>


Vitaly added the comment:

The preceding results are via Python 2.7.10

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27071>
_______________________________________

From report at bugs.python.org  Mon May 23 17:42:22 2016
From: report at bugs.python.org (Ethan Furman)
Date: Mon, 23 May 2016 21:42:22 +0000
Subject: [issue23990] Callable builtin doesn't respect descriptors
In-Reply-To: <1429296768.81.0.194105997153.issue23990@psf.upfronthosting.co.za>
Message-ID: <1464039742.85.0.67532041602.issue23990@psf.upfronthosting.co.za>


Ethan Furman added the comment:

The BDFL would be the BDFL  (Guido van Rossum ;) or whomever he asks to do the job.

Don't worry too much about drafts.  Pick one of the existing PEPs (409 is fairly short), and follow the same type of layouts.  Make your arguments for what should be changed and why, then post it to Python-Ideas for initial discussion.  As points come up either for or against it you'll add those to your draft PEP.  If -Ideas doesn't kill it you can then post your most up-to-date draft to Python-Dev for the next round of discussion.

Make sure to have examples of the desired behavior, and decent arguments to refute the objections already raised in this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23990>
_______________________________________

From report at bugs.python.org  Mon May 23 17:42:47 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 23 May 2016 21:42:47 +0000
Subject: [issue27095] Simplify MAKE_FUNCTION
In-Reply-To: <1464038780.83.0.81155899453.issue27095@psf.upfronthosting.co.za>
Message-ID: <1464039767.11.0.32064565304.issue27095@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
components: +Interpreter Core
dependencies: +ceval: use Wordcode, 16-bit bytecode
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27095>
_______________________________________

From report at bugs.python.org  Mon May 23 17:46:22 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 23 May 2016 21:46:22 +0000
Subject: [issue27066] SystemError if custom opener returns -1
In-Reply-To: <1463701849.23.0.646090431797.issue27066@psf.upfronthosting.co.za>
Message-ID: <1464039982.5.0.769051666556.issue27066@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

BTW, I may wait to commit this until after we've moved to GitHub. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27066>
_______________________________________

From report at bugs.python.org  Mon May 23 17:46:44 2016
From: report at bugs.python.org (Vitaly)
Date: Mon, 23 May 2016 21:46:44 +0000
Subject: [issue27071] unittest.TestCase.assertCountEqual is a very misleading
 name
In-Reply-To: <1463788380.52.0.782790370377.issue27071@psf.upfronthosting.co.za>
Message-ID: <1464040004.35.0.0977217769344.issue27071@psf.upfronthosting.co.za>


Vitaly added the comment:

Same results on Python.org's Python 3.5.1 shell:
>>> class Test(u.TestCase):
...     def test_equal_count_of_same_elements(self):
...         self.assertCountEqual(set([1,2,3]), set([1,2,3]))
...     def test_equal_count_of_different_elements(self):
...         self.assertCountEqual(set([1,2,3]), set([1,2,4]))
...     def test_different_count(self):
...         self.assertCountEqual(set([1,2,3]), set([1,2,3,4]))
... 
>>> u.main()
FF.
======================================================================
FAIL: test_different_count (__main__.Test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "<stdin>", line 7, in test_different_count
AssertionError: Element counts were not equal:
First has 0, Second has 1:  4

======================================================================
FAIL: test_equal_count_of_different_elements (__main__.Test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "<stdin>", line 5, in test_equal_count_of_different_elements
AssertionError: Element counts were not equal:
First has 1, Second has 0:  3

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27071>
_______________________________________

From report at bugs.python.org  Mon May 23 17:48:28 2016
From: report at bugs.python.org (Vitaly)
Date: Mon, 23 May 2016 21:48:28 +0000
Subject: [issue27071] unittest.TestCase.assertCountEqual is a very misleading
 name
In-Reply-To: <1463788380.52.0.782790370377.issue27071@psf.upfronthosting.co.za>
Message-ID: <1464040108.61.0.503746683911.issue27071@psf.upfronthosting.co.za>


Vitaly added the comment:

With missing last line, this time:

======================================================================
FAIL: test_equal_count_of_different_elements (__main__.Test)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "<stdin>", line 5, in test_equal_count_of_different_elements
AssertionError: Element counts were not equal:
First has 1, Second has 0:  3
First has 0, Second has 1:  4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27071>
_______________________________________

From report at bugs.python.org  Mon May 23 17:50:23 2016
From: report at bugs.python.org (Vitaly)
Date: Mon, 23 May 2016 21:50:23 +0000
Subject: [issue27071] unittest.TestCase.assertCountEqual is a very misleading
 name
In-Reply-To: <1463788380.52.0.782790370377.issue27071@psf.upfronthosting.co.za>
Message-ID: <1464040223.25.0.210491159623.issue27071@psf.upfronthosting.co.za>


Vitaly added the comment:

I think that assertUnorderedEqual would contrast nicely with assertSequenceEqual

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27071>
_______________________________________

From report at bugs.python.org  Mon May 23 18:15:00 2016
From: report at bugs.python.org (Johannes Spangenberg)
Date: Mon, 23 May 2016 22:15:00 +0000
Subject: [issue26971] python v3.5.1: sys.paths not respecting DESTDIRS and
 DESTSHARED
In-Reply-To: <1462628482.0.0.926875224828.issue26971@psf.upfronthosting.co.za>
Message-ID: <1464041700.29.0.920105318117.issue26971@psf.upfronthosting.co.za>


Johannes Spangenberg added the comment:

I can confirm this issue. I did run it on Linux SuSE 13.1 (64 Bit). Unlike other components, which are installed in `lib/`, `lib-dynload` is installed in `lib64/python3.5/`. But `sys.path` still points to `lib/python3.5/lib-dynload`. It did run in on :

mkdir build
cd build
../configure --prefix="${HOME}/.opt"
nice -n 19 make -j 6
make install

----------
nosy: +Johannes Spangenberg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26971>
_______________________________________

From report at bugs.python.org  Mon May 23 18:23:42 2016
From: report at bugs.python.org (Graham Dumpleton)
Date: Mon, 23 May 2016 22:23:42 +0000
Subject: [issue23990] Callable builtin doesn't respect descriptors
In-Reply-To: <1429296768.81.0.194105997153.issue23990@psf.upfronthosting.co.za>
Message-ID: <1464042222.33.0.672288291054.issue23990@psf.upfronthosting.co.za>


Graham Dumpleton added the comment:

If someone is going to try and do anything in the area of better proxy object support, I hope you will also look at all the work I have done on that before for wrapt (https://github.com/GrahamDumpleton/wrapt).

Two related issue this has already found are http://bugs.python.org/issue19072 and http://bugs.python.org/issue19070.

The wrapt package uses two separate proxy object types. A base ObjectProxy and a CallableObjectProxy because of the specific issue with how callable() works.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23990>
_______________________________________

From report at bugs.python.org  Mon May 23 18:28:59 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 23 May 2016 22:28:59 +0000
Subject: [issue27071] unittest.TestCase.assertCountEqual is a very misleading
 name
In-Reply-To: <1463788380.52.0.782790370377.issue27071@psf.upfronthosting.co.za>
Message-ID: <1464042539.63.0.950380235536.issue27071@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

assertUnorderedSequenceEqual would make more sense to me given the natural relation to assertSequenceEqual.

We aren't dealing with sets (though sets are valid sequences) as this method specifically does not require sequence items to be hashable.  Explicitly putting the word sequence in the name makes that more clear.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27071>
_______________________________________

From report at bugs.python.org  Mon May 23 18:37:13 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 23 May 2016 22:37:13 +0000
Subject: [issue27071] unittest.TestCase.assertCountEqual is a very misleading
 name
In-Reply-To: <1463788380.52.0.782790370377.issue27071@psf.upfronthosting.co.za>
Message-ID: <1464043033.87.0.95312606137.issue27071@psf.upfronthosting.co.za>


R. David Murray added the comment:

how about assertSequenceEqualUnordered

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27071>
_______________________________________

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: [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 18:47:17 2016
From: report at bugs.python.org (Campbell Barton)
Date: Mon, 23 May 2016 22:47:17 +0000
Subject: [issue27096] Ability to get random bits from random.Random (as with
 os.urandom)
In-Reply-To: <1464043046.76.0.140037772611.issue27096@psf.upfronthosting.co.za>
Message-ID: <1464043637.44.0.726691112669.issue27096@psf.upfronthosting.co.za>


Campbell Barton added the comment:

Correction, meant to write: random.randbytes(n).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27096>
_______________________________________

From report at bugs.python.org  Mon May 23 19:07:40 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 23 May 2016 23:07:40 +0000
Subject: [issue27096] Ability to get random bytes from random.Random (as with
 os.urandom)
In-Reply-To: <1464043046.76.0.140037772611.issue27096@psf.upfronthosting.co.za>
Message-ID: <1464044860.48.0.710221532034.issue27096@psf.upfronthosting.co.za>


R. David Murray added the comment:

It seems reasonable to me, but I'm not the one to sign off on something like this.  I've nosied someone who will have an opinion :)

Would doing:

    mybytes = bytes(random.randint(0, 255) for i in range(size))

be faster enough to be workable?  I suppose that might build a list under the covers...maybe preallocating a bytearray and filling it with ints would work better.

----------
nosy: +r.david.murray, rhettinger
title: Ability to get random bits from random.Random (as with os.urandom) -> Ability to get random bytes from random.Random (as with os.urandom)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27096>
_______________________________________

From report at bugs.python.org  Mon May 23 19:18:49 2016
From: report at bugs.python.org (Demur Rumed)
Date: Mon, 23 May 2016 23:18:49 +0000
Subject: [issue27095] Simplify MAKE_FUNCTION
In-Reply-To: <1464038780.83.0.81155899453.issue27095@psf.upfronthosting.co.za>
Message-ID: <1464045529.28.0.655667944009.issue27095@psf.upfronthosting.co.za>


Demur Rumed added the comment:

Attached are modifications to the patch based on feedback from Nikita. It produces a larger patch tho. The changes are to combine return branches in compiler_make_closure & to combine code between compiler_function & compiler_lambda into compiler_default_arguments

----------
Added file: http://bugs.python.org/file42960/mkfu2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27095>
_______________________________________

From report at bugs.python.org  Mon May 23 19:21:41 2016
From: report at bugs.python.org (Campbell Barton)
Date: Mon, 23 May 2016 23:21:41 +0000
Subject: [issue27096] Ability to get random bytes from random.Random (as with
 os.urandom)
In-Reply-To: <1464043046.76.0.140037772611.issue27096@psf.upfronthosting.co.za>
Message-ID: <1464045701.04.0.698058921246.issue27096@psf.upfronthosting.co.za>


Campbell Barton added the comment:

@r.david.murray, yes, this avoids list creation, but is still quite slow.

To create 1mb of data, you can compare the following:

    python -m timeit -s 'from os import urandom' 'print(len(urandom(1000000)))'

    python -m timeit -s 'from random import randint' 'print(len(bytes(randint(0, 255) for i in range(1000000))))'

On my system `os.urandom` is 0.04sec, using randint takes 2.24sec (approx 50x slower).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27096>
_______________________________________

From report at bugs.python.org  Mon May 23 19:52:36 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 23 May 2016 23:52:36 +0000
Subject: [issue27071] unittest.TestCase.assertCountEqual is a very misleading
 name
In-Reply-To: <1463788380.52.0.782790370377.issue27071@psf.upfronthosting.co.za>
Message-ID: <1464047556.11.0.671093306001.issue27071@psf.upfronthosting.co.za>


Martin Panter added the comment:

assertMultisetEqual?

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27071>
_______________________________________

From report at bugs.python.org  Mon May 23 19:56:41 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 23 May 2016 23:56:41 +0000
Subject: [issue27071] unittest.TestCase.assertCountEqual is a very misleading
 name
In-Reply-To: <1463788380.52.0.782790370377.issue27071@psf.upfronthosting.co.za>
Message-ID: <1464047801.92.0.48773327907.issue27071@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

assertSequenceEqualUnordered also works R. David.  I was going to suggest that as well but edited it out to keep my suggestion simpler. :)

I don't like the assertMultisetEqual suggestion as this is most notably an api having nothing to do with sets.

#bikeshed

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27071>
_______________________________________

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: [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 20:09:17 2016
From: report at bugs.python.org (Demur Rumed)
Date: Tue, 24 May 2016 00:09:17 +0000
Subject: [issue27093] Silence warning in cjkcodecs.h
In-Reply-To: <1464011054.7.0.0824737908148.issue27093@psf.upfronthosting.co.za>
Message-ID: <1464048557.48.0.413636849968.issue27093@psf.upfronthosting.co.za>


Changes by Demur Rumed <gunkmute at gmail.com>:


----------
components: +Extension Modules

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27093>
_______________________________________

From report at bugs.python.org  Mon May 23 20:11:20 2016
From: report at bugs.python.org (Vitaly)
Date: Tue, 24 May 2016 00:11:20 +0000
Subject: [issue27071] unittest.TestCase.assertCountEqual is a very misleading
 name
In-Reply-To: <1463788380.52.0.782790370377.issue27071@psf.upfronthosting.co.za>
Message-ID: <1464048680.63.0.654407887084.issue27071@psf.upfronthosting.co.za>


Vitaly added the comment:

assertSequenceEqualUnordered is not a good fit, because it doesn't follow the de facto naming convention, whereby "Equal" should be the suffix.

Also assertSequenceEqualUnordered would be considered an oxymoron, since the word "Sequence" implies ordered, while "Unordered" is the opposite. It's like saying "ordered unordered collection".

My vote (if I had one) is still with assertUnorderedEqual. I think that from the word "Unordered" it's a reasonable leap that it refers to an unordered collection of elements, and it would be easy to remember.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27071>
_______________________________________

From report at bugs.python.org  Mon May 23 20:36:43 2016
From: report at bugs.python.org (Michael Felt)
Date: Tue, 24 May 2016 00:36:43 +0000
Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not
 available (e.g., AIX)
In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za>
Message-ID: <1464050203.05.0.71511096798.issue26439@psf.upfronthosting.co.za>


Michael Felt added the comment:

A bug was found, and has been corrected - but I am unclear on how to best submit the differences.

Editing the current "review" code is not a good idea, as there are many differences.

Please recommend correct course of action.

p.s. I will have also removed the imports for _ctypes and the use of LIBPATH

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26439>
_______________________________________

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: [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 21:50:56 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 24 May 2016 01:50:56 +0000
Subject: [issue24225] Idlelib: changing file names
In-Reply-To: <1431934587.56.0.38760352205.issue24225@psf.upfronthosting.co.za>
Message-ID: <1464054656.88.0.905292336014.issue24225@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I have privately committed 3 patches.  Patch 1 is a renaming patch equivalent to Al's 2 renaming patches.  Patch 2 updates filesnames within code, equivalent to Al's third patch.  At this point, 'python -m test.test_idle' ran with all 188 test_methods passing.  (I added several more test files last week.)  IDLE started, but loading of the 9 extension files failed, entries with old names in .idlerc/config-extensions.cfg caused warning messages.  The htests more or less work.

Patch 3 results in IDLE starting without warnings and with all extensions loaded.  It a) updated the file names in config-extensions.def.  It b) added '<newname> = <oldname>', for example 'runscript = ScriptBinding', where 'ScriptBinding' is still the name of the class defined in the file, to meet the extension requirement that extension files have a callable entry point with the same name as the file.

It also c) temporarily blocks reading from and writing to .idlerc/config-extensions.cfg.  Reading old file names in existing customizations results in failed imports.  This could be fixed in 3.6 by filtering old names, but there would still be the problem that writing customizations with new names would result in failed import warnings in all older versions, and we cannot patch existing releases.  This is another example of how all-version config files are fragile to change.

At this point, IDLE starts normally, with no warnings.  I will retry the htests, work through the menus, and test the shell and editor windows, looking for other name related problems.  Once this is done, and any fixes made, this issue will be complete, and I would like to push the three or four patches.

Ned, do you want me to post the patches first?

I will open another issue about turning extensions into normal code, so config-extensions will only be for external extensions.  Then config-extensions.cfg can be read (with filtering) and written (but there will be nothing to write without added extensions).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24225>
_______________________________________

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: [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 22:03:28 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 24 May 2016 02:03:28 +0000
Subject: [issue24225] Idlelib: changing file names
In-Reply-To: <1431934587.56.0.38760352205.issue24225@psf.upfronthosting.co.za>
Message-ID: <1464055408.5.0.537152093122.issue24225@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

'De-extensionizing' issue is #27099.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24225>
_______________________________________

From report at bugs.python.org  Mon May 23 22:04:11 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 24 May 2016 02:04:11 +0000
Subject: [issue27099] IDLE: turn builting extensions into regular modules
In-Reply-To: <1464055360.13.0.626532918919.issue27099@psf.upfronthosting.co.za>
Message-ID: <1464055451.36.0.765461497269.issue27099@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
dependencies: +Idlelib: changing file names

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27099>
_______________________________________

From report at bugs.python.org  Mon May 23 22:04:21 2016
From: report at bugs.python.org (Colm Buckley)
Date: Tue, 24 May 2016 02:04:21 +0000
Subject: [issue26839] Python 3.5 running on Linux kernel 3.17+ can block at
 startup or on importing the random module on getrandom()
In-Reply-To: <1461524654.13.0.869541747252.issue26839@psf.upfronthosting.co.za>
Message-ID: <1464055461.33.0.523890697142.issue26839@psf.upfronthosting.co.za>


Colm Buckley added the comment:

@haypo - just wondering where things stand with this? Is this patch going to get pushed to the mainline?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26839>
_______________________________________

From report at bugs.python.org  Mon May 23 22:28:45 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 24 May 2016 02:28:45 +0000
Subject: [issue23990] Callable builtin doesn't respect descriptors
In-Reply-To: <1429296768.81.0.194105997153.issue23990@psf.upfronthosting.co.za>
Message-ID: <1464056925.71.0.98871970011.issue23990@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Ionel, 8 core developers (an unusually large number for a tracker issue) have posted here and the closest thing to a consensus is that this is an enhancement request.  Beyond that, opinions are scattered.  No one is going to commit a patch in this circumstance.  So Ethan is right about writing a PEP.  See PEP1 for guidelines.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23990>
_______________________________________

From report at bugs.python.org  Mon May 23 23:10:23 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 24 May 2016 03:10:23 +0000
Subject: [issue27098] Pickle of memoryview not raising error
In-Reply-To: <1464053875.71.0.444720123134.issue27098@psf.upfronthosting.co.za>
Message-ID: <1464059423.84.0.91627931558.issue27098@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

I cannot reproduce this. Pickling memoryview objects works well on my OS.

Python 3.5.1+ (default, Mar 30 2016, 22:46:26) 
[GCC 5.3.1 20160330] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import pickle
>>> mv = memoryview(b'123')
>>> mv.__reduce__()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.5/copyreg.py", line 65, in _reduce_ex
    raise TypeError("can't pickle %s objects" % base.__name__)
TypeError: can't pickle memoryview objects
>>> pickle.dumps(mv)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can't pickle memoryview objects

----------
nosy: +xiang.zhang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27098>
_______________________________________

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: [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  Mon May 23 23:29:33 2016
From: report at bugs.python.org (Ned Deily)
Date: Tue, 24 May 2016 03:29:33 +0000
Subject: [issue24225] Idlelib: changing file names
In-Reply-To: <1431934587.56.0.38760352205.issue24225@psf.upfronthosting.co.za>
Message-ID: <1464060573.56.0.622121763063.issue24225@psf.upfronthosting.co.za>


Ned Deily added the comment:

> Ned, do you want me to post the patches first?

Terry, at this stage of the release cycle, I think that's up to you and whether you want someone to do a code review prior to pushing upstream.  Since this sounds like a fairly major change, though, it might be the prudent thing to do.  I would be happy to take a quick look at the patches myself but I'm not in a position to do a detailed review of IDLE code; hopefully, others more familiar with it would be.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24225>
_______________________________________

From report at bugs.python.org  Mon May 23 23:39:50 2016
From: report at bugs.python.org (Ned Deily)
Date: Tue, 24 May 2016 03:39:50 +0000
Subject: [issue27099] IDLE: turn builting extensions into regular modules
In-Reply-To: <1464055360.13.0.626532918919.issue27099@psf.upfronthosting.co.za>
Message-ID: <1464061190.03.0.0521890602586.issue27099@psf.upfronthosting.co.za>


Ned Deily added the comment:

I don't have an opinion on the matter, other than a reminder about the current cross-version (and cross-platform) compatibility issues with a user's IDLE configuration files as alluded to in Issue20580.  Perhaps others more familiar with IDLE's internals would have comments?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27099>
_______________________________________

From report at bugs.python.org  Mon May 23 23:55:38 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 24 May 2016 03:55:38 +0000
Subject: [issue27100] Attempting to use class with both __enter__ & __exit__
 undefined yields __exit__ attribute error
In-Reply-To: <1464060517.76.0.559675330412.issue27100@psf.upfronthosting.co.za>
Message-ID: <1464062137.99.0.158563247257.issue27100@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

This seems to be designed. From PEP343 it tells clearly:

    If either of the relevant methods are not found
    as expected, the interpreter will raise AttributeError, in the
    order that they are tried (__exit__, __enter__).

But currently I don't find out why.

----------
nosy: +xiang.zhang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27100>
_______________________________________

From report at bugs.python.org  Tue May 24 00:02:37 2016
From: report at bugs.python.org (Ned Deily)
Date: Tue, 24 May 2016 04:02:37 +0000
Subject: [issue26971] python v3.5.1: sys.paths not respecting DESTDIRS and
 DESTSHARED
In-Reply-To: <1462628482.0.0.926875224828.issue26971@psf.upfronthosting.co.za>
Message-ID: <1464062557.97.0.391891497082.issue26971@psf.upfronthosting.co.za>


Ned Deily added the comment:

That's very odd!  I don't have a SuSE system available to test with but it is not clear to me why that would have different behavior because where the standard library extension modules directory (lib-dynload) is installed is controlled by the Python configure and Makefile and, in the vanilla copies downloadable from python.org, I can't find any relevant references to lib64 (there are some in setup.py as far as where to look for linking with other library files).  Are you sure you are using an unpatched 3.5.1 source tarball downloaded from python.org?  And that any lib-dynload in /lib64 wasn't installed by SuSE?  When I follow the steps you give, I end up with the extension modules in ~/.opt/lib/python3.5/lib-dynload as expected.  I don't know what else to suggest.  Anyone else have any ideas?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26971>
_______________________________________

From report at bugs.python.org  Tue May 24 00:32:39 2016
From: report at bugs.python.org (Ned Deily)
Date: Tue, 24 May 2016 04:32:39 +0000
Subject: [issue26955] Implement equivalent to `pip.locations.distutils_scheme`
 in distutils
In-Reply-To: <1462378664.68.0.201238634465.issue26955@psf.upfronthosting.co.za>
Message-ID: <1464064359.97.0.762187954144.issue26955@psf.upfronthosting.co.za>


Ned Deily added the comment:

Sylvain, OK.  I suggest you bring the matter up on the distutils-sig mailing list (if you haven't already) because that's where discussions and decisions are made about features for Python packaging including distutils.  Otherwise, the issue is likely to languish here.  Good luck!

https://mail.python.org/mailman/listinfo/distutils-sig

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26955>
_______________________________________

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: [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 01:28:48 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 24 May 2016 05:28:48 +0000
Subject: [issue27100] Attempting to use class with both __enter__ & __exit__
 undefined yields __exit__ attribute error
In-Reply-To: <1464060517.76.0.559675330412.issue27100@psf.upfronthosting.co.za>
Message-ID: <1464067728.69.0.334509726499.issue27100@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Nick, I've seen the come-up several times with people learning about context managers.  The current error message seems cause confusion because it checks for __exit__ before __enter__, implying that the __enter__ is optional which it isn't.   Do you have any objections testing for __enter__ first?

----------
assignee:  -> rhettinger
nosy: +ncoghlan
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27100>
_______________________________________

From report at bugs.python.org  Tue May 24 01:41:14 2016
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 24 May 2016 05:41:14 +0000
Subject: [issue27100] Attempting to use class with both __enter__ & __exit__
 undefined yields __exit__ attribute error
In-Reply-To: <1464060517.76.0.559675330412.issue27100@psf.upfronthosting.co.za>
Message-ID: <1464068474.82.0.136297200371.issue27100@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

I don't completely understand. If you get an AttributeError for __enter__, will you think only an __enter__ is required?

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27100>
_______________________________________

From report at bugs.python.org  Tue May 24 01:47:03 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 May 2016 05:47:03 +0000
Subject: [issue27098] Pickle of memoryview not raising error
In-Reply-To: <1464053875.71.0.444720123134.issue27098@psf.upfronthosting.co.za>
Message-ID: <1464068823.2.0.39293397651.issue27098@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This was fixed in issue22995. Please wait 3.5.2.

----------
nosy: +serhiy.storchaka
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27098>
_______________________________________

From report at bugs.python.org  Tue May 24 01:48:18 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 May 2016 05:48:18 +0000
Subject: [issue27093] Silence warning in cjkcodecs.h
In-Reply-To: <1464011054.7.0.0824737908148.issue27093@psf.upfronthosting.co.za>
Message-ID: <20160524054815.15443.21671.5C08FE21@psf.io>


Roundup Robot added the comment:

New changeset 3732828f2835 by Benjamin Peterson in branch '3.5':
fix indentation and add curlies (closes #27093)
https://hg.python.org/cpython/rev/3732828f2835

New changeset f0438e1a4761 by Benjamin Peterson in branch '2.7':
fix indentation and add curlies (closes #27093)
https://hg.python.org/cpython/rev/f0438e1a4761

New changeset 7a7f54fe0698 by Benjamin Peterson in branch 'default':
merge 3.5 (#27093)
https://hg.python.org/cpython/rev/7a7f54fe0698

----------
nosy: +python-dev
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27093>
_______________________________________

From report at bugs.python.org  Tue May 24 01:51:59 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 May 2016 05:51:59 +0000
Subject: [issue27095] Simplify MAKE_FUNCTION
In-Reply-To: <1464038780.83.0.81155899453.issue27095@psf.upfronthosting.co.za>
Message-ID: <1464069119.22.0.86610742779.issue27095@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

At first look your patch looks good (I'll make more detailed review later), but you should wait until we have finished all work related to the conversion to wordcode.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27095>
_______________________________________

From report at bugs.python.org  Tue May 24 01:56:11 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 24 May 2016 05:56:11 +0000
Subject: [issue7159] Urllib2 authentication memory.
In-Reply-To: <1255793559.46.0.185389780208.issue7159@psf.upfronthosting.co.za>
Message-ID: <1464069371.34.0.551768702257.issue7159@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Should this be closed?  A substantial patch was pushed year ago and I see no indication of further issue.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7159>
_______________________________________

From report at bugs.python.org  Tue May 24 02:10:23 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 24 May 2016 06:10:23 +0000
Subject: [issue27100] Attempting to use class with both __enter__ & __exit__
 undefined yields __exit__ attribute error
In-Reply-To: <1464060517.76.0.559675330412.issue27100@psf.upfronthosting.co.za>
Message-ID: <1464070223.14.0.961241488189.issue27100@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

As Jonathan notes, the cause for confusion here is that we currently retrieve the attributes in the opposite order from the way we execute them, prompting the "Why is it looking for __exit__ first?", "Oh, __enter__ must be optional, so it didn't care that it was missing" train of thought.

If I recall correctly, rather than stemming from any particular design principle, the current behaviour is an artifact of the initial implementation that didn't use any dedicated opcodes: since CPython uses a stack-based VM, we needed __enter__ to be above __exit__ on the stack, and the most efficient way to achieve that was to do the attribute lookups in the reverse order of invocation.

When SETUP_WITH was introduced, that original method lookup ordering (and associated error message precedence) was preserved, even though the technical rationale for that ordering no longer applied.

Given that, I don't see any problem with switching the lookup order now, and I agree that should be less confusing, given that the most obvious explanation for getting an error message about __enter__ when both are missing is that the interpreter tries to call __enter__ before it tries to do anything with __exit__. (That intuitive explanation still isn't 100% accurate, but it's closer than thinking __enter__ is optional)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27100>
_______________________________________

From report at bugs.python.org  Tue May 24 02:15:46 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 May 2016 06:15:46 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <20160524061542.11207.44098.01155EC1@psf.io>


Roundup Robot added the comment:

New changeset 3a57eafd8401 by Serhiy Storchaka in branch 'default':
Issue #26647: Python interpreter now uses 16-bit wordcode instead of bytecode.
https://hg.python.org/cpython/rev/3a57eafd8401

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Tue May 24 02:18:07 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 May 2016 06:18:07 +0000
Subject: [issue27097] ceval: Wordcode follow up, explicit unsigned short read
In-Reply-To: <1464048499.12.0.811410474415.issue27097@psf.upfronthosting.co.za>
Message-ID: <1464070687.82.0.191801560687.issue27097@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
stage:  -> patch review
Added file: http://bugs.python.org/file42964/ushort.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27097>
_______________________________________

From report at bugs.python.org  Tue May 24 02:18:33 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 May 2016 06:18:33 +0000
Subject: [issue27097] ceval: Wordcode follow up, explicit unsigned short read
In-Reply-To: <1464048499.12.0.811410474415.issue27097@psf.upfronthosting.co.za>
Message-ID: <1464070713.51.0.581755415625.issue27097@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27097>
_______________________________________

From report at bugs.python.org  Tue May 24 02:25:06 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 May 2016 06:25:06 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1464071106.39.0.720221754411.issue26647@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Oh, I forgot to add a note in What's New. And the documentation of the dis module should be updated (EXTENDED_ARG etc). Could anyone do this?

----------
stage: commit review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Tue May 24 02:37:27 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 24 May 2016 06:37:27 +0000
Subject: [issue27071] unittest.TestCase.assertCountEqual is a very misleading
 name
In-Reply-To: <1463788380.52.0.782790370377.issue27071@psf.upfronthosting.co.za>
Message-ID: <1464071847.31.0.24335062208.issue27071@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Further churning of the names will cause more harm than good.  I recommend closing this (to end the bike-shedding and the stream of superlatives from the OP).  This ship has sailed and users are already relying on the published API.

Foord: "In the absence of a *dramatically* better name leave it alone."
Storchaka: "I vote for status quo."
Murray:  "I say leave well enough alone unless someone comes up with a simply brilliant better name."
Smith: "I'm not against adding a new name if it makes glorious sense, but we should not remove the old names from unittest as that causes unnecessary pain (based on past experience)."

FWIW, most of the suggestions in this issue would not help with a "never read the docs, just reading the code" kind of user.  Without biasing the result,  ask other Python user's to guess what "assertItemsEqual" or "assertElementsEqual" do, and see whether they correctly deduce that it tests the equality of two unordered multisets formed from two input iterables.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27071>
_______________________________________

From report at bugs.python.org  Tue May 24 02:42:10 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 May 2016 06:42:10 +0000
Subject: [issue27096] Ability to get random bytes from random.Random (as with
 os.urandom)
In-Reply-To: <1464043046.76.0.140037772611.issue27096@psf.upfronthosting.co.za>
Message-ID: <1464072130.78.0.404352921676.issue27096@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

$ ./python -m timeit -s 'from os import urandom' 'urandom(1000000)'
10 loops, best of 3: 132 msec per loop
$ ./python -m timeit -s 'from random import getrandbits' 'n = 1000000; getrandbits(n*8).to_bytes(n, "little")'
100 loops, best of 3: 14.1 msec per loop

With the purposed method this can be up to 3.4 times faster, but as I said in issue27072, I don't think API growing is worth the benefit.

----------
assignee:  -> rhettinger
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27096>
_______________________________________

From report at bugs.python.org  Tue May 24 02:57:52 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 24 May 2016 06:57:52 +0000
Subject: [issue27096] Ability to get random bytes from random.Random (as with
 os.urandom)
In-Reply-To: <1464043046.76.0.140037772611.issue27096@psf.upfronthosting.co.za>
Message-ID: <1464073072.34.0.921897053167.issue27096@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
nosy: +tim.peters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27096>
_______________________________________

From report at bugs.python.org  Tue May 24 03:12:53 2016
From: report at bugs.python.org (Johannes S.)
Date: Tue, 24 May 2016 07:12:53 +0000
Subject: [issue26971] python v3.5.1: sys.paths not respecting DESTDIRS and
 DESTSHARED
In-Reply-To: <1462628482.0.0.926875224828.issue26971@psf.upfronthosting.co.za>
Message-ID: <1464073973.71.0.231686951994.issue26971@psf.upfronthosting.co.za>


Johannes S. added the comment:

I tried it again and I also tried 3.6.0a1 now. 3.6.0a1 has the issue as well. I have downloaded the tarballs from https://www.python.org/downloads/release/python-351/ and https://www.python.org/downloads/release/python-360a1/.

I have run it on my Laptop (Arch Linux) now. The issue did *not* occur there. But I discovered that I can trigger a similar issue by specifying the libdir explicitly with

    `../configure --prefix="/some/dir" --libdir="/some/dir/lib64"`.

I thing it would be reasonable to assume that both issues are related.

----------
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26971>
_______________________________________

From report at bugs.python.org  Tue May 24 03:18:39 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 24 May 2016 07:18:39 +0000
Subject: [issue26915] Test identity first in membership operation of ItemsView, 
 ValuesView and Sequence in collections.abc
In-Reply-To: <1462256356.96.0.954300432794.issue26915@psf.upfronthosting.co.za>
Message-ID: <1464074319.62.0.179537210507.issue26915@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee: rhettinger -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26915>
_______________________________________

From report at bugs.python.org  Tue May 24 04:23:23 2016
From: report at bugs.python.org (Christian Kleineidam)
Date: Tue, 24 May 2016 08:23:23 +0000
Subject: =?utf-8?q?=5Bissue27091=5D_Python_IDLE_doesn=27t_like_=F0=9F=92=99?=
In-Reply-To: <1464007203.98.0.542395550852.issue27091@psf.upfronthosting.co.za>
Message-ID: <1464078203.96.0.0917385132623.issue27091@psf.upfronthosting.co.za>


Christian Kleineidam added the comment:

My version is: Python 3.5.0 (v3.5.0:374f501f4567, Sep 13 2015, 02:16:59) [MSC v.1900 32 bit (Intel)] on win32

Yes, I think the issue is likely a dublicate of http://bugs.python.org/issue13153

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27091>
_______________________________________

From report at bugs.python.org  Tue May 24 04:55:05 2016
From: report at bugs.python.org (Eryk Sun)
Date: Tue, 24 May 2016 08:55:05 +0000
Subject: =?utf-8?q?=5Bissue27091=5D_Python_IDLE_doesn=27t_like_=F0=9F=92=99?=
In-Reply-To: <1464007203.98.0.542395550852.issue27091@psf.upfronthosting.co.za>
Message-ID: <1464080105.88.0.102488034646.issue27091@psf.upfronthosting.co.za>


Changes by Eryk Sun <eryksun+pybugs at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> IDLE crashes when pasting non-BMP unicode char on Py3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27091>
_______________________________________

From report at bugs.python.org  Tue May 24 05:01:02 2016
From: report at bugs.python.org (Clement Rouault)
Date: Tue, 24 May 2016 09:01:02 +0000
Subject: [issue23026] Winreg module doesn't support REG_QWORD,
 small DWORD doc update
In-Reply-To: <1418242433.97.0.849861872047.issue23026@psf.upfronthosting.co.za>
Message-ID: <1464080462.39.0.594106956948.issue23026@psf.upfronthosting.co.za>


Clement Rouault added the comment:

I would like to discuss the fact that this patch is a new feature.

In the current state, CPython handles the `REG_QWORD` type as an unkown type and returns the raw registry value: a string of size 8.
In my opinion this behavior does not match the Windows documentation (REG_QWORD: A 64-bit number)
or CPython's own behavior regarding REG_DWORD that returns a Python `int` (more important).

Is this enough to consider this a bugfix ? and therefore port it to 2.7 ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23026>
_______________________________________

From report at bugs.python.org  Tue May 24 05:39:50 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 May 2016 09:39:50 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <20160524061542.11207.44098.01155EC1@psf.io>
Message-ID: <CAMpsgwY98fsyRET7MMYcbPYN5Y=PdP-itBw8MNh9PdmeKg=xLQ@mail.gmail.com>


STINNER Victor added the comment:

> New changeset 3a57eafd8401 by Serhiy Storchaka in branch 'default':
> Issue #26647: Python interpreter now uses 16-bit wordcode instead of bytecode.
> https://hg.python.org/cpython/rev/3a57eafd8401

Yeah, congrats Demur!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Tue May 24 06:01:09 2016
From: report at bugs.python.org (Paul Moore)
Date: Tue, 24 May 2016 10:01:09 +0000
Subject: [issue23026] Winreg module doesn't support REG_QWORD,
 small DWORD doc update
In-Reply-To: <1418242433.97.0.849861872047.issue23026@psf.upfronthosting.co.za>
Message-ID: <1464084069.18.0.945266523397.issue23026@psf.upfronthosting.co.za>


Paul Moore added the comment:

I'm not sure I follow your comment. In Python 3.5,

>>> from winreg import REG_QWORD
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: cannot import name 'REG_QWORD'

So exposing REG_QWORD from the winreg module would be a change in behaviour, not a bug fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23026>
_______________________________________

From report at bugs.python.org  Tue May 24 06:50:04 2016
From: report at bugs.python.org (Clement Rouault)
Date: Tue, 24 May 2016 10:50:04 +0000
Subject: [issue23026] Winreg module doesn't support REG_QWORD,
 small DWORD doc update
In-Reply-To: <1418242433.97.0.849861872047.issue23026@psf.upfronthosting.co.za>
Message-ID: <1464087004.92.0.652922573392.issue23026@psf.upfronthosting.co.za>


Clement Rouault added the comment:

My comment was about the behavior of `winreg.QueryValueEx`. The current behavior is:

>>> import winreg
>>> tstkey = winreg.OpenKey(winreg.HKEY_CURRENT_USER, "TestKey")
>>> winreg.QueryValueEx(tstkey, "MYDWORD") # a REG_DWORD value
(16909060, 4)
>>> winreg.QueryValueEx(tstkey, "MYQWORD") # a REG_QWORD value
(b'\x08\x07\x06\x05\x04\x03\x02\x01', 11)

With this patch the new behavior would be:

>>> winreg.QueryValueEx(tstkey, "MYQWORD") # a REG_QWORD value
(72623859790382856, 11)

I agree that exposing REG_QWORD is a new feature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23026>
_______________________________________

From report at bugs.python.org  Tue May 24 07:17:13 2016
From: report at bugs.python.org (Paul Moore)
Date: Tue, 24 May 2016 11:17:13 +0000
Subject: [issue23026] Winreg module doesn't support REG_QWORD,
 small DWORD doc update
In-Reply-To: <1418242433.97.0.849861872047.issue23026@psf.upfronthosting.co.za>
Message-ID: <1464088633.87.0.713580933974.issue23026@psf.upfronthosting.co.za>


Paul Moore added the comment:

Hmm, OK. So code that currently needs to access QWORD values and decodes the bytes returned would be broken by this change. Equally it is possible (albeit not ideal) to get the data out with the current behaviour.

I can't judge how likely it is that anyone has written code like this - personally, I'd prefer not to take the risk. But if someone else feels I'm being over-cautious, that's fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23026>
_______________________________________

From report at bugs.python.org  Tue May 24 07:41:39 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 May 2016 11:41:39 +0000
Subject: [issue27071] unittest.TestCase.assertCountEqual is a very misleading
 name
In-Reply-To: <1463788380.52.0.782790370377.issue27071@psf.upfronthosting.co.za>
Message-ID: <1464090099.47.0.910367231395.issue27071@psf.upfronthosting.co.za>


R. David Murray added the comment:

Agreed.  Time to close the issue.  If someone wants to do actual testing as Raymond suggests, and finds a name that actually works, they can either reopen this with a report or open a new issue.

----------
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27071>
_______________________________________

From report at bugs.python.org  Tue May 24 08:27:25 2016
From: report at bugs.python.org (Demur Rumed)
Date: Tue, 24 May 2016 12:27:25 +0000
Subject: [issue27095] Simplify MAKE_FUNCTION
In-Reply-To: <1464038780.83.0.81155899453.issue27095@psf.upfronthosting.co.za>
Message-ID: <1464092845.1.0.0912709647192.issue27095@psf.upfronthosting.co.za>


Demur Rumed added the comment:

May've been best to wait on posting a patch, but long weekend yesterday made time available

mkfu3 updates mkfu2 with wordcode. Includes fix to EXTENDED_ARG documentation

----------
Added file: http://bugs.python.org/file42965/mkfu3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27095>
_______________________________________

From report at bugs.python.org  Tue May 24 09:02:29 2016
From: report at bugs.python.org (Brad Olson)
Date: Tue, 24 May 2016 13:02:29 +0000
Subject: [issue7159] Urllib2 authentication memory.
In-Reply-To: <1464069371.34.0.551768702257.issue7159@psf.upfronthosting.co.za>
Message-ID: <CAJYt1WfcgFpzrS=6hMGkXssYeDCpNt+4rQnrdenr3wkqKC1hBQ@mail.gmail.com>


Brad Olson added the comment:

Yes, Go ahead. Thanks.

On Tue, May 24, 2016 at 1:56 AM, Terry J. Reedy <report at bugs.python.org>
wrote:

>
> Terry J. Reedy added the comment:
>
> Should this be closed?  A substantial patch was pushed year ago and I see
> no indication of further issue.
>
> ----------
> nosy: +terry.reedy
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue7159>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7159>
_______________________________________

From report at bugs.python.org  Tue May 24 09:18:41 2016
From: report at bugs.python.org (Steve Dower)
Date: Tue, 24 May 2016 13:18:41 +0000
Subject: [issue23026] Winreg module doesn't support REG_QWORD,
 small DWORD doc update
In-Reply-To: <1418242433.97.0.849861872047.issue23026@psf.upfronthosting.co.za>
Message-ID: <1464095921.67.0.522192810843.issue23026@psf.upfronthosting.co.za>


Steve Dower added the comment:

Changing a return value type without notice certainly can't go into a maintenance release. I'd assumed an extra import too, but since it's transparent this is 3.6 only (definitely not a security fix, so 2.7 isn't up for discussion).

----------
versions:  -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23026>
_______________________________________

From report at bugs.python.org  Tue May 24 09:21:49 2016
From: report at bugs.python.org (Upendra Kumar)
Date: Tue, 24 May 2016 13:21:49 +0000
Subject: [issue27051] Create PIP gui
In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za>
Message-ID: <1464096109.68.0.833511279502.issue27051@psf.upfronthosting.co.za>


Upendra Kumar added the comment:

These are some of the code parts which may be necessary :

1. Code for identification of OS

from sys import platform

if platform.startswith("linux"):
    #linux
elif platform == "darwin":
    #mac os x
else platform == "win32":
    # Windows

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27051>
_______________________________________

From report at bugs.python.org  Tue May 24 09:33:44 2016
From: report at bugs.python.org (Upendra Kumar)
Date: Tue, 24 May 2016 13:33:44 +0000
Subject: [issue27051] Create PIP gui
In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za>
Message-ID: <1464096824.3.0.22926896529.issue27051@psf.upfronthosting.co.za>


Upendra Kumar added the comment:

2. Detecting different versions of Python installed :


For Windows :

It is explained in PEP 514 by Steve Dower. 

Windows has registry keys which can be accessed by winreg or _winreg module.

Priority of registry keys :
HKEY_CURRENT_USER > HKEY_LOCAL_MACHINE

On 64 bit Windows there is another registry key for 32 bit programs,
HKEY_LOCAL_MACHINE\Software\Wow6432Node

Therefore using registry keys we can know about Python packages installed by enumerating on :

1. HKEY_CURRENT_USER\Software\Python\<Company>\<Tag>\<InstallPath>
2. HKEY_LOCAL_MACHINE\Software\Python\<Company>\<Tag>\<InstallPath>
3. HKEY_LOCAL_MACHINE\Wow6432Node\Python\<Company>\<Tag>\<InstallPath>

<Tag> will tell the version number of Python, and in <InstallPath> key there are two more subkeys which will tell the location of Python executable :

1. <Executable Path>
2. <WindowedExecutablePath>




For Linux :

We can find Python installations in /usr/bin/pythonXYZ




For MAC OS :

It can be searched for in 

/Library/Frameworks/
/System/Library/Frameworks

If Python was installed by Homebrew :

Then the location can be in 
/usr/local

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27051>
_______________________________________

From report at bugs.python.org  Tue May 24 09:39:34 2016
From: report at bugs.python.org (Upendra Kumar)
Date: Tue, 24 May 2016 13:39:34 +0000
Subject: [issue27051] Create PIP gui
In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za>
Message-ID: <1464097174.45.0.574487649529.issue27051@psf.upfronthosting.co.za>


Upendra Kumar added the comment:

3. Detecting Virtual Environment

Virtual environment can be detected using pip module :

from pip.locations import running_under_virtualenv

if running_under_virtualenv():
      #If user provided path for virtual environment, evrything okay
else:
      #Prompt for error

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27051>
_______________________________________

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: [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 09:43:07 2016
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 24 May 2016 13:43:07 +0000
Subject: [issue27102] Spam
In-Reply-To: <0000629394c7$45bbfcaf$0277fcd5$@whywouldwe.com>
Message-ID: <1464097387.67.0.779364318488.issue27102@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
nosy:  -cerberos
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed
title: nice story -> Spam

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27102>
_______________________________________

From report at bugs.python.org  Tue May 24 09:43:19 2016
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 24 May 2016 13:43:19 +0000
Subject: [issue27102] Spam
Message-ID: <1464097399.36.0.602322049653.issue27102@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
Removed message: http://bugs.python.org/msg266251

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27102>
_______________________________________

From report at bugs.python.org  Tue May 24 10:52:07 2016
From: report at bugs.python.org (Clement Rouault)
Date: Tue, 24 May 2016 14:52:07 +0000
Subject: [issue23026] Winreg module doesn't support REG_QWORD,
 small DWORD doc update
In-Reply-To: <1418242433.97.0.849861872047.issue23026@psf.upfronthosting.co.za>
Message-ID: <1464101527.78.0.0143521682389.issue23026@psf.upfronthosting.co.za>


Clement Rouault added the comment:

Stated as you did, it makes sens. Should the change of return type be acknowledged somewhere in the documentation ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23026>
_______________________________________

From report at bugs.python.org  Tue May 24 11:03:00 2016
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 24 May 2016 15:03:00 +0000
Subject: [issue23026] Winreg module doesn't support REG_QWORD,
 small DWORD doc update
In-Reply-To: <1464101527.78.0.0143521682389.issue23026@psf.upfronthosting.co.za>
Message-ID: <CAKJDb-MoFx+-YtrNF4NpTouu366kgZ2x9UwB6-_ADZwts9uVVg@mail.gmail.com>


Zachary Ware added the comment:

Clement Rouault added the comment:
> Stated as you did, it makes sens. Should the change of return type be acknowledged somewhere in the documentation ?

Yes, it should be mentioned in Doc/whatsnew/3.6.rst and probably also
somewhere in Doc/library/winreg.rst

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23026>
_______________________________________

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: [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 12:41:29 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 24 May 2016 16:41:29 +0000
Subject: [issue7159] Urllib2 authentication memory.
In-Reply-To: <1255793559.46.0.185389780208.issue7159@psf.upfronthosting.co.za>
Message-ID: <1464108089.18.0.741719555191.issue7159@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7159>
_______________________________________

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: [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 13:37:24 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 24 May 2016 17:37:24 +0000
Subject: [issue27097] ceval: Wordcode follow up, explicit unsigned short read
In-Reply-To: <1464048499.12.0.811410474415.issue27097@psf.upfronthosting.co.za>
Message-ID: <1464111444.5.0.978926162531.issue27097@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

This assignment:

    oparg = *(unsigned short*)next_instr

has undefined behaviour, according to the C standards. I'm not sure it's a good idea to introduce this into the core.

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27097>
_______________________________________

From report at bugs.python.org  Tue May 24 14:00:21 2016
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 24 May 2016 18:00:21 +0000
Subject: [issue27097] ceval: Wordcode follow up, explicit unsigned short read
In-Reply-To: <1464048499.12.0.811410474415.issue27097@psf.upfronthosting.co.za>
Message-ID: <1464112821.77.0.654652483905.issue27097@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> has undefined behaviour, according to the C standards.

I retract this; I'm no longer convinced this is true. Sorry for the noise.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27097>
_______________________________________

From report at bugs.python.org  Tue May 24 14:05:19 2016
From: report at bugs.python.org (Alexandra Beebe)
Date: Tue, 24 May 2016 18:05:19 +0000
Subject: [issue27104] enable-framework
In-Reply-To: <1464109808.75.0.969768619517.issue27104@psf.upfronthosting.co.za>
Message-ID: <1464113119.66.0.25214155091.issue27104@psf.upfronthosting.co.za>


Alexandra Beebe added the comment:

Never mind... User error.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27104>
_______________________________________

From report at bugs.python.org  Tue May 24 14:07:45 2016
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 24 May 2016 18:07:45 +0000
Subject: [issue27083] PYTHONCASEOK is ignored on Windows
In-Reply-To: <1463899532.05.0.0164205622545.issue27083@psf.upfronthosting.co.za>
Message-ID: <1464113265.29.0.867417552649.issue27083@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee:  -> brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27083>
_______________________________________

From report at bugs.python.org  Tue May 24 14:08:54 2016
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 24 May 2016 18:08:54 +0000
Subject: [issue27059] find_spec and find_loader ignore package/path argument
In-Reply-To: <1463683793.33.0.38773604471.issue27059@psf.upfronthosting.co.za>
Message-ID: <1464113334.83.0.227893094572.issue27059@psf.upfronthosting.co.za>


Brett Cannon added the comment:

https://docs.python.org/3.6/library/importlib.html#examples has an Examples section that's new to the Python 3.6 docs which covers your use-case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27059>
_______________________________________

From report at bugs.python.org  Tue May 24 14:43:43 2016
From: report at bugs.python.org (mdcb)
Date: Tue, 24 May 2016 18:43:43 +0000
Subject: [issue24510] Make _PyCoro_GetAwaitableIter a public API
In-Reply-To: <1435246558.17.0.296607565259.issue24510@psf.upfronthosting.co.za>
Message-ID: <1464115423.5.0.519070830563.issue24510@psf.upfronthosting.co.za>


Changes by mdcb <mdcb808 at gmail.com>:


----------
nosy: +mdcb808 at gmail.com

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24510>
_______________________________________

From report at bugs.python.org  Tue May 24 14:44:00 2016
From: report at bugs.python.org (mdcb)
Date: Tue, 24 May 2016 18:44:00 +0000
Subject: [issue24511] Add methods for async protocols
In-Reply-To: <1435246948.22.0.255546128718.issue24511@psf.upfronthosting.co.za>
Message-ID: <1464115440.11.0.202871932534.issue24511@psf.upfronthosting.co.za>


Changes by mdcb <mdcb808 at gmail.com>:


----------
nosy: +mdcb808 at gmail.com

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24511>
_______________________________________

From report at bugs.python.org  Tue May 24 14:54:52 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 24 May 2016 18:54:52 +0000
Subject: [issue14196] Unhandled exceptions in pdb return value display
In-Reply-To: <1330906516.74.0.432612109172.issue14196@psf.upfronthosting.co.za>
Message-ID: <1464116092.04.0.056097309806.issue14196@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Georg, if you agree that Xavier's analysis is correct, we can close this as not a bug.

----------
nosy: +georg.brandl, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue14196>
_______________________________________

From report at bugs.python.org  Tue May 24 15:05:10 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 May 2016 19:05:10 +0000
Subject: [issue27097] ceval: Wordcode follow up, explicit unsigned short read
In-Reply-To: <1464048499.12.0.811410474415.issue27097@psf.upfronthosting.co.za>
Message-ID: <1464116710.35.0.535977915553.issue27097@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

What if change the type of next_instr to unsigned short*? This would guarantee that the read is aligned since the start of code data is aligned.

I have small doubt about PREDICT(). I doubt that the compiler is smart enough to infer that *next_instr and *(unsigned short*)next_instr & 255 is the same. It can do unneeded work. I don't know whether this have negative effect.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27097>
_______________________________________

From report at bugs.python.org  Tue May 24 15:19:23 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 May 2016 19:19:23 +0000
Subject: [issue27097] ceval: Wordcode follow up, explicit unsigned short read
In-Reply-To: <1464048499.12.0.811410474415.issue27097@psf.upfronthosting.co.za>
Message-ID: <1464117563.15.0.702867642052.issue27097@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Using Raymond's microbenchmark from issue25823:

$ ./python.exe exercise_oparg.py
Unpatched:  0.8331978429996525
Patched:    0.7600522060020012

Pybench exposes 7% speed up (detailed report is attached).

----------
Added file: http://bugs.python.org/file42966/pybench-diff.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27097>
_______________________________________

From report at bugs.python.org  Tue May 24 15:24:59 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 24 May 2016 19:24:59 +0000
Subject: [issue27104] enable-framework
In-Reply-To: <1464109808.75.0.969768619517.issue27104@psf.upfronthosting.co.za>
Message-ID: <1464117899.14.0.712586515858.issue27104@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
resolution: rejected -> not a bug
stage:  -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27104>
_______________________________________

From report at bugs.python.org  Tue May 24 15:29:51 2016
From: report at bugs.python.org (Adrian Wielgosik)
Date: Tue, 24 May 2016 19:29:51 +0000
Subject: [issue27097] ceval: Wordcode follow up, explicit unsigned short read
In-Reply-To: <1464048499.12.0.811410474415.issue27097@psf.upfronthosting.co.za>
Message-ID: <1464118191.11.0.000908101021697.issue27097@psf.upfronthosting.co.za>


Adrian Wielgosik added the comment:

I'm pretty sure this is undefined behavior. Here's how similar code was fixed in Chromium:

https://codereview.chromium.org/9117014/patch/1/2

----------
nosy: +Adrian Wielgosik

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27097>
_______________________________________

From report at bugs.python.org  Tue May 24 16:03:57 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 24 May 2016 20:03:57 +0000
Subject: [issue27097] ceval: Wordcode follow up, explicit unsigned short read
In-Reply-To: <1464048499.12.0.811410474415.issue27097@psf.upfronthosting.co.za>
Message-ID: <1464120237.44.0.198529628779.issue27097@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I hope following patch is free from undefined behavior.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27097>
_______________________________________

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: [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: [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: [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: [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: [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: [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: [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:43:59 2016
From: report at bugs.python.org (Oren Milman)
Date: Tue, 24 May 2016 20:43:59 +0000
Subject: [issue27111] redundant variables in long_add and long_sub
In-Reply-To: <1464122604.65.0.69831533642.issue27111@psf.upfronthosting.co.za>
Message-ID: <1464122639.27.0.393212477598.issue27111@psf.upfronthosting.co.za>


Changes by Oren Milman <orenmn at gmail.com>:


Added file: http://bugs.python.org/file42974/patchedCPythonTestOutput.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27111>
_______________________________________

From report at bugs.python.org  Tue May 24 16:44:27 2016
From: report at bugs.python.org (Oren Milman)
Date: Tue, 24 May 2016 20:44:27 +0000
Subject: [issue27111] redundant variables in long_add and long_sub
In-Reply-To: <1464122604.65.0.69831533642.issue27111@psf.upfronthosting.co.za>
Message-ID: <1464122667.29.0.769680064555.issue27111@psf.upfronthosting.co.za>


Changes by Oren Milman <orenmn at gmail.com>:


Added file: http://bugs.python.org/file42975/CPythonTestOutput.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27111>
_______________________________________

From report at bugs.python.org  Tue May 24 16:48:00 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 May 2016 20:48:00 +0000
Subject: [issue27110] smtpd.__all__ list is incomplete
In-Reply-To: <1464122507.71.0.719319292765.issue27110@psf.upfronthosting.co.za>
Message-ID: <1464122880.35.0.109246499929.issue27110@psf.upfronthosting.co.za>


R. David Murray added the comment:

Maybe we should blacklist MailmanProxy?  I think we are planning to deprecate it but just haven't yet done the work.  Looks fine otherwise.

----------
components: +email
nosy: +barry, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27110>
_______________________________________

From report at bugs.python.org  Tue May 24 16:50:37 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 May 2016 20:50:37 +0000
Subject: [issue27107] mailbox.__all__ list is incomplete
In-Reply-To: <1464121814.28.0.86378219066.issue27107@psf.upfronthosting.co.za>
Message-ID: <1464123037.05.0.686828755855.issue27107@psf.upfronthosting.co.za>


R. David Murray added the comment:

Rather than adding the new class to the list of tests, we could take this opportunity to convert this test file to the new format, unless there's some reason that doesn't work (I don't expect there to be).

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27107>
_______________________________________

From report at bugs.python.org  Tue May 24 16:53:39 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 May 2016 20:53:39 +0000
Subject: [issue27108] mimetypes.__all__ list is incomplete
In-Reply-To: <1464121896.07.0.577561794509.issue27108@psf.upfronthosting.co.za>
Message-ID: <1464123219.01.0.581050909227.issue27108@psf.upfronthosting.co.za>


R. David Murray added the comment:

LGTM

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27108>
_______________________________________

From report at bugs.python.org  Tue May 24 16:56:37 2016
From: report at bugs.python.org (=?utf-8?q?Jacek_Ko=C5=82odziej?=)
Date: Tue, 24 May 2016 20:56:37 +0000
Subject: [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 16:57:26 2016
From: report at bugs.python.org (=?utf-8?q?Jacek_Ko=C5=82odziej?=)
Date: Tue, 24 May 2016 20:57:26 +0000
Subject: [issue27110] smtpd.__all__ list is incomplete
In-Reply-To: <1464122507.71.0.719319292765.issue27110@psf.upfronthosting.co.za>
Message-ID: <1464123446.34.0.4372914047.issue27110@psf.upfronthosting.co.za>


Changes by Jacek Ko?odziej <kolodziejj at gmail.com>:


Removed 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:57:31 2016
From: report at bugs.python.org (=?utf-8?q?Jacek_Ko=C5=82odziej?=)
Date: Tue, 24 May 2016 20:57:31 +0000
Subject: [issue27110] smtpd.__all__ list is incomplete
In-Reply-To: <1464122507.71.0.719319292765.issue27110@psf.upfronthosting.co.za>
Message-ID: <1464123451.52.0.169790100242.issue27110@psf.upfronthosting.co.za>


Changes by Jacek Ko?odziej <kolodziejj at gmail.com>:


Added file: http://bugs.python.org/file42977/smtpd_all.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27110>
_______________________________________

From report at bugs.python.org  Tue May 24 17:01:46 2016
From: report at bugs.python.org (=?utf-8?q?Jacek_Ko=C5=82odziej?=)
Date: Tue, 24 May 2016 21:01:46 +0000
Subject: [issue23883] __all__ lists are incomplete
In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za>
Message-ID: <1464123706.92.0.728183472702.issue23883@psf.upfronthosting.co.za>


Jacek Ko?odziej added the comment:

Per Martin's request, I've created a few new issues for next batch of module's __all__ list updates:
* cgi: #27105
* configparser: #27106
* mailbox: #27107
* mimetypes: #27108
* plistlib: #27109
* smtpd: #27110
* tokenize: #27112

I've also looked at pydoc module, but I'm not sure what to do with it: `doc` function has only a brief docstring, it's not mentioned in docs at all. Should it really be in pydoc.__all__?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23883>
_______________________________________

From report at bugs.python.org  Tue May 24 17:01:49 2016
From: report at bugs.python.org (Campbell Barton)
Date: Tue, 24 May 2016 21:01:49 +0000
Subject: [issue27096] Ability to get random bytes from random.Random (as with
 os.urandom)
In-Reply-To: <1464043046.76.0.140037772611.issue27096@psf.upfronthosting.co.za>
Message-ID: <1464123709.76.0.67061687623.issue27096@psf.upfronthosting.co.za>


Campbell Barton added the comment:

@serhiy.storchaka, while a properly working function that uses getrandbits isn't so complex, its not trivial either.

It needs to create smaller chunks and join them (also check zero size case which raises an error if passed).

eg:

```
    def urandom_from_random(rng, length):
        if length == 0:
            return b''
    
        import sys
        chunk_size = 65535
        chunks = []
        while length >= chunk_size:
            chunks.append(rng.getrandbits(chunk_size * 8).to_bytes(chunk_size, sys.byteorder))
            length -= chunk_size
        if length:
            chunks.append(rng.getrandbits(length * 8).to_bytes(length, sys.byteorder))
        result = b''.join(chunks)
        return result
```

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27096>
_______________________________________

From report at bugs.python.org  Tue May 24 17:19:49 2016
From: report at bugs.python.org (Demur Rumed)
Date: Tue, 24 May 2016 21:19:49 +0000
Subject: [issue27097] ceval: Wordcode follow up, explicit unsigned short read
In-Reply-To: <1464048499.12.0.811410474415.issue27097@psf.upfronthosting.co.za>
Message-ID: <1464124788.97.0.846150269982.issue27097@psf.upfronthosting.co.za>


Demur Rumed added the comment:

There is no strict aliasing issues because aliasing is explicitly allowed for char buffers. The only issue is unaligned memory reads, but allocations are well aligned, so there'd have to be explicit work to allocate & then put code at an uneven offset. CPython never does this. This leaves the only issue being if a jump has an uneven jump offset. But jumping into the middle of an instruction is already undefined behavior because if I jump into a byte that happens to be BINARY_ADD on an empty stack it's undefined behavior. Jumping into the middle of an instruction thus falls under "Undefined behavior due to invalid bytecode"

tl;dr There is no undefined behavior given correct bytecode layout, & we already have undefined behavior given incorrect bytecode layout. PREDICT concerns may be valid; the solution there may be to have a PEEKOPARG which we can then check the short value before splitting it if the opcode portion matches

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27097>
_______________________________________

From report at bugs.python.org  Tue May 24 17:19:58 2016
From: report at bugs.python.org (=?utf-8?q?Jacek_Ko=C5=82odziej?=)
Date: Tue, 24 May 2016 21:19:58 +0000
Subject: [issue27107] mailbox.__all__ list is incomplete
In-Reply-To: <1464121814.28.0.86378219066.issue27107@psf.upfronthosting.co.za>
Message-ID: <1464124798.56.0.387978247259.issue27107@psf.upfronthosting.co.za>


Jacek Ko?odziej added the comment:

David, what do you mean by "new format"? Can you point me to some existing code?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27107>
_______________________________________

From report at bugs.python.org  Tue May 24 17:32:47 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 24 May 2016 21:32:47 +0000
Subject: [issue27107] mailbox.__all__ list is incomplete
In-Reply-To: <1464121814.28.0.86378219066.issue27107@psf.upfronthosting.co.za>
Message-ID: <1464125567.59.0.44533338693.issue27107@psf.upfronthosting.co.za>


R. David Murray added the comment:

Look at your mimetypes patch, for example.   That if __name__='__main__' clause is all that is needed.  The test_main stuff can be dropped.

The question, I suppose, is the reap_children call, and that may be why it hasn't been converted yet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27107>
_______________________________________

From report at bugs.python.org  Tue May 24 17:36:30 2016
From: report at bugs.python.org (Dave Sawyer)
Date: Tue, 24 May 2016 21:36:30 +0000
Subject: [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 17:37:39 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 May 2016 21:37:39 +0000
Subject: [issue27097] ceval: Wordcode follow up, explicit unsigned short read
In-Reply-To: <1464048499.12.0.811410474415.issue27097@psf.upfronthosting.co.za>
Message-ID: <1464125858.99.0.000574000770729.issue27097@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> I'm pretty sure this is undefined behavior.

Are you talking about the exact C implementation, or the risk of unaligned memory accesses?

I suggest to add an assertion to ensure that the pointer is aligned to 16-bits.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27097>
_______________________________________

From report at bugs.python.org  Tue May 24 17:38:24 2016
From: report at bugs.python.org (Dave Sawyer)
Date: Tue, 24 May 2016 21:38:24 +0000
Subject: [issue27113] sqlite3 connect parameter "check_same_thread" not
 documented
In-Reply-To: <1464125789.84.0.570004715823.issue27113@psf.upfronthosting.co.za>
Message-ID: <1464125904.82.0.946318749807.issue27113@psf.upfronthosting.co.za>


Changes by Dave Sawyer <kingsawyer at gmail.com>:


----------
title: sqlite3 open parameter "check_same_thread" not documented -> sqlite3 connect parameter "check_same_thread" not documented

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27113>
_______________________________________

From report at bugs.python.org  Tue May 24 17:38:40 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 24 May 2016 21:38:40 +0000
Subject: [issue27097] ceval: Wordcode follow up, explicit unsigned short read
In-Reply-To: <1464048499.12.0.811410474415.issue27097@psf.upfronthosting.co.za>
Message-ID: <1464125920.46.0.0215216529016.issue27097@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> +#define NEXTOPARG()     (oparg = *(unsigned short*)next_instr, opcode = OPOF(oparg), oparg = ARGOF(oparg), next_instr += 2)

I dislike this approach. I would prefer to use the unsigned short* type for next_instr, and put an assertion when next_instr is first assigned.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27097>
_______________________________________

From report at bugs.python.org  Tue May 24 17:53:05 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 24 May 2016 21:53:05 +0000
Subject: [issue27110] smtpd.__all__ list is incomplete
In-Reply-To: <1464122880.35.0.109246499929.issue27110@psf.upfronthosting.co.za>
Message-ID: <20160524175302.0776c117@subdivisions.wooz.org>


Barry A. Warsaw added the comment:

On May 24, 2016, at 08:48 PM, R. David Murray wrote:

>Maybe we should blacklist MailmanProxy?  I think we are planning to deprecate
>it but just haven't yet done the work.  Looks fine otherwise.

It's probably not used much TBH.  aiosmtpd has a generic Proxy class.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27110>
_______________________________________

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: [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 18:30:39 2016
From: report at bugs.python.org (Steve Dower)
Date: Tue, 24 May 2016 22:30:39 +0000
Subject: [issue27114] SSLContext._load_windows_store_certs fails with
 PermissionError
In-Reply-To: <1464128675.76.0.296997884833.issue27114@psf.upfronthosting.co.za>
Message-ID: <1464129039.26.0.387464416946.issue27114@psf.upfronthosting.co.za>


Steve Dower added the comment:

Added a patch against 3.5 that handles PermissionError and warns about the failure.

I think this should be applied against 2.7, 3.5 and 3.6, and that it's unfortunately untestable (without adding extra API to force it to fail). Any concerns?

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file42979/27114_1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27114>
_______________________________________

From report at bugs.python.org  Tue May 24 18:43:27 2016
From: report at bugs.python.org (Roundup Robot)
Date: Tue, 24 May 2016 22:43:27 +0000
Subject: [issue23026] Winreg module doesn't support REG_QWORD,
 small DWORD doc update
In-Reply-To: <1418242433.97.0.849861872047.issue23026@psf.upfronthosting.co.za>
Message-ID: <20160524224323.637.94223.C0FA8767@psf.io>


Roundup Robot added the comment:

New changeset ac2a2534f793 by Steve Dower in branch 'default':
Issue #23026: winreg.QueryValueEx() now return an integer for REG_QWORD type. (Patch by hakril)
https://hg.python.org/cpython/rev/ac2a2534f793

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23026>
_______________________________________

From report at bugs.python.org  Tue May 24 18:44:11 2016
From: report at bugs.python.org (Steve Dower)
Date: Tue, 24 May 2016 22:44:11 +0000
Subject: [issue23026] Winreg module doesn't support REG_QWORD,
 small DWORD doc update
In-Reply-To: <1418242433.97.0.849861872047.issue23026@psf.upfronthosting.co.za>
Message-ID: <1464129851.94.0.118945195031.issue23026@psf.upfronthosting.co.za>


Steve Dower added the comment:

I'd appreciate at least one other person looking over my commit before I close this, just to confirm that the notes I added to the docs are fine.

----------
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23026>
_______________________________________

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: [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 19:44:15 2016
From: report at bugs.python.org (Demur Rumed)
Date: Tue, 24 May 2016 23:44:15 +0000
Subject: [issue27097] ceval: Wordcode follow up, explicit unsigned short read
In-Reply-To: <1464048499.12.0.811410474415.issue27097@psf.upfronthosting.co.za>
Message-ID: <1464133455.46.0.788626211033.issue27097@psf.upfronthosting.co.za>


Demur Rumed added the comment:

There's some difficulty in changing next_instr to an unsigned short* unless pointer arithmetic converts it back to unsigned char*. Code relies on f_lasti to be a byte index more than it relies on f_lasti to be -1 at first. Should this change include converting jump offsets to word increments? This patch seeks to be a minimal change to achieve the desired aligned/batched memory read behavior of NEXTOP/NEXTARG. Perhaps a clear description of how deep the changes should be is in order

It's also a bit hard to assert pointer alignment without failling back to stdint's uintptr_t. It may be sufficient to assert f_lasti is an even number

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27097>
_______________________________________

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: [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 22:36:27 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 25 May 2016 02:36:27 +0000
Subject: [issue27116] Documentation for regular expression alphanumeric
 matching are swapped.
 https://docs.python.org/2/library/re.html#regular-expression-syntax
In-Reply-To: <1464143092.14.0.677352167387.issue27116@psf.upfronthosting.co.za>
Message-ID: <1464143787.0.0.765884564204.issue27116@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

I don't think no need to swap. The current doc is right.

>>> re.findall(r'\W+', 'abcd123_#@@@@')
['#@@@@']
>>> re.findall(r'\w+', 'abcd123_#@@@@')
['abcd123_']

It's apparent that \w match alphanumeric and \W vice versa.

----------
nosy: +xiang.zhang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27116>
_______________________________________

From report at bugs.python.org  Tue May 24 22:41:23 2016
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 25 May 2016 02:41:23 +0000
Subject: [issue27116] Documentation for regular expression alphanumeric
 matching are swapped.
 https://docs.python.org/2/library/re.html#regular-expression-syntax
In-Reply-To: <1464143092.14.0.677352167387.issue27116@psf.upfronthosting.co.za>
Message-ID: <1464144083.21.0.94929732142.issue27116@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
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: [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  Tue May 24 23:45:06 2016
From: report at bugs.python.org (Luiz Poleto)
Date: Wed, 25 May 2016 03:45:06 +0000
Subject: [issue26306] Can't create abstract tuple
In-Reply-To: <1454934113.76.0.551150355835.issue26306@psf.upfronthosting.co.za>
Message-ID: <1464147906.55.0.904810921272.issue26306@psf.upfronthosting.co.za>


Luiz Poleto added the comment:

Same as reported on issue #5996. Apparently this happens not only with tuple but with any builtin type.

There is a patch on that issue but there hasn't been any activity since 2011.

----------
nosy: +luiz.poleto

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26306>
_______________________________________

From report at bugs.python.org  Tue May 24 23:49:34 2016
From: report at bugs.python.org (Luiz Poleto)
Date: Wed, 25 May 2016 03:49:34 +0000
Subject: [issue24235] ABCs don't fail metaclass instantiation
In-Reply-To: <1431985736.79.0.831498694265.issue24235@psf.upfronthosting.co.za>
Message-ID: <1464148174.43.0.612200272241.issue24235@psf.upfronthosting.co.za>


Luiz Poleto added the comment:

This seems to be related to issues #5996 and #26306.

----------
nosy: +luiz.poleto

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24235>
_______________________________________

From report at bugs.python.org  Tue May 24 23:51:01 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 May 2016 03:51:01 +0000
Subject: [issue27097] ceval: Wordcode follow up, explicit unsigned short read
In-Reply-To: <1464048499.12.0.811410474415.issue27097@psf.upfronthosting.co.za>
Message-ID: <1464148261.37.0.00881081381871.issue27097@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Hmm, don't know why my patch was not uploaded first time. It contained exactly what Victor said. Yes, we need to multiply or divide by 2 when convert from pointer difference to byte offset, but this doesn't affect performance. I think the next step is the change of the meaning of jump offsets and instruction numbers.

----------
Added file: http://bugs.python.org/file42980/ushort2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27097>
_______________________________________

From report at bugs.python.org  Tue May 24 23:51:21 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 May 2016 03:51:21 +0000
Subject: [issue27117] turtledemo does not work with IDLE's new dark theme.
In-Reply-To: <1464145339.77.0.706051446081.issue27117@psf.upfronthosting.co.za>
Message-ID: <1464148281.4.0.433543334609.issue27117@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27117>
_______________________________________

From report at bugs.python.org  Tue May 24 23:55:07 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 May 2016 03:55:07 +0000
Subject: [issue27111] redundant variables in long_add and long_sub
In-Reply-To: <1464122604.65.0.69831533642.issue27111@psf.upfronthosting.co.za>
Message-ID: <1464148507.77.0.820448071759.issue27111@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +serhiy.storchaka
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27111>
_______________________________________

From report at bugs.python.org  Tue May 24 23:58:45 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 May 2016 03:58:45 +0000
Subject: [issue27107] mailbox.__all__ list is incomplete
In-Reply-To: <1464121814.28.0.86378219066.issue27107@psf.upfronthosting.co.za>
Message-ID: <1464148725.95.0.647398356935.issue27107@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Yes, the reap_children call is the culprit. I think resolving this problem is out of the scope of this simple issue (there is separate issue for this).

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27107>
_______________________________________

From report at bugs.python.org  Wed May 25 00:01:08 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 May 2016 04:01:08 +0000
Subject: [issue27109] plistlib.__all__ list is incomplete
In-Reply-To: <1464121972.25.0.312623599868.issue27109@psf.upfronthosting.co.za>
Message-ID: <1464148868.75.0.891987090719.issue27109@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27109>
_______________________________________

From report at bugs.python.org  Wed May 25 00:05:55 2016
From: report at bugs.python.org (Petr Ovtchenkov)
Date: Wed, 25 May 2016 04:05:55 +0000
Subject: [issue27101] Compilation of python (modules) for foreign target
 platform problem.
In-Reply-To: <1464066887.71.0.116030526807.issue27101@psf.upfronthosting.co.za>
Message-ID: <1464149155.67.0.598257926244.issue27101@psf.upfronthosting.co.za>


Changes by Petr Ovtchenkov <abominable-snowman at yandex.ru>:


Removed 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  Wed May 25 00:08:04 2016
From: report at bugs.python.org (Petr Ovtchenkov)
Date: Wed, 25 May 2016 04:08:04 +0000
Subject: [issue27101] Compilation of python (modules) for foreign target
 platform problem.
In-Reply-To: <1464066887.71.0.116030526807.issue27101@psf.upfronthosting.co.za>
Message-ID: <1464149284.45.0.325052904856.issue27101@psf.upfronthosting.co.za>


Petr Ovtchenkov added the comment:

for 3.5 branch

----------
Added file: http://bugs.python.org/file42981/0001-Compilation-modules-for-foreign-target-platform.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27101>
_______________________________________

From report at bugs.python.org  Wed May 25 00:09:12 2016
From: report at bugs.python.org (Petr Ovtchenkov)
Date: Wed, 25 May 2016 04:09:12 +0000
Subject: [issue27101] Compilation of python (modules) for foreign target
 platform problem.
In-Reply-To: <1464066887.71.0.116030526807.issue27101@psf.upfronthosting.co.za>
Message-ID: <1464149352.82.0.589651156574.issue27101@psf.upfronthosting.co.za>


Petr Ovtchenkov added the comment:

for 3.5 branch

----------
Added file: http://bugs.python.org/file42982/0002-Compilation-ssl-module-for-foreign-target-platform.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27101>
_______________________________________

From report at bugs.python.org  Wed May 25 00:12:48 2016
From: report at bugs.python.org (Petr Ovtchenkov)
Date: Wed, 25 May 2016 04:12:48 +0000
Subject: [issue27101] Compilation of python (modules) for foreign target
 platform problem.
In-Reply-To: <1464066887.71.0.116030526807.issue27101@psf.upfronthosting.co.za>
Message-ID: <1464149568.22.0.641623733724.issue27101@psf.upfronthosting.co.za>


Petr Ovtchenkov added the comment:

for 2.7 branch

----------
versions: +Python 2.7
Added file: http://bugs.python.org/file42983/0001-Compilation-modules-for-foreign-target-platform.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27101>
_______________________________________

From report at bugs.python.org  Wed May 25 00:13:33 2016
From: report at bugs.python.org (Petr Ovtchenkov)
Date: Wed, 25 May 2016 04:13:33 +0000
Subject: [issue27101] Compilation of python (modules) for foreign target
 platform problem.
In-Reply-To: <1464066887.71.0.116030526807.issue27101@psf.upfronthosting.co.za>
Message-ID: <1464149613.58.0.915940674491.issue27101@psf.upfronthosting.co.za>


Petr Ovtchenkov added the comment:

for 2.7 branch

----------
Added file: http://bugs.python.org/file42984/0002-Compilation-ssl-module-for-foreign-target-platform.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27101>
_______________________________________

From report at bugs.python.org  Wed May 25 00:18:49 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 May 2016 04:18:49 +0000
Subject: [issue27083] PYTHONCASEOK is ignored on Windows
In-Reply-To: <1463899532.05.0.0164205622545.issue27083@psf.upfronthosting.co.za>
Message-ID: <1464149929.31.0.303962315418.issue27083@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Did you forgot to upload a patch?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27083>
_______________________________________

From report at bugs.python.org  Wed May 25 01:38:23 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 May 2016 05:38:23 +0000
Subject: [issue27105] cgi.__all__ is incomplete
In-Reply-To: <1464121575.73.0.75569808483.issue27105@psf.upfronthosting.co.za>
Message-ID: <1464154703.19.0.163690060426.issue27105@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I don't think test() should be exposed as public API.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27105>
_______________________________________

From report at bugs.python.org  Wed May 25 01:46:06 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 May 2016 05:46:06 +0000
Subject: [issue27112] tokenize.__all__ list is incomplete
In-Reply-To: <1464123395.58.0.823594635343.issue27112@psf.upfronthosting.co.za>
Message-ID: <1464155166.32.0.542159340015.issue27112@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The blacklist is too long. I think it would be better to use white list.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27112>
_______________________________________

From report at bugs.python.org  Wed May 25 01:52:22 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 May 2016 05:52:22 +0000
Subject: [issue27106] configparser.__all__ is incomplete
In-Reply-To: <1464121705.13.0.123221989673.issue27106@psf.upfronthosting.co.za>
Message-ID: <1464155542.51.0.427163927209.issue27106@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27106>
_______________________________________

From report at bugs.python.org  Wed May 25 02:01:24 2016
From: report at bugs.python.org (Antti Haapala)
Date: Wed, 25 May 2016 06:01:24 +0000
Subject: [issue27097] ceval: Wordcode follow up, explicit unsigned short read
In-Reply-To: <1464048499.12.0.811410474415.issue27097@psf.upfronthosting.co.za>
Message-ID: <1464156084.93.0.875459302492.issue27097@psf.upfronthosting.co.za>


Antti Haapala added the comment:

Casting the pointer is OK, explicitly typing the pointer is even better; then the arithmetic is even clearer and it is easy to add offsets in words!

However what I'd prefer here as the size of the type is important, to use `uint16_t` or typedef instead of just `unsigned short`, which is a statemeent that the value must be at least "2 bytes wide".

----------
nosy: +ztane

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27097>
_______________________________________

From report at bugs.python.org  Wed May 25 02:10:40 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 May 2016 06:10:40 +0000
Subject: [issue27097] ceval: Wordcode follow up, explicit unsigned short read
In-Reply-To: <1464048499.12.0.811410474415.issue27097@psf.upfronthosting.co.za>
Message-ID: <1464156640.79.0.744253384991.issue27097@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This is separate issue (see issue17884).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27097>
_______________________________________

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: [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:13:12 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 25 May 2016 06:13:12 +0000
Subject: [issue27118] Several Py_XDECREFs in typeobject.c are not necessary
In-Reply-To: <1464156760.73.0.28265991298.issue27118@psf.upfronthosting.co.za>
Message-ID: <1464156792.01.0.982701489702.issue27118@psf.upfronthosting.co.za>


Changes by Xiang Zhang <angwerzx at 126.com>:


----------
title: Several Py_XDECREFs are not necessary -> Several Py_XDECREFs in typeobject.c are not necessary
type:  -> enhancement
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27118>
_______________________________________

From report at bugs.python.org  Wed May 25 02:14:39 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 25 May 2016 06:14:39 +0000
Subject: [issue27118] Several Py_XDE/INCREFs in typeobject.c are not necessary
In-Reply-To: <1464156760.73.0.28265991298.issue27118@psf.upfronthosting.co.za>
Message-ID: <1464156879.88.0.128261107918.issue27118@psf.upfronthosting.co.za>


Changes by Xiang Zhang <angwerzx at 126.com>:


----------
title: Several Py_XDECREFs in typeobject.c are not necessary -> Several Py_XDE/INCREFs in typeobject.c are not necessary

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27118>
_______________________________________

From report at bugs.python.org  Wed May 25 02:17:21 2016
From: report at bugs.python.org (=?utf-8?q?Jacek_Ko=C5=82odziej?=)
Date: Wed, 25 May 2016 06:17:21 +0000
Subject: [issue27105] cgi.__all__ is incomplete
In-Reply-To: <1464121575.73.0.75569808483.issue27105@psf.upfronthosting.co.za>
Message-ID: <1464157041.65.0.160180631954.issue27105@psf.upfronthosting.co.za>


Jacek Ko?odziej added the comment:

Well, but it is documented in public docs:

    cgi.test()

    Robust test CGI script, usable as main program. Writes minimal HTTP headers and formats all information provided to the script in HTML form.


Should I remove it from __all__ and probably from the docs, too?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27105>
_______________________________________

From report at bugs.python.org  Wed May 25 02:27:54 2016
From: report at bugs.python.org (=?utf-8?q?Jacek_Ko=C5=82odziej?=)
Date: Wed, 25 May 2016 06:27:54 +0000
Subject: [issue27112] tokenize.__all__ list is incomplete
In-Reply-To: <1464123395.58.0.823594635343.issue27112@psf.upfronthosting.co.za>
Message-ID: <1464157674.16.0.824544511094.issue27112@psf.upfronthosting.co.za>


Jacek Ko?odziej added the comment:

I disagree:
* blacklist has 48 entries now, whitelist would have 72 ones
* whitelisting requires adding new public names to two places instead of one
* test.support.check__all__ currently don't support whitelisting, it would need to be added

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27112>
_______________________________________

From report at bugs.python.org  Wed May 25 02:30:24 2016
From: report at bugs.python.org (SilentGhost)
Date: Wed, 25 May 2016 06:30:24 +0000
Subject: [issue27118] Several Py_XDE/INCREFs in typeobject.c are not necessary
In-Reply-To: <1464156760.73.0.28265991298.issue27118@psf.upfronthosting.co.za>
Message-ID: <1464157824.29.0.0208556410445.issue27118@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
components: +Interpreter Core
nosy: +serhiy.storchaka
stage:  -> patch review
type: enhancement -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27118>
_______________________________________

From report at bugs.python.org  Wed May 25 02:39:22 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 May 2016 06:39:22 +0000
Subject: [issue27118] Several Py_XDE/INCREFs in typeobject.c are not necessary
In-Reply-To: <1464156760.73.0.28265991298.issue27118@psf.upfronthosting.co.za>
Message-ID: <1464158362.22.0.223707975031.issue27118@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM.

----------
stage: patch review -> commit review
type: behavior -> enhancement

_______________________________________
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: [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 02:44:08 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 May 2016 06:44:08 +0000
Subject: [issue27112] tokenize.__all__ list is incomplete
In-Reply-To: <1464123395.58.0.823594635343.issue27112@psf.upfronthosting.co.za>
Message-ID: <1464158648.6.0.156009118533.issue27112@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

* White list consists mostly from token.__all__.
* All names in black list are implementation details. Names in white list are stable and already repeated in docs.
* test.support.check__all__ shouldn't be used in this case. See other tests for public API that doesn't use it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27112>
_______________________________________

From report at bugs.python.org  Wed May 25 02:56:10 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 May 2016 06:56:10 +0000
Subject: [issue27097] ceval: Wordcode follow up, explicit unsigned short read
In-Reply-To: <1464048499.12.0.811410474415.issue27097@psf.upfronthosting.co.za>
Message-ID: <1464159370.28.0.727497707889.issue27097@psf.upfronthosting.co.za>


STINNER Victor added the comment:

ushort2.patch LGTM, but I added many small comments on the review ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27097>
_______________________________________

From report at bugs.python.org  Wed May 25 02:58:51 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 May 2016 06:58:51 +0000
Subject: [issue27097] ceval: Wordcode follow up, explicit unsigned short read
In-Reply-To: <1464048499.12.0.811410474415.issue27097@psf.upfronthosting.co.za>
Message-ID: <1464159531.85.0.506897340622.issue27097@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Antti Haapala:
> However what I'd prefer here as the size of the type is important, to use `uint16_t` or typedef instead of just `unsigned short`, which is a statemeent that the value must be at least "2 bytes wide".

I'm not aware of a platform where sizeof(unsigned short) is not *exactly* 16-bits. At least, no platform supported by CPython.

Include/unicodeobject.h is quite explicit:

#if SIZEOF_SHORT == 2
typedef unsigned short Py_UCS2;
#else
#error "Could not find a proper typedef for Py_UCS2"
#endif

Maybe we should use a similar code in ceval.c?

#if SIZEOF_SHORT != 2
#  error "Could not find a proper type for 16-bit pointer"
#endif

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27097>
_______________________________________

From report at bugs.python.org  Wed May 25 03:01:32 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 May 2016 07:01:32 +0000
Subject: [issue27097] ceval: Wordcode follow up, explicit unsigned short read
In-Reply-To: <1464048499.12.0.811410474415.issue27097@psf.upfronthosting.co.za>
Message-ID: <1464159692.43.0.255007199107.issue27097@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Demur: "This patch [ ushort.patch ] seeks to be a minimal change to achieve the desired aligned/batched memory read behavior of NEXTOP/NEXTARG."

We are concerned by undefined behaviours in CPython for portability reasons. Using a "unsigned short*" pointer avoids the undefined behaviour.

I'm talking about unsigned char* => unsigned short* conversion followed by a dereference:

+#define NEXTOPARG()     (oparg = *(unsigned short*)next_instr, opcode = OPOF(oparg), oparg = ARGOF(oparg), next_instr += 2)

With ushort2.patch, the risk is reduced at once place which is now "protected" by an assertion:

+    assert(_Py_IS_ALIGNED(PyBytes_AS_STRING(co->co_code), unsigned short));
+    first_instr = (unsigned short*) PyBytes_AS_STRING(co->co_code);

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27097>
_______________________________________

From report at bugs.python.org  Wed May 25 03:23:20 2016
From: report at bugs.python.org (lorenzogotuned)
Date: Wed, 25 May 2016 07:23:20 +0000
Subject: [issue27051] Create PIP gui
In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za>
Message-ID: <1464161000.68.0.451256976529.issue27051@psf.upfronthosting.co.za>


lorenzogotuned added the comment:

@Terry: Fine, we can do it.

@Upendra: All the checks you mentioned have to be performed at start-up, so create a script that returns a configuration object for the UI. I think you can try to build a first easy view in which a package is selected (an input form when you can type a package name, with two buttons: 'search', 'install'); when a button is pushed, an the event is generated as Terry suggested.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27051>
_______________________________________

From report at bugs.python.org  Wed May 25 03:40:51 2016
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 25 May 2016 07:40:51 +0000
Subject: [issue23026] Winreg module doesn't support REG_QWORD,
 small DWORD doc update
In-Reply-To: <1418242433.97.0.849861872047.issue23026@psf.upfronthosting.co.za>
Message-ID: <1464162051.65.0.764955612586.issue23026@psf.upfronthosting.co.za>


Eryk Sun added the comment:

In Py2Reg, `(*retDataBuf==NULL)` needs spaces around the == operator.

Should the changes to the winreg docs be noted as new in 3.6? 

Bikeshedding: in "What's New" you mention the change to QueryValueEx, but Reg2Py and Py2Reg affect EnumValue, QueryValueEx, and SetValueEx. Maybe change it to a more general description, like this:

    winreg
    ------

    Added the 64-bit integer type :data:`REG_QWORD <winreg.REG_QWORD>`.
    (Contributed by Clement Rouault in :issue:`23026`.)

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23026>
_______________________________________

From report at bugs.python.org  Wed May 25 03:43:02 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 25 May 2016 07:43:02 +0000
Subject: [issue16182] readline: Wrong tab completion scope indices in Unicode
 terminals
In-Reply-To: <1349813384.06.0.615857426211.issue16182@psf.upfronthosting.co.za>
Message-ID: <1464162182.27.0.163744997738.issue16182@psf.upfronthosting.co.za>


Martin Panter added the comment:

I?m a bit worried about flex_complete() covering up errors. If I add calls to PyErr_WriteUnraisable(), I can see both the s1 and s2 decodes failing. Input the following line:

>>> "?"; import x;

and then move the cursor back one place, so it is directly after the ?x?, but not after the semicolon (;). Then press Tab. Both errors are:

ValueError: embedded null byte

It looks like the reason is that PyUnicode_DecodeLocaleAndSize() requires that str[len] is a null character (the error message is misleading). It seems the len parameter is mainly there to verify that there are no embedded null characters, i.e. you cannot use it to give a truncated string.

It looks like Py_DecodeLocale() is used underneath; maybe it is simpler to call that directly. But it does not solve the string truncating problem.

A test case (perhaps using a pseudo-terminal) might also help pick this kind of thing up, if we can?t report errors any other way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16182>
_______________________________________

From report at bugs.python.org  Wed May 25 03:56:17 2016
From: report at bugs.python.org (Franklin? Lee)
Date: Wed, 25 May 2016 07:56:17 +0000
Subject: [issue26632] __all__ decorator
In-Reply-To: <1458786797.31.0.0749407715279.issue26632@psf.upfronthosting.co.za>
Message-ID: <1464162977.24.0.437491590252.issue26632@psf.upfronthosting.co.za>


Franklin? Lee added the comment:

>>If @public were only to be used as a decorator, it would not be possible to
>>have `public` called on a function outside of its definition. But someone
>>might call `public(some_decorator(some_function))`.
>
>Do you mean, they'd call this is some module other than the one some_function
>was defined in?  I don't know that this is a use case we even want to support.

I mean they'd define their own function as a wrapped version of another function.


>That's true in a sense.  It doesn't change the decorated thing at all.  I
>think it's important to keep in mind that @public isn't the only way to add to
>__all__.

I mean more in that it acts in the scope of its caller, rather than its definition.


>You should get something like:
>
>AttributeError: 'tuple' object has no attribute 'append'
>
>which seems pretty obvious.

I don't think the C version shows a traceback, so it won't be clear that you're trying to assign to `__all__`.

When I rewrote `public` from memory, I wrote it something like this:
        try:
            dunder_all.append(name)
        except TypeError:
            module.__all__ = [*dunder_all, name]


>Well, consenting adults and all.  I'm not sure we need to protect ourselves so
>strictly against people who don't read the docs and don't understand Python
>(i.e. random cargo-culters).

Python is a popular learning language, and many will be students who haven't yet trained to reflexively look up docs. I saw the lack of such habits in Python's IRC channel.

"Consenting adults", I feel, is a reason to grant power: don't stop people from doing something they might need to do. But @public on a class method is just an error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26632>
_______________________________________

From report at bugs.python.org  Wed May 25 04:03:01 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 25 May 2016 08:03:01 +0000
Subject: [issue25419] Readline completion of module names in import statements
In-Reply-To: <1444994208.15.0.362897114106.issue25419@psf.upfronthosting.co.za>
Message-ID: <1464163381.93.0.904697039808.issue25419@psf.upfronthosting.co.za>


Martin Panter added the comment:

I moved all the calls targetting the readline module into a ReadlineCompleter subclass. However the logic for parsing ?import? statements still exists in the base Completer class in private methods. An overview of the two classes:

class Completer:
    def complete(self, text, state):
        self._get_matches(text)
    def _get_matches(text):
        # Only completes global and object.attr names, like before
    def _code_matches(self, code, ...):
        # Completes import statements, otherwise returns (None, ...)

class ReadlineCompleter(Completer):  # New public class
    def complete(self, text, state):
        # Moved Yury?s Tab insertion logic here
        return super().complete(...)
    def _get_matches(text):
        code = readline.get_line_buffer()[:readline.get_endidx()]
        self._code_matches(code)
        super()._get_matches(text)  # Fallback to existing behaviour

Perhaps the _code_matches() and related methods could be turned into more general public APIs, e.g. complete_code(code) -> list of modules, attributes, globals, etc. But that would affect global_matches() and attr_matches(), which I have not touched so far.

Other changes:
* Limit underscore-prefixed completions, consistent with Issue 25011; see new _filter_identifiers() method
* Changed the demo in the documentation; attributes like __doc__ are omitted by default
* Removed workaround for non-ASCII input in favour of fixing Issue 16182

----------
dependencies: +readline: Wrong tab completion scope indices in Unicode terminals
Added file: http://bugs.python.org/file42986/complete-import.v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25419>
_______________________________________

From report at bugs.python.org  Wed May 25 04:13:01 2016
From: report at bugs.python.org (Eryk Sun)
Date: Wed, 25 May 2016 08:13:01 +0000
Subject: [issue27119] `compile` doesn't compile into an AST object as specified
In-Reply-To: <1464158567.97.0.0204496298527.issue27119@psf.upfronthosting.co.za>
Message-ID: <1464163981.13.0.194675480737.issue27119@psf.upfronthosting.co.za>


Eryk Sun added the comment:

What you're looking for is in the 2nd paragraph of the ast docs:

    An abstract syntax tree can be generated by passing
    ast.PyCF_ONLY_AST as a flag to the compile() built-in
    function, or using the parse() helper provided in this
    module. The result will be a tree of objects whose
    classes all inherit from ast.AST. An abstract syntax
    tree can be compiled into a Python code object using
    the built-in compile() function.

For example:

    >>> mod = compile('42', '', 'exec', ast.PyCF_ONLY_AST)
    >>> mod
    <_ast.Module object at 0x7f0e45b15be0
    >>> ast.dump(mod)
    'Module(body=[Expr(value=Num(n=42))])'

In the discussion of `flags`, I think the compile docs should explicitly list ast.PyCF_ONLY_AST and the CO_FUTURE_* flags in a table.

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27119>
_______________________________________

From report at bugs.python.org  Wed May 25 04:46:44 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 25 May 2016 08:46:44 +0000
Subject: [issue27021] It is not documented that os.writev() suffer from
 SC_IOV_MAX
In-Reply-To: <1463247246.11.0.121733863987.issue27021@psf.upfronthosting.co.za>
Message-ID: <1464166004.89.0.703594865603.issue27021@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
versions:  -Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27021>
_______________________________________

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: [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 05:10:35 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 25 May 2016 09:10:35 +0000
Subject: [issue27108] mimetypes.__all__ list is incomplete
In-Reply-To: <1464121896.07.0.577561794509.issue27108@psf.upfronthosting.co.za>
Message-ID: <1464167435.37.0.881839555199.issue27108@psf.upfronthosting.co.za>


Martin Panter added the comment:

I left a comment about the empty blacklist. Other than removing the blacklist parameter, I think this is good to go.

----------
nosy: +martin.panter
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27108>
_______________________________________

From report at bugs.python.org  Wed May 25 05:11:46 2016
From: report at bugs.python.org (Franklin? Lee)
Date: Wed, 25 May 2016 09:11:46 +0000
Subject: [issue27119] `compile` doesn't compile into an AST object as specified
In-Reply-To: <1464158567.97.0.0204496298527.issue27119@psf.upfronthosting.co.za>
Message-ID: <1464167506.8.0.958720098297.issue27119@psf.upfronthosting.co.za>


Franklin? Lee added the comment:

> What you're looking for is in the 2nd paragraph of the ast docs:

Oh. I considered that, but then compile's docs say:

    The optional arguments flags and dont_inherit
    control which future statements (see PEP 236)
    affect the compilation of source.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27119>
_______________________________________

From report at bugs.python.org  Wed May 25 05:17:12 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 25 May 2016 09:17:12 +0000
Subject: [issue27107] mailbox.__all__ list is incomplete
In-Reply-To: <1464121814.28.0.86378219066.issue27107@psf.upfronthosting.co.za>
Message-ID: <1464167832.43.0.718634686788.issue27107@psf.upfronthosting.co.za>


Martin Panter added the comment:

This patch looks good to me. I agree the reap_children() thing is a separate problem.

----------
nosy: +martin.panter
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27107>
_______________________________________

From report at bugs.python.org  Wed May 25 05:40:54 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 25 May 2016 09:40:54 +0000
Subject: [issue27032] Remove deprecated html.parser.HTMLParser.unescape()
In-Reply-To: <1463339146.08.0.655083281356.issue27032@psf.upfronthosting.co.za>
Message-ID: <1464169254.14.0.144911400798.issue27032@psf.upfronthosting.co.za>


Martin Panter added the comment:

I wonder if removing HTMLParser().unescape() would hurt Python 2 ? 3 compatibility. This was mentioned in Ezio?s draft deprecation policy PEP <https://mail.python.org/pipermail/python-committers/2016-January/003706.html>: ?nothing that is available and not deprecated in 2.7 should be removed from Python 3 as long as 2.7 is officially supported?.

Is there any pressing need to get rid of the method? Maybe just fix the reference to Python 3.5 for the time being.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27032>
_______________________________________

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: [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 06:31:53 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 25 May 2016 10:31:53 +0000
Subject: [issue27110] smtpd.__all__ list is incomplete
In-Reply-To: <1464122507.71.0.719319292765.issue27110@psf.upfronthosting.co.za>
Message-ID: <1464172313.53.0.380323081741.issue27110@psf.upfronthosting.co.za>


Martin Panter added the comment:

MailmanProxy is already included in __all__. Is there any advantage of removing it? Normally things are left in __all__ even when they actually get deprecated, as far as I understand.

The patch looks sensible to me (though I am not very familiar with the module).

----------
nosy: +martin.panter
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27110>
_______________________________________

From report at bugs.python.org  Wed May 25 06:41:30 2016
From: report at bugs.python.org (=?utf-8?q?Jacek_Ko=C5=82odziej?=)
Date: Wed, 25 May 2016 10:41:30 +0000
Subject: [issue27108] mimetypes.__all__ list is incomplete
In-Reply-To: <1464121896.07.0.577561794509.issue27108@psf.upfronthosting.co.za>
Message-ID: <1464172890.13.0.406892013888.issue27108@psf.upfronthosting.co.za>


Jacek Ko?odziej added the comment:

Thank you, Martin. I'm uploading amended patch.

----------
Added file: http://bugs.python.org/file42988/mimetypes_all.v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27108>
_______________________________________

From report at bugs.python.org  Wed May 25 07:19:49 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 25 May 2016 11:19:49 +0000
Subject: [issue27109] plistlib.__all__ list is incomplete
In-Reply-To: <1464121972.25.0.312623599868.issue27109@psf.upfronthosting.co.za>
Message-ID: <1464175189.21.0.727860748104.issue27109@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27109>
_______________________________________

From report at bugs.python.org  Wed May 25 07:26:10 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 25 May 2016 11:26:10 +0000
Subject: [issue27106] configparser.__all__ is incomplete
In-Reply-To: <1464121705.13.0.123221989673.issue27106@psf.upfronthosting.co.za>
Message-ID: <1464175570.8.0.314772648187.issue27106@psf.upfronthosting.co.za>


Martin Panter added the comment:

Looks good to me

----------
nosy: +martin.panter
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27106>
_______________________________________

From report at bugs.python.org  Wed May 25 07:40:08 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 25 May 2016 11:40:08 +0000
Subject: [issue27105] cgi.__all__ is incomplete
In-Reply-To: <1464121575.73.0.75569808483.issue27105@psf.upfronthosting.co.za>
Message-ID: <1464176408.85.0.858149731993.issue27105@psf.upfronthosting.co.za>


Martin Panter added the comment:

I don?t see why test() should be a special case. A few of the other functions seem to be just for debugging and testing too, e.g. print_environ().

Is there any advantage to having the test case in a separate MiscTestCase class, as opposed to the existing CgiTests class?

----------
nosy: +martin.panter
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27105>
_______________________________________

From report at bugs.python.org  Wed May 25 07:47:29 2016
From: report at bugs.python.org (=?utf-8?q?Jacek_Ko=C5=82odziej?=)
Date: Wed, 25 May 2016 11:47:29 +0000
Subject: [issue27105] cgi.__all__ is incomplete
In-Reply-To: <1464121575.73.0.75569808483.issue27105@psf.upfronthosting.co.za>
Message-ID: <1464176849.4.0.00701669200528.issue27105@psf.upfronthosting.co.za>


Jacek Ko?odziej added the comment:

Martin:

> Is there any advantage to having the test case in a separate MiscTestCase class, as opposed to the existing CgiTests class?

Other than "the first test [well, that I know of] for __all__ list was in separate class called MiscTestCase so each next one follows the same fashion" and "sometimes such test would fit into some existing TestCase class and sometimes not, so let's always put it into separate class for cohesion" - no, I don't see any.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27105>
_______________________________________

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: [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 08:00:48 2016
From: report at bugs.python.org (Hugh C. Lauer)
Date: Wed, 25 May 2016 12:00:48 +0000
Subject: [issue27054] Python installation problem: No module named 'encodings'
In-Reply-To: <1463669398.91.0.875145076547.issue27054@psf.upfronthosting.co.za>
Message-ID: <45B64D1540141C4AA0F8F3974D714AEA64D4715C@S197.admin.wpi.edu>


Hugh C. Lauer added the comment:

I am back from my travels.

Thanks very much, Stefan. Running as administrator did the trick for Windows 10 installations. I now have a reliable, repeatable protocol that I can give to students with little computing experience that will enable them to install Python on their Windows 10 laptops.

Hugh Lauer
Worcester Polytechnic Institute

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27054>
_______________________________________

From report at bugs.python.org  Wed May 25 08:04:08 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Wed, 25 May 2016 12:04:08 +0000
Subject: [issue15625] Support u and w codes in memoryview
In-Reply-To: <1344719787.86.0.485615026169.issue15625@psf.upfronthosting.co.za>
Message-ID: <1464177848.51.0.703685694169.issue15625@psf.upfronthosting.co.za>


???? ????????? added the comment:

Trigger the same bug....

I want to effectively slice big unicode string. So I decide to use memoryview for that in order to eliminate memory copying.

In [33]: a = array.array('u', '??????')
In [34]: m = memoryview(a)
In [35]: m[2:]
Out[35]: <memory at 0x7efc98fcc048>
In [36]: m[0]
...
NotImplementedError: memoryview: format w not supported


1. Why format 'w' error if I asked 'u' ?
2. Format 'w' is not listed in https://docs.python.org/3.5/library/array.html
3. What is alternative for fast slicing, like memoryview(bytearray(b'test')), but for unicode ?

----------
nosy: +mmarkk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue15625>
_______________________________________

From report at bugs.python.org  Wed May 25 08:04:52 2016
From: report at bugs.python.org (Hugh C. Lauer)
Date: Wed, 25 May 2016 12:04:52 +0000
Subject: [issue27054] Python installation problem: No module named 'encodings'
In-Reply-To: <1463673364.87.0.464630969517.issue27054@psf.upfronthosting.co.za>
Message-ID: <45B64D1540141C4AA0F8F3974D714AEA64D471D7@S197.admin.wpi.edu>


Hugh C. Lauer added the comment:

I am back from my travels.

Thanks Zachary for this. On Windows 10, no PYTHON or PYTHONHOME environment variable is set. On Windows 7, they are set. Moreover, even though I am installing Python 3.5.1, the refer to C:\Program files\Python34 !

I will continue to experiment with this.

Regards,

Hugh Lauer
Worcester Polytechnic Institute

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27054>
_______________________________________

From report at bugs.python.org  Wed May 25 08:25:33 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 May 2016 12:25:33 +0000
Subject: [issue27105] cgi.__all__ is incomplete
In-Reply-To: <1464121575.73.0.75569808483.issue27105@psf.upfronthosting.co.za>
Message-ID: <1464179133.48.0.0500975747246.issue27105@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

OK. This is unusual name for public function and looks rather as internal function for manual module testing, but since it is documented, we perhaps should add its name to __all__. The patch LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27105>
_______________________________________

From report at bugs.python.org  Wed May 25 08:34:10 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 May 2016 12:34:10 +0000
Subject: [issue27032] Remove deprecated html.parser.HTMLParser.unescape()
In-Reply-To: <1463339146.08.0.655083281356.issue27032@psf.upfronthosting.co.za>
Message-ID: <1464179650.43.0.881588716187.issue27032@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Good point. Maybe the deprecation period of HTMLParser.unescape() should be prolonged.

On other side, this method is not documented, nor in 2.7, nor in 3.x. It is not a part of official API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27032>
_______________________________________

From report at bugs.python.org  Wed May 25 08:36:20 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 May 2016 12:36:20 +0000
Subject: [issue27120] xmllib unable to parse in UTF8 format
In-Reply-To: <1464167373.86.0.726090753957.issue27120@psf.upfronthosting.co.za>
Message-ID: <1464179780.61.0.971041385927.issue27120@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Could you please provide minimal reproducer? Minimal script and minimal data that expose the issue.

----------
nosy: +serhiy.storchaka
stage:  -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27120>
_______________________________________

From report at bugs.python.org  Wed May 25 08:43:04 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 May 2016 12:43:04 +0000
Subject: [issue27118] Several Py_XDE/INCREFs in typeobject.c are not necessary
In-Reply-To: <1464156760.73.0.28265991298.issue27118@psf.upfronthosting.co.za>
Message-ID: <1464180184.11.0.191307860037.issue27118@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
assignee:  -> serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27118>
_______________________________________

From report at bugs.python.org  Wed May 25 09:00:11 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 25 May 2016 13:00:11 +0000
Subject: [issue27112] tokenize.__all__ list is incomplete
In-Reply-To: <1464123395.58.0.823594635343.issue27112@psf.upfronthosting.co.za>
Message-ID: <1464181211.47.0.874663152643.issue27112@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think it might be better to add a separate ?import tokenize as tokenize_module?. Or just ?import tokenize? inside the test function. IMO changing all the names adds too much churn with minimal benefit.

Maybe also should restore the ?from unittest import . . .? line. But keep an ?import unittest? line somewhere so the __main__ bit at the bottom works.

Perhaps it would be good to merge MiscTestCase into the existing TestMisc class.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27112>
_______________________________________

From report at bugs.python.org  Wed May 25 09:01:51 2016
From: report at bugs.python.org (Hugh C. Lauer)
Date: Wed, 25 May 2016 13:01:51 +0000
Subject: [issue27054] Python installation problem: No module named 'encodings'
In-Reply-To: <45B64D1540141C4AA0F8F3974D714AEA64D471D7@S197.admin.wpi.edu>
Message-ID: <45B64D1540141C4AA0F8F3974D714AEA64D47402@S197.admin.wpi.edu>


Hugh C. Lauer added the comment:

All, it seems that installation of Python 3.5.1 on Windows 7 must also be done as administrator. Once I did that, the installation of Python 3.5.1, numpy 1.11.0, and matplotlib 1.5.1 all went seamlessly.

The only environment variable that was changed was to add the Python installation directory to the PATH environment variable.

Regards,

Hugh C. Lauer
Worcester Polytechnic Institute

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27054>
_______________________________________

From report at bugs.python.org  Wed May 25 09:03:00 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 May 2016 13:03:00 +0000
Subject: [issue27118] Several Py_XDE/INCREFs in typeobject.c are not necessary
In-Reply-To: <1464156760.73.0.28265991298.issue27118@psf.upfronthosting.co.za>
Message-ID: <1464181380.84.0.972625708553.issue27118@psf.upfronthosting.co.za>


STINNER Victor added the comment:

LGTM too.

Serhiy, do you want to push the patch?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27118>
_______________________________________

From report at bugs.python.org  Wed May 25 09:10:39 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 May 2016 13:10:39 +0000
Subject: [issue27097] ceval: Wordcode follow up, explicit unsigned short read
In-Reply-To: <1464048499.12.0.811410474415.issue27097@psf.upfronthosting.co.za>
Message-ID: <1464181839.98.0.367624313587.issue27097@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Updated patch addresses Victor's comments.

----------
Added file: http://bugs.python.org/file42990/ushort3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27097>
_______________________________________

From report at bugs.python.org  Wed May 25 09:14:10 2016
From: report at bugs.python.org (Enrico)
Date: Wed, 25 May 2016 13:14:10 +0000
Subject: [issue27120] xmllib unable to parse in UTF8 format
In-Reply-To: <1464167373.86.0.726090753957.issue27120@psf.upfronthosting.co.za>
Message-ID: <1464182050.1.0.0341623192197.issue27120@psf.upfronthosting.co.za>


Enrico added the comment:

I have attached xmllib.py. This file is in python23\lib folder.

The strings in XML file are in cyrillic language.

My code:
import xmllib

class Parser(xmllib.XMLParser):
    # a simple styling engine

    def __init__(self):
        xmllib.XMLParser.__init__(self)
        self.cursupervisore = None
        self.curdata        = ''

        self.elements = {'Superv':(self.starttag_superv, self.endtag_superv)
........
                        }
    def load(self, file):
        while 1:
            s = file.readline()

            if not s:
                break
            self.feed(s)
        self.close()

def read_plant_tree(filexml):
      c = Parser()
      c.load(filexml)

----------
Added file: http://bugs.python.org/file42991/xmllib.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27120>
_______________________________________

From report at bugs.python.org  Wed May 25 09:15:28 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 25 May 2016 13:15:28 +0000
Subject: [issue27118] Several Py_XDE/INCREFs in typeobject.c are not necessary
In-Reply-To: <1464156760.73.0.28265991298.issue27118@psf.upfronthosting.co.za>
Message-ID: <20160525131522.629.20429.10E6D887@psf.io>


Roundup Robot added the comment:

New changeset 3b4c3dda679a by Serhiy Storchaka in branch 'default':
Issue #27118: Clean up Py_XINCREF/Py_XDECREF in typeobject.c.
https://hg.python.org/cpython/rev/3b4c3dda679a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27118>
_______________________________________

From report at bugs.python.org  Wed May 25 09:16:35 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 May 2016 13:16:35 +0000
Subject: [issue27118] Several Py_XDE/INCREFs in typeobject.c are not necessary
In-Reply-To: <1464156760.73.0.28265991298.issue27118@psf.upfronthosting.co.za>
Message-ID: <1464182195.71.0.546725383177.issue27118@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Done. Thank you for your contribution Xiang Zhang.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27118>
_______________________________________

From report at bugs.python.org  Wed May 25 09:16:53 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 25 May 2016 13:16:53 +0000
Subject: [issue23883] __all__ lists are incomplete
In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za>
Message-ID: <1464182213.94.0.849709373586.issue23883@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think pydoc could be left alone. The RST documentation doesn?t say anything about importing any functions from the module that I can see. I was surprised that it even defines __all__ = ["help"]. Perhaps pydoc.doc() was another false indication in Serhiy?s list.

----------
dependencies: +cgi.__all__ is incomplete, configparser.__all__ is incomplete, mailbox.__all__ list is incomplete, mimetypes.__all__ list is incomplete, plistlib.__all__ list is incomplete, smtpd.__all__ list is incomplete, tokenize.__all__ list is incomplete

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23883>
_______________________________________

From report at bugs.python.org  Wed May 25 09:19:21 2016
From: report at bugs.python.org (Andrea De Pasquale)
Date: Wed, 25 May 2016 13:19:21 +0000
Subject: [issue27010] email library could "recover" from bad mime boundary
 like (some?) email clients do
In-Reply-To: <1463067718.45.0.558318505018.issue27010@psf.upfronthosting.co.za>
Message-ID: <1464182361.88.0.659968543066.issue27010@psf.upfronthosting.co.za>


Changes by Andrea De Pasquale <andrea at de-pasquale.name>:


----------
nosy: +adepasquale

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27010>
_______________________________________

From report at bugs.python.org  Wed May 25 09:19:26 2016
From: report at bugs.python.org (R. David Murray)
Date: Wed, 25 May 2016 13:19:26 +0000
Subject: [issue26306] Can't create abstract tuple
In-Reply-To: <1454934113.76.0.551150355835.issue26306@psf.upfronthosting.co.za>
Message-ID: <1464182366.68.0.380454964178.issue26306@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> duplicate
stage: test needed -> resolved
status: open -> closed
superseder:  -> abstract class instantiable when subclassing dict

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26306>
_______________________________________

From report at bugs.python.org  Wed May 25 09:21:58 2016
From: report at bugs.python.org (Maciej Szulik)
Date: Wed, 25 May 2016 13:21:58 +0000
Subject: [issue5996] abstract class instantiable when subclassing dict
In-Reply-To: <1242050763.07.0.145569961651.issue5996@psf.upfronthosting.co.za>
Message-ID: <1464182518.31.0.714093727773.issue5996@psf.upfronthosting.co.za>


Changes by Maciej Szulik <soltysh at gmail.com>:


----------
nosy: +maciej.szulik

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5996>
_______________________________________

From report at bugs.python.org  Wed May 25 09:28:08 2016
From: report at bugs.python.org (R. David Murray)
Date: Wed, 25 May 2016 13:28:08 +0000
Subject: [issue27108] mimetypes.__all__ list is incomplete
In-Reply-To: <1464121896.07.0.577561794509.issue27108@psf.upfronthosting.co.za>
Message-ID: <1464182888.8.0.267708954143.issue27108@psf.upfronthosting.co.za>


R. David Murray added the comment:

I thought having the empty blacklist was a good reminder, in case names are added later that need blacklisting (though granted that should be unlikely at this point, since we are more consistent about using _ names for internals now).  I have no objection to removing it, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27108>
_______________________________________

From report at bugs.python.org  Wed May 25 09:29:31 2016
From: report at bugs.python.org (R. David Murray)
Date: Wed, 25 May 2016 13:29:31 +0000
Subject: [issue27110] smtpd.__all__ list is incomplete
In-Reply-To: <1464122507.71.0.719319292765.issue27110@psf.upfronthosting.co.za>
Message-ID: <1464182971.79.0.659608485532.issue27110@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yeah, good point.  Leave it alone.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27110>
_______________________________________

From report at bugs.python.org  Wed May 25 09:31:54 2016
From: report at bugs.python.org (R. David Murray)
Date: Wed, 25 May 2016 13:31:54 +0000
Subject: [issue27122] Hang with contextlib.ExitStack and subprocess.Popen
 (regression)
In-Reply-To: <1464176880.25.0.308106356091.issue27122@psf.upfronthosting.co.za>
Message-ID: <1464183114.36.0.744442480238.issue27122@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27122>
_______________________________________

From report at bugs.python.org  Wed May 25 09:32:26 2016
From: report at bugs.python.org (R. David Murray)
Date: Wed, 25 May 2016 13:32:26 +0000
Subject: [issue27122] Hang with contextlib.ExitStack and subprocess.Popen
 (regression)
In-Reply-To: <1464176880.25.0.308106356091.issue27122@psf.upfronthosting.co.za>
Message-ID: <1464183146.97.0.0777080921282.issue27122@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +gps

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27122>
_______________________________________

From report at bugs.python.org  Wed May 25 09:34:07 2016
From: report at bugs.python.org (R. David Murray)
Date: Wed, 25 May 2016 13:34:07 +0000
Subject: [issue27032] Remove deprecated html.parser.HTMLParser.unescape()
In-Reply-To: <1463339146.08.0.655083281356.issue27032@psf.upfronthosting.co.za>
Message-ID: <1464183247.8.0.454211022671.issue27032@psf.upfronthosting.co.za>


R. David Murray added the comment:

Nevertheless, our current standing policy is to not remove anything until after 2.7 goes out of maintenance entirely.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27032>
_______________________________________

From report at bugs.python.org  Wed May 25 09:35:17 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 25 May 2016 13:35:17 +0000
Subject: [issue27032] Remove deprecated html.parser.HTMLParser.unescape()
In-Reply-To: <1463339146.08.0.655083281356.issue27032@psf.upfronthosting.co.za>
Message-ID: <1464183317.06.0.947628915176.issue27032@psf.upfronthosting.co.za>


Berker Peksag added the comment:

It was removed before and added back with a deprecation warning (because someone was using it).

A little bit off-topic, but it would be great to have a "deprecated APIs in Python 3" list somewhere in the Python documentation (see https://docs.djangoproject.com/en/dev/internals/deprecation/ for an example).

----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27032>
_______________________________________

From report at bugs.python.org  Wed May 25 09:39:15 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 25 May 2016 13:39:15 +0000
Subject: [issue27113] sqlite3 connect parameter "check_same_thread" not
 documented
In-Reply-To: <1464125789.84.0.570004715823.issue27113@psf.upfronthosting.co.za>
Message-ID: <1464183555.0.0.406197707439.issue27113@psf.upfronthosting.co.za>


Berker Peksag added the comment:

This is a duplicate of issue 16509, but I'm going to keep this open since there is a patch attached here.

----------
nosy: +berker.peksag
stage:  -> needs patch
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27113>
_______________________________________

From report at bugs.python.org  Wed May 25 09:41:01 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 25 May 2016 13:41:01 +0000
Subject: [issue16509] sqlite3 docs do not explain check_same_thread
In-Reply-To: <1353310851.97.0.745365364193.issue16509@psf.upfronthosting.co.za>
Message-ID: <1464183661.79.0.592635389513.issue16509@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Issue 27113 has a patch and more detailed description so I'm going to close this one as a 'duplicate'.

Thanks for the report!

----------
nosy: +berker.peksag
resolution:  -> duplicate
stage: needs patch -> resolved
status: open -> closed
superseder:  -> sqlite3 connect parameter "check_same_thread" not documented

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16509>
_______________________________________

From report at bugs.python.org  Wed May 25 09:41:51 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 25 May 2016 13:41:51 +0000
Subject: [issue27113] sqlite3 connect parameter "check_same_thread" not
 documented
In-Reply-To: <1464125789.84.0.570004715823.issue27113@psf.upfronthosting.co.za>
Message-ID: <1464183711.51.0.57629338852.issue27113@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27113>
_______________________________________

From report at bugs.python.org  Wed May 25 09:41:56 2016
From: report at bugs.python.org (Upendra Kumar)
Date: Wed, 25 May 2016 13:41:56 +0000
Subject: [issue27051] Create PIP gui
In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za>
Message-ID: <1464183716.33.0.493223981745.issue27051@psf.upfronthosting.co.za>


Upendra Kumar added the comment:

I am posting flow of logic for application and related page layouts.

Related layouts are :

1. welcome_v1
2. select_venv_system
3. install_pyPI_v1
4. install_local_archive_v1
5. install_pythonlibs_v1
6. install_requirements_v1
7. update_package_v1
8. remove_package_v1
9. finish_tasks_v1 ( can be decided later depending on further options )

Here , update_package_v1 and remove_package_v1 will be very similar.
Therefore, for now I have made layout for update_package_v1 only.

----------
Added file: http://bugs.python.org/file42992/design_flow.pdf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27051>
_______________________________________

From report at bugs.python.org  Wed May 25 09:43:30 2016
From: report at bugs.python.org (Upendra Kumar)
Date: Wed, 25 May 2016 13:43:30 +0000
Subject: [issue27051] Create PIP gui
In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za>
Message-ID: <1464183810.95.0.593846218361.issue27051@psf.upfronthosting.co.za>


Changes by Upendra Kumar <upendra.k14 at iiits.in>:


Added file: http://bugs.python.org/file42993/welcome_v1.jpg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27051>
_______________________________________

From report at bugs.python.org  Wed May 25 09:44:00 2016
From: report at bugs.python.org (Upendra Kumar)
Date: Wed, 25 May 2016 13:44:00 +0000
Subject: [issue27051] Create PIP gui
In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za>
Message-ID: <1464183840.96.0.94286191223.issue27051@psf.upfronthosting.co.za>


Changes by Upendra Kumar <upendra.k14 at iiits.in>:


Added file: http://bugs.python.org/file42994/select_venv_system.jpg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27051>
_______________________________________

From report at bugs.python.org  Wed May 25 09:44:21 2016
From: report at bugs.python.org (Upendra Kumar)
Date: Wed, 25 May 2016 13:44:21 +0000
Subject: [issue27051] Create PIP gui
In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za>
Message-ID: <1464183861.03.0.828324754196.issue27051@psf.upfronthosting.co.za>


Changes by Upendra Kumar <upendra.k14 at iiits.in>:


Added file: http://bugs.python.org/file42995/install_pyPI_v1.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27051>
_______________________________________

From report at bugs.python.org  Wed May 25 09:44:56 2016
From: report at bugs.python.org (Upendra Kumar)
Date: Wed, 25 May 2016 13:44:56 +0000
Subject: [issue27051] Create PIP gui
In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za>
Message-ID: <1464183896.51.0.469914264887.issue27051@psf.upfronthosting.co.za>


Changes by Upendra Kumar <upendra.k14 at iiits.in>:


Added file: http://bugs.python.org/file42996/install_requirement_v1.jpg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27051>
_______________________________________

From report at bugs.python.org  Wed May 25 09:45:29 2016
From: report at bugs.python.org (Upendra Kumar)
Date: Wed, 25 May 2016 13:45:29 +0000
Subject: [issue27051] Create PIP gui
In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za>
Message-ID: <1464183929.05.0.0817816604429.issue27051@psf.upfronthosting.co.za>


Changes by Upendra Kumar <upendra.k14 at iiits.in>:


Added file: http://bugs.python.org/file42997/install_local_archive_v1.jpg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27051>
_______________________________________

From report at bugs.python.org  Wed May 25 09:46:35 2016
From: report at bugs.python.org (Upendra Kumar)
Date: Wed, 25 May 2016 13:46:35 +0000
Subject: [issue27051] Create PIP gui
In-Reply-To: <1463550469.55.0.680424350053.issue27051@psf.upfronthosting.co.za>
Message-ID: <1464183995.28.0.678209775474.issue27051@psf.upfronthosting.co.za>


Changes by Upendra Kumar <upendra.k14 at iiits.in>:


Added file: http://bugs.python.org/file42998/update_package_v1.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27051>
_______________________________________

From report at bugs.python.org  Wed May 25 09:48:29 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 25 May 2016 13:48:29 +0000
Subject: [issue27118] Several Py_XDE/INCREFs in typeobject.c are not necessary
In-Reply-To: <1464156760.73.0.28265991298.issue27118@psf.upfronthosting.co.za>
Message-ID: <1464184109.28.0.20638883116.issue27118@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

It's my pleasure and thanks for your time reviewing this thread too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27118>
_______________________________________

From report at bugs.python.org  Wed May 25 09:52:59 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 May 2016 13:52:59 +0000
Subject: [issue27122] Hang with contextlib.ExitStack and subprocess.Popen
 (regression)
In-Reply-To: <1464176880.25.0.308106356091.issue27122@psf.upfronthosting.co.za>
Message-ID: <1464184379.26.0.716103338712.issue27122@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Simplified script to reproduce the bug.

----------
nosy: +haypo
Added file: http://bugs.python.org/file42999/hang_bug2.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27122>
_______________________________________

From report at bugs.python.org  Wed May 25 09:55:48 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 May 2016 13:55:48 +0000
Subject: [issue27122] Hang with contextlib.ExitStack and subprocess.Popen
 (regression)
In-Reply-To: <1464176880.25.0.308106356091.issue27122@psf.upfronthosting.co.za>
Message-ID: <1464184548.47.0.39880653692.issue27122@psf.upfronthosting.co.za>


STINNER Victor added the comment:

It's a regression introduced by the PEP 479 in Lib/contextlib.py by the changeset 36a8d935c322, "PEP 479: Change StopIteration handling inside generators (Closes issue #22906)".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27122>
_______________________________________

From report at bugs.python.org  Wed May 25 09:55:55 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 May 2016 13:55:55 +0000
Subject: [issue27122] Hang with contextlib.ExitStack and subprocess.Popen
 (regression)
In-Reply-To: <1464176880.25.0.308106356091.issue27122@psf.upfronthosting.co.za>
Message-ID: <1464184554.99.0.2184130595.issue27122@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27122>
_______________________________________

From report at bugs.python.org  Wed May 25 09:57:11 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 May 2016 13:57:11 +0000
Subject: [issue27122] Hang with contextlib.ExitStack and subprocess.Popen
 (regression)
In-Reply-To: <1464176880.25.0.308106356091.issue27122@psf.upfronthosting.co.za>
Message-ID: <1464184631.57.0.462130333719.issue27122@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Workaround, or maybe fix?, for the issue:

diff -r 0af15b8ef3b2 Lib/contextlib.py
--- a/Lib/contextlib.py Thu May 12 10:37:58 2016 +0300
+++ b/Lib/contextlib.py Wed May 25 15:56:50 2016 +0200
@@ -87,6 +87,8 @@ class _GeneratorContextManager(ContextDe
                 # (see PEP 479).
                 if exc.__cause__ is value:
                     return False
+                if exc is value:
+                    return
                 raise
             except:
                 # only re-raise if it's *not* the exception that was

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27122>
_______________________________________

From report at bugs.python.org  Wed May 25 10:05:19 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 May 2016 14:05:19 +0000
Subject: [issue26814] [WIP] Add a new _PyObject_FastCall() function which
 avoids the creation of a tuple or dict for arguments
In-Reply-To: <1461229041.59.0.994194592206.issue26814@psf.upfronthosting.co.za>
Message-ID: <1464185119.8.0.0765486321732.issue26814@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I fixed even more issues with my setup to run benchmark. Results should be even more reliable. Moreover, I fixed multiple reference leaks in the code which introduced performance regressions. I started to write articles to explain how to run stable benchmarks:

* https://haypo.github.io/journey-to-stable-benchmark-system.html
* https://haypo.github.io/journey-to-stable-benchmark-deadcode.html
* https://haypo.github.io/journey-to-stable-benchmark-average.html

Summary of benchmarks at the revision e6f3bf996c01:

Faster (25):
- pickle_list: 1.29x faster
- etree_generate: 1.22x faster
- pickle_dict: 1.19x faster
- etree_process: 1.16x faster
- mako_v2: 1.13x faster
- telco: 1.09x faster
- raytrace: 1.08x faster
- etree_iterparse: 1.08x faster
- regex_compile: 1.07x faster
- json_dump_v2: 1.07x faster
- etree_parse: 1.06x faster
- regex_v8: 1.05x faster
- call_method_unknown: 1.05x faster
- chameleon_v2: 1.05x faster
- fastunpickle: 1.04x faster
- django_v3: 1.04x faster
- chaos: 1.04x faster
- 2to3: 1.03x faster
- pathlib: 1.03x faster
- unpickle_list: 1.03x faster
- json_load: 1.03x faster
- fannkuch: 1.03x faster
- call_method: 1.02x faster
- unpack_sequence: 1.02x faster
- call_method_slots: 1.02x faster

Slower (4):
- regex_effbot: 1.08x slower
- nbody: 1.08x slower
- spectral_norm: 1.07x slower
- nqueens: 1.06x slower

Not significat (13):
- tornado_http
- startup_nosite
- simple_logging
- silent_logging
- richards
- pidigits
- normal_startup
- meteor_contest
- go
- formatted_logging
- float
- fastpickle
- call_simple

I'm now investigating why 4 benchmarks are slower.

Note: I'm still using my patched CPython benchmark suite to get more stable benchmark. I will send patches upstream later.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26814>
_______________________________________

From report at bugs.python.org  Wed May 25 10:10:18 2016
From: report at bugs.python.org (Thomas Kluyver)
Date: Wed, 25 May 2016 14:10:18 +0000
Subject: [issue27113] sqlite3 connect parameter "check_same_thread" not
 documented
In-Reply-To: <1464125789.84.0.570004715823.issue27113@psf.upfronthosting.co.za>
Message-ID: <1464185418.35.0.663393048735.issue27113@psf.upfronthosting.co.za>


Changes by Thomas Kluyver <thomas at kluyver.me.uk>:


----------
nosy: +takluyver

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27113>
_______________________________________

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: [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 10:30:40 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 25 May 2016 14:30:40 +0000
Subject: [issue27122] Hang with contextlib.ExitStack and subprocess.Popen
 (regression)
In-Reply-To: <1464176880.25.0.308106356091.issue27122@psf.upfronthosting.co.za>
Message-ID: <1464186640.63.0.295256446094.issue27122@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

The suggested fix looks basically correct to me - the problem is that the new except clause added by that patch is currently missing the "don't re-raise the passed in exception" logic needed to fully abide by the context management protocol, but we missed that on the patch review.

The only tweak I would recommend is putting that check before the check for StopIteration being converted to RuntimeError so it's immediately obvious to the reader that it takes priority over the exc.__cause__ check.

The comment on that clause should also be adjusted to reflect the fixed behaviour.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27122>
_______________________________________

From report at bugs.python.org  Wed May 25 10:33:33 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 25 May 2016 14:33:33 +0000
Subject: [issue26936] android: test_socket fails
In-Reply-To: <1462288246.37.0.495121419926.issue26936@psf.upfronthosting.co.za>
Message-ID: <1464186813.34.0.835711175064.issue26936@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

Problems with the socket module on Android:
API 21:
    a) Both getservbyname() and getservbyport() fail when the optional 'protocolname' parameter is not set to 'tcp' or 'udp'.
    b) getservbyname() fails when 'servicename' is set to 'http'.
    getaddrinfo() fails either when:
        c) 'port' is 'http'.
        d) Or the optional 'type' is not set to socket.SOCK_STREAM or socket.SOCK_DGRAM and 'port' is a string.

API 23:
    e) getservbyport() fails when the optional 'protocolname' parameter is not set to 'tcp' or 'udp'.

IMHO case b) and c) are difficult to fix.
For case d), one could use the Python implementation of getaddrinfo, but Android does not have the deprecated getipnodebyaddr(), so it is necessary to disable ipv6 in this case. Not sure if this is worth it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26936>
_______________________________________

From report at bugs.python.org  Wed May 25 10:36:50 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 25 May 2016 14:36:50 +0000
Subject: [issue26936] android: test_socket fails
In-Reply-To: <1462288246.37.0.495121419926.issue26936@psf.upfronthosting.co.za>
Message-ID: <1464187010.48.0.810825749871.issue26936@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

This patch fixes the testGetServBy test for API 21 and 23 (fixing the cases a) and e) of my previous msg).

----------
keywords: +patch
Added file: http://bugs.python.org/file43000/null-proto.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26936>
_______________________________________

From report at bugs.python.org  Wed May 25 10:40:08 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 May 2016 14:40:08 +0000
Subject: [issue27097] ceval: Wordcode follow up, explicit unsigned short read
In-Reply-To: <1464048499.12.0.811410474415.issue27097@psf.upfronthosting.co.za>
Message-ID: <1464187208.26.0.9405040544.issue27097@psf.upfronthosting.co.za>


STINNER Victor added the comment:

ushort3.patch LGTM.

You might also add (copy) the added assertions in PyCode_New*().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27097>
_______________________________________

From report at bugs.python.org  Wed May 25 10:40:43 2016
From: report at bugs.python.org (Xavier de Gaye)
Date: Wed, 25 May 2016 14:40:43 +0000
Subject: [issue26936] android: test_socket fails
In-Reply-To: <1462288246.37.0.495121419926.issue26936@psf.upfronthosting.co.za>
Message-ID: <1464187243.8.0.748807076486.issue26936@psf.upfronthosting.co.za>


Xavier de Gaye added the comment:

This patch fixes the testGetaddrinfo test for API 21 (the test runs fine on API 23):
    The failing statement 'socket.getaddrinfo(HOST, "http")' in testGetaddrinfo does not test explicitly for "http" and for the absence of the optional 'type' parameter.
    When is_android is True, the 'socket.getaddrinfo('127.0.0.1', "echo", type=socket.SOCK_DGRAM)' statement is run instead and the test is ok.

----------
dependencies: +add is_android in test.support to detect Android platform
Added file: http://bugs.python.org/file43001/test-getaddrinfo.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26936>
_______________________________________

From report at bugs.python.org  Wed May 25 10:43:01 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 May 2016 14:43:01 +0000
Subject: [issue27122] Hang with contextlib.ExitStack and subprocess.Popen
 (regression)
In-Reply-To: <1464176880.25.0.308106356091.issue27122@psf.upfronthosting.co.za>
Message-ID: <1464187381.19.0.150415144914.issue27122@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> The loop seems to be in PyErr_SetObject in a loop that recursively go through PyException_GetContext.

We should also fix this function to avoid the infinite loop.

Maybe we should deny setting "exc.__context__=exc" (modify PyException_SetContext for that). Maybe raise a new RuntimeError in this case?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27122>
_______________________________________

From report at bugs.python.org  Wed May 25 10:55:09 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 25 May 2016 14:55:09 +0000
Subject: [issue27096] Ability to get random bytes from random.Random (as with
 os.urandom)
In-Reply-To: <1464043046.76.0.140037772611.issue27096@psf.upfronthosting.co.za>
Message-ID: <1464188109.59.0.698102746849.issue27096@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Sorry Campbell, I concur with Serhiy that this isn't worth growing the API.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27096>
_______________________________________

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: [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 11:53:16 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 25 May 2016 15:53:16 +0000
Subject: [issue27122] Hang with contextlib.ExitStack and subprocess.Popen
 (regression)
In-Reply-To: <1464187381.19.0.150415144914.issue27122@psf.upfronthosting.co.za>
Message-ID: <7C5B09BE-D5E4-46CB-9B43-6CFB2BF268E8@gmail.com>


Yury Selivanov added the comment:

> 
> Maybe we should deny setting "exc.__context__=exc" (modify PyException_SetContext for that). Maybe raise a new RuntimeError in this case?

There is a patch for that somewhere on the tracker

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27122>
_______________________________________

From report at bugs.python.org  Wed May 25 11:55:58 2016
From: report at bugs.python.org (Lennart Grahl)
Date: Wed, 25 May 2016 15:55:58 +0000
Subject: [issue27124] binascii.a2b_hex raises binascii.Error and ValueError,
 not TypeError
In-Reply-To: <1464190951.12.0.309980767012.issue27124@psf.upfronthosting.co.za>
Message-ID: <1464191758.68.0.963867406137.issue27124@psf.upfronthosting.co.za>


Lennart Grahl added the comment:

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))

What surprised me even more was that it raises ValueError (although binascii.Error inherits ValueError) in case a unicode string has been passed as an argument:

try:
    binascii.a2b_hex('?')
except binascii.Error:
    print('binascii.Error')
except ValueError:
    print('ValueError')

----------
title: binascii.a2b_hex raises binascii.Error, not TypeError -> binascii.a2b_hex raises binascii.Error and ValueError, not TypeError

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27124>
_______________________________________

From report at bugs.python.org  Wed May 25 12:23:49 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Wed, 25 May 2016 16:23:49 +0000
Subject: [issue27124] binascii.a2b_hex raises binascii.Error and ValueError,
 not TypeError
In-Reply-To: <1464190951.12.0.309980767012.issue27124@psf.upfronthosting.co.za>
Message-ID: <1464193429.56.0.927592994042.issue27124@psf.upfronthosting.co.za>


Steven D'Aprano added the comment:

In Python 3.x, 'a' is just as much a Unicode string as '?'. I agree that binascii.a2b_hex should raise ValueError for argument '?', or ';' for that matter, as they are invalid values. There's an inconsistency in why some invalid characters raise ValueError and some raise binascii.Error. But since binascii.Error is a subclass of ValueError, it probably doesn't matter that much, so long as the documentation is clear.

----------
nosy: +steven.daprano

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27124>
_______________________________________

From report at bugs.python.org  Wed May 25 12:42:06 2016
From: report at bugs.python.org (Andrea De Pasquale)
Date: Wed, 25 May 2016 16:42:06 +0000
Subject: [issue27010] email library could "recover" from bad mime boundary
 like (some?) email clients do
In-Reply-To: <1463067718.45.0.558318505018.issue27010@psf.upfronthosting.co.za>
Message-ID: <1464194526.48.0.137591479488.issue27010@psf.upfronthosting.co.za>


Andrea De Pasquale added the comment:

Isn't this covered by the following test case?

Lib/test/test_email/test_defect_handling.py:18

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27010>
_______________________________________

From report at bugs.python.org  Wed May 25 12:49:30 2016
From: report at bugs.python.org (=?utf-8?q?Jacek_Ko=C5=82odziej?=)
Date: Wed, 25 May 2016 16:49:30 +0000
Subject: [issue23883] __all__ lists are incomplete
In-Reply-To: <1428423790.05.0.732881467443.issue23883@psf.upfronthosting.co.za>
Message-ID: <1464194970.12.0.979027753153.issue23883@psf.upfronthosting.co.za>


Jacek Ko?odziej added the comment:

In this case I'm proposing a small patch just for testing pydoc module's __all__ list and left the decision to you, whether to apply it or not. :)

Test doesn't use test.support.check__all__ (see msg266312) - blacklist would be huge and expected list, as you already pointed out, has only one value.

----------
Added file: http://bugs.python.org/file43002/Issue23883_pydoc_all.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23883>
_______________________________________

From report at bugs.python.org  Wed May 25 12:52:08 2016
From: report at bugs.python.org (Denis Akhiyarov)
Date: Wed, 25 May 2016 16:52:08 +0000
Subject: [issue6818] remove/delete method for zipfile/tarfile objects
In-Reply-To: <1251866532.69.0.504306670253.issue6818@psf.upfronthosting.co.za>
Message-ID: <1464195128.77.0.0570387306939.issue6818@psf.upfronthosting.co.za>


Denis Akhiyarov added the comment:

has this been merged?

----------
nosy: +Denis Akhiyarov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6818>
_______________________________________

From report at bugs.python.org  Wed May 25 13:03:20 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 25 May 2016 17:03:20 +0000
Subject: [issue27097] ceval: Wordcode follow up, explicit unsigned short read
In-Reply-To: <1464048499.12.0.811410474415.issue27097@psf.upfronthosting.co.za>
Message-ID: <20160525170248.28572.98825.87D4CC36@psf.io>


Roundup Robot added the comment:

New changeset eda3716d6425 by Serhiy Storchaka in branch 'default':
Issue #27097: Python interpreter is now about 7% faster due to optimized
https://hg.python.org/cpython/rev/eda3716d6425

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27097>
_______________________________________

From report at bugs.python.org  Wed May 25 13:04:35 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 May 2016 17:04:35 +0000
Subject: [issue27097] ceval: Wordcode follow up, explicit unsigned short read
In-Reply-To: <1464048499.12.0.811410474415.issue27097@psf.upfronthosting.co.za>
Message-ID: <1464195875.84.0.93149422816.issue27097@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
assignee:  -> serhiy.storchaka
resolution:  -> fixed
stage: patch review -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27097>
_______________________________________

From report at bugs.python.org  Wed May 25 13:07:00 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 May 2016 17:07:00 +0000
Subject: [issue25823] Speed-up oparg decoding on little-endian machines
In-Reply-To: <1449567251.61.0.853791637694.issue25823@psf.upfronthosting.co.za>
Message-ID: <1464196020.73.0.140526368989.issue25823@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Corresponding patch was committed in issue27097.

----------
dependencies:  -ceval: use Wordcode, 16-bit bytecode
resolution:  -> out of date
stage:  -> resolved
status: open -> closed
superseder:  -> ceval: Wordcode follow up, explicit unsigned short read

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25823>
_______________________________________

From report at bugs.python.org  Wed May 25 13:09:06 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 May 2016 17:09:06 +0000
Subject: [issue27097] ceval: Wordcode follow up, explicit unsigned short read
In-Reply-To: <1464048499.12.0.811410474415.issue27097@psf.upfronthosting.co.za>
Message-ID: <1464196146.81.0.919195376045.issue27097@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27097>
_______________________________________

From report at bugs.python.org  Wed May 25 13:12:10 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 May 2016 17:12:10 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1464196330.31.0.523323501363.issue26647@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I join in the congratulations, Demur! Thank you for your contributions.

I left this issue open for updating the documentation and other polishing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Wed May 25 13:15:10 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 25 May 2016 17:15:10 +0000
Subject: [issue27097] ceval: Wordcode follow up, explicit unsigned short read
In-Reply-To: <1464048499.12.0.811410474415.issue27097@psf.upfronthosting.co.za>
Message-ID: <1464196510.77.0.629680094874.issue27097@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Debug builds are broken after eda3716d6425: http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.x%203.x/builds/4332/steps/compile/logs/stdio

----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27097>
_______________________________________

From report at bugs.python.org  Wed May 25 13:30:46 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Wed, 25 May 2016 17:30:46 +0000
Subject: [issue27122] Hang with contextlib.ExitStack and subprocess.Popen
 (regression)
In-Reply-To: <1464176880.25.0.308106356091.issue27122@psf.upfronthosting.co.za>
Message-ID: <1464197446.46.0.597212525818.issue27122@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

Yes, and it seems that it is waiting for a review. http://bugs.python.org/issue25782

----------
nosy: +ebarry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27122>
_______________________________________

From report at bugs.python.org  Wed May 25 13:36:19 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 25 May 2016 17:36:19 +0000
Subject: [issue27097] ceval: Wordcode follow up, explicit unsigned short read
In-Reply-To: <1464048499.12.0.811410474415.issue27097@psf.upfronthosting.co.za>
Message-ID: <20160525173603.24275.32657.1152D164@psf.io>


Roundup Robot added the comment:

New changeset b26d07812a8e by Serhiy Storchaka in branch 'default':
Fixed the use of _Py_IS_ALIGNED (issue #27097).
https://hg.python.org/cpython/rev/b26d07812a8e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27097>
_______________________________________

From report at bugs.python.org  Wed May 25 13:37:49 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 25 May 2016 17:37:49 +0000
Subject: [issue27097] ceval: Wordcode follow up, explicit unsigned short read
In-Reply-To: <1464048499.12.0.811410474415.issue27097@psf.upfronthosting.co.za>
Message-ID: <1464197869.22.0.863765372944.issue27097@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Opps, sorry. Fixed now. Thank you Berker for fast response.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27097>
_______________________________________

From report at bugs.python.org  Wed May 25 13:52:52 2016
From: report at bugs.python.org (R. David Murray)
Date: Wed, 25 May 2016 17:52:52 +0000
Subject: [issue27010] email library could "recover" from bad mime boundary
 like (some?) email clients do
In-Reply-To: <1463067718.45.0.558318505018.issue27010@psf.upfronthosting.co.za>
Message-ID: <1464198772.37.0.57656187231.issue27010@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yes.  The current behavior is not a bug, the question is, do we want to deal with that XXX comment in the test by detecting the duplicate and reconizing the "extra" mime part?  The defect detection would remain.

----------
stage:  -> needs patch
type:  -> enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27010>
_______________________________________

From report at bugs.python.org  Wed May 25 14:12:51 2016
From: report at bugs.python.org (Mark Grandi)
Date: Wed, 25 May 2016 18:12:51 +0000
Subject: [issue23026] Winreg module doesn't support REG_QWORD,
 small DWORD doc update
In-Reply-To: <1418242433.97.0.849861872047.issue23026@psf.upfronthosting.co.za>
Message-ID: <1464199971.42.0.0979145218142.issue23026@psf.upfronthosting.co.za>


Mark Grandi added the comment:

in 'test_winreg.py', there should probably be a test that covers REG_QWORD_LITTLE_ENDIAN, even if they are essentially equivalent 

Also, in Py2Reg and Reg2Py, it seems that both are missing the 'case' clause for REG_QWORD_LITTLE_ENDIAN as well

case REG_QWORD:
case REG_QWORD_LITTLE_ENDIAN:
<code here>

And sure, i would have the documentation changes listed in 'Doc/whatsnew/3.6.rst'. And now that I think about it, the documentation in '/Doc/library/winreg.rst' should probably mention that REG_QWORD and REG_QWORD_LITTLE_ENDIAN are new as of python 3.6

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23026>
_______________________________________

From report at bugs.python.org  Wed May 25 14:13:04 2016
From: report at bugs.python.org (Steve Dower)
Date: Wed, 25 May 2016 18:13:04 +0000
Subject: [issue27054] Python installation problem: No module named 'encodings'
In-Reply-To: <45B64D1540141C4AA0F8F3974D714AEA64D3D93D@S197.admin.wpi.edu>
Message-ID: <1464199984.52.0.984083730435.issue27054@psf.upfronthosting.co.za>


Steve Dower added the comment:

I suspect PYTHONHOME is the problem and not the installation method. There have been thousands of (presumably successful) installations of Python 3.5, and I expect most of them are just for the current user (as that's the default). If these were all failing for this reason, we'd have heard before now :)

There are likely to be some configurations that will cause the initial install to fail if you aren't running as an administrator, but that doesn't sound like the issue here.

Rogue installers that write to Python's registry keys (e.g. Anaconda) are more likely to cause problems here, as are those that globally set environment variables like PYTHONHOME/PYTHONPATH. If, like me, you install a lot of different bundles to figure out which is best, then some of these may be lingering around.

But I'm 99.99% certain that our installer is not at fault and there's nothing to fix here.

----------
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27054>
_______________________________________

From report at bugs.python.org  Wed May 25 14:25:38 2016
From: report at bugs.python.org (Steve Dower)
Date: Wed, 25 May 2016 18:25:38 +0000
Subject: [issue23026] Winreg module doesn't support REG_QWORD,
 small DWORD doc update
In-Reply-To: <1418242433.97.0.849861872047.issue23026@psf.upfronthosting.co.za>
Message-ID: <1464200738.57.0.149938237523.issue23026@psf.upfronthosting.co.za>


Steve Dower added the comment:

Thanks!

I don't think we need to mention doc changes in whatsnew, but I've made the description more general and added the "New in version 3.6" notes to the winreg page.

The formatting was presumably copied from the surrounding code, but I've fixed all instances of it.

I can't actually add ``case REG_QWORD_LITTLE_ENDIAN:`` as it has the same value as REG_QWORD and won't compile.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23026>
_______________________________________

From report at bugs.python.org  Wed May 25 14:26:29 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 25 May 2016 18:26:29 +0000
Subject: [issue23026] Winreg module doesn't support REG_QWORD,
 small DWORD doc update
In-Reply-To: <1418242433.97.0.849861872047.issue23026@psf.upfronthosting.co.za>
Message-ID: <20160525182620.26938.35240.79B21E66@psf.io>


Roundup Robot added the comment:

New changeset ed4eec682199 by Steve Dower in branch 'default':
Closes #23026: Documentation improvements and code formatting
https://hg.python.org/cpython/rev/ed4eec682199

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23026>
_______________________________________

From report at bugs.python.org  Wed May 25 14:29:58 2016
From: report at bugs.python.org (Mark Grandi)
Date: Wed, 25 May 2016 18:29:58 +0000
Subject: [issue23026] Winreg module doesn't support REG_QWORD,
 small DWORD doc update
In-Reply-To: <1418242433.97.0.849861872047.issue23026@psf.upfronthosting.co.za>
Message-ID: <1464200998.09.0.375719609141.issue23026@psf.upfronthosting.co.za>


Mark Grandi added the comment:

Oh, I didn't realize that both REG_QWORD and REG_QWORD_LITTLE_ENDIAN had the same value, that works then.

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23026>
_______________________________________

From report at bugs.python.org  Wed May 25 14:37:41 2016
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 25 May 2016 18:37:41 +0000
Subject: [issue27054] Python installation problem: No module named 'encodings'
In-Reply-To: <45B64D1540141C4AA0F8F3974D714AEA64D3D93D@S197.admin.wpi.edu>
Message-ID: <1464201461.41.0.0467578432369.issue27054@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
stage:  -> resolved

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27054>
_______________________________________

From report at bugs.python.org  Wed May 25 14:39:57 2016
From: report at bugs.python.org (Demur Rumed)
Date: Wed, 25 May 2016 18:39:57 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1464201597.8.0.353974842562.issue26647@psf.upfronthosting.co.za>


Demur Rumed added the comment:

A documentation touch up for EXTENDED_ARG is included in #27095

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Wed May 25 14:40:42 2016
From: report at bugs.python.org (Zachary Ware)
Date: Wed, 25 May 2016 18:40:42 +0000
Subject: [issue23026] Winreg module doesn't support REG_QWORD,
 small DWORD doc update
In-Reply-To: <1418242433.97.0.849861872047.issue23026@psf.upfronthosting.co.za>
Message-ID: <1464201642.26.0.294214583655.issue23026@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23026>
_______________________________________

From report at bugs.python.org  Wed May 25 15:01:17 2016
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 25 May 2016 19:01:17 +0000
Subject: [issue27097] ceval: Wordcode follow up, explicit unsigned short read
In-Reply-To: <1464197869.22.0.863765372944.issue27097@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbD6KZ_u1ZkTRJwva-wapF0HaJFHZ_n5T2cdrK+FUArcQ@mail.gmail.com>


STINNER Victor added the comment:

Why not using sizeof(unsigned short) in the macro, rtbaer than 2?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27097>
_______________________________________

From report at bugs.python.org  Wed May 25 15:29:28 2016
From: report at bugs.python.org (=?utf-8?q?Jacek_Ko=C5=82odziej?=)
Date: Wed, 25 May 2016 19:29:28 +0000
Subject: [issue27112] tokenize.__all__ list is incomplete
In-Reply-To: <1464123395.58.0.823594635343.issue27112@psf.upfronthosting.co.za>
Message-ID: <1464204568.53.0.291388416141.issue27112@psf.upfronthosting.co.za>


Jacek Ko?odziej added the comment:

> * All names in black list are implementation details. Names in white list are stable and already repeated in docs.

Assumption here is that implementation details shouldn't "look" public - they should have names starting with "_"; I think blacklisting names in these tests encourages good practice - if something "looks" public, either:
* it should be documented and placed in __all__
* renamed to something that doesn't look public anymore
* in some special cases - be explicitely blacklisted in test.

But ok, assuming we go with whitelisting and plain self.assertCountEqual:

> * White list consists mostly from token.__all__.

Should I then do:

    import token
    expected = token.__all__ + ["COMMENT", "NL", "ENCODING", "TokenInfo", "TokenError", "detect_encoding", "untokenize", "open", "tokenize"]

?

> IMO changing all the names adds too much churn with minimal benefit.

I wouldn't call it minimal, it has some positive impact on readability, see last line from The Zen of Python. :) Of course, final call is yours.

Single import of unittest is such a small change I would rather keep it.

I fully agree existing TestMisc class is a good place for this test, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27112>
_______________________________________

From report at bugs.python.org  Wed May 25 15:52:56 2016
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Wed, 25 May 2016 19:52:56 +0000
Subject: [issue27106] configparser.__all__ is incomplete
In-Reply-To: <1464121705.13.0.123221989673.issue27106@psf.upfronthosting.co.za>
Message-ID: <1464205976.79.0.780709892671.issue27106@psf.upfronthosting.co.za>


?ukasz Langa added the comment:

The reason we specifically omitted Error was two-fold:
- the name "Error" is very generic and during a star-import might easily shadow some other class of the same name;
- Error is only a base class for exceptions raised by configparser and as such isn't part of the public API. You can see the same behavior in concurrent.futures for example. However, now I noticed configparser.Error is listed in the documentation so the assertion that "it's not public API" is effectively incorrect.

So I'm torn a little here. On the one hand, it's nice to add Error for completeness. On the other hand, is this change solving a real issue or just satisfying your inner librarian? The reason we have to ask ourselves this question is that this change bears a small risk of breaking user code that was working before. Take a look at this example:
```
from wave import *
from configparser import *

cfg = ConfigParser()
cfg.read('appconfig.ini')
try:
  with Wave_read(cfg['samples']['sad_trombone']) as wav:
    n = wav.getnframes()
    frames = wav.readframes(n)
except Error as e:
  print("Invalid sample:", e)
except KeyError as e:
  print("Can't find {!r} in the config".format(str(e)))
else:
  play_sound(frames)
```
Sure, it's bad code but the point is: it was working before and had a decent error handling strategy. With the change in __all__, it will just crash because wave.Error was never caught.

Is this likely to happen? I don't think so. Knowing my luck, will it happen to somebody? Yeah. So the question remains: why do we want Error in __all__ in the first place? Is it worth it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27106>
_______________________________________

From report at bugs.python.org  Wed May 25 16:54:23 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 25 May 2016 20:54:23 +0000
Subject: [issue24225] Idlelib: changing file names
In-Reply-To: <1431934587.56.0.38760352205.issue24225@psf.upfronthosting.co.za>
Message-ID: <1464209663.91.0.232892728421.issue24225@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Ned, the rename (only) patch is useless to read as it is hg's bloated expansion of the rename commands in i3rename.bat.

The main update is based on my review of Al's patch.  In user testing, I discovered that the debugger depended on 'RemoteDebugger.py' being prefix + 'Debugger.py', so that its code needed more than a simple name replacement when I changed to 'debugger.py' and 'debugger_r.py'.  We both missed "from idlelib import PathBrowser" buried in EditorWindow.open_path_browser.  I plan to collapse the update patches after I finish live user testing.  I am now using patched IDLE for further editing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24225>
_______________________________________

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: [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 18:44:46 2016
From: report at bugs.python.org (Phoenix)
Date: Wed, 25 May 2016 22:44:46 +0000
Subject: [issue27125] Typo in Python 2 multiprocessing documentation
In-Reply-To: <1464216185.35.0.531405853541.issue27125@psf.upfronthosting.co.za>
Message-ID: <1464216286.91.0.165278063747.issue27125@psf.upfronthosting.co.za>


Phoenix added the comment:

Later in the same paragraph:

"This value will automatically inherited by"

s/b (emphasis added)

"This value will **be** automatically inherited by"

Or, if you prefer your infinitives unsplit:

"This value will be inherited automatically by"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27125>
_______________________________________

From report at bugs.python.org  Wed May 25 18:55:47 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 25 May 2016 22:55:47 +0000
Subject: [issue24225] Idlelib: changing file names
In-Reply-To: <1431934587.56.0.38760352205.issue24225@psf.upfronthosting.co.za>
Message-ID: <1464216947.52.0.853644286914.issue24225@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Serhiy, and anyone else: I am *painfully* aware that any change to idlelib could break 3rd party imports.  Efforts to improve IDLE have been crippled by the restriction of not doing so for years. But idlelib exists to implement IDLE and change is necessary to modernize IDLE.

In June/July 2010, after KBK left IDLE development, there was a long pydev discussion (50-100? posts) based on agreement that IDLE was somewhat old and crusty.  The question was whether to removed it from the stdlib or modernize it.  The latter meant: use ttk widgets, more to a modern single window, multi-pane, multi-tab design, and (I am sure) modernize the code.  As a Python user on Windows, I urged keeping IDLE.  The response, and the end of the discussion, were decisions to a) keep IDLE, at least for awhile, and b) to hand me commit privileges so I could try to help modernize IDLE.

I subsequently added 'a comprehensive test suite' as part of 'modernize'.  With GSOC student help, a start has been made.  What have not been added -- yet -- are tests that require refactoring and api changes -- because such changes could possibly break some person's use of the module.  I am no longer willing to apply significant patches without being able to freely write needed tests.

In February 2013, I helped write PEP 434, which mostly formalized points that were more or less informally true before.  One is the purpose of idlelib.  Another is that idlelib should be regarded as private in that it should be allowed to change, and even break 3rd party use (sometime in the undefined future) as needed to improve IDLE.

[Insert first 4 paragraphs and other bits of #26993, as well as the posts on this issue from a year ago.]

Why this patch, now.  1. a consistent set of PEP 8 module names, distinct from class names, is already beneficial to me.  Also see Al's and my comments above.  Note that Al independently came to the same conclusion as I after writing a few IDLE patches.  Others who have worked with the code have said the same.  2. Consolidation and splitting of files will require new names anyway.  3.  Even if we kept the current nasty hodgepodge of naming styles, I expect that changes withing files would eventually break most 3rd party imports anyway.  4. I think it better to break 3rd party imports all at once, in an early alpha release, than haphazardly over the course of 3.6 releases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24225>
_______________________________________

From report at bugs.python.org  Wed May 25 19:05:06 2016
From: report at bugs.python.org (Evan Jones)
Date: Wed, 25 May 2016 23:05:06 +0000
Subject: [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 19:05:18 2016
From: report at bugs.python.org (Evan Jones)
Date: Wed, 25 May 2016 23:05:18 +0000
Subject: [issue27126] Mac system sqlite3 not fork safe: Bundle a version?
In-Reply-To: <1464217505.87.0.0701340905112.issue27126@psf.upfronthosting.co.za>
Message-ID: <1464217518.93.0.761317994898.issue27126@psf.upfronthosting.co.za>


Changes by Evan Jones <evan.jones at bluecore.com>:


Added file: http://bugs.python.org/file43004/osx_python3_crash.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27126>
_______________________________________

From report at bugs.python.org  Wed May 25 19:07:09 2016
From: report at bugs.python.org (Evan Jones)
Date: Wed, 25 May 2016 23:07:09 +0000
Subject: [issue20353] Hanging bug with multiprocessing + sqlite3 + tkinter (OS
 X 10.9 only)
In-Reply-To: <1390415067.55.0.719190169135.issue20353@psf.upfronthosting.co.za>
Message-ID: <1464217629.28.0.52788793782.issue20353@psf.upfronthosting.co.za>


Evan Jones added the comment:

I believe the root cause of this bug is the following issue: http://bugs.python.org/issue27126 ; a workaround is to run the following code before forking any subprocesses: sqlite3.connect(':memory:').close()

----------
nosy: +evan.jones at bluecore.com

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20353>
_______________________________________

From report at bugs.python.org  Wed May 25 19:16:47 2016
From: report at bugs.python.org (Evan Jones)
Date: Wed, 25 May 2016 23:16:47 +0000
Subject: [issue24573] Using multiprocessing with tkinter frames in Python
 3.4.3 crashes in OS X
In-Reply-To: <1436149068.06.0.463306574037.issue24573@psf.upfronthosting.co.za>
Message-ID: <1464218207.43.0.825166524941.issue24573@psf.upfronthosting.co.za>


Evan Jones added the comment:

This is another instance of the following bug: http://bugs.python.org/issue27126

libdispatch (grand central dispatch) is not fork safe. The forkserver approach is a good workaround, thanks!

----------
nosy: +evan.jones at bluecore.com

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24573>
_______________________________________

From report at bugs.python.org  Wed May 25 19:44:41 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 25 May 2016 23:44:41 +0000
Subject: [issue27122] Hang with contextlib.ExitStack and subprocess.Popen
 (regression)
In-Reply-To: <1464176880.25.0.308106356091.issue27122@psf.upfronthosting.co.za>
Message-ID: <1464219881.38.0.196675214058.issue27122@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
nosy: +gregory.p.smith -gps

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27122>
_______________________________________

From report at bugs.python.org  Wed May 25 20:19:01 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 26 May 2016 00:19:01 +0000
Subject: [issue18383] test_warnings modifies warnings.filters when running
 with "-W default"
In-Reply-To: <1373117774.47.0.846306714059.issue18383@psf.upfronthosting.co.za>
Message-ID: <1464221941.83.0.971468373796.issue18383@psf.upfronthosting.co.za>


Martin Panter added the comment:

New patch with common _add_filters() function, and added resetwarnings() calls to avoid the conflict with pre-defined filters.

----------
Added file: http://bugs.python.org/file43005/issue18383_avoid_dups_4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18383>
_______________________________________

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: [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  Wed May 25 21:56:32 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 26 May 2016 01:56:32 +0000
Subject: [issue27125] Typo in Python 2 multiprocessing documentation
In-Reply-To: <1464216185.35.0.531405853541.issue27125@psf.upfronthosting.co.za>
Message-ID: <1464227792.09.0.509621987737.issue27125@psf.upfronthosting.co.za>


Martin Panter added the comment:

The ?do authentication? error is already fixed in Python 3, but the other error also exists in Python 3. This patch also fixes related errors in Python 3 that I found.

----------
keywords: +patch
nosy: +martin.panter
stage:  -> patch review
versions: +Python 3.5, Python 3.6
Added file: http://bugs.python.org/file43007/will-be.py3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27125>
_______________________________________

From report at bugs.python.org  Wed May 25 21:57:21 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 26 May 2016 01:57:21 +0000
Subject: [issue27125] Typo in Python 2 multiprocessing documentation
In-Reply-To: <1464216185.35.0.531405853541.issue27125@psf.upfronthosting.co.za>
Message-ID: <1464227841.91.0.823331535231.issue27125@psf.upfronthosting.co.za>


Martin Panter added the comment:

Python 2 patch, including the do ? no fix

----------
Added file: http://bugs.python.org/file43008/will-be.py2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27125>
_______________________________________

From report at bugs.python.org  Wed May 25 22:47:27 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 26 May 2016 02:47:27 +0000
Subject: [issue26632] __all__ decorator
In-Reply-To: <1464162977.24.0.437491590252.issue26632@psf.upfronthosting.co.za>
Message-ID: <20160525224722.0ec1ad6f@anarchist.wooz.org>


Barry A. Warsaw added the comment:

On May 25, 2016, at 07:56 AM, Franklin? Lee wrote:

>>AttributeError: 'tuple' object has no attribute 'append'
>>which seems pretty obvious.  
>
>I don't think the C version shows a traceback, so it won't be clear that
>you're trying to assign to `__all__`.

Thanks!  I'll fix both the C and Python versions to raise a ValueError when
__all__ isn't a list.  I'll make the change in my atpublic PyPI project
(version 0.3) and will update the CPython patch if and when it gets accepted.

I think for now at least I won't autoconvert it to a list.  Happy to change
that if e.g. Guido prefers. :)

>>Well, consenting adults and all.  I'm not sure we need to protect ourselves
>>so strictly against people who don't read the docs and don't understand
>>Python (i.e. random cargo-culters).
>
>Python is a popular learning language, and many will be students who haven't
>yet trained to reflexively look up docs. I saw the lack of such habits in
>Python's IRC channel.
>
>"Consenting adults", I feel, is a reason to grant power: don't stop people
>from doing something they might need to do. But @public on a class method is
>just an error.

Would you consider submitting a patch on the project?

https://gitlab.com/warsaw/public

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26632>
_______________________________________

From report at bugs.python.org  Wed May 25 23:04:25 2016
From: report at bugs.python.org (Luiz Poleto)
Date: Thu, 26 May 2016 03:04:25 +0000
Subject: [issue27124] binascii.a2b_hex raises binascii.Error and ValueError,
 not TypeError
In-Reply-To: <1464190951.12.0.309980767012.issue27124@psf.upfronthosting.co.za>
Message-ID: <1464231865.98.0.0245399992994.issue27124@psf.upfronthosting.co.za>


Luiz Poleto added the comment:

binascii.Error is used throughout the module for most of the validations, with only a few of them using TypeError/ValueError. I guess it would make more sense to update these to raise binascii.Error (unless they were left on purpose) to make it consistent with the rest of the module, although changing from TypeError to binascii.Error might break existing code.

Anyway, since a2b_hex is currently raising binascii.Error for an odd-length input, the attached patch fixes the documentation to reflect it.

----------
keywords: +patch
nosy: +luiz.poleto
Added file: http://bugs.python.org/file43009/issue27124.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27124>
_______________________________________

From report at bugs.python.org  Wed May 25 23:41:22 2016
From: report at bugs.python.org (Ned Deily)
Date: Thu, 26 May 2016 03:41:22 +0000
Subject: [issue27126] Apple-supplied libsqlite3 on OS X is not fork safe;
 can cause crashes
In-Reply-To: <1464217505.87.0.0701340905112.issue27126@psf.upfronthosting.co.za>
Message-ID: <1464234082.87.0.50830094705.issue27126@psf.upfronthosting.co.za>


Ned Deily added the comment:

Thanks for your analysis!  I'm sure that you are correct about Issue20353.  It could also be the root cause of other crashes reported when internet proxies are used with urllib* invoking the _scproxy helper extension module, as reported in Issue13829.

The question is what can be done.  There seem to be two separate issues here.  The first is a crash when using Python's sqlite3 module, the problem your test case files demonstrate.  Note this *isn't* a problem when using the sqlite3 module from any of the current python.org OS X binary installer Pythons (2.7 or 3.x) because those Pythons do not use the Apple-supplied system libsqlite3; they already link with their own newer private copy.  Your py2 test, of course, does fail when using the Apple-supplied system Pythons.  We can't solve that problem; only Apple can; you could open a bug report with them.  If other distributors of Python on OS X rely on the system libsqlite3, they could avoid such crashes by also supplying their own copy.  For example, MacPorts already does, so your test cases don't fail with their Pythons.  I don't know what other distributors, like Homebrew or Anaconda, do.  We could add a note to Mac/README.

Second, the stickier (and totally separate) problem is what to do about _scproxy.  If, under the covers, the calls that _scproxy make to the Apple-supplied System Configuration framework use the un-forksafe Apple libsqlite3, there is nothing we can do about that; supplying a private copy of libsqlite3 isn't going to change what the framework uses and, in any case, it would be a really bad idea to even try to hack that.  So, if we don't change _scproxy or urllib*'s use of it, only Apple can fix the problem.  Since we can't expect that that is going to happen, the question becomes what alternatives are there.  One would be to find a way to eliminate _scproxy or its use of the unsafe SC framework calls.  Another approach would be to simply document ths restriction that urllib calls invoking ProxyHandler must be made in a main process (or whatever the precise restriction is) and leave it at that (https://docs.python.org/dev/library/urllib.request.html#urllib.request.ProxyHandler).

Ronald, what do you think?

----------
title: Mac system sqlite3 not fork safe: Bundle a version? -> Apple-supplied libsqlite3 on OS X is not fork safe;  can cause crashes
type:  -> crash
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27126>
_______________________________________

From report at bugs.python.org  Wed May 25 23:55:17 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 26 May 2016 03:55:17 +0000
Subject: [issue27122] Hang with contextlib.ExitStack and subprocess.Popen
 (regression)
In-Reply-To: <1464176880.25.0.308106356091.issue27122@psf.upfronthosting.co.za>
Message-ID: <1464234917.2.0.452314417939.issue27122@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Experimenting with this locally, it looks like the C level hang is indeed due to #25782, but the fact that we're implicitly trying to do "exc.__context__ = exc" is a new bug in _GeneratorContextManager introduced by the PEP 479 changes.

However, I'm now wondering whether that's also revealed a more general oversight in ExitStack's "_fix_exception_context" internal helper function: it's not explicitly handling the case where an __exit__ method re-raises the exception that was passed in, rather than returning a false value (indicating to the context management machinery that it should re-raise the original exception). I just hadn't noticed that before since all stdlib context managers are well-behaved in that regard (modulo bugs like the PEP 479 one).

Some failed attempts to create a simpler reproducer than Victor's last example show it isn't straightforward to get the current code to misbehave, but an upfront check for "new_exc is old_exc" may still be a worthwhile defensive coding measure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27122>
_______________________________________

From report at bugs.python.org  Thu May 26 00:08:41 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 26 May 2016 04:08:41 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1464235721.17.0.52705242412.issue26647@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Chatting to Russell Keith-Magee, I realised the bytecode section in the devguide's description of the code generation pipeline may need some tweaks to account for the differences between 3.6 and earlier versions: https://docs.python.org/devguide/compiler.html#ast-to-cfg-to-bytecode

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Thu May 26 00:12:10 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 26 May 2016 04:12:10 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1464235930.66.0.652233123212.issue26647@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I switched the target component to Documentation to reflect that as far as we know this is feature complete from a functional perspective, but there hasn't been a review of the docs for bytecode references yet, nor a decision on whether or not we want to systematically switching to using "wordcode" instead.

----------
components: +Documentation -Interpreter Core

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Thu May 26 00:22:08 2016
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 26 May 2016 04:22:08 +0000
Subject: [issue24225] Idlelib: changing file names
In-Reply-To: <1431934587.56.0.38760352205.issue24225@psf.upfronthosting.co.za>
Message-ID: <1464236528.94.0.886790375306.issue24225@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

To add to Terry's points: folks that would like to keep using the idlelib APIs as they exist in Python 3.5 will be free to create an idlelib35 project on PyPI, and bundle that or depend on it, depending on how their application manages dependencies.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24225>
_______________________________________

From report at bugs.python.org  Thu May 26 00:25:39 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 May 2016 04:25:39 +0000
Subject: [issue18383] test_warnings modifies warnings.filters when running
 with "-W default"
In-Reply-To: <1373117774.47.0.846306714059.issue18383@psf.upfronthosting.co.za>
Message-ID: <1464236739.3.0.369180672639.issue18383@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

LGTM, except that initial_len is now always 0.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18383>
_______________________________________

From report at bugs.python.org  Thu May 26 01:21:28 2016
From: report at bugs.python.org (Franklin? Lee)
Date: Thu, 26 May 2016 05:21:28 +0000
Subject: [issue26632] __all__ decorator
In-Reply-To: <1458786797.31.0.0749407715279.issue26632@psf.upfronthosting.co.za>
Message-ID: <1464240088.61.0.0252901998921.issue26632@psf.upfronthosting.co.za>


Franklin? Lee added the comment:

I probably won't submit a patch, but I can definitely write a bunch of private notes toward a patch and forget about them. >_>

Idea 1: Crawl up the call tree and see whether you hit a module definition or a class definition first.

Idea 2: Inspect __qualname__ to determine whether it's a method/inner function. That might have the same problems with @wraps, though, and you wouldn't be allowed to use a classmethod as a module's function.

Idea 2 seems to be the right thing. If ".__qualname__ != .__name__", it's an error. If you really want to use `public` in the above cases, you should use the assignment form of `public` (whatever it turns out to be), or explicitly append to __all__.

Rule: The programmer should not explicitly use `public(a_func)`, and should use assignment-form `public` if `@public` is not possible (== the decorator form is not being used at the point of definition). I think this way won't have errors passing silently and failing mysteriously.

First draft of error message (not considering assignment-form):
    "'public' should only be used as a decorator for a function/class in module scope."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26632>
_______________________________________

From report at bugs.python.org  Thu May 26 02:16:03 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 26 May 2016 06:16:03 +0000
Subject: [issue24225] Idlelib: changing file names
In-Reply-To: <1431934587.56.0.38760352205.issue24225@psf.upfronthosting.co.za>
Message-ID: <1464243363.36.0.702662384381.issue24225@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The only external uses I know of currently are the imports of percolator/colorizer and textview in turtledemo.  There is currently a coloring glitch in 3.5 which continues in 3.6 after the renames.  See #27117.  I won't be surprised if making the colorizer easier to test (by adding an option to explicity pass a color scheme, for instance) makes it easier to use.

I will keep other uses in mind if informed about them.

My careful use tests also pinned down an existing and bizarre glitch in tkinter.simpledialog, reported in #27115.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24225>
_______________________________________

From report at bugs.python.org  Thu May 26 02:29:45 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 26 May 2016 06:29:45 +0000
Subject: [issue27076] Doc and comment spelling fixes
In-Reply-To: <1463819479.86.0.838684690734.issue27076@psf.upfronthosting.co.za>
Message-ID: <20160526062924.627.15606.A1E25FF5@psf.io>


Roundup Robot added the comment:

New changeset a3a64b85883f by Martin Panter in branch '3.5':
Issue #27076: Doc, comment and tests spelling fixes
https://hg.python.org/cpython/rev/a3a64b85883f

New changeset 5d254703bd84 by Martin Panter in branch 'default':
Issue #27076: Merge spelling from 3.5
https://hg.python.org/cpython/rev/5d254703bd84

New changeset d3d8faaaaade by Martin Panter in branch 'default':
Issue #27076: More doc and comment spelling fixes for 3.6, by Ville Skytt?
https://hg.python.org/cpython/rev/d3d8faaaaade

New changeset 1e80e53ce20d by Martin Panter in branch '2.7':
Issue #27076: Doc, comment and test function name spelling fixes
https://hg.python.org/cpython/rev/1e80e53ce20d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27076>
_______________________________________

From report at bugs.python.org  Thu May 26 02:29:46 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 26 May 2016 06:29:46 +0000
Subject: [issue5486] doc copyedits
In-Reply-To: <1236968402.64.0.364958791658.issue5486@psf.upfronthosting.co.za>
Message-ID: <20160526062924.627.62346.6E252265@psf.io>


Roundup Robot added the comment:

New changeset 00f379f33a3e by Georg Brandl in branch '2.7':
#5486: typos.
https://hg.python.org/cpython/rev/00f379f33a3e

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5486>
_______________________________________

From report at bugs.python.org  Thu May 26 02:29:47 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 26 May 2016 06:29:47 +0000
Subject: [issue9911] doc copyedits
In-Reply-To: <1285080181.79.0.899000794299.issue9911@psf.upfronthosting.co.za>
Message-ID: <20160526062924.627.1520.D1E96788@psf.io>


Roundup Robot added the comment:

New changeset 90b49a29fe0c by Georg Brandl in branch '2.7':
#9911: doc copyedits.
https://hg.python.org/cpython/rev/90b49a29fe0c

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9911>
_______________________________________

From report at bugs.python.org  Thu May 26 02:29:47 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 26 May 2016 06:29:47 +0000
Subject: [issue21528] Fix a number of typos in the documentation
In-Reply-To: <1400456947.04.0.361173205763.issue21528@psf.upfronthosting.co.za>
Message-ID: <20160526062924.627.60831.F7B72ED9@psf.io>


Roundup Robot added the comment:

New changeset 33f6e360826e by Donald Stufft in branch '2.7':
Fix Issue #21528 - Fix documentation typos
https://hg.python.org/cpython/rev/33f6e360826e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21528>
_______________________________________

From report at bugs.python.org  Thu May 26 02:45:03 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 26 May 2016 06:45:03 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1464245103.31.0.13951917742.issue26647@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Hi, I ran the CPython benchmark suite (my fork modified to be more stable) on ed4eec682199 (patched) vs 7a7f54fe0698 (base). The patched version contains wordcode (issue #26647) + 16-bit fetch for opcode and oparg (issue #27097).

The speedup is quite nice. Attached default-May26-03-05-10.log contains the full output.

Faster (27):
- unpack_sequence: 1.11x faster
- simple_logging: 1.11x faster
- silent_logging: 1.10x faster
- formatted_logging: 1.09x faster
- raytrace: 1.08x faster
- chaos: 1.08x faster
- etree_process: 1.08x faster
- call_simple: 1.07x faster
- mako_v2: 1.07x faster
- tornado_http: 1.07x faster
- nqueens: 1.07x faster
- regex_compile: 1.06x faster
- pathlib: 1.06x faster
- 2to3: 1.06x faster
- richards: 1.05x faster
- spectral_norm: 1.05x faster
- etree_generate: 1.05x faster
- chameleon_v2: 1.04x faster
- pickle_list: 1.03x faster
- pickle_dict: 1.03x faster
- regex_v8: 1.03x faster
- go: 1.03x faster
- call_method: 1.03x faster
- django_v3: 1.03x faster
- telco: 1.02x faster
- json_load: 1.02x faster
- call_method_unknown: 1.02x faster

Slower (1):
- fannkuch: 1.07x slower

Not significat (14):
- unpickle_list
- startup_nosite
- regex_effbot
- pidigits
- normal_startup
- nbody
- meteor_contest
- json_dump_v2
- float
- fastunpickle
- fastpickle
- etree_parse
- etree_iterparse
- call_method_slots

----------
Added file: http://bugs.python.org/file43010/default-May26-03-05-10.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Thu May 26 04:47:27 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 26 May 2016 08:47:27 +0000
Subject: [issue27076] Doc and comment spelling fixes
In-Reply-To: <1463819479.86.0.838684690734.issue27076@psf.upfronthosting.co.za>
Message-ID: <1464252447.45.0.215928833439.issue27076@psf.upfronthosting.co.za>


Martin Panter added the comment:

I pushed all the changes, including the MSI files, except for ?heterogeneous?.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27076>
_______________________________________

From report at bugs.python.org  Thu May 26 05:03:13 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 26 May 2016 09:03:13 +0000
Subject: [issue27124] binascii.a2b_hex raises binascii.Error and ValueError,
 not TypeError
In-Reply-To: <1464190951.12.0.309980767012.issue27124@psf.upfronthosting.co.za>
Message-ID: <1464253393.15.0.201785871313.issue27124@psf.upfronthosting.co.za>


Martin Panter added the comment:

The TypeError ? binascii.Error changeover was made in revision eb45f85c4c79, to this function, along with various decoding functions in the base64 module. The base64 documenation was only slowly updated in a series of bug fixes, and it looks like unhexlify() is the only one left.

At the top of the binascii documentation, it says that the decoding functions accept ASCII strings. The general check for non-ASCII code points (raising ValueError) would be done before the specific checks for hexadecimal digits and having the right length.

Luiz?s patch looks okay to me.

----------
nosy: +martin.panter
stage:  -> patch review
versions: +Python 3.5, Python 3.6 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27124>
_______________________________________

From report at bugs.python.org  Thu May 26 05:11:55 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 May 2016 09:11:55 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1464253915.39.0.511390134967.issue26647@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think we should make yet few related changes:

* Change meaning of jump offsets. They should count not bytes, but code units (16-bit words). This will extend the range addressed by short commands (from 256 bytes to 256 words) and simplify ceval.c.
* Change f_lasti, tb_lasti etc to count code units instead of bytes.
* Change disassembler to show addresses in code units, not bytes.

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. That is why I think we should do this in this issue.

What is better, provide one large patch or separate simpler patches for every stage?

----------
components: +Interpreter Core

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Thu May 26 05:53:09 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 26 May 2016 09:53:09 +0000
Subject: [issue27106] configparser.__all__ is incomplete
In-Reply-To: <1464121705.13.0.123221989673.issue27106@psf.upfronthosting.co.za>
Message-ID: <1464256389.63.0.896750902606.issue27106@psf.upfronthosting.co.za>


Martin Panter added the comment:

My personal opinion is to include all public APIs. Names that are omitted from __all__ may not come up in pydoc, and it is surprising when I use ?import * ? in the interactive interpreter to play with a module and there is something missing.

To mitigate the risk of breaking code, I have been maintaining a list of the modules affected at <https://docs.python.org/3.6/whatsnew/3.6.html#changes-in-the-python-api>, which warns that extra symbols will be imported in 3.6.

On the other hand, there are other cases where people wanted to exclude APIs from __all__; I pointed out two at <https://bugs.python.org/issue26632#msg266117>.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27106>
_______________________________________

From report at bugs.python.org  Thu May 26 05:57:03 2016
From: report at bugs.python.org (Rotem Yaari)
Date: Thu, 26 May 2016 09:57:03 +0000
Subject: [issue25782] CPython hangs on error __context__ set to the error
 itself
In-Reply-To: <1449076441.38.0.963505882098.issue25782@psf.upfronthosting.co.za>
Message-ID: <1464256623.28.0.941420687636.issue25782@psf.upfronthosting.co.za>


Changes by Rotem Yaari <vmalloc at gmail.com>:


----------
nosy: +Rotem Yaari

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25782>
_______________________________________

From report at bugs.python.org  Thu May 26 06:15:59 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 26 May 2016 10:15:59 +0000
Subject: [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 06:32:40 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 26 May 2016 10:32:40 +0000
Subject: [issue18383] test_warnings modifies warnings.filters when running
 with "-W default"
In-Reply-To: <1373117774.47.0.846306714059.issue18383@psf.upfronthosting.co.za>
Message-ID: <20160526102654.627.30670.3FCA6E84@psf.io>


Roundup Robot added the comment:

New changeset f57f4e33ba5e by Martin Panter in branch '3.5':
Issue #18383: Avoid adding duplicate filters when warnings is reloaded
https://hg.python.org/cpython/rev/f57f4e33ba5e

New changeset 90bb91be6f3b by Martin Panter in branch 'default':
Issue #18383: Merge warnings fix from 3.5
https://hg.python.org/cpython/rev/90bb91be6f3b

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18383>
_______________________________________

From report at bugs.python.org  Thu May 26 06:36:10 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 26 May 2016 10:36:10 +0000
Subject: [issue27128] Add _PyObject_FastCall()
In-Reply-To: <1464257756.81.0.101125062969.issue27128@psf.upfronthosting.co.za>
Message-ID: <1464258970.03.0.07510502298.issue27128@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Quick & dirty microbenchmark: I ran bench_fast-2.py of the issue #26814. It looks like everything is slower :-p In fact, I already noticed this issue and I think that it is fixed with better compilation option: use "./configure --with-lto" and "make profile-opt". See my article:
https://haypo.github.io/journey-to-stable-benchmark-deadcode.html

----------------------------------+-------------+---------------
Tests                             |    original |       fastcall
----------------------------------+-------------+---------------
filter                            | 76.2 us (*) |  116 us (+52%)
map                               | 73.6 us (*) |  102 us (+38%)
sorted(list, key=lambda x: x)     |   82 us (*) |  121 us (+48%)
sorted(list)                      | 14.7 us (*) | 17.3 us (+18%)
b=MyBytes(); bytes(b)             |  182 ns (*) |  243 ns (+33%)
namedtuple.attr                   |  802 ns (*) | 1.44 us (+80%)
object.__setattr__(obj, "x", 1)   |  133 ns (*) |  166 ns (+25%)
object.__getattribute__(obj, "x") |  116 ns (*) |  142 ns (+22%)
getattr(1, "real")                |   76 ns (*) |   95 ns (+25%)
bounded_pymethod(1, 2)            |   72 ns (*) |  102 ns (+42%)
unbound_pymethod(obj, 1, 2)       |   71 ns (*) |   99 ns (+38%)
func()                            |   57 ns (*) |   81 ns (+41%)
func(1, 2, 3)                     |   72 ns (*) |  100 ns (+39%)
----------------------------------+-------------+---------------
Total                             |  248 us (*) |  358 us (+44%)
----------------------------------+-------------+---------------

At least, we have a starting point ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27128>
_______________________________________

From report at bugs.python.org  Thu May 26 07:10:59 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 May 2016 11:10:59 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1464261059.44.0.496970152632.issue26647@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is large patch (not including generated Python/importlib.h and Python/importlib_external.h).

----------
stage: needs patch -> patch review
Added file: http://bugs.python.org/file43012/wordcode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Thu May 26 07:24:44 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 May 2016 11:24:44 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1464261884.68.0.236275931128.issue26647@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


Removed file: http://bugs.python.org/file43012/wordcode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Thu May 26 07:25:13 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 May 2016 11:25:13 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1464261913.11.0.671580561115.issue26647@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


Added file: http://bugs.python.org/file43013/wordcode.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Thu May 26 07:39:57 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 26 May 2016 11:39:57 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1464261915.93.0.887496441223.issue26647@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwYpyL4RL1U3XDTTLTpk_equn5Nk8ydwKz2e4t0sKUZoZA@mail.gmail.com>


STINNER Victor added the comment:

Serhiy: please open a new issue for your change. While it's related, it's
different enough to deserve its own issue.

By the way , please don't include generated importlib .h file in your
patches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Thu May 26 08:07:45 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 26 May 2016 12:07:45 +0000
Subject: [issue18383] test_warnings modifies warnings.filters when running
 with "-W default"
In-Reply-To: <1373117774.47.0.846306714059.issue18383@psf.upfronthosting.co.za>
Message-ID: <1464264465.49.0.667219675533.issue18383@psf.upfronthosting.co.za>


Martin Panter added the comment:

I eliminated initial_len from my final version.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18383>
_______________________________________

From report at bugs.python.org  Thu May 26 08:13:40 2016
From: report at bugs.python.org (Demur Rumed)
Date: Thu, 26 May 2016 12:13:40 +0000
Subject: [issue27097] ceval: Wordcode follow up, explicit unsigned short read
In-Reply-To: <1464048499.12.0.811410474415.issue27097@psf.upfronthosting.co.za>
Message-ID: <1464264820.4.0.074870599633.issue27097@psf.upfronthosting.co.za>


Demur Rumed added the comment:

PREDICT could be optimized by having a HAS_ARG check on the constant op to decide whether we assign oparg = OPARG(word)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27097>
_______________________________________

From report at bugs.python.org  Thu May 26 09:09:42 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 26 May 2016 13:09:42 +0000
Subject: [issue27128] Add _PyObject_FastCall()
In-Reply-To: <1464257756.81.0.101125062969.issue27128@psf.upfronthosting.co.za>
Message-ID: <1464268182.3.0.363385586196.issue27128@psf.upfronthosting.co.za>


STINNER Victor added the comment:

default-May26-13-36-33.log: CPython benchmark suite run using stable config.

Faster (15):
- regex_effbot: 1.26x faster
- telco: 1.08x faster
- unpack_sequence: 1.07x faster
- mako_v2: 1.05x faster
- meteor_contest: 1.05x faster
- chaos: 1.04x faster
- nbody: 1.04x faster
- call_method_slots: 1.04x faster
- etree_iterparse: 1.04x faster
- etree_parse: 1.04x faster
- call_method: 1.03x faster
- raytrace: 1.03x faster
- nqueens: 1.03x faster
- call_method_unknown: 1.03x faster
- formatted_logging: 1.02x faster

Slower (8):
- etree_generate: 1.05x slower
- etree_process: 1.03x slower
- call_simple: 1.03x slower
- chameleon_v2: 1.02x slower
- pathlib: 1.02x slower
- float: 1.02x slower
- silent_logging: 1.02x slower
- json_load: 1.02x slower

----------
Added file: http://bugs.python.org/file43014/default-May26-13-36-33.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27128>
_______________________________________

From report at bugs.python.org  Thu May 26 09:10:52 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 26 May 2016 13:10:52 +0000
Subject: [issue27128] Add _PyObject_FastCall()
In-Reply-To: <1464257756.81.0.101125062969.issue27128@psf.upfronthosting.co.za>
Message-ID: <1464268252.04.0.184565962287.issue27128@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Updated bench_fast-2.py result with Python compiled with PGO+LTO, with benchmark.py fixed to compute average + standard deviation. Only getattr() really seems slower:

----------------------------------+-----------------------+--------------------------
Tests                             |              original |                  fastcall
----------------------------------+-----------------------+--------------------------
filter                            | 75.8 us +- 0.1 us (*) |         78.1 us +- 0.1 us
map                               | 72.6 us +- 0.1 us (*) |         71.4 us +- 0.0 us
sorted(list, key=lambda x: x)     | 83.7 us +- 0.1 us (*) |         82.3 us +- 0.3 us
sorted(list)                      | 14.9 us +- 0.0 us (*) |         14.7 us +- 0.0 us
b=MyBytes(); bytes(b)             |    199 ns +- 2 ns (*) |            194 ns +- 1 ns
namedtuple.attr                   |   830 ns +- 20 ns (*) | 1.09 us +- 0.01 us (+31%)
object.__setattr__(obj, "x", 1)   |    133 ns +- 0 ns (*) |            134 ns +- 1 ns
object.__getattribute__(obj, "x") |    117 ns +- 0 ns (*) |            115 ns +- 1 ns
getattr(1, "real")                | 93.2 ns +- 0.9 ns (*) |  76.9 ns +- 0.7 ns (-17%)
bounded_pymethod(1, 2)            | 73.4 ns +- 0.6 ns (*) |         70.7 ns +- 0.4 ns
unbound_pymethod(obj, 1, 2)       | 74.5 ns +- 0.2 ns (*) |         71.8 ns +- 0.6 ns
func()                            | 60.2 ns +- 0.4 ns (*) |         59.3 ns +- 0.1 ns
func(1, 2, 3)                     | 74.6 ns +- 0.4 ns (*) |         72.2 ns +- 0.3 ns
----------------------------------+-----------------------+--------------------------
Total                             |            249 us (*) |                    248 us
----------------------------------+-----------------------+--------------------------

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27128>
_______________________________________

From report at bugs.python.org  Thu May 26 09:13:12 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 May 2016 13:13:12 +0000
Subject: [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:14:27 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 May 2016 13:14:27 +0000
Subject: [issue26647] ceval: use Wordcode, 16-bit bytecode
In-Reply-To: <1459034868.93.0.159802163565.issue26647@psf.upfronthosting.co.za>
Message-ID: <1464268467.64.0.824236029409.issue26647@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Issue27129.

----------
components:  -Interpreter Core
dependencies: +Wordcode, part 2
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26647>
_______________________________________

From report at bugs.python.org  Thu May 26 09:14:36 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 26 May 2016 13:14:36 +0000
Subject: [issue18383] test_warnings modifies warnings.filters when running
 with "-W default"
In-Reply-To: <1373117774.47.0.846306714059.issue18383@psf.upfronthosting.co.za>
Message-ID: <1464268476.13.0.952221378974.issue18383@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Note: My issue #26742 has been marked as a duplicate of this one.

I confirm that "./python -Wd -m test -j0 test_warnings" doesn't complain "1 test altered the execution environment: test_warnings" anymore. Thanks for the fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18383>
_______________________________________

From report at bugs.python.org  Thu May 26 09:23:35 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 26 May 2016 13:23:35 +0000
Subject: [issue27097] ceval: Wordcode follow up, explicit unsigned short read
In-Reply-To: <1464264820.4.0.074870599633.issue27097@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZ5obmwjRuCyotOLAeW3ORxKVHL3thLE8PzsarL_m2C7g@mail.gmail.com>


STINNER Victor added the comment:

Please focus this issue on documenting changes, and open new issues
for further optimizations.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27097>
_______________________________________

From report at bugs.python.org  Thu May 26 09:29:29 2016
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 26 May 2016 13:29:29 +0000
Subject: [issue27129] Wordcode, part 2
In-Reply-To: <1464268387.83.0.862540030058.issue27129@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbaT+eo+1O54fcVFpUsxq4+Ri_01qoXxOpK+BzR-Hr0_g@mail.gmail.com>


STINNER Victor added the comment:

> Changes f_lasti, tb_lasti etc to count code units instead of bytes.

I asked Demur to not break f_lasti. I don't understand if this change
breaks applications using f_lasti or not.

For example, asyncio/coroutines.py uses:

            if caller.f_code.co_code[caller.f_lasti] != _YIELD_FROM:
                value = value[0]

Does this code still work with your change?

Maybe this code is already broken by wordcode, but it doesn't really
matter since it should only be used on the exact version 3.4.0. The
code works around a bug in Python 3.4.0, fixed in Python 3.4.1 (issue
#21209).

Other known users of f_lasti are development tools like debuggers
(pdb), profilers, code coverage, etc. We should check these tools.

----------

_______________________________________
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: [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 09:59:30 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 26 May 2016 13:59:30 +0000
Subject: [issue27130] zlib: OverflowError while trying to compress 2^32 bytes
 or more
In-Reply-To: <1464270042.87.0.0233765451432.issue27130@psf.upfronthosting.co.za>
Message-ID: <1464271170.44.0.495612389689.issue27130@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

This behaviour seems to have been fixed in issue25626. But you can only get that feature with Python3.5+.

----------
nosy: +xiang.zhang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27130>
_______________________________________

From report at bugs.python.org  Thu May 26 09:59:53 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 26 May 2016 13:59:53 +0000
Subject: [issue27130] zlib: OverflowError while trying to compress 2^32 bytes
 or more
In-Reply-To: <1464270042.87.0.0233765451432.issue27130@psf.upfronthosting.co.za>
Message-ID: <1464271193.95.0.537925284391.issue27130@psf.upfronthosting.co.za>


Changes by Xiang Zhang <angwerzx at 126.com>:


----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27130>
_______________________________________

From report at bugs.python.org  Thu May 26 10:01:32 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 26 May 2016 14:01:32 +0000
Subject: [issue5996] abstract class instantiable when subclassing dict
In-Reply-To: <1242050763.07.0.145569961651.issue5996@psf.upfronthosting.co.za>
Message-ID: <1464271292.48.0.611123179412.issue5996@psf.upfronthosting.co.za>


Changes by Xiang Zhang <angwerzx at 126.com>:


----------
nosy: +xiang.zhang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5996>
_______________________________________

From report at bugs.python.org  Thu May 26 10:13:07 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 26 May 2016 14:13:07 +0000
Subject: [issue26816] Make concurrent.futures.Executor an abc
In-Reply-To: <1461236512.66.0.771218032413.issue26816@psf.upfronthosting.co.za>
Message-ID: <1464271987.39.0.542336005188.issue26816@psf.upfronthosting.co.za>


Changes by Xiang Zhang <angwerzx at 126.com>:


----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26816>
_______________________________________

From report at bugs.python.org  Thu May 26 10:21:52 2016
From: report at bugs.python.org (Andrea De Pasquale)
Date: Thu, 26 May 2016 14:21:52 +0000
Subject: [issue27010] email library could "recover" from bad mime boundary
 like (some?) email clients do
In-Reply-To: <1463067718.45.0.558318505018.issue27010@psf.upfronthosting.co.za>
Message-ID: <1464272512.9.0.979144794996.issue27010@psf.upfronthosting.co.za>


Andrea De Pasquale added the comment:

How about the following patch? If it's different from what you had in mind, please let me know.

----------
keywords: +patch
Added file: http://bugs.python.org/file43016/issue27010-notuniqueboundary.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27010>
_______________________________________

From report at bugs.python.org  Thu May 26 10:27:58 2016
From: report at bugs.python.org (Evan Jones)
Date: Thu, 26 May 2016 14:27:58 +0000
Subject: [issue27126] Apple-supplied libsqlite3 on OS X is not fork safe;
 can cause crashes
In-Reply-To: <1464217505.87.0.0701340905112.issue27126@psf.upfronthosting.co.za>
Message-ID: <1464272878.96.0.814422528364.issue27126@psf.upfronthosting.co.za>


Evan Jones added the comment:

To be clear: My reproduction scripts crash both Python 2.7.10 and Python 3.5.1 when you:

1. Download the source bundle from python.org.
2. Run ./configure; make
3. Use the built binary (because ./configure picks up the system version of libsqlite.dylib)

I did some more digging: The underlying root cause is Mac OS X's libdispatch.dylib. A ton of system APIs (like this proxy one, or GUI libraries, etc), use it. It seems the proxy settings API use it to manage inter-process communication. libdispatch has code that explicitly "poisons" the process if it forks. I think this is because it internally spawns threads, so the forked child state is unreliable, and they figure it is better for it to crash than to fail randomly. This is the classic "don't mix threads and fork" issue, its just that the threads are hidden inside a bunch of system APIs.

One fix for this particular bug would be for _scproxy to fork and use IPC to read the settings, which I think was mentioned in Issue13829. I think it would not also be crazy to ship the amalgamated sqlite3 with Python, to avoid an accidental dependency on sqlite3.

Finally: it might make sense to have 'forkserver' be the default mode for multiprocessing on Mac OS X, since there are other things that cause this same problem (Tkinter is reported on the internet).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27126>
_______________________________________

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: [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 11:28:32 2016
From: report at bugs.python.org (R. David Murray)
Date: Thu, 26 May 2016 15:28:32 +0000
Subject: [issue27010] email library could "recover" from bad mime boundary
 like (some?) email clients do
In-Reply-To: <1463067718.45.0.558318505018.issue27010@psf.upfronthosting.co.za>
Message-ID: <1464276512.91.0.723889506919.issue27010@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks for the patch.  I'll take a look at this during the PyCon sprints.

----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27010>
_______________________________________

From report at bugs.python.org  Thu May 26 11:36:31 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 26 May 2016 15:36:31 +0000
Subject: [issue5996] abstract class instantiable when subclassing dict
In-Reply-To: <1242050763.07.0.145569961651.issue5996@psf.upfronthosting.co.za>
Message-ID: <1464276991.88.0.298998723298.issue5996@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <raymond.hettinger at gmail.com>:


----------
assignee: rhettinger -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5996>
_______________________________________

From report at bugs.python.org  Thu May 26 11:37:22 2016
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Thu, 26 May 2016 15:37:22 +0000
Subject: [issue26526] In parsermodule.c,
 replace over 2KLOC of hand-crafted validation code, with a DFA
In-Reply-To: <1457600551.84.0.318395917649.issue26526@psf.upfronthosting.co.za>
Message-ID: <1464277042.12.0.282189466425.issue26526@psf.upfronthosting.co.za>


Fred L. Drake, Jr. added the comment:

I see your message to python-dev, and apologize for taking so long to get to this.

I do intend to read through your changes, and hope to be able to make time while I'm at PyCon this coming week.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26526>
_______________________________________

From report at bugs.python.org  Thu May 26 11:39:06 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 26 May 2016 15:39:06 +0000
Subject: [issue27131] Unit test random shuffle
Message-ID: <1464277146.71.0.570096870767.issue27131@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

This tests that a specific shuffle result is obtained (which is an implementation specific detail subject to change).  An alternate possible test would just check to see that all the inputs are present in the output.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27131>
_______________________________________

From report at bugs.python.org  Thu May 26 12:07:45 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 26 May 2016 16:07:45 +0000
Subject: [issue21084] IDLE can't deal with characters above the range
 (U+0000-U+FFFF)
In-Reply-To: <1396008065.84.0.00802001667749.issue21084@psf.upfronthosting.co.za>
Message-ID: <1464278865.47.0.5835035296.issue21084@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Tk Text (and other widgets, but Text is the main issue) has two display problems: astral chars and long lines (over a thousand chars, say).  These problems can manifest in various places: file names, shell input (keyboard or clipboard), shell output, editor input (keyboard, clipboard, or file).  IDLE needs to take more control over what is displayed to work around both problems.

Tk Text also has a display feature: substring tagging.  I have been heistant to simple replace astral chars with their \U000hhhhh expansion because of the aliasing problem: in shell output, for instance, the user would not know if the program wrote 1 char or 10.  It would also be impossible to know if a reverse transformation might be needed.  Tagging astral expansions would solve both problems.

import re

astral = re.compile(r'([^\x00-\uffff])')
s = 'X\U00011111Y\U00011112\U00011113Z'
for i, ss in enumerate(re.split(astral, s)):
    if not i%2:
        print(ss, end='')
    else:
        print(r'\\U%08x' % ord(ss), end='')
# prints
X\\U00011111Y\\U00011112\\U00011113Z

Now replace print with test.insert, with an 'astral' tag for the second.  tk will not double '\'s.  Astral tag could switch, for instance, to underline version of current font.  This should work with any color scheme.

[Separate but related issue: augment Format or context menu with functions to convert between literal char, escape string, and name representation (using unicodedatabase).]

----------
nosy: +terry.reedy
resolution: duplicate -> 
versions: +Python 3.6 -Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21084>
_______________________________________

From report at bugs.python.org  Thu May 26 12:58:30 2016
From: report at bugs.python.org (Nathan Harold)
Date: Thu, 26 May 2016 16:58:30 +0000
Subject: =?utf-8?q?=5Bissue27043=5D_Describe_what_=E2=80=98inspect=2Ecleandoc?=
 =?utf-8?q?=E2=80=99_does_to_synopsis_line=2E?=
In-Reply-To: <1463445757.83.0.886794484792.issue27043@psf.upfronthosting.co.za>
Message-ID: <1464281910.68.0.147653695421.issue27043@psf.upfronthosting.co.za>


Nathan Harold added the comment:

Here's my shot at a revision (corresponding patch attached):

   Clean up indentation from docstrings that are indented to line up with blocks
   of code.  All leading whitespace is removed from the first line.  Any leading
   whitespace that can be uniformly removed from the second line onwards is
   removed.  Empty lines at the beginning and end are subsequently removed.  Also,
   all tabs are expanded to spaces.

This version also makes it explicit that nothing happens to trailing whitespace, should a line happen to have any.  This actually seems to be a difference between this function and the sample implementation in the PEP.

One odd side effect of that difference is that a line consisting only of whitespace may actually not be removed from the beginning or end of the string, if the preceding whitespace removals aren't sufficient to leave the line completely empty.  For instance:

>>> inspect.cleandoc('   A \n  B \n   \n  ')
'A \nB \n '

Two spaces are removed from each of the second, third, and fourth lines.  The fourth line is then empty and is removed; the third line still contains one space and is kept.

On the other hand, as defined in the PEP, the extra space on the third line is removed as trailing whitespace, so that the third line is then removed entirely:

>>> trim('   A \n  B \n   \n  ')
'A\nB'

Most likely this difference rarely affects anything.  In any case, mentioning it here because it influenced exactly how I revised the docs.

----------
keywords: +patch
nosy: +nharold
Added file: http://bugs.python.org/file43018/cleandoc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27043>
_______________________________________

From report at bugs.python.org  Thu May 26 13:13:57 2016
From: report at bugs.python.org (B. Clausius)
Date: Thu, 26 May 2016 17:13:57 +0000
Subject: [issue1222585] C++ compilation support for distutils
Message-ID: <1464282837.78.0.432988512077.issue1222585@psf.upfronthosting.co.za>


Changes by B. Clausius <barcc at gmx.de>:


----------
nosy: +barcc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1222585>
_______________________________________

From report at bugs.python.org  Thu May 26 14:04:02 2016
From: report at bugs.python.org (jonathan.kross)
Date: Thu, 26 May 2016 18:04:02 +0000
Subject: [issue27131] Unit test random shuffle
In-Reply-To: <1464277146.71.0.570096870767.issue27131@psf.upfronthosting.co.za>
Message-ID: <1464285842.18.0.615251233535.issue27131@psf.upfronthosting.co.za>


jonathan.kross added the comment:

Changed the test to assertCountEqual which will check that all the inputs are present and equal in the output.

----------
Added file: http://bugs.python.org/file43019/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 14:04:22 2016
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 26 May 2016 18:04:22 +0000
Subject: [issue26526] In parsermodule.c,
 replace over 2KLOC of hand-crafted validation code, with a DFA
In-Reply-To: <1457600551.84.0.318395917649.issue26526@psf.upfronthosting.co.za>
Message-ID: <1464285862.38.0.000214375042492.issue26526@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26526>
_______________________________________

From report at bugs.python.org  Thu May 26 14:07:14 2016
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 26 May 2016 18:07:14 +0000
Subject: [issue27129] Wordcode, part 2
In-Reply-To: <1464268387.83.0.862540030058.issue27129@psf.upfronthosting.co.za>
Message-ID: <1464286034.81.0.644471329272.issue27129@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27129>
_______________________________________

From report at bugs.python.org  Thu May 26 14:38:31 2016
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 26 May 2016 18:38:31 +0000
Subject: [issue27129] Wordcode, part 2
In-Reply-To: <1464268387.83.0.862540030058.issue27129@psf.upfronthosting.co.za>
Message-ID: <1464287911.89.0.316622734303.issue27129@psf.upfronthosting.co.za>


Brett Cannon added the comment:

So is avoiding changing f_lasti just to minimize breakage of tools? Aren't they going to have to update to support the wordcode changes anyway?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27129>
_______________________________________

From report at bugs.python.org  Thu May 26 14:55:33 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 May 2016 18:55:33 +0000
Subject: [issue27129] Wordcode, part 2
In-Reply-To: <1464268387.83.0.862540030058.issue27129@psf.upfronthosting.co.za>
Message-ID: <1464288933.11.0.881026034037.issue27129@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The patch contains the change of Lib/asyncio/coroutines.py. This is the only change in Python code besides the dis module.

I can keep f_lasti to be twice the number of instructions, but this will complicate the patch. The simplest way perhaps is to convert this read-only attribute to the property that multiplies internal f_lasti by 2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27129>
_______________________________________

From report at bugs.python.org  Thu May 26 15:18:25 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 26 May 2016 19:18:25 +0000
Subject: [issue27114] SSLContext._load_windows_store_certs fails with
 PermissionError
In-Reply-To: <1464128675.76.0.296997884833.issue27114@psf.upfronthosting.co.za>
Message-ID: <20160526191813.121226.55802.0DA43755@psf.io>


Roundup Robot added the comment:

New changeset 40f3f2b27112 by Steve Dower in branch '2.7':
Issue #27114: Fix SSLContext._load_windows_store_certs fails with PermissionError
https://hg.python.org/cpython/rev/40f3f2b27112

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27114>
_______________________________________

From report at bugs.python.org  Thu May 26 15:20:11 2016
From: report at bugs.python.org (Roundup Robot)
Date: Thu, 26 May 2016 19:20:11 +0000
Subject: [issue27114] SSLContext._load_windows_store_certs fails with
 PermissionError
In-Reply-To: <1464128675.76.0.296997884833.issue27114@psf.upfronthosting.co.za>
Message-ID: <20160526192006.121210.77261.89F476D0@psf.io>


Roundup Robot added the comment:

New changeset 29f163db229e by Steve Dower in branch '3.5':
Issue #27114: Fix SSLContext._load_windows_store_certs fails with PermissionError
https://hg.python.org/cpython/rev/29f163db229e

New changeset eaee5aed6fbc by Steve Dower in branch 'default':
Issue #27114: Fix SSLContext._load_windows_store_certs fails with PermissionError
https://hg.python.org/cpython/rev/eaee5aed6fbc

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27114>
_______________________________________

From report at bugs.python.org  Thu May 26 15:26:06 2016
From: report at bugs.python.org (Steve Dower)
Date: Thu, 26 May 2016 19:26:06 +0000
Subject: [issue27114] SSLContext._load_windows_store_certs fails with
 PermissionError
In-Reply-To: <1464128675.76.0.296997884833.issue27114@psf.upfronthosting.co.za>
Message-ID: <1464290766.87.0.117475201716.issue27114@psf.upfronthosting.co.za>


Steve Dower added the comment:

One slight change to the patch for 2.7 - has to catch OSError.

Just realised that I forgot to mention the reason we shouldn't just let the exception propagate out is that we then never load certificates specified by the SSL_CERT_FILE variable. Handling the exception allows a workaround.

If the exception occurs and no other certificates have been provided, it seems certain that a later operation is going to fail with a much more useful message (i.e. unverifiable connection, or whatever it says). There are also libraries (I think urllib is the one that was causing me actual trouble) that keep retrying the call when it fails, and all of those would need to be updated to handle this error.

The docs don't specify potential exceptions, so I see only good by not raising an exception here.

----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27114>
_______________________________________

From report at bugs.python.org  Thu May 26 15:28:09 2016
From: report at bugs.python.org (Steve Dower)
Date: Thu, 26 May 2016 19:28:09 +0000
Subject: [issue27114] SSLContext._load_windows_store_certs fails with
 PermissionError
In-Reply-To: <1464128675.76.0.296997884833.issue27114@psf.upfronthosting.co.za>
Message-ID: <1464290889.05.0.329985836886.issue27114@psf.upfronthosting.co.za>


Changes by Steve Dower <steve.dower at python.org>:


----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27114>
_______________________________________

From report at bugs.python.org  Thu May 26 15:43:18 2016
From: report at bugs.python.org (Klamann)
Date: Thu, 26 May 2016 19:43:18 +0000
Subject: [issue27130] zlib: OverflowError while trying to compress 2^32 bytes
 or more
In-Reply-To: <1464270042.87.0.0233765451432.issue27130@psf.upfronthosting.co.za>
Message-ID: <1464291798.95.0.489788824859.issue27130@psf.upfronthosting.co.za>


Klamann added the comment:

> But you can only get that feature with Python3.5+.

Well, I have Python 3.5.1 installed and the problem still persists. I'm not sure that 25626 ist the same problem - in the comments they say this was not an issue in Python 3.4 or 2.x, but this is clearly the case here.

Another thing I've noticed: Contrary to my previous statement, zlib.decompress() doesn't work on archives that are larger than 4GB (I was mislead by the fact that my 1GB archive contained a 6GB file).

When I use gzip.compress() on more than 2^32 bytes, the same OverflowError occurs as with zlib.compress(). But when I use gzip.decompress(), I can extract archives that are larger than 4GB.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27130>
_______________________________________

From report at bugs.python.org  Thu May 26 16:00:05 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 26 May 2016 20:00:05 +0000
Subject: [issue27131] Unit test random shuffle
In-Reply-To: <1464277146.71.0.570096870767.issue27131@psf.upfronthosting.co.za>
Message-ID: <1464292805.56.0.0488260095088.issue27131@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Okay, this looks fine.  I'll apply it within a few days.

----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27131>
_______________________________________

From report at bugs.python.org  Thu May 26 16:23:02 2016
From: report at bugs.python.org (ppperry)
Date: Thu, 26 May 2016 20:23:02 +0000
Subject: [issue27012] Rename the posix module to _os
In-Reply-To: <1463080606.17.0.881585678376.issue27012@psf.upfronthosting.co.za>
Message-ID: <1464294182.4.0.123464586539.issue27012@psf.upfronthosting.co.za>


Changes by ppperry <mapreader at olum.org>:


----------
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27012>
_______________________________________

From report at bugs.python.org  Thu May 26 16:31:41 2016
From: report at bugs.python.org (Dino Viehland)
Date: Thu, 26 May 2016 20:31:41 +0000
Subject: [issue27127] Never have GET_ITER not followed by FOR_ITER
In-Reply-To: <1464227064.89.0.81963094053.issue27127@psf.upfronthosting.co.za>
Message-ID: <1464294701.61.0.466029083717.issue27127@psf.upfronthosting.co.za>


Dino Viehland added the comment:

I like how this makes the loop opcodes more regular - it should make things like Pyjion (http://www.github.com/Microsoft/Pyjion) which translate bytecode into native code.  We already have some code (currently commented out) checking that GET_ITER is followed by FOR_ITER to do some optimizations around loops.  

Another issue we ran into was that this leaves the iterable on the stack while the loop is running...  I'm just curious if your larger change alter that in anyway?

----------
nosy: +dino.viehland

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27127>
_______________________________________

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: [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 16:58:22 2016
From: report at bugs.python.org (Nathan Harold)
Date: Thu, 26 May 2016 20:58:22 +0000
Subject: [issue26553] Write HTTP in uppercase
In-Reply-To: <1457936613.19.0.773642660577.issue26553@psf.upfronthosting.co.za>
Message-ID: <1464296302.28.0.912266573515.issue26553@psf.upfronthosting.co.za>


Nathan Harold added the comment:

The 2_fix* patches were unfortunately slightly broken because an unrelated revision to xmlrpc.client.rst changed one of the lines the patch files were using as an anchor (by adding a period to the end).

I've uploaded the 3_fix* series, which addresses this.  The actual changes in these patches are identical to those in their precursors: capitalization of HTTP, HTTPS, FTP, and URL in a few places.

----------
nosy: +nharold
Added file: http://bugs.python.org/file43020/3_fix_3.6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26553>
_______________________________________

From report at bugs.python.org  Thu May 26 16:58:36 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 26 May 2016 20:58:36 +0000
Subject: [issue27132] New assert method that checks an error message for a
 list of strings
In-Reply-To: <1464295693.41.0.439639952512.issue27132@psf.upfronthosting.co.za>
Message-ID: <1464296316.69.0.844219086947.issue27132@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

You can use assertRaisesRegex() for this.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27132>
_______________________________________

From report at bugs.python.org  Thu May 26 16:58:48 2016
From: report at bugs.python.org (Nathan Harold)
Date: Thu, 26 May 2016 20:58:48 +0000
Subject: [issue26553] Write HTTP in uppercase
In-Reply-To: <1457936613.19.0.773642660577.issue26553@psf.upfronthosting.co.za>
Message-ID: <1464296328.56.0.915631300443.issue26553@psf.upfronthosting.co.za>


Changes by Nathan Harold <penw81-ml at yahoo.com>:


Added file: http://bugs.python.org/file43021/3_fix_3.5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26553>
_______________________________________

From report at bugs.python.org  Thu May 26 16:59:30 2016
From: report at bugs.python.org (Nathan Harold)
Date: Thu, 26 May 2016 20:59:30 +0000
Subject: [issue26553] Write HTTP in uppercase
In-Reply-To: <1457936613.19.0.773642660577.issue26553@psf.upfronthosting.co.za>
Message-ID: <1464296370.66.0.938205675573.issue26553@psf.upfronthosting.co.za>


Changes by Nathan Harold <penw81-ml at yahoo.com>:


Added file: http://bugs.python.org/file43022/3_fix_2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26553>
_______________________________________

From report at bugs.python.org  Thu May 26 17:29:29 2016
From: report at bugs.python.org (Maciej Szulik)
Date: Thu, 26 May 2016 21:29:29 +0000
Subject: [issue27132] New assert method that checks an error message for a
 list of strings
In-Reply-To: <1464295693.41.0.439639952512.issue27132@psf.upfronthosting.co.za>
Message-ID: <1464298169.93.0.452305260304.issue27132@psf.upfronthosting.co.za>


Maciej Szulik added the comment:

You could, but then you end up writing nasty regex-es to do that. The idea here is to create a native function that will verify a number of words in whatever order.

----------

_______________________________________
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: [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 18:01:25 2016
From: report at bugs.python.org (Zachary Ware)
Date: Thu, 26 May 2016 22:01:25 +0000
Subject: [issue27133] python 3.5.1 will not compile because libffi module uses
 wrong CFLAGS
In-Reply-To: <1464299251.55.0.694249257494.issue27133@psf.upfronthosting.co.za>
Message-ID: <1464300085.82.0.117497454378.issue27133@psf.upfronthosting.co.za>


Zachary Ware added the comment:

Would you be interested in submitting a patch?  The whole ctypes package and the bundled libffi in particular are fairly unloved.

As a workaround, if you have libffi installed on your system, you can use the '--with-system-ffi' flag to Python's configure script to direct the ctypes build to use the installed libffi.

Also note that unless you specifically need ctypes (or are building for someone who might), it may not be the end of the world for ctypes to not be available; the overall build should not fail just due to a ctypes build failure.

----------
nosy: +amaury.forgeotdarc, belopolsky, meador.inge, zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27133>
_______________________________________

From report at bugs.python.org  Thu May 26 19:04:11 2016
From: report at bugs.python.org (Maciej Szulik)
Date: Thu, 26 May 2016 23:04:11 +0000
Subject: [issue25591] refactor imaplib tests
In-Reply-To: <1447107407.81.0.130095933409.issue25591@psf.upfronthosting.co.za>
Message-ID: <1464303851.9.0.0576643729853.issue25591@psf.upfronthosting.co.za>


Maciej Szulik added the comment:

David I'm uploading the patch with all the review comments addressed. The changes from just the review can be seen here: https://bitbucket.org/soltysh/cpython/commits/91708e0c6e7c5230bd69b1135b82ef47b6dc4d43?at=default (please ignore the changes to test_logincapa_withclient_certfile, these are not part of the final patch).

----------
Added file: http://bugs.python.org/file43023/new_imap_tests_v4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25591>
_______________________________________

From report at bugs.python.org  Thu May 26 19:28:00 2016
From: report at bugs.python.org (Martin Panter)
Date: Thu, 26 May 2016 23:28:00 +0000
Subject: [issue27132] New assert method that checks an error message for a
 list of strings
In-Reply-To: <1464295693.41.0.439639952512.issue27132@psf.upfronthosting.co.za>
Message-ID: <1464305280.07.0.38432994137.issue27132@psf.upfronthosting.co.za>


Martin Panter added the comment:

Maybe a generic superset test would be good enough:

def assertSuperset(self, superset, subset):
    # Expand for friendlier failure handling
    self.assertTrue(all(e in superset for e in subset))

self.assertSuperset("Error message", ("mess", "or me"))

Or is that too obscure, treating a string as a set of substrings?

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27132>
_______________________________________

From report at bugs.python.org  Thu May 26 20:09:31 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 27 May 2016 00:09:31 +0000
Subject: =?utf-8?q?=5Bissue27043=5D_Describe_what_=E2=80=98inspect=2Ecleandoc?=
 =?utf-8?q?=E2=80=99_does_to_synopsis_line=2E?=
In-Reply-To: <1463445757.83.0.886794484792.issue27043@psf.upfronthosting.co.za>
Message-ID: <1464307771.18.0.862617509168.issue27043@psf.upfronthosting.co.za>


Martin Panter added the comment:

Patch looks good to me, thanks Nathan

----------
nosy: +martin.panter
stage:  -> patch review
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27043>
_______________________________________

From report at bugs.python.org  Thu May 26 21:11:44 2016
From: report at bugs.python.org (Ben Finney)
Date: Fri, 27 May 2016 01:11:44 +0000
Subject: =?utf-8?q?=5Bissue27043=5D_Describe_what_=E2=80=98inspect=2Ecleandoc?=
 =?utf-8?q?=E2=80=99_does_to_synopsis_line=2E?=
In-Reply-To: <1464281910.68.0.147653695421.issue27043@psf.upfronthosting.co.za>
Message-ID: <1464311501.2653593.620104361.01981811@webmail.messagingengine.com>


Ben Finney added the comment:

On Fri, May 27, 2016, at 02:58, Nathan Harold wrote:
> Here's my shot at a revision (corresponding patch attached):

Thanks for that. The only improvement I'd ask for is to more clearly
separate
the description into two paragraphs: overall description of the effect
of the
function; then, detailed description of the specific transformations.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27043>
_______________________________________

From report at bugs.python.org  Thu May 26 22:24:32 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 27 May 2016 02:24:32 +0000
Subject: [issue27130] zlib: OverflowError while trying to compress 2^32 bytes
 or more
In-Reply-To: <1464270042.87.0.0233765451432.issue27130@psf.upfronthosting.co.za>
Message-ID: <1464315872.56.0.62086441181.issue27130@psf.upfronthosting.co.za>


Martin Panter added the comment:

This is similar, but different to the other bug. The other bug was only about output limits for incrementally decompressed data. Klamann?s bug is about the actual size of input (and possibly also output) buffers.

The gzip.compress() implementation uses zlib.compressobj.compress(), which does not accept 2 or 4 GiB input either.

The underlying zlib library uses ?unsigned int? for the size of input and output chunks. It has to be called multiple times to handle 4 GiB. In both Python 2 and 3, the one-shot compress() function only does a single call to zlib. This explains why Python 3 cannot take 4 GiB.

Python 2 uses an ?int? for the input buffer size, hence the 2 GiB limit.

I tend to think of these cases as bugs, which could be fixed in 3.5 and 2.7. Sometimes others also treat adding 64-bit support as a bug fix, e.g. file.read() on Python 2 (Issue 21932). But other times it is handled as a new feature for the next Python version, e.g. os.read() was fixed in 3.5, but not 2.7 (Issue 21932), random.getrandbits() proposed for 3.6 only (Issue 27072).

This kind of bug is apparently already fixed for crc32() and adler32() in Python 2 and 3; see Issue 10276.

This line from zlib.compress() also worries me:

zst.avail_out = length + length/1000 + 12 + 1; /* unsigned ints */

I suspect it may overflow, but I don?t have enough memory to verify. You would need to compress just under 4 GiB of data that requires 5 MB or more when compressed (i.e. not all the same bytes, or maybe try level=0).

Also, the logic for expanding the output buffer in each of zlib.decompress(), compressobj.compress(), decompressobj.decompress(), compressobj.flush(), and decompressobj.flush() looks faulty when it hits UINT_MAX. I suspect it may overwrite unallocated memory or do other funny stuff, but again I don?t have enough memory to verify. What happens when you decompress more than 4 GiB when the compressed input is less than 4 GiB?

Code fixes that I think could be made:

1. Avoid the output buffer size overflow in the zlib.compress() function

2. Rewrite zlib.compress() to call deflate() in a loop, one iteration for each 4 GiB input or output chunk

3. Allow the zlib.decompress() function to expand the output buffer beyond 4 GiB

4. Rewrite zlib.decompress() to pass 4 GiB input chunks to inflate()

5. Allow the compressobj.compress() method to expand the output buffer beyond 4 GiB

6. Rewrite compressobj.compress() to pass 4 GiB input chunks to deflate()

7. Allow the decompressobj.decompress() method to expand the output buffer beyond 4?GiB

8. Rewrite decompressobj.decompress() to pass 4 GiB input chunks to inflate(), and to save 4 GiB in decompressobj.unconsumed_tail and unused_data

9. Change the two flush() methods to abort if they allocate UINT_MAX bytes, rather than pointing into unallocated memory (I don?t think this could happen in real usage, but the code shares the same problem as above.)

----------
components: +Extension Modules -Library (Lib)
stage:  -> needs patch
versions: +Python 3.6 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27130>
_______________________________________

From report at bugs.python.org  Thu May 26 22:35:16 2016
From: report at bugs.python.org (Daniel Holth)
Date: Fri, 27 May 2016 02:35:16 +0000
Subject: [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  Thu May 26 22:36:50 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 27 May 2016 02:36:50 +0000
Subject: [issue27130] zlib: OverflowError while trying to compress 2^32 bytes
 or more
In-Reply-To: <1464270042.87.0.0233765451432.issue27130@psf.upfronthosting.co.za>
Message-ID: <1464316610.93.0.57359578066.issue27130@psf.upfronthosting.co.za>


Martin Panter added the comment:

Sorry Issue 10276 regarding crc32() and adler32() was only fixed for Python 3. Issue 23306 is open about crc32() in Python 2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27130>
_______________________________________

From report at bugs.python.org  Thu May 26 22:38:15 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 27 May 2016 02:38:15 +0000
Subject: [issue23306] Within zipfile,
 use of zlib.crc32 raises OverflowError at argument-parsing time on
 large strings
In-Reply-To: <1422056966.81.0.518971767948.issue23306@psf.upfronthosting.co.za>
Message-ID: <1464316695.75.0.131129487818.issue23306@psf.upfronthosting.co.za>


Martin Panter added the comment:

Apparently crc32() was fixed in Python 3 via Issue 10276.

See also Issue 27130 about 64-bit support more generally in zlib.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23306>
_______________________________________

From report at bugs.python.org  Thu May 26 22:38:38 2016
From: report at bugs.python.org (Daniel Holth)
Date: Fri, 27 May 2016 02:38:38 +0000
Subject: [issue18373] implement sys.get/setbyteswarningflag()
In-Reply-To: <1373065124.82.0.249288626652.issue18373@psf.upfronthosting.co.za>
Message-ID: <1464316718.29.0.86220003976.issue18373@psf.upfronthosting.co.za>


Daniel Holth added the comment:

Superceded by http://bugs.python.org/issue27134 , a simpler solution providing a with StrBytesRaises(): context manager.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18373>
_______________________________________

From report at bugs.python.org  Thu May 26 22:40:38 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 27 May 2016 02:40:38 +0000
Subject: [issue10276] zlib crc32/adler32 buffer length truncation (64-bit)
In-Reply-To: <1288604765.69.0.684600327936.issue10276@psf.upfronthosting.co.za>
Message-ID: <1464316838.23.0.213166762883.issue10276@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
Removed message: http://bugs.python.org/msg135066

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10276>
_______________________________________

From report at bugs.python.org  Thu May 26 22:41:08 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 27 May 2016 02:41:08 +0000
Subject: [issue10276] zlib crc32/adler32 buffer length truncation (64-bit)
In-Reply-To: <1288604765.69.0.684600327936.issue10276@psf.upfronthosting.co.za>
Message-ID: <1464316868.94.0.606973927808.issue10276@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
Removed message: http://bugs.python.org/msg135065

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10276>
_______________________________________

From report at bugs.python.org  Thu May 26 22:42:43 2016
From: report at bugs.python.org (Dennis Clarke)
Date: Fri, 27 May 2016 02:42:43 +0000
Subject: [issue27133] python 3.5.1 will not compile because libffi module uses
 wrong CFLAGS
In-Reply-To: <1464300085.82.0.117497454378.issue27133@psf.upfronthosting.co.za>
Message-ID: <92f9258d-9db6-a45c-5153-7d4391cbec5e@blastwave.org>


Dennis Clarke added the comment:

On 05/26/2016 06:01 PM, Zachary Ware wrote:
>
> Zachary Ware added the comment:
>
> Would you be interested in submitting a patch?

Sure, of course. There are a number of problems in the Makefile(s) for a 
system not using gcc and where CFLAGS and LD_foo is pretty important. 
Certainly where the RPATH and RUNPATH in the resultant ELF output 
binaries really really matters. So yes, sure. If I can get it sorted out.

> The whole ctypes package and the bundled libffi in particular are
 > fairly unloved.

Put me in that ground also :-\

> As a workaround, if you have libffi installed on your system

I try to avoid it actually.

> you can use the '--with-system-ffi' flag to Python's configure
 > script to direct the ctypes build to use the installed libffi.

If there were such a thing as system libffi then I would give that a try 
but for now I am on my own and will need to everything from sources.

> Also note that unless you specifically need ctypes (or are
 > building for someone who might)

Well, strictly speaking, I don't.  However someone else may and I have 
to roll this out to a pile of systems eventually.  For now it is just 
internal on my build servers.

> it may not be the end of the world for ctypes to not be available;

Is there a configure option to disable them?  I should look.

> the overall build should not fail just due to a ctypes build failure.

cool ... let's hope for the best.

Dennis

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27133>
_______________________________________

From report at bugs.python.org  Thu May 26 23:18:22 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 27 May 2016 03:18:22 +0000
Subject: [issue26834] Add truncated SHA512/224 and SHA512/256
In-Reply-To: <1461439661.19.0.970129415182.issue26834@psf.upfronthosting.co.za>
Message-ID: <1464319102.84.0.79594691176.issue26834@psf.upfronthosting.co.za>


Martin Panter added the comment:

Would it be appropriate to mention these hashes higher up in the documentation, e.g. where it lists the names of the always-present constructors?

I haven?t had a close look at the C code. It looks like you are also adding better multithreading support for SHA-512 objects (? related to Issue 4821).

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26834>
_______________________________________

From report at bugs.python.org  Fri May 27 00:13:03 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 May 2016 04:13:03 +0000
Subject: [issue27132] New assert method that checks an error message for a
 list of strings
In-Reply-To: <1464295693.41.0.439639952512.issue27132@psf.upfronthosting.co.za>
Message-ID: <1464322383.17.0.728491667235.issue27132@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

This issue looks similar to issue24922, and I think it should be closed for same reasons.

----------
nosy: +berker.peksag, ezio.melotti, michael.foord, rbcollins

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27132>
_______________________________________

From report at bugs.python.org  Fri May 27 00:17:52 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 27 May 2016 04:17:52 +0000
Subject: [issue27130] zlib: OverflowError while trying to compress 2^32 bytes
 or more
In-Reply-To: <1464270042.87.0.0233765451432.issue27130@psf.upfronthosting.co.za>
Message-ID: <1464322672.87.0.829442227702.issue27130@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

Quick and careless scanning at night lead me to a wrong result, Sorry.

> You would need to compress just under 4 GiB of data that requires 5 MB or more when compressed (i.e. not all the same bytes, or maybe try level=0).

With enough memory, compressing with level 0 does raise a error while the default level didn't. 

Except for overflow fix, does zlib have to support large data in one operation? For example, it's OK that zlib.compress does not support data beyond 4GB since we can split data in application and then call zlib.compress on each part and finally concatenate the results.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27130>
_______________________________________

From report at bugs.python.org  Fri May 27 00:18:05 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 May 2016 04:18:05 +0000
Subject: [issue27134] allow str(bytes) raises an exception to be controlled
 programmatically
In-Reply-To: <1464316515.99.0.657478307138.issue27134@psf.upfronthosting.co.za>
Message-ID: <1464322685.74.0.895802883724.issue27134@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Isn't this a duplicate of issue18373?

----------
nosy: +serhiy.storchaka

_______________________________________
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: [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 01:29:00 2016
From: report at bugs.python.org (Dennis Clarke)
Date: Fri, 27 May 2016 05:29:00 +0000
Subject: [issue27133] python 3.5.1 will not compile because libffi module uses
 wrong CFLAGS
In-Reply-To: <1464300085.82.0.117497454378.issue27133@psf.upfronthosting.co.za>
Message-ID: <9d0055e6-fc32-c1c0-9b60-db2ce1f88cbf@blastwave.org>


Dennis Clarke added the comment:

On 05/26/2016 06:01 PM, Zachary Ware wrote:
>
> Zachary Ware added the comment:
>
> Would you be interested in submitting a patch?

Right now I am trying to get a clean build of libffi outside of the 
python tree and then will use the --use-system-libffi option to get 
around this mess. Of course, that sort of means that the libffi sources 
build and test clean and that, of course, is its own struggle.

see  https://sourceware.org/ml/libffi-discuss/2016/msg00024.html

and  https://sourceware.org/ml/libffi-discuss/2016/msg00025.html

I'll keep you posted on progress here.

Dennis

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27133>
_______________________________________

From report at bugs.python.org  Fri May 27 01:42:04 2016
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 27 May 2016 05:42:04 +0000
Subject: [issue27135] nested list produced with multiplication is linked to
 the same list
In-Reply-To: <1464326700.96.0.464435009997.issue27135@psf.upfronthosting.co.za>
Message-ID: <1464327724.88.0.576830586746.issue27135@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

That's just how Python works. https://docs.python.org/3/faq/programming.html#how-do-i-create-a-multidimensional-list

----------
nosy: +benjamin.peterson
resolution:  -> not a bug
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27135>
_______________________________________

From report at bugs.python.org  Fri May 27 02:00:46 2016
From: report at bugs.python.org (Nofar Schnider)
Date: Fri, 27 May 2016 06:00:46 +0000
Subject: [issue25926] problems with "times" keyword in itertools.repeat
In-Reply-To: <1450806036.21.0.954073881918.issue25926@psf.upfronthosting.co.za>
Message-ID: <1464328846.01.0.0319428915766.issue25926@psf.upfronthosting.co.za>


Nofar Schnider added the comment:

Issue #25926
Changed all "equivalent to" occurrences to "roughly equivalent to"

----------
hgrepos: +344
nosy: +Nofar Schnider
Added file: http://bugs.python.org/file43025/itertools.rst

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25926>
_______________________________________

From report at bugs.python.org  Fri May 27 02:02:48 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 May 2016 06:02:48 +0000
Subject: [issue27120] xmllib unable to parse in UTF8 format
In-Reply-To: <1464167373.86.0.726090753957.issue27120@psf.upfronthosting.co.za>
Message-ID: <1464328968.07.0.176948588125.issue27120@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

See also issue222587. Seems this was the reason why the xmllib module was deprecated.

Use the xml package for parsing XML (xml.etree.ElementTree, xml.dom.minidom, xml.sax, etc).

----------
resolution:  -> wont fix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27120>
_______________________________________

From report at bugs.python.org  Fri May 27 02:03:07 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 May 2016 06:03:07 +0000
Subject: [issue27120] xmllib unable to parse in UTF8 format
In-Reply-To: <1464167373.86.0.726090753957.issue27120@psf.upfronthosting.co.za>
Message-ID: <1464328987.31.0.297939578001.issue27120@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27120>
_______________________________________

From report at bugs.python.org  Fri May 27 02:07:06 2016
From: report at bugs.python.org (Nofar Schnider)
Date: Fri, 27 May 2016 06:07:06 +0000
Subject: [issue25926] problems with "times" keyword in itertools.repeat
In-Reply-To: <1450806036.21.0.954073881918.issue25926@psf.upfronthosting.co.za>
Message-ID: <1464329226.76.0.842827476959.issue25926@psf.upfronthosting.co.za>


Changes by Nofar Schnider <nofarsch at gmail.com>:


Removed file: http://bugs.python.org/file43025/itertools.rst

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25926>
_______________________________________

From report at bugs.python.org  Fri May 27 02:11:02 2016
From: report at bugs.python.org (Nofar Schnider)
Date: Fri, 27 May 2016 06:11:02 +0000
Subject: [issue25926] problems with "times" keyword in itertools.repeat
In-Reply-To: <1450806036.21.0.954073881918.issue25926@psf.upfronthosting.co.za>
Message-ID: <1464329462.15.0.269455822653.issue25926@psf.upfronthosting.co.za>


Nofar Schnider added the comment:

Attached a diff
All occurrences of "equivalent to" are switched to "roughly equivalent to"

----------
hgrepos: +345
keywords: +patch
Added file: http://bugs.python.org/file43026/issue25926.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25926>
_______________________________________

From report at bugs.python.org  Fri May 27 02:45:13 2016
From: report at bugs.python.org (Marco Buttu)
Date: Fri, 27 May 2016 06:45:13 +0000
Subject: [issue7951] Should str.format allow negative indexes when used for
 __getitem__ access?
In-Reply-To: <1266450859.13.0.906832569526.issue7951@psf.upfronthosting.co.za>
Message-ID: <1464331513.62.0.216689365166.issue7951@psf.upfronthosting.co.za>


Marco Buttu added the comment:

The error message is misleading:

>>> s = '{names[-1]} loves {0[1]}'
>>> s.format(('C', 'Python'), names=('Dennis', 'Guido'))
Traceback (most recent call last):
    ...
TypeError: tuple indices must be integers or slices, not str

----------
nosy: +marco.buttu

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7951>
_______________________________________

From report at bugs.python.org  Fri May 27 02:57:59 2016
From: report at bugs.python.org (Matthew Tanous)
Date: Fri, 27 May 2016 06:57:59 +0000
Subject: [issue27135] nested list produced with multiplication is linked to
 the same list
In-Reply-To: <1464327724.88.0.576830586746.issue27135@psf.upfronthosting.co.za>
Message-ID: <BA1AA6FB-47C8-4B55-AB6F-901C1B0D67B9@gmail.com>


Matthew Tanous added the comment:

I'm aware that it's how Python works at present. My point was that this is awkward and counter-intuitive, with no purpose I can see worth serving.

"That's just how it works" seems to me a rather insufficient answer, especially for such a seemingly trivial change.

So, no, it's not technically a bug. But I think it's worth some discussion.

> On May 26, 2016, at 11:42 PM, Benjamin Peterson <report at bugs.python.org> wrote:
> 
> 
> Benjamin Peterson added the comment:
> 
> That's just how Python works. https://docs.python.org/3/faq/programming.html#how-do-i-create-a-multidimensional-list
> 
> ----------
> nosy: +benjamin.peterson
> resolution:  -> not a bug
> status: open -> closed
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue27135>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27135>
_______________________________________

From report at bugs.python.org  Fri May 27 03:22:32 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 27 May 2016 07:22:32 +0000
Subject: [issue5784] raw deflate format and zlib module
In-Reply-To: <1240006221.86.0.263428051867.issue5784@psf.upfronthosting.co.za>
Message-ID: <1464333752.97.0.6247738292.issue5784@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
stage: patch review -> commit review
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5784>
_______________________________________

From report at bugs.python.org  Fri May 27 03:40:41 2016
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 27 May 2016 07:40:41 +0000
Subject: [issue27126] Apple-supplied libsqlite3 on OS X is not fork safe;
 can cause crashes
In-Reply-To: <1464217505.87.0.0701340905112.issue27126@psf.upfronthosting.co.za>
Message-ID: <1464334841.23.0.24212151305.issue27126@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

There is a clear gap between two use cases for Python on OSX:

1) Integrate nicely with Apple stuff

2) Be useful as a development platform for software that will be deployed on Linux machines.

Both use cases are valid, but have slightly different trade-offs. I have both use-cases, but tend not to do things that cause problems here.  In any case I tend to favour the first use case, it is easy enough to develop locally and test on Linux (VMs, docker, ...) for the second use case.

A particular problem is using os.fork, as Evan notes there are problems with using Apples frameworks in programs that use fork without exec-ing a new program. Libdispatch is one problem, but higher-level frameworks are also problematic (the _scproxy problem is not only caused the use of libdispatch).

Spawning off a small executable for the _scproxy case could be worthwhile, although I haven't fully thought about the implications of that. I wouldn't like removing the use of _scproxy, it uses the documented programmatic way to access system-wide proxy configuration. Using something like scutil(1) might work as well, but is hackish.

Changing the default mode for multiprocessing could also be useful, but could result in calls about code that works on Linux but doesn't on OSX due to differences in fork mode.

BTW. Using fork without exec is unsafe in any program using threads, people tend to run into this more on OSX because Apple's libraries use background threads while other Unix-y platforms don't tend to do that.

As to shipping the sqlite with the CPython source: that's not something we do in general. It would be better to document the issue in the build instructions for CPython, and/or tweak the CPython build process to issue a warning when it detects that is using the system version of sqlite on OSX.

BTW2. Another problematic issue on OSX is accessing the system trust store for SSL certificates.  AFAIK the current binaries still use Apple's build of OpenSSL that uses a private API to access the system trust store, using a standalone OpenSSL would require some way to make OpenSSL use the trust store; either by shipping a script to dump the trust store in a format that OpenSSL can use or by using Apple's APIs to access the trust store. IIRC there is an issue about that, but I cannot find it at the moment. Using the public APIs might result in similar problems as mentioned in this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27126>
_______________________________________

From report at bugs.python.org  Fri May 27 04:45:57 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 27 May 2016 08:45:57 +0000
Subject: [issue5784] raw deflate format and zlib module
In-Reply-To: <1240006221.86.0.263428051867.issue5784@psf.upfronthosting.co.za>
Message-ID: <20160527084552.13905.13432.4830B7B4@psf.io>


Roundup Robot added the comment:

New changeset 4c88d6d18e85 by Martin Panter in branch '3.5':
Issue #5784: Expand documentation and tests for zlib wbits parameter
https://hg.python.org/cpython/rev/4c88d6d18e85

New changeset 4d4f27fc70d5 by Martin Panter in branch 'default':
Issue #5784: Merge zlib from 3.5
https://hg.python.org/cpython/rev/4d4f27fc70d5

New changeset e5fc74588cea by Martin Panter in branch '2.7':
Issue #5784: Expand documentation and tests for zlib wbits parameter
https://hg.python.org/cpython/rev/e5fc74588cea

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5784>
_______________________________________

From report at bugs.python.org  Fri May 27 05:12:14 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 27 May 2016 09:12:14 +0000
Subject: [issue5784] raw deflate format and zlib module
In-Reply-To: <1240006221.86.0.263428051867.issue5784@psf.upfronthosting.co.za>
Message-ID: <1464340334.5.0.277114963488.issue5784@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Failure on Python 2.7:

http://buildbot.python.org/all/builders/x86%20OpenIndiana%202.7/builds/3348/steps/test/logs/stdio

======================================================================
ERROR: test_wbits (test.test_zlib.CompressObjectTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/export/home/buildbot/32bits/2.7.cea-indiana-x86/build/Lib/test/test_zlib.py", line 534, in test_wbits
    self.assertEqual(zlib.decompress(zlib15, 0), HAMLET_SCENE)
error: Error -2 while preparing to decompress data: inconsistent stream state

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5784>
_______________________________________

From report at bugs.python.org  Fri May 27 07:02:19 2016
From: report at bugs.python.org (pyptr2)
Date: Fri, 27 May 2016 11:02:19 +0000
Subject: [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 07:33:31 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 27 May 2016 11:33:31 +0000
Subject: [issue5784] raw deflate format and zlib module
In-Reply-To: <1240006221.86.0.263428051867.issue5784@psf.upfronthosting.co.za>
Message-ID: <20160527113320.122363.11074.196ED194@psf.io>


Roundup Robot added the comment:

New changeset ca49614989dd by Martin Panter in branch '3.5':
Issue #5784: wbits=0 apparently added in zlib v1.2.3.5
https://hg.python.org/cpython/rev/ca49614989dd

New changeset 1771f0ac9fc2 by Martin Panter in branch 'default':
Issue #5784: Merge zlib from 3.5
https://hg.python.org/cpython/rev/1771f0ac9fc2

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5784>
_______________________________________

From report at bugs.python.org  Fri May 27 07:57:53 2016
From: report at bugs.python.org (pyptr2)
Date: Fri, 27 May 2016 11:57:53 +0000
Subject: [issue27136] sock_connect fails for bluetooth (and probably others)
In-Reply-To: <1464346938.98.0.196127839357.issue27136@psf.upfronthosting.co.za>
Message-ID: <1464350273.73.0.596942665013.issue27136@psf.upfronthosting.co.za>


pyptr2 added the comment:

s/prevents/causes/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27136>
_______________________________________

From report at bugs.python.org  Fri May 27 08:06:00 2016
From: report at bugs.python.org (Demur Rumed)
Date: Fri, 27 May 2016 12:06:00 +0000
Subject: [issue27129] Wordcode, part 2
In-Reply-To: <1464268387.83.0.862540030058.issue27129@psf.upfronthosting.co.za>
Message-ID: <1464350760.95.0.236121770887.issue27129@psf.upfronthosting.co.za>


Demur Rumed added the comment:

https://github.com/search?q=f_lasti&type=Code

Popular use of f_lasti is checking it for -1, checking the instruction at the byte offset of f_lasti, checking the argument with code[f_lasti+1] (Some bad code checking f_lasti+3 which'll break with 3.6)

abarnert discussed how bytecode should be typed to Python code. Ideally it'd be typed as a "(instruction, arg)" tuple. He considered creating a "words" type similar to "bytes" but with 16 bit values. It's a bit niche to introduce a builtin for. So if the co_code object is remaining a bytes object then it seems intuitive to keep f_lasti as a bytes offset. Clashes with jump offsets no longer being a bytes offset even in Python code tho

In reality most of the results on github all seem to be copying a few distinct uses. So maybe backwards compatibiltiy isn't so important

Other search https://searchcode.com/?q=f_lasti&loc=0&loc2=10000&src=3&src=7&src=1&lan=19 doesn't produce many results either

----------
nosy: +Demur Rumed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27129>
_______________________________________

From report at bugs.python.org  Fri May 27 08:17:50 2016
From: report at bugs.python.org (pyptr2)
Date: Fri, 27 May 2016 12:17:50 +0000
Subject: [issue27136] sock_connect fails for bluetooth (and probably others)
In-Reply-To: <1464346938.98.0.196127839357.issue27136@psf.upfronthosting.co.za>
Message-ID: <1464351470.31.0.629818311416.issue27136@psf.upfronthosting.co.za>


Changes by pyptr2 <mathis.ahrens at gmx.de>:


Added file: http://bugs.python.org/file43028/test_async_btsock.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27136>
_______________________________________

From report at bugs.python.org  Fri May 27 08:25:12 2016
From: report at bugs.python.org (pyptr2)
Date: Fri, 27 May 2016 12:25:12 +0000
Subject: [issue27136] sock_connect fails for bluetooth (and probably others)
In-Reply-To: <1464346938.98.0.196127839357.issue27136@psf.upfronthosting.co.za>
Message-ID: <1464351912.26.0.701640319782.issue27136@psf.upfronthosting.co.za>


Changes by pyptr2 <mathis.ahrens at gmx.de>:


----------
components: +Library (Lib)
versions: +Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27136>
_______________________________________

From report at bugs.python.org  Fri May 27 08:29:50 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 27 May 2016 12:29:50 +0000
Subject: [issue27129] Wordcode, part 2
In-Reply-To: <1464350760.95.0.236121770887.issue27129@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwaLMWtL69582Y1oGTDAYv6spFgn47Eiov6j6KKVROndWw@mail.gmail.com>


STINNER Victor added the comment:

> if the co_code object is remaining a bytes object then it seems intuitive to keep f_lasti as a bytes offset

Right.

> In reality most of the results on github all seem to be copying a few distinct uses. So maybe backwards compatibiltiy isn't so important

Backwards compatibiltiy is important.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27129>
_______________________________________

From report at bugs.python.org  Fri May 27 08:30:52 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Fri, 27 May 2016 12:30:52 +0000
Subject: [issue27135] nested list produced with multiplication is linked to
 the same list
In-Reply-To: <1464326700.96.0.464435009997.issue27135@psf.upfronthosting.co.za>
Message-ID: <1464352252.61.0.126972300177.issue27135@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

The reason why Python behaves like that in this case is a side-effect of the way the data model is implemented. Lists are a mutable data type, which means that referencing the same list - which is what you are doing - as opposed to creating a new one each time, does exactly what is expected of the data model, which is to keep a reference to the original list. Consider:

x = ??
y = x

The object bound to `y` refers to the same object as the one bound to `x`, such that `x is y`, for every possible value of `x`. As `=` is the assignment operator (and not the copy operator, is such a thing existed), `y` merely has a reference to `x`.

There are very valid use cases where you will want to get a reference to the original list to modify it, for example in a function that is meant to alter the original. If you want a copy, use `l[:]` (or `l.copy()` in more recent versions).

In Python, every object and operation is evaluated once, when the interpreter comes across it (in a for or while loop, it will come over the same point multiple times, so it will evaluate it multiple times). By doing:

[[x] * y] * n

You are essentially doing this:

l_1 = [x] # one-element list
l_2 = l_1 * y # list with `y` times `x` in it (references to `x`, not copies)
l_3 = [l_2] # a new list with one element, `l_2`
l_4 = l_3 * n # list with `n` times `l_3` in it (references to `l_3`, not copies)

As you can see, it makes no sense to have multiple different lists by doing that. Doing a list comprehension, such as:

[[None] * n for _ in range(N)]

Will evaluate a new list each time the interpreter comes across it, which will be N times for this case. Thus, you get a different list everytime.

In other words, the reason that "That's just how it works" is because this behaviour is a side-effect, not something that's out of the way. Creating a new special case for this particular case seems like a very big stretch. Remember, "Special cases aren't special enough to break the rules."

This change that is "seemingly trivial" to you is actually asking to break the Python semantics in some weird and convoluted way, for no gain since we have list comprehensions (that you seem to already be acquainted with).

Did that seem like a sufficient answer? ;-)

----------
nosy: +ebarry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27135>
_______________________________________

From report at bugs.python.org  Fri May 27 08:40:58 2016
From: report at bugs.python.org (Daniel Holth)
Date: Fri, 27 May 2016 12:40:58 +0000
Subject: [issue18373] implement sys.get/setbyteswarningflag()
In-Reply-To: <1373065124.82.0.249288626652.issue18373@psf.upfronthosting.co.za>
Message-ID: <1464352858.74.0.444115066699.issue18373@psf.upfronthosting.co.za>


Changes by Daniel Holth <dholth at fastmail.fm>:


Removed file: http://bugs.python.org/file30787/byteswarningflag.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18373>
_______________________________________

From report at bugs.python.org  Fri May 27 08:41:43 2016
From: report at bugs.python.org (Daniel Holth)
Date: Fri, 27 May 2016 12:41:43 +0000
Subject: [issue27134] allow str(bytes) raises an exception to be controlled
 programmatically
In-Reply-To: <1464316515.99.0.657478307138.issue27134@psf.upfronthosting.co.za>
Message-ID: <1464352903.42.0.680757330425.issue27134@psf.upfronthosting.co.za>


Daniel Holth added the comment:

Continuing discussion in the older bug

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27134>
_______________________________________

From report at bugs.python.org  Fri May 27 08:54:45 2016
From: report at bugs.python.org (Daniel Holth)
Date: Fri, 27 May 2016 12:54:45 +0000
Subject: [issue18373] let code force str(bytes) to raise an exception
In-Reply-To: <1373065124.82.0.249288626652.issue18373@psf.upfronthosting.co.za>
Message-ID: <1464353685.08.0.10021136992.issue18373@psf.upfronthosting.co.za>


Daniel Holth added the comment:

Better to continue discussion here.

Attached is my second, simpler version of the feature. A context manager is included:

with string.StrBytesRaises():
    str(b'bytes')

# raises an exception

In a normal program, you might just set the flag to True, but in a library that has no hope of setting the -bb flag you might use it during serialization rather than checking isinstance() on all input.

----------
title: implement sys.get/setbyteswarningflag() -> let code force str(bytes) to raise an exception
versions: +Python 3.6 -Python 3.5
Added file: http://bugs.python.org/file43029/strbytes.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18373>
_______________________________________

From report at bugs.python.org  Fri May 27 09:02:02 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 27 May 2016 13:02:02 +0000
Subject: [issue18373] let code force str(bytes) to raise an exception
In-Reply-To: <1373065124.82.0.249288626652.issue18373@psf.upfronthosting.co.za>
Message-ID: <1464354122.15.0.884180309304.issue18373@psf.upfronthosting.co.za>


STINNER Victor added the comment:

strbytes.patch of #27134: adding calls to PyThreadState_GetDict()+PyDict_GetItemString() seems inefficient for a rare use case

I would prefer to modify the existing Py_BytesWarningFlag flag.

The flag is process-wide. If it's an issue, we can use a thread-local storage (TLS) for the flag in C.

FYI get_exec_path() uses the following code to temporarely ignore the warning:

    # {b'PATH': ...}.get('PATH') and {'PATH': ...}.get(b'PATH') emit a
    # BytesWarning when using python -b or python -bb: ignore the warning
    with warnings.catch_warnings():
        warnings.simplefilter("ignore", BytesWarning)
        ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18373>
_______________________________________

From report at bugs.python.org  Fri May 27 09:17:29 2016
From: report at bugs.python.org (Daniel Holth)
Date: Fri, 27 May 2016 13:17:29 +0000
Subject: [issue18373] let code force str(bytes) to raise an exception
In-Reply-To: <1464354122.15.0.884180309304.issue18373@psf.upfronthosting.co.za>
Message-ID: <1464355046.97317.620544801.06E58518@webmail.messagingengine.com>


Daniel Holth added the comment:

My reasoning was that str(bytes) would normally be called so rarely that
who cares.

On Fri, May 27, 2016, at 09:02 AM, STINNER Victor wrote:
> 
> STINNER Victor added the comment:
> 
> strbytes.patch of #27134: adding calls to
> PyThreadState_GetDict()+PyDict_GetItemString() seems inefficient for a
> rare use case
> 
> I would prefer to modify the existing Py_BytesWarningFlag flag.
> 
> The flag is process-wide. If it's an issue, we can use a thread-local
> storage (TLS) for the flag in C.
> 
> FYI get_exec_path() uses the following code to temporarely ignore the
> warning:
> 
>     # {b'PATH': ...}.get('PATH') and {'PATH': ...}.get(b'PATH') emit a
>     # BytesWarning when using python -b or python -bb: ignore the warning
>     with warnings.catch_warnings():
>         warnings.simplefilter("ignore", BytesWarning)
>         ...
> 
> ----------
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue18373>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18373>
_______________________________________

From report at bugs.python.org  Fri May 27 09:47:46 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 27 May 2016 13:47:46 +0000
Subject: [issue5784] raw deflate format and zlib module
In-Reply-To: <1240006221.86.0.263428051867.issue5784@psf.upfronthosting.co.za>
Message-ID: <20160527134734.13769.29920.6590F6A8@psf.io>


Roundup Robot added the comment:

New changeset 0df93ab07a8f by Martin Panter in branch '2.7':
Issue #5784: Cannot test wbits=0 unless we know we have zlib v1.2.3.5
https://hg.python.org/cpython/rev/0df93ab07a8f

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5784>
_______________________________________

From report at bugs.python.org  Fri May 27 10:00:48 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 27 May 2016 14:00:48 +0000
Subject: [issue5784] raw deflate format and zlib module
In-Reply-To: <1240006221.86.0.263428051867.issue5784@psf.upfronthosting.co.za>
Message-ID: <1464357648.71.0.982575944033.issue5784@psf.upfronthosting.co.za>


Martin Panter added the comment:

Apparently zlib only supports windowBits (wbits) = 0 since v1.2.3.5. I added a version check in the Python 3 tests, which seems to have solved the buildbot problems (OpenIndiana and OS X buildbots). In Python 2 I removed the test, because Python 2 has no zlib.ZLIB_RUNTIME_VERSION to check.

----------
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5784>
_______________________________________

From report at bugs.python.org  Fri May 27 10:08:35 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 27 May 2016 14:08:35 +0000
Subject: [issue5784] raw deflate format and zlib module
In-Reply-To: <1240006221.86.0.263428051867.issue5784@psf.upfronthosting.co.za>
Message-ID: <1464358115.0.0.741769889905.issue5784@psf.upfronthosting.co.za>


STINNER Victor added the comment:

> In Python 2 I removed the test, because Python 2 has no zlib.ZLIB_RUNTIME_VERSION to check.

It makes sense. You didn't touch the C code of the module, only doc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5784>
_______________________________________

From report at bugs.python.org  Fri May 27 10:38:52 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 May 2016 14:38:52 +0000
Subject: [issue26372] Popen.communicate not ignoring BrokenPipeError
In-Reply-To: <1455672512.72.0.551664124622.issue26372@psf.upfronthosting.co.za>
Message-ID: <1464359932.57.0.791911570309.issue26372@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Ping.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26372>
_______________________________________

From report at bugs.python.org  Fri May 27 11:20:26 2016
From: report at bugs.python.org (Daniel Holth)
Date: Fri, 27 May 2016 15:20:26 +0000
Subject: [issue18373] let code force str(bytes) to raise an exception
In-Reply-To: <1464355046.97317.620544801.06E58518@webmail.messagingengine.com>
Message-ID: <1464362423.128281.620657449.7EE59825@webmail.messagingengine.com>


Daniel Holth added the comment:

Then you prefer the older three year old patch that adds to pystate.h ?
http://bugs.python.org/review/18373/#ps8545

I remember not being happy with how complicated it turned out, and
perhaps having problems with not wanting the "warn once" behavior? It
seems more Pythonic to store the flag in a dict.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18373>
_______________________________________

From report at bugs.python.org  Fri May 27 11:55:28 2016
From: report at bugs.python.org (Evan Jones)
Date: Fri, 27 May 2016 15:55:28 +0000
Subject: [issue27126] Apple-supplied libsqlite3 on OS X is not fork safe;
 can cause crashes
In-Reply-To: <1464217505.87.0.0701340905112.issue27126@psf.upfronthosting.co.za>
Message-ID: <1464364528.91.0.161402037246.issue27126@psf.upfronthosting.co.za>


Evan Jones added the comment:

I have a crazy idea, but I'm not 100% sure how to implement it: If Python was able to detect and report this error in a friendly way, it would allow people to easily understand what is happening and to work around it. How can we do it?

First idea: In the implementation of os.fork(), detect if libdispatch has been used. If it has, throw an exception. I think this is probably possible using the libdispatch public APIs, but I'll need to figure out the details. In general, this could apply on Linux as well: throw an exception if the process has more than one thread running?

Second idea: On Mac OS X only, libdispatch is intentionally crashing the process. We could install a signal handler that attempts to detect *this specific crash* in order to throw a friendlier exception, or at worst crash with a useful message.

Third idea: Add documentation to the multiprocessing module and os.fork that they are very unsafe on Mac OS X?

Maybe there is a better way of making this crash "friendlier"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27126>
_______________________________________

From report at bugs.python.org  Fri May 27 12:18:27 2016
From: report at bugs.python.org (Nathan Harold)
Date: Fri, 27 May 2016 16:18:27 +0000
Subject: =?utf-8?q?=5Bissue27043=5D_Describe_what_=E2=80=98inspect=2Ecleandoc?=
 =?utf-8?q?=E2=80=99_does_to_synopsis_line=2E?=
In-Reply-To: <1463445757.83.0.886794484792.issue27043@psf.upfronthosting.co.za>
Message-ID: <1464365907.39.0.530323734626.issue27043@psf.upfronthosting.co.za>


Nathan Harold added the comment:

Split version (cleandoc2.patch):

   Clean up indentation from docstrings that are indented to line up with blocks
   of code.
   
   All leading whitespace is removed from the first line.  Any leading whitespace
   that can be uniformly removed from the second line onwards is removed.  Empty
   lines at the beginning and end are subsequently removed.  Also, all tabs are
   expanded to spaces.

----------
Added file: http://bugs.python.org/file43030/cleandoc2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27043>
_______________________________________

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: [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 13:01:55 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 27 May 2016 17:01:55 +0000
Subject: [issue27137] functools.partial: Inconsistency between Python and C
 implementations
In-Reply-To: <1464367158.87.0.208604382314.issue27137@psf.upfronthosting.co.za>
Message-ID: <1464368515.14.0.243252351517.issue27137@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27137>
_______________________________________

From report at bugs.python.org  Fri May 27 13:03:52 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 May 2016 17:03:52 +0000
Subject: [issue27137] functools.partial: Inconsistency between Python and C
 implementations
In-Reply-To: <1464367158.87.0.208604382314.issue27137@psf.upfronthosting.co.za>
Message-ID: <1464368632.35.0.123101909039.issue27137@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27137>
_______________________________________

From report at bugs.python.org  Fri May 27 13:54:43 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 27 May 2016 17:54:43 +0000
Subject: [issue27136] sock_connect fails for bluetooth (and probably others)
In-Reply-To: <1464346938.98.0.196127839357.issue27136@psf.upfronthosting.co.za>
Message-ID: <1464371683.7.0.466489595411.issue27136@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I cannot run your test program. Can you explain what it does and what you expected?

Also, watch your language.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27136>
_______________________________________

From report at bugs.python.org  Fri May 27 14:07:17 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 27 May 2016 18:07:17 +0000
Subject: [issue27137] functools.partial: Inconsistency between Python and C
 implementations
In-Reply-To: <1464367158.87.0.208604382314.issue27137@psf.upfronthosting.co.za>
Message-ID: <1464372437.66.0.595813438385.issue27137@psf.upfronthosting.co.za>


Changes by Xiang Zhang <angwerzx at 126.com>:


----------
nosy: +xiang.zhang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27137>
_______________________________________

From report at bugs.python.org  Fri May 27 14:16:46 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 May 2016 18:16:46 +0000
Subject: [issue5784] raw deflate format and zlib module
In-Reply-To: <1240006221.86.0.263428051867.issue5784@psf.upfronthosting.co.za>
Message-ID: <1464373006.74.0.337536596891.issue5784@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I would write the test as:

    v = tuple(map(int, zlib.ZLIB_RUNTIME_VERSION.split(".")))
    supports_wbits_0 = v >= (1, 2, 3, 5)

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5784>
_______________________________________

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: [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 14:37:18 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 27 May 2016 18:37:18 +0000
Subject: [issue27138] FileFinder.find_spec() docstring needs to be corrected.
In-Reply-To: <1464373576.22.0.0993428685624.issue27138@psf.upfronthosting.co.za>
Message-ID: <20160527183712.121222.15410.9F9467C4@psf.io>


Roundup Robot added the comment:

New changeset ac9c1aeecfb4 by Eric Snow in branch '3.5':
Issue #27138: Fix the doc comment for FileFinder.find_spec().
https://hg.python.org/cpython/rev/ac9c1aeecfb4

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27138>
_______________________________________

From report at bugs.python.org  Fri May 27 14:56:59 2016
From: report at bugs.python.org (Roundup Robot)
Date: Fri, 27 May 2016 18:56:59 +0000
Subject: [issue27138] FileFinder.find_spec() docstring needs to be corrected.
In-Reply-To: <1464373576.22.0.0993428685624.issue27138@psf.upfronthosting.co.za>
Message-ID: <20160527185650.18946.55097.835D7AB2@psf.io>


Roundup Robot added the comment:

New changeset 4348fb8cae27 by Eric Snow in branch 'default':
Issue #27138: Fix the doc comment for FileFinder.find_spec().
https://hg.python.org/cpython/rev/4348fb8cae27

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27138>
_______________________________________

From report at bugs.python.org  Fri May 27 15:01:43 2016
From: report at bugs.python.org (Eric Snow)
Date: Fri, 27 May 2016 19:01:43 +0000
Subject: [issue27138] FileFinder.find_spec() docstring needs to be corrected.
In-Reply-To: <1464373576.22.0.0993428685624.issue27138@psf.upfronthosting.co.za>
Message-ID: <1464375703.35.0.995938233805.issue27138@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
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: [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 15:57:11 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 27 May 2016 19:57:11 +0000
Subject: [issue5784] raw deflate format and zlib module
In-Reply-To: <1464373006.74.0.337536596891.issue5784@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwaWympBuvy5oHp=ekxh054aNWw+RXjzWoqDPwqr353kYA@mail.gmail.com>


STINNER Victor added the comment:

I agree Serhiy :-) i hesitated to propose exactly the same change.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5784>
_______________________________________

From report at bugs.python.org  Fri May 27 16:12:18 2016
From: report at bugs.python.org (Matthew Tanous)
Date: Fri, 27 May 2016 20:12:18 +0000
Subject: [issue27135] nested list produced with multiplication is linked to
 the same list
In-Reply-To: <1464352252.61.0.126972300177.issue27135@psf.upfronthosting.co.za>
Message-ID: <B6C0B9AD-0B74-48D3-9A39-45E269D99C46@gmail.com>


Matthew Tanous added the comment:

It makes sense, except for this case is not true when "x" is an immutable data type - it appears as though something like [5] * n creates a list of totally separate elements (even if they start as the same thing).

It is difficult to see a case where I would not want separate elements from a mutable type as well. It would seem to me that having the "*" operator function as the list comprehension does now would be more logical and straightforward.

This would change the default list in a way that is mostly unseen: [5] * 3 would still result in [5, 5, 5] while treating mutable nesting in a way that I believe would be more understandable from the apparent intent of the syntax in question.

This would also resolve the problem of being unable to use the list multiplication to create a list of mutable objects. If I have a mutable object Foo and wish to create a list of different instances of them, I cannot use the straightforward syntax [Foo()] * n at present to do this, as there will only be one actual Foo instance in that list. I think that this is confusing to developers who would generally expect that this shortcut (and this is the only purpose of the operator for lists) would create a list of different instances.

> On May 27, 2016, at 6:30 AM, Emanuel Barry <report at bugs.python.org> wrote:
> 
> 
> Emanuel Barry added the comment:
> 
> The reason why Python behaves like that in this case is a side-effect of the way the data model is implemented. Lists are a mutable data type, which means that referencing the same list - which is what you are doing - as opposed to creating a new one each time, does exactly what is expected of the data model, which is to keep a reference to the original list. Consider:
> 
> x = ??
> y = x
> 
> The object bound to `y` refers to the same object as the one bound to `x`, such that `x is y`, for every possible value of `x`. As `=` is the assignment operator (and not the copy operator, is such a thing existed), `y` merely has a reference to `x`.
> 
> There are very valid use cases where you will want to get a reference to the original list to modify it, for example in a function that is meant to alter the original. If you want a copy, use `l[:]` (or `l.copy()` in more recent versions).
> 
> In Python, every object and operation is evaluated once, when the interpreter comes across it (in a for or while loop, it will come over the same point multiple times, so it will evaluate it multiple times). By doing:
> 
> [[x] * y] * n
> 
> You are essentially doing this:
> 
> l_1 = [x] # one-element list
> l_2 = l_1 * y # list with `y` times `x` in it (references to `x`, not copies)
> l_3 = [l_2] # a new list with one element, `l_2`
> l_4 = l_3 * n # list with `n` times `l_3` in it (references to `l_3`, not copies)
> 
> As you can see, it makes no sense to have multiple different lists by doing that. Doing a list comprehension, such as:
> 
> [[None] * n for _ in range(N)]
> 
> Will evaluate a new list each time the interpreter comes across it, which will be N times for this case. Thus, you get a different list everytime.
> 
> In other words, the reason that "That's just how it works" is because this behaviour is a side-effect, not something that's out of the way. Creating a new special case for this particular case seems like a very big stretch. Remember, "Special cases aren't special enough to break the rules."
> 
> This change that is "seemingly trivial" to you is actually asking to break the Python semantics in some weird and convoluted way, for no gain since we have list comprehensions (that you seem to already be acquainted with).
> 
> Did that seem like a sufficient answer? ;-)
> 
> ----------
> nosy: +ebarry
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue27135>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27135>
_______________________________________

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: [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 16:41:57 2016
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 27 May 2016 20:41:57 +0000
Subject: [issue27140] Opcode for creating dict with constant keys
In-Reply-To: <1464381640.82.0.0689379791356.issue27140@psf.upfronthosting.co.za>
Message-ID: <1464381717.23.0.587489468431.issue27140@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27140>
_______________________________________

From report at bugs.python.org  Fri May 27 16:44:22 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 27 May 2016 20:44:22 +0000
Subject: [issue27095] Simplify MAKE_FUNCTION
In-Reply-To: <1464038780.83.0.81155899453.issue27095@psf.upfronthosting.co.za>
Message-ID: <1464381862.41.0.0958175392432.issue27095@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

In general the patch LGTM, besides few minor comments.

But new implementation uses longer bytecode for annotations. Current code packs argument names in one constant tuple:

$ ./python -m dis
def f(x: int, y: str, z: float): pass
  1           0 LOAD_NAME                0 (int)
              2 LOAD_NAME                1 (str)
              4 LOAD_NAME                2 (float)
              6 LOAD_CONST               0 (('x', 'y', 'z'))
              8 LOAD_CONST               1 (<code object f at 0xb6fc1640, file "<stdin>", line 1>)
             10 LOAD_CONST               2 ('f')
             12 EXTENDED_ARG             4
             14 EXTENDED_ARG          1024
             16 MAKE_FUNCTION        262144
             18 STORE_NAME               3 (f)
             20 LOAD_CONST               3 (None)
             22 RETURN_VALUE

New code uses LOAD_CONST for every name:

$ ./python -m dis
def f(x: int, y: str, z: float): pass
  1           0 LOAD_CONST               0 ('x')
              2 LOAD_NAME                0 (int)
              4 LOAD_CONST               1 ('y')
              6 LOAD_NAME                1 (str)
              8 LOAD_CONST               2 ('z')
             10 LOAD_NAME                2 (float)
             12 BUILD_MAP                3
             14 LOAD_CONST               3 (<code object f at 0xb7035a20, file "<stdin>", line 1>)
             16 LOAD_CONST               4 ('f')
             18 MAKE_FUNCTION            4
             20 STORE_NAME               3 (f)
             22 LOAD_CONST               5 (None)
             24 RETURN_VALUE

With new opcode that creates a dict from values and a tuple of keys (issue27140) new code would be only one instruction longer.

----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27095>
_______________________________________

From report at bugs.python.org  Fri May 27 16:59:09 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Fri, 27 May 2016 20:59:09 +0000
Subject: [issue27135] nested list produced with multiplication is linked to
 the same list
In-Reply-To: <1464326700.96.0.464435009997.issue27135@psf.upfronthosting.co.za>
Message-ID: <1464382749.72.0.73246620934.issue27135@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

You do raise a valid point, sequence repetition (*) on lists of mutable objects serves very little purpose. However, as I stated, it is a side-effect of the data model and changing it would be yet another special case, which aren't special enough to break the rules, and this applies here.

Keep in mind that, currently, this is only confusing to newbies. Your idea would make this confusing for long-time Python programmers.

If you still wish to propose such a change, I recommend to take this to the Python-ideas mailing list (point to this issue in your email). Be warned though that most core developers (and most non-core devs such as myself) will probably prefer the statu quo, again because the change would be yet another special case, and probably view this as an attractive nuisance ("Why does [[x] * y] * n create separate lists but x = y = [] refer to the same list?").

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27135>
_______________________________________

From report at bugs.python.org  Fri May 27 17:18:47 2016
From: report at bugs.python.org (pyptr2)
Date: Fri, 27 May 2016 21:18:47 +0000
Subject: [issue27136] sock_connect fails for bluetooth (and probably others)
In-Reply-To: <1464346938.98.0.196127839357.issue27136@psf.upfronthosting.co.za>
Message-ID: <1464383927.45.0.33773275373.issue27136@psf.upfronthosting.co.za>


pyptr2 added the comment:

The test program should try to connect to a bluetooth device, using asyncio.
The bluetooth address is obviously made up, so it would likely fail to do so, but it should not raise an exception before even trying:

$ python3.5 test_async_btsock.py 
Traceback (most recent call last):
  File "test_async_btsock.py", line 9, in <module>
    loop.run_until_complete(coro)
  File "/usr/lib/python3.5/asyncio/base_events.py", line 373, in run_until_complete
    return future.result()
  File "/usr/lib/python3.5/asyncio/futures.py", line 274, in result
    raise self._exception
  File "/usr/lib/python3.5/asyncio/selector_events.py", line 400, in sock_connect
    base_events._check_resolved_address(sock, address)
  File "/usr/lib/python3.5/asyncio/base_events.py", line 151, in _check_resolved_address
    " got host %r" % host)
ValueError: address must be resolved (IP address), got host '00:01:02:03:04:05'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27136>
_______________________________________

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: [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 17:56:06 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 27 May 2016 21:56:06 +0000
Subject: [issue27136] sock_connect fails for bluetooth (and probably others)
In-Reply-To: <1464346938.98.0.196127839357.issue27136@psf.upfronthosting.co.za>
Message-ID: <1464386166.44.0.0445825679835.issue27136@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

pyptr2, can you reproduce this with latest asyncio (from github.com/python/asyncio)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27136>
_______________________________________

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: [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 18:18:12 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 27 May 2016 22:18:12 +0000
Subject: [issue27136] sock_connect fails for bluetooth (and probably others)
In-Reply-To: <1464346938.98.0.196127839357.issue27136@psf.upfronthosting.co.za>
Message-ID: <1464387492.7.0.342255624614.issue27136@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Maybe the form requirements for Bluetooth addresses are different than for IP or ipv6? I guess the validation should be protocol-specific.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27136>
_______________________________________

From report at bugs.python.org  Fri May 27 18:21:22 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 27 May 2016 22:21:22 +0000
Subject: [issue27136] sock_connect fails for bluetooth (and probably others)
In-Reply-To: <1464346938.98.0.196127839357.issue27136@psf.upfronthosting.co.za>
Message-ID: <1464387682.65.0.098632416202.issue27136@psf.upfronthosting.co.za>


Yury Selivanov added the comment:

> Maybe the form requirements for Bluetooth addresses are different than for IP or ipv6? I guess the validation should be protocol-specific.

Right, I've just looked at the code [1].  We should return from _ipaddr_info if family is not an AF_UNSPEC, AF_INET or AF_INET6.

[1] https://github.com/python/asyncio/blob/master/asyncio/base_events.py#L90

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27136>
_______________________________________

From report at bugs.python.org  Fri May 27 18:32:43 2016
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 27 May 2016 22:32:43 +0000
Subject: [issue27136] sock_connect fails for bluetooth (and probably others)
In-Reply-To: <1464387682.65.0.098632416202.issue27136@psf.upfronthosting.co.za>
Message-ID: <B89C2442-2E28-4B54-9907-B3B2E8B0D2B1@gmail.com>


Yury Selivanov added the comment:

>> Maybe the form requirements for Bluetooth addresses are different than for IP or ipv6? I guess the validation should be protocol-specific.
> 
> Right, I've just looked at the code [1].  We should return from _ipaddr_info if family is not an AF_UNSPEC, AF_INET or AF_INET6.

Actually, we should probably return in case of AF_UNSPEC too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27136>
_______________________________________

From report at bugs.python.org  Fri May 27 19:00:55 2016
From: report at bugs.python.org (Martin Panter)
Date: Fri, 27 May 2016 23:00:55 +0000
Subject: [issue5784] raw deflate format and zlib module
In-Reply-To: <1240006221.86.0.263428051867.issue5784@psf.upfronthosting.co.za>
Message-ID: <1464390055.05.0.219285839553.issue5784@psf.upfronthosting.co.za>


Martin Panter added the comment:

> v = tuple(map(int, zlib.ZLIB_RUNTIME_VERSION.split(".")))
> supports_wbits_0 = v >= (1, 2, 3, 5)

That was basically my first thought. But I didn?t want to presume that every element of the version is an integer. For instance, the current string in the ?develop? branch of zlib has "1.2.8.1-motley".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5784>
_______________________________________

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: [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  Fri May 27 20:34:35 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 28 May 2016 00:34:35 +0000
Subject: [issue20699] Document that binary IO classes work with bytes-likes
 objects
In-Reply-To: <1392889792.36.0.922412998797.issue20699@psf.upfronthosting.co.za>
Message-ID: <1464395675.73.0.13462442272.issue20699@psf.upfronthosting.co.za>


Martin Panter added the comment:

Porting this to Python 2 uncovered a few flaws that I am unsure how to best handle. In this patch I have added workarounds, but perhaps we can find better fixes.

1. The io.BytesIO.write() C implementation does not accept array.array() objects. I suspect it only accepts objects implementing the ?new? memoryview() buffer protocol, and array() only implements the ?old? buffer() protocol.

In Python 2, is array.array() considered a bytes-like object? If so, the proposed update to the write() documentation is not consistent. Perhaps it is a real bug to fix in the BytesIO implementation. Or is test_array_writes() just going too far for Python 2?

I added code to skip the relevant test in test_array_writes(). Maybe it would be simplest to document that in general, BufferedIOBase.write() only has to accept ?new? memoryview()-able objects.

2. The _pyio.BufferedIOBase.readinto() native Python implementation cannot assign into arbitrary bytes-like objects. Python 2 does not have memoryview.cast("B"), buffer() objects seem to be read-only, and I can?t think of any other easy way.

I reverted back to only testing native Python readinto() methods with bytearray(). But perhaps it would be best to document that for Python 2, only memoryview()-able arrays of bytes are acceptable, which should be practical to  handle in native Python code.

3. The _pyio.BytesIO.write() and BufferedWriter.write() native Python implementations did not handle obscure bytes-like objects well. I added buffer() calls to the code. But I am not sure this is a good idea, because it will raise warnings with ?python -3?. An alternative might be to again only require write() to accept memoryview()-able arrays of bytes.

Perhaps the Python 2 definition of ?bytes-like object? should be restricted to the ?new? memoryview() buffer protocol, and to 1-D arrays of bytes. I.e. memoryview(byteslike).ndim == 1 and memoryview(byteslike).format == "B".

----------
Added file: http://bugs.python.org/file43033/bytes-like-param.py2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20699>
_______________________________________

From report at bugs.python.org  Fri May 27 21:09:13 2016
From: report at bugs.python.org (=?utf-8?q?Rub=C3=A9n_Rivero_Capriles?=)
Date: Sat, 28 May 2016 01:09:13 +0000
Subject: [issue27143] python 3.5 conflict with Mailman, ebtables and firewalld
In-Reply-To: <1464395175.01.0.190089225196.issue27143@psf.upfronthosting.co.za>
Message-ID: <1464397753.17.0.624623437033.issue27143@psf.upfronthosting.co.za>


Rub?n Rivero Capriles added the comment:

# whereis python
python: /usr/bin/python 
/usr/bin/python2.7 
/usr/bin/python2.7-config 
/usr/lib/python2.7 
/usr/lib64/python2.7 
/etc/python 
/usr/local/bin/python3.5-config 
/usr/local/bin/python3.5m-config 
/usr/local/bin/python3.5m 
/usr/local/bin/python3.5 
/usr/local/lib/python3.5 
/usr/include/python2.7 
/usr/share/man/man1/python.1.gz

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27143>
_______________________________________

From report at bugs.python.org  Fri May 27 21:35:48 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 May 2016 01:35:48 +0000
Subject: [issue20699] Document that binary IO classes work with bytes-likes
 objects
In-Reply-To: <1392889792.36.0.922412998797.issue20699@psf.upfronthosting.co.za>
Message-ID: <20160528013544.10672.51562.8BD38E08@psf.io>


Roundup Robot added the comment:

New changeset bd41151a7429 by Martin Panter in branch '3.5':
Issue #20699: Document that ?io? methods accept bytes-like objects
https://hg.python.org/cpython/rev/bd41151a7429

New changeset c1b40a29dc7a by Martin Panter in branch 'default':
Issue #20699: Merge io bytes-like fixes from 3.5
https://hg.python.org/cpython/rev/c1b40a29dc7a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20699>
_______________________________________

From report at bugs.python.org  Fri May 27 21:52:18 2016
From: report at bugs.python.org (Alok Singhal)
Date: Sat, 28 May 2016 01:52:18 +0000
Subject: [issue26083] ValueError: insecure string pickle in subprocess.Popen
 on Python 2
In-Reply-To: <1452544995.42.0.684031601483.issue26083@psf.upfronthosting.co.za>
Message-ID: <1464400338.66.0.889160610961.issue26083@psf.upfronthosting.co.za>


Alok Singhal added the comment:

I think there is a small problem with the fix in changeset 268d13c7e939 (msg258029).  It copies the string from the return value of _eintr_retry_call() twice.  I am attaching a trivial fix.

----------
keywords: +patch
nosy: +AlokSinghal
Added file: http://bugs.python.org/file43034/subprocess.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26083>
_______________________________________

From report at bugs.python.org  Fri May 27 22:04:58 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 28 May 2016 02:04:58 +0000
Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not
 available (e.g., AIX)
In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za>
Message-ID: <1464401098.89.0.898951604374.issue26439@psf.upfronthosting.co.za>


Martin Panter added the comment:

Strictly speaking, Python 2.7 never had special support for RTLD_MEMBER or find_library(). That is why I am unsure about many of these changes being done in 2.7. They seem more like new features than bug fixes. Especially once you start talking about a smart CDLL() that tests for a file and then falls back to RTLD_MEMBER.

Whether you represent an archive member as an (archive, member) tuple, or as an "archive(member)" string, or something else, it is still an extension of the API of CDLL(), and arguably also of find_library().

I think I have already tried to explain that on Linux, find_library("libm.so") is far from normal usage (although may be technically legal if there was a library called liblibm.so.so).

Also, on Linux I wouldn?t recommend CDLL("libcrypt.so"), which relies on a file only intended for build time. On Debian, the glibc library <https://packages.debian.org/source/jessie/glibc> has separate packages for shared libraries (libc6) and development libraries (libc6-dev). It should be possible to run programs with libc6 installed, but without libc6-dev. Looking at the file lists for ?i386? architecture, libc6-dev includes:

/usr/lib/i386-linux-gnu/libcrypt.a
/usr/lib/i386-linux-gnu/libcrypt.so

It symbolically links to /lib/i386-linux-gnu/libcrypt.so.1, which is provided by libc6:

/lib/i386-linux-gnu/libcrypt-2.19.so
/lib/i386-linux-gnu/libcrypt.so.1

So on Debian (and with Linux in general), CDLL("libcrypt.so") may work in some cases, but you should normally use CDLL("libcrypt.so.1") instead.

Usually people just upload a new version of the original patch (original changes, plus new changes, in one file). I think it would be too confusing looking at differences between two patches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26439>
_______________________________________

From report at bugs.python.org  Fri May 27 22:35:38 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 May 2016 02:35:38 +0000
Subject: [issue26553] Write HTTP in uppercase
In-Reply-To: <1457936613.19.0.773642660577.issue26553@psf.upfronthosting.co.za>
Message-ID: <20160528023533.18926.50493.88197C75@psf.io>


Roundup Robot added the comment:

New changeset 4275181c4229 by Martin Panter in branch '3.5':
Issue #26553: Capitalization of HTTP, HTTPS, FTP, and URL
https://hg.python.org/cpython/rev/4275181c4229

New changeset 8c92ebcca83f by Martin Panter in branch 'default':
Issue #26553: Merge capitalization from 3.5
https://hg.python.org/cpython/rev/8c92ebcca83f

New changeset d914d681b7f3 by Martin Panter in branch '2.7':
Issue #26553: Capitalization of HTTP, HTTPS, FTP, and URL
https://hg.python.org/cpython/rev/d914d681b7f3

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26553>
_______________________________________

From report at bugs.python.org  Fri May 27 23:12:39 2016
From: report at bugs.python.org (Martin Panter)
Date: Sat, 28 May 2016 03:12:39 +0000
Subject: [issue26553] Write HTTP in uppercase
In-Reply-To: <1457936613.19.0.773642660577.issue26553@psf.upfronthosting.co.za>
Message-ID: <1464405159.91.0.421448358514.issue26553@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thankyou Nathan, and also Anish & Aatish.

For the record, it is normally enough to do a patch against the latest (3.6), and any minor conflicts can be sorted out when applying it to 3.5. In this case the 3.5 and 3.6 patches were basically the same. But the separate patch for 2.7 was very helpful, because there are so many differences between 2 and 3.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26553>
_______________________________________

From report at bugs.python.org  Fri May 27 23:19:54 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Sat, 28 May 2016 03:19:54 +0000
Subject: [issue27137] functools.partial: Inconsistency between Python and C
 implementations
In-Reply-To: <1464367158.87.0.208604382314.issue27137@psf.upfronthosting.co.za>
Message-ID: <1464405594.78.0.630294477297.issue27137@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

Attached patch turns the Python implementation of functools.partial into a class. The implementation is as close to the C version as possible, except __repr__ where I went for a different, more Pythonic approach (output is identical).

I haven't yet added tests for this, and I had to fix something (because some errors occur if _functools is not present and that's the only way I know to make the tests run against the Python implementation). One test fails with the patch (and sys.modules["_functools"] = None):

...........................................................E....................
....................................................................
======================================================================
ERROR: test_pickle (test.test_functools.TestPartialC)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "E:\GitHub\cpython\lib\test\test_functools.py", line 224, in test_pickle
    f_copy = pickle.loads(pickle.dumps(f, proto))
_pickle.PicklingError: Can't pickle <class 'functools.partial'>: it's not the sa
me object as functools.partial

----------------------------------------------------------------------
Ran 148 tests in 0.216s

FAILED (errors=1)

I'll try to see what kind of tests I can add to this to reliably test both 'partial' implementations. I'll also see what I can do about that one failing test. Oddly enough, there seems to be a test for subclassing '_functools.partial', which I might extend.

Raymond, what do you think?

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file43035/functools_partial_1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27137>
_______________________________________

From report at bugs.python.org  Fri May 27 23:53:32 2016
From: report at bugs.python.org (Ben Finney)
Date: Sat, 28 May 2016 03:53:32 +0000
Subject: =?utf-8?q?=5Bissue27043=5D_Describe_what_=E2=80=98inspect=2Ecleandoc?=
 =?utf-8?q?=E2=80=99_does_to_synopsis_line=2E?=
In-Reply-To: <1464365907.39.0.530323734626.issue27043@psf.upfronthosting.co.za>
Message-ID: <20160528035323.GE2150@benfinney.id.au>


Ben Finney added the comment:

On 27-May-2016, Nathan Harold wrote:
> 
> Split version (cleandoc2.patch):
> 
>    Clean up indentation from docstrings that are indented to line up
>    with blocks of code.
>    
>    All leading whitespace is removed from the first line. Any
>    leading whitespace that can be uniformly removed from the second
>    line onwards is removed. Empty lines at the beginning and end are
>    subsequently removed. Also, all tabs are expanded to spaces.

That looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27043>
_______________________________________

From report at bugs.python.org  Sat May 28 01:12:17 2016
From: report at bugs.python.org (Ketan Bhatt)
Date: Sat, 28 May 2016 05:12:17 +0000
Subject: [issue26149] Suggest PyCharm Community as an editor for Unix platforms
In-Reply-To: <1453153728.95.0.733172914649.issue26149@psf.upfronthosting.co.za>
Message-ID: <1464412337.81.0.592228485963.issue26149@psf.upfronthosting.co.za>


Ketan Bhatt added the comment:

I would want to work on this, for 2 days. 
This is going to be my first contribution to python, please bear with me if i make some silly mistake.

Looking forward to your support. Thank you

----------
nosy: +Ketan Bhatt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26149>
_______________________________________

From report at bugs.python.org  Sat May 28 01:39:49 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 May 2016 05:39:49 +0000
Subject: [issue27142] Default int value with xmlrpclib / xmlrpc.client
In-Reply-To: <1464387462.23.0.765030008479.issue27142@psf.upfronthosting.co.za>
Message-ID: <1464413989.32.0.628312771704.issue27142@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

XML-RPC Specification: http://xmlrpc.scripting.com/spec.html .

----------
nosy: +loewis, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27142>
_______________________________________

From report at bugs.python.org  Sat May 28 01:39:53 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 28 May 2016 05:39:53 +0000
Subject: [issue27137] functools.partial: Inconsistency between Python and C
 implementations
In-Reply-To: <1464367158.87.0.208604382314.issue27137@psf.upfronthosting.co.za>
Message-ID: <1464413993.72.0.955027674246.issue27137@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

-1 I prefer to keep the current clean, easy-to-understand, easy-to-get-right code which complies with the documented API.  I see no real benefit in twisting the code around to match non-guaranteed implementation details.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27137>
_______________________________________

From report at bugs.python.org  Sat May 28 01:40:49 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 28 May 2016 05:40:49 +0000
Subject: [issue27141] Fix collections.UserList shallow copy
In-Reply-To: <1464384542.41.0.303372176211.issue27141@psf.upfronthosting.co.za>
Message-ID: <1464414049.76.0.719500184347.issue27141@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Please add a test case.

----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27141>
_______________________________________

From report at bugs.python.org  Sat May 28 02:34:35 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sat, 28 May 2016 06:34:35 +0000
Subject: [issue27143] python 3.5 conflict with Mailman, ebtables and firewalld
In-Reply-To: <1464395175.01.0.190089225196.issue27143@psf.upfronthosting.co.za>
Message-ID: <20160527233430.462ad6e8.barry@wooz.org>


Barry A. Warsaw added the comment:

On May 28, 2016, at 12:26 AM, Rub?n Rivero Capriles wrote:

>While: Installing mailman.

Which version of Mailman?  Mailman 2.1 is not compatible with Python 3,
Mailman 3.0 is only compatible with Python 3.4, and Mailman 3.1 (not yet
released) will be compatible with 3.4 and 3.5.

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27143>
_______________________________________

From report at bugs.python.org  Sat May 28 02:44:41 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 May 2016 06:44:41 +0000
Subject: [issue20699] Document that binary IO classes work with bytes-likes
 objects
In-Reply-To: <1392889792.36.0.922412998797.issue20699@psf.upfronthosting.co.za>
Message-ID: <1464417881.1.0.468302430782.issue20699@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Things are more complex in 2.7. Not all objects supporting old buffer protocol support new buffer protocol, and not all functions accepting old buffer protocol work with new buffer protocol.

>>> buffer(array.array('I'))
<read-only buffer for 0xb70fec00, size -1, offset 0 at 0xb70feb60>
>>> memoryview(array.array('I'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: cannot make memory view because object does not have the buffer interface
>>> zlib.compress(buffer('abc'))
"x\x9cKLJ\x06\x00\x02M\x01'"
>>> zlib.compress(memoryview('abc'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: compress() argument 1 must be string or read-only buffer, not memoryview

The definition of the "bytes-like object" term (changed in 74e1c50498f8) looks not correct in 2.7, because it mentions memoryview (rarely supported in 2.7 besides backported from 3.x features), but not buffer (widely supported in 2.7). It is referred only in one place (in Doc/library/hmac.rst, copied from 3.x in issue21306). I would suggest to avoid using this term, and be more specific about supported protocols in every concrete case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20699>
_______________________________________

From report at bugs.python.org  Sat May 28 02:48:29 2016
From: report at bugs.python.org (=?utf-8?q?Rub=C3=A9n_Rivero_Capriles?=)
Date: Sat, 28 May 2016 06:48:29 +0000
Subject: [issue27143] python 3.5 conflict with Mailman, ebtables and firewalld
In-Reply-To: <1464395175.01.0.190089225196.issue27143@psf.upfronthosting.co.za>
Message-ID: <1464418109.52.0.226030127063.issue27143@psf.upfronthosting.co.za>


Rub?n Rivero Capriles added the comment:

I have Mailman 2.1.5
Is it possible to use it with Python 2.7?
I would need to park the Python 3.5 recently donwloaded until Mailman 3.1 is released?
Or should I download both Python 3.4 and Mailman 3.0
I have no problem in uninstalling anything that would cause conflict

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27143>
_______________________________________

From report at bugs.python.org  Sat May 28 02:57:36 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 May 2016 06:57:36 +0000
Subject: [issue27137] functools.partial: Inconsistency between Python and C
 implementations
In-Reply-To: <1464367158.87.0.208604382314.issue27137@psf.upfronthosting.co.za>
Message-ID: <1464418656.61.0.517267922483.issue27137@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

One problem with current Python implementation is that it doesn't support pickling. The ability of pickling functools.partial() is used in the pickle module for supporting __newobj_ex__ with pickle protocols 2 and 3 (issue24164) and for supporting pickling of operator.methodcaller() objects with keyword arguments (issue22955).

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27137>
_______________________________________

From report at bugs.python.org  Sat May 28 03:06:12 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 28 May 2016 07:06:12 +0000
Subject: [issue27137] functools.partial: Inconsistency between Python and C
 implementations
In-Reply-To: <1464367158.87.0.208604382314.issue27137@psf.upfronthosting.co.za>
Message-ID: <1464419172.47.0.156459828142.issue27137@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

This kind of feature creep has a cost in tern complexity, maintenance, risk of bugs, loss of a clean example for others learn from, and in slower code.

----------
assignee: rhettinger -> ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27137>
_______________________________________

From report at bugs.python.org  Sat May 28 03:06:29 2016
From: report at bugs.python.org (Chi Hsuan Yen)
Date: Sat, 28 May 2016 07:06:29 +0000
Subject: [issue26083] ValueError: insecure string pickle in subprocess.Popen
 on Python 2
In-Reply-To: <1452544995.42.0.684031601483.issue26083@psf.upfronthosting.co.za>
Message-ID: <1464419189.35.0.015883715886.issue26083@psf.upfronthosting.co.za>


Chi Hsuan Yen added the comment:

Great point!

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26083>
_______________________________________

From report at bugs.python.org  Sat May 28 03:18:42 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 May 2016 07:18:42 +0000
Subject: [issue25926] problems with "times" keyword in itertools.repeat
In-Reply-To: <1450806036.21.0.954073881918.issue25926@psf.upfronthosting.co.za>
Message-ID: <20160528071839.122118.9794.EC2FF09E@psf.io>


Roundup Robot added the comment:

New changeset 613314c3f9ed by Raymond Hettinger in branch '3.5':
Issue 25926:  Clarify that the pure python equivalents are only approximate.
https://hg.python.org/cpython/rev/613314c3f9ed

New changeset e67e970de54a by Raymond Hettinger in branch 'default':
Issue 25926:  Clarify that the pure python equivalents are only approximate.
https://hg.python.org/cpython/rev/e67e970de54a

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25926>
_______________________________________

From report at bugs.python.org  Sat May 28 03:26:51 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 May 2016 07:26:51 +0000
Subject: [issue25926] problems with "times" keyword in itertools.repeat
In-Reply-To: <1450806036.21.0.954073881918.issue25926@psf.upfronthosting.co.za>
Message-ID: <20160528072647.10326.3370.B998AC85@psf.io>


Roundup Robot added the comment:

New changeset f66c30f66235 by Raymond Hettinger in branch '2.7':
Issue 25926:  Clarify that the pure python equivalents are only approximate.
https://hg.python.org/cpython/rev/f66c30f66235

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25926>
_______________________________________

From report at bugs.python.org  Sat May 28 03:27:44 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 28 May 2016 07:27:44 +0000
Subject: [issue25926] Clarify that the itertools pure python equivalents are
 only approximate.
In-Reply-To: <1450806036.21.0.954073881918.issue25926@psf.upfronthosting.co.za>
Message-ID: <1464420464.89.0.347040386011.issue25926@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Nofar, thanks for the patch.

----------
components: +Documentation -Interpreter Core
resolution:  -> fixed
status: open -> closed
title: problems with "times" keyword in itertools.repeat -> Clarify that the itertools pure python equivalents are only approximate.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25926>
_______________________________________

From report at bugs.python.org  Sat May 28 03:33:16 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 May 2016 07:33:16 +0000
Subject: [issue27137] functools.partial: Inconsistency between Python and C
 implementations
In-Reply-To: <1464367158.87.0.208604382314.issue27137@psf.upfronthosting.co.za>
Message-ID: <1464420796.11.0.287851600586.issue27137@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

If the Python implementation is just a rough example, and the functools module always require the _functools module, exact behavior of the Python implementation is not very important, as well as its performance. If the functools module can be used without C implementation, Python implementation is just not completely compatible.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27137>
_______________________________________

From report at bugs.python.org  Sat May 28 03:58:49 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 May 2016 07:58:49 +0000
Subject: [issue27141] Fix collections.UserList shallow copy
In-Reply-To: <1464384542.41.0.303372176211.issue27141@psf.upfronthosting.co.za>
Message-ID: <1464422329.81.0.744326225132.issue27141@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

What about UserDict?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27141>
_______________________________________

From report at bugs.python.org  Sat May 28 07:26:07 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 May 2016 11:26:07 +0000
Subject: [issue25926] Clarify that the itertools pure python equivalents are
 only approximate.
In-Reply-To: <1450806036.21.0.954073881918.issue25926@psf.upfronthosting.co.za>
Message-ID: <20160528112603.122124.96704.B686A5A0@psf.io>


Roundup Robot added the comment:

New changeset 35fa2ec1f237 by Serhiy Storchaka in branch 'default':
Merge heads (issue #25926).
https://hg.python.org/cpython/rev/35fa2ec1f237

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25926>
_______________________________________

From report at bugs.python.org  Sat May 28 07:47:16 2016
From: report at bugs.python.org (Bar Harel)
Date: Sat, 28 May 2016 11:47:16 +0000
Subject: [issue27141] Fix collections.UserList shallow copy
In-Reply-To: <1464384542.41.0.303372176211.issue27141@psf.upfronthosting.co.za>
Message-ID: <1464436036.49.0.171131017875.issue27141@psf.upfronthosting.co.za>


Bar Harel added the comment:

I thought about UserDict, but adding this simple patch to UserDict will result in infinite recursion (due to how copy is implemented in there). We will have to change the implementation of UserDict's copy method.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27141>
_______________________________________

From report at bugs.python.org  Sat May 28 07:48:47 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 May 2016 11:48:47 +0000
Subject: [issue27138] FileFinder.find_spec() docstring needs to be corrected.
In-Reply-To: <1464373576.22.0.0993428685624.issue27138@psf.upfronthosting.co.za>
Message-ID: <20160528114843.103227.35550.449E0918@psf.io>


Roundup Robot added the comment:

New changeset 8a49da84fc1d by Serhiy Storchaka in branch '3.5':
Issue #27138: Regenerate Python/importlib_external.h.
https://hg.python.org/cpython/rev/8a49da84fc1d

New changeset fb965ee44d5e by Serhiy Storchaka in branch 'default':
Issue #27138: Regenerate Python/importlib_external.h.
https://hg.python.org/cpython/rev/fb965ee44d5e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27138>
_______________________________________

From report at bugs.python.org  Sat May 28 08:10:24 2016
From: report at bugs.python.org (Bar Harel)
Date: Sat, 28 May 2016 12:10:24 +0000
Subject: [issue27141] Fix collections.UserList shallow copy
In-Reply-To: <1464384542.41.0.303372176211.issue27141@psf.upfronthosting.co.za>
Message-ID: <1464437424.9.0.859596780143.issue27141@psf.upfronthosting.co.za>


Bar Harel added the comment:

Added UserDict and UserList tests.
Keep in mind I am currently skipping UserDict's tests until we will implement the correct mechanism.
We do not need the same tests or functionality for UserString as UserString is immutable.

----------
Added file: http://bugs.python.org/file43036/UserObj_tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27141>
_______________________________________

From report at bugs.python.org  Sat May 28 09:25:06 2016
From: report at bugs.python.org (=?utf-8?q?Rub=C3=A9n_Rivero_Capriles?=)
Date: Sat, 28 May 2016 13:25:06 +0000
Subject: [issue27143] python 3.5 conflict with Mailman, ebtables and firewalld
In-Reply-To: <1464395175.01.0.190089225196.issue27143@psf.upfronthosting.co.za>
Message-ID: <1464441906.58.0.438040568106.issue27143@psf.upfronthosting.co.za>


Rub?n Rivero Capriles added the comment:

Hi. I decided to reinstall CentOs 7 and already installed Python 3.4 at http://www.codeghar.com/blog/install-latest-python-on-centos-7.html

I am downloading the tarball for mailman 3.0.3. I will greatly appreciate if you quickly let me know how to install it. I do not wish to use mailman bundler.

----------

_______________________________________
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: [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 09:26:47 2016
From: report at bugs.python.org (Grzegorz Grzywacz)
Date: Sat, 28 May 2016 13:26:47 +0000
Subject: [issue27144] concurrent.futures.as_completed() memory inefficiency
In-Reply-To: <1464441935.81.0.0559700033116.issue27144@psf.upfronthosting.co.za>
Message-ID: <1464442007.41.0.786581611725.issue27144@psf.upfronthosting.co.za>


Changes by Grzegorz Grzywacz <grzgrzgrz3 at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file43038/issue27144.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27144>
_______________________________________

From report at bugs.python.org  Sat May 28 09:52:17 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 28 May 2016 13:52:17 +0000
Subject: [issue26526] In parsermodule.c,
 replace over 2KLOC of hand-crafted validation code, with a DFA
In-Reply-To: <1457600551.84.0.318395917649.issue26526@psf.upfronthosting.co.za>
Message-ID: <1464443537.91.0.713090494087.issue26526@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26526>
_______________________________________

From report at bugs.python.org  Sat May 28 09:55:09 2016
From: report at bugs.python.org (pyptr2)
Date: Sat, 28 May 2016 13:55:09 +0000
Subject: [issue27136] sock_connect fails for bluetooth (and probably others)
In-Reply-To: <1464346938.98.0.196127839357.issue27136@psf.upfronthosting.co.za>
Message-ID: <1464443709.1.0.601222402886.issue27136@psf.upfronthosting.co.za>


pyptr2 added the comment:

Thanks for looking into this. Some comments:

1.
yuri, I haven't tried the github repo. Is that where the development happens? The description suggests it is outdated since the adoption, but there are some commits that aren't in hg...?
Anyhow, the relevant code looks identical to me.

2.
guido, yes validation would be domain specific.
But, just to understand: why validate at all?
If I give create_connection() or sock_connect() an unresolved address, then I would expect some "yield from resolve(domain, name)" to happen, which would be getaddrinfo() for IP-domain. If that would hang the event loop on some platform, do it in an executor. This is exactly what create_server() already does, by the way.

3.
AF_UNPSEC seems to mean (AF_INET or AF_INET6) to a lot of people these days, possibly because getaddrinfo() accepts these three AFs. I am not 100% sure, but that is why I think it is reasonable that _ipaddr_info() handles AF_UNSPEC in the way it does.

4.
For my use case, anything that stops check_resolve() from raising when given a resolved non-IP address would be enough for now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27136>
_______________________________________

From report at bugs.python.org  Sat May 28 10:04:30 2016
From: report at bugs.python.org (SilentGhost)
Date: Sat, 28 May 2016 14:04:30 +0000
Subject: [issue27144] concurrent.futures.as_completed() memory inefficiency
In-Reply-To: <1464441935.81.0.0559700033116.issue27144@psf.upfronthosting.co.za>
Message-ID: <1464444270.27.0.121638081361.issue27144@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
stage:  -> patch review
versions:  -Python 3.2, Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27144>
_______________________________________

From report at bugs.python.org  Sat May 28 10:05:37 2016
From: report at bugs.python.org (SilentGhost)
Date: Sat, 28 May 2016 14:05:37 +0000
Subject: [issue27139] Increased test coverage for statistics.median_grouped
Message-ID: <1464444337.4.0.606888636136.issue27139@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +steven.daprano
stage:  -> patch review
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27139>
_______________________________________

From report at bugs.python.org  Sat May 28 10:09:34 2016
From: report at bugs.python.org (SilentGhost)
Date: Sat, 28 May 2016 14:09:34 +0000
Subject: [issue27121] imghdr does not support jpg files with Lavc bytes
In-Reply-To: <1464170447.09.0.218380322577.issue27121@psf.upfronthosting.co.za>
Message-ID: <1464444574.6.0.544644916931.issue27121@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
components: +Library (Lib)
nosy: +r.david.murray
stage:  -> test needed
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/issue27121>
_______________________________________

From report at bugs.python.org  Sat May 28 10:43:00 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 28 May 2016 14:43:00 +0000
Subject: [issue27136] sock_connect fails for bluetooth (and probably others)
In-Reply-To: <1464443709.1.0.601222402886.issue27136@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJJ47CNH7ygUqsgV_oFtOvoQiWjrwJXLEqwKo83hgoDHrA@mail.gmail.com>


Guido van Rossum added the comment:

> Why validate at all?

Because (at least for the IP 4/6 protocols) when you give a host name
Python's socket code will do a synchronous DNS lookup which would hold
up the entire event loop until it's done. This would be a major
problem in some cases, so we want to disallow it completely.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27136>
_______________________________________

From report at bugs.python.org  Sat May 28 10:44:05 2016
From: report at bugs.python.org (Julio C Cardoza)
Date: Sat, 28 May 2016 14:44:05 +0000
Subject: [issue27139] Increased test coverage for statistics.median_grouped
Message-ID: <1464446645.63.0.403096467331.issue27139@psf.upfronthosting.co.za>


New submission from Julio C Cardoza:

I had signed the contributor agreement.!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27139>
_______________________________________

From report at bugs.python.org  Sat May 28 10:53:26 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 May 2016 14:53:26 +0000
Subject: [issue27129] Wordcode, part 2
In-Reply-To: <1464268387.83.0.862540030058.issue27129@psf.upfronthosting.co.za>
Message-ID: <1464447206.7.0.632505024082.issue27129@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Here is a patch that implements only the first change -- makes jump offsets be in 16-bit units, not bytes. This is minimal change, it doesn't include refactoring.

----------
Added file: http://bugs.python.org/file43039/word-jump-offsets.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27129>
_______________________________________

From report at bugs.python.org  Sat May 28 11:31:22 2016
From: report at bugs.python.org (Ned Deily)
Date: Sat, 28 May 2016 15:31:22 +0000
Subject: [issue27101] Compilation of python (modules) for foreign target
 platform problem.
In-Reply-To: <1464066887.71.0.116030526807.issue27101@psf.upfronthosting.co.za>
Message-ID: <1464449482.58.0.790194343034.issue27101@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at python.org>:


----------
nosy: +doko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27101>
_______________________________________

From report at bugs.python.org  Sat May 28 11:45:53 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 May 2016 15:45:53 +0000
Subject: [issue27129] Wordcode, part 2
In-Reply-To: <1464268387.83.0.862540030058.issue27129@psf.upfronthosting.co.za>
Message-ID: <1464450353.47.0.611257044743.issue27129@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


Removed file: http://bugs.python.org/file43039/word-jump-offsets.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27129>
_______________________________________

From report at bugs.python.org  Sat May 28 11:46:10 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 May 2016 15:46:10 +0000
Subject: [issue27129] Wordcode, part 2
In-Reply-To: <1464268387.83.0.862540030058.issue27129@psf.upfronthosting.co.za>
Message-ID: <1464450370.68.0.937634444053.issue27129@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


Added file: http://bugs.python.org/file43040/word-jump-offsets.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27129>
_______________________________________

From report at bugs.python.org  Sat May 28 11:58:41 2016
From: report at bugs.python.org (Oren Milman)
Date: Sat, 28 May 2016 15:58:41 +0000
Subject: [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 11:59:19 2016
From: report at bugs.python.org (Oren Milman)
Date: Sat, 28 May 2016 15:59:19 +0000
Subject: [issue27145] long_add and long_sub might return a new int where
 &small_ints[x] could be returned
In-Reply-To: <1464451117.45.0.85462287723.issue27145@psf.upfronthosting.co.za>
Message-ID: <1464451159.86.0.743423844883.issue27145@psf.upfronthosting.co.za>


Changes by Oren Milman <orenmn at gmail.com>:


Added file: http://bugs.python.org/file43042/CPythonTestOutput.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27145>
_______________________________________

From report at bugs.python.org  Sat May 28 11:59:44 2016
From: report at bugs.python.org (Oren Milman)
Date: Sat, 28 May 2016 15:59:44 +0000
Subject: [issue27145] long_add and long_sub might return a new int where
 &small_ints[x] could be returned
In-Reply-To: <1464451117.45.0.85462287723.issue27145@psf.upfronthosting.co.za>
Message-ID: <1464451184.98.0.482963238493.issue27145@psf.upfronthosting.co.za>


Changes by Oren Milman <orenmn at gmail.com>:


Added file: http://bugs.python.org/file43043/patchedCPythonTestOutput.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27145>
_______________________________________

From report at bugs.python.org  Sat May 28 12:21:22 2016
From: report at bugs.python.org (R. David Murray)
Date: Sat, 28 May 2016 16:21:22 +0000
Subject: [issue27132] New assert method that checks an error message for a
 list of strings
In-Reply-To: <1464295693.41.0.439639952512.issue27132@psf.upfronthosting.co.za>
Message-ID: <1464452482.33.0.31845669973.issue27132@psf.upfronthosting.co.za>


R. David Murray added the comment:

Serhiy, how do you spell "match if and only if all of the following substrings exist in the target string, in any position" in a regex?  If we aren't going to add the method, we should add an example of how to do this to the assertMsgRegex docs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27132>
_______________________________________

From report at bugs.python.org  Sat May 28 12:21:36 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sat, 28 May 2016 16:21:36 +0000
Subject: [issue27143] python 3.5 conflict with Mailman, ebtables and firewalld
In-Reply-To: <1464395175.01.0.190089225196.issue27143@psf.upfronthosting.co.za>
Message-ID: <1464452496.76.0.463651724692.issue27143@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

This is definitely not the right place to discuss this.  Please use the Mailman 3 users mailing list or the Mailman Developers mailing list.

https://lists.mailman3.org/archives/list/mailman-users at mailman3.org/
https://mail.python.org/mailman/listinfo/mailman-developers

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27143>
_______________________________________

From report at bugs.python.org  Sat May 28 12:50:22 2016
From: report at bugs.python.org (Oren Milman)
Date: Sat, 28 May 2016 16:50:22 +0000
Subject: [issue27073] redundant checks in long_add and long_sub
In-Reply-To: <1463816500.87.0.013124059613.issue27073@psf.upfronthosting.co.za>
Message-ID: <1464454222.0.0.0974149410133.issue27073@psf.upfronthosting.co.za>


Oren Milman added the comment:

After giving it some more thought (while working on another, somewhat related issue - http://bugs.python.org/issue27145), I realized that that assert in long_add could further verify that the int x_add returned is a multiple-digit int (as x_add had received two multiple-digit ints to begin with).

The important thing about this updated assert is that it verifies that x_add didn't return a reference to an element in small_ints (as small ints must be single-digit ints), so negating it in-place is safe.

I have updated the assert and added an appropriate comment. The updated diff file is attached.

----------
Added file: http://bugs.python.org/file43044/issue27073.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27073>
_______________________________________

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: [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:08:42 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 May 2016 17:08:42 +0000
Subject: [issue27146] posixmodule.c needs stdio.h
In-Reply-To: <1464455007.27.0.77870799101.issue27146@psf.upfronthosting.co.za>
Message-ID: <1464455322.59.0.171606547996.issue27146@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27146>
_______________________________________

From report at bugs.python.org  Sat May 28 13:09:12 2016
From: report at bugs.python.org (Oren Milman)
Date: Sat, 28 May 2016 17:09:12 +0000
Subject: [issue27073] redundant checks in long_add and long_sub
In-Reply-To: <1463816500.87.0.013124059613.issue27073@psf.upfronthosting.co.za>
Message-ID: <1464455352.72.0.920255631058.issue27073@psf.upfronthosting.co.za>


Oren Milman added the comment:

And after quadruple checking myself, I found a foolish mistake - in that flow, x_add received at least one multiple-digit int (not necessarily two :().

I fixed that mistake in the comment. The updated diff file is attached.

----------
Added file: http://bugs.python.org/file43045/issue27073.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27073>
_______________________________________

From report at bugs.python.org  Sat May 28 13:14:15 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 May 2016 17:14:15 +0000
Subject: [issue27073] redundant checks in long_add and long_sub
In-Reply-To: <1463816500.87.0.013124059613.issue27073@psf.upfronthosting.co.za>
Message-ID: <1464455655.25.0.300838591236.issue27073@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I don't think this assert is needed. Nothing bad happens if the asserted condition is false. On other side, additional assert can slow down debug build (that is already slower than release build).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27073>
_______________________________________

From report at bugs.python.org  Sat May 28 13:31:58 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 28 May 2016 17:31:58 +0000
Subject: [issue27132] New assert method that checks an error message for a
 list of strings
In-Reply-To: <1464295693.41.0.439639952512.issue27132@psf.upfronthosting.co.za>
Message-ID: <1464456718.31.0.381276455071.issue27132@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The simple way is just write all possible variants ('ENABLE.*NOAUTH|NOAUTH.*ENABLE').

The general way is to use itertools.permutations():

    pattern = '|'.join(map('.*'.join, permutations(map(re.escape, strings))))

See also similar problem in issue19681. The first my patch used permutations(). But there was committed the patch with manually written variants.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27132>
_______________________________________

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: [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 14:10:11 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 May 2016 18:10:11 +0000
Subject: [issue27147] importlib docs do not mention PEP 420
In-Reply-To: <1464458038.31.0.784289682435.issue27147@psf.upfronthosting.co.za>
Message-ID: <20160528181008.32447.73832.A278329B@psf.io>


Roundup Robot added the comment:

New changeset 6f50c04e4a1e by Eric Snow in branch '3.5':
Issue #27147: Mention PEP 420 in the importlib docs.
https://hg.python.org/cpython/rev/6f50c04e4a1e

New changeset 0177af33ce76 by Eric Snow in branch 'default':
Issue #27147: Mention PEP 420 in the importlib docs.
https://hg.python.org/cpython/rev/0177af33ce76

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27147>
_______________________________________

From report at bugs.python.org  Sat May 28 14:10:56 2016
From: report at bugs.python.org (Eric Snow)
Date: Sat, 28 May 2016 18:10:56 +0000
Subject: [issue27147] importlib docs do not mention PEP 420
In-Reply-To: <1464458038.31.0.784289682435.issue27147@psf.upfronthosting.co.za>
Message-ID: <1464459056.48.0.0860836528087.issue27147@psf.upfronthosting.co.za>


Changes by Eric Snow <ericsnowcurrently at gmail.com>:


----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27147>
_______________________________________

From report at bugs.python.org  Sat May 28 14:23:45 2016
From: report at bugs.python.org (R. David Murray)
Date: Sat, 28 May 2016 18:23:45 +0000
Subject: [issue27132] New assert method that checks an error message for a
 list of strings
In-Reply-To: <1464295693.41.0.439639952512.issue27132@psf.upfronthosting.co.za>
Message-ID: <1464459825.55.0.205214096894.issue27132@psf.upfronthosting.co.za>


R. David Murray added the comment:

The complexity of those solutions argues in favor of adding a method, I'd say.

Personally I'd write multiple asserts rather than regex permutations.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27132>
_______________________________________

From report at bugs.python.org  Sat May 28 14:33:11 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 28 May 2016 18:33:11 +0000
Subject: [issue3982] support .format for bytes
In-Reply-To: <1222530641.39.0.0764973101836.issue3982@psf.upfronthosting.co.za>
Message-ID: <1464460391.49.0.33972895813.issue3982@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

This came up in the language summit today when discussing twisted.  .format() is still not supported on bytes though % is in 3.5.

realistically it sounded like twisted needs to support python 3.4 for many years so they can't rely on bytes having a .format() method that also works on 2.7 anyways... but assuming .format() is only useful for text may still have been an oversight.  (i'll have to go re-read pep 460 and 461 and discussion before commenting further)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3982>
_______________________________________

From report at bugs.python.org  Sat May 28 15:25:00 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 May 2016 19:25:00 +0000
Subject: [issue26083] ValueError: insecure string pickle in subprocess.Popen
 on Python 2
In-Reply-To: <1452544995.42.0.684031601483.issue26083@psf.upfronthosting.co.za>
Message-ID: <20160528192450.32435.10369.E01618F5@psf.io>


Roundup Robot added the comment:

New changeset 184dfef08a93 by Gregory P. Smith in branch '2.7':
issue26083: Avoid duplicate error message string from a subprocess exec failure.Avoid a duplicate error message string from a subprocess exec failure.
https://hg.python.org/cpython/rev/184dfef08a93

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26083>
_______________________________________

From report at bugs.python.org  Sat May 28 15:25:16 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 28 May 2016 19:25:16 +0000
Subject: [issue26083] ValueError: insecure string pickle in subprocess.Popen
 on Python 2
In-Reply-To: <1452544995.42.0.684031601483.issue26083@psf.upfronthosting.co.za>
Message-ID: <1464463516.0.0.181184756711.issue26083@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26083>
_______________________________________

From report at bugs.python.org  Sat May 28 15:36:26 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Sat, 28 May 2016 19:36:26 +0000
Subject: [issue27137] functools.partial: Inconsistency between Python and C
 implementations
In-Reply-To: <1464367158.87.0.208604382314.issue27137@psf.upfronthosting.co.za>
Message-ID: <1464464186.39.0.423703453541.issue27137@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

Serhiy, it seems as though _functools is always required for functools to work - heck, tests start to fail all over the place if it isn't available, because functools.reduce doesn't exist.

Subclassing _functools.partial is already tested for, so I wouldn't qualify it as an implementation detail myself. Moreover, I feel that we should try to (somewhat) keep both implementations identical - or close enough.

It seems that _pickle checks for _functools.partial, and that trying to pickle the pure Python version triggers the error in msg266530.

This probably doesn't matter for most (if not all) of cases where CPython is concerned. But I care about the ability for alternate implementations to work the same way.

Compromise: rename the current partial function to partial_func and keep it around ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27137>
_______________________________________

From report at bugs.python.org  Sat May 28 15:53:22 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 May 2016 19:53:22 +0000
Subject: [issue24225] Idlelib: changing file names
In-Reply-To: <1431934587.56.0.38760352205.issue24225@psf.upfronthosting.co.za>
Message-ID: <20160528195318.111021.38971.55C9456C@psf.io>


Roundup Robot added the comment:

New changeset 6ecd4db71b88 by Terry Jan Reedy in branch 'default':
Issue #24225: Rename many idlelib/*.py and idlelib/idle_test/test_*.py files.
https://hg.python.org/cpython/rev/6ecd4db71b88

New changeset 0c3fdb161901 by Terry Jan Reedy in branch 'default':
Issue #24225: Within idlelib files, update idlelib module names.
https://hg.python.org/cpython/rev/0c3fdb161901

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24225>
_______________________________________

From report at bugs.python.org  Sat May 28 16:25:32 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 May 2016 20:25:32 +0000
Subject: [issue24225] Idlelib: changing file names
In-Reply-To: <1431934587.56.0.38760352205.issue24225@psf.upfronthosting.co.za>
Message-ID: <1464467132.93.0.184338962489.issue24225@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Revision should definitely be tested on Mac by running IDLE from a console to check for any Mac-specific warnings and check that the menu looks 'right', which is to say, same as with 3.5.

Still to do: news entries, What's New section, README.txt revision with new names.

----------
stage: test needed -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24225>
_______________________________________

From report at bugs.python.org  Sat May 28 16:30:50 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 28 May 2016 20:30:50 +0000
Subject: [issue24225] Idlelib: changing file names
In-Reply-To: <1431934587.56.0.38760352205.issue24225@psf.upfronthosting.co.za>
Message-ID: <1464467450.81.0.448719413532.issue24225@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I have a new idea for public interfaces: keep most of idlelib private and add a new 'interface' module containing public interfaces.  It could be backported to 3.5 and even 2.7.

This was prompted by working with turtledemo.  It currently imports textview, percolator, and colorizer to create a colorized code viewer.  At the moment, changing the names in the three imports worked, but that could change if any of the files are refactored.  (And what about people who have trouble hooking the three components together correctly?)

Instead, lets create, say, class ColorCodeview (or maybe a function) in interface and have turtledemo do one import, say 'from idlelib.interface import ColorCodeview'.  The internal code code would be slilghtly different in each of 2.7, 3.5, and 3.6 (and maybe different again sometime after the initial commit).  But the import and basic use should be the same.

The only thing I might put in the main idlelib doc would be something like 'See the interface module for currently supported external uses of idlelib components."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24225>
_______________________________________

From report at bugs.python.org  Sat May 28 16:44:12 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 28 May 2016 20:44:12 +0000
Subject: [issue9327] doctest DocFileCase setUp/tearDown asymmetry
In-Reply-To: <1279750116.68.0.946227736764.issue9327@psf.upfronthosting.co.za>
Message-ID: <1464468252.16.0.521865835763.issue9327@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> resolved
status: open -> closed
superseder:  -> doctest.DocTestCase fails when run repeatedly

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9327>
_______________________________________

From report at bugs.python.org  Sat May 28 17:06:11 2016
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 28 May 2016 21:06:11 +0000
Subject: [issue25731] Assigning and deleting __new__ attr on the class does
 not allow to create instances of this class
In-Reply-To: <1448454590.41.0.350843358205.issue25731@psf.upfronthosting.co.za>
Message-ID: <1464469571.59.0.771017866581.issue25731@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

I'll have to think about how to fix this while maintaining compatiblity with obscure cases like above.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25731>
_______________________________________

From report at bugs.python.org  Sat May 28 17:06:53 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 May 2016 21:06:53 +0000
Subject: [issue27146] posixmodule.c needs stdio.h
In-Reply-To: <1464455007.27.0.77870799101.issue27146@psf.upfronthosting.co.za>
Message-ID: <20160528210649.13744.79255.000AFC0A@psf.io>


Roundup Robot added the comment:

New changeset c8e113bf56ae by Gregory P. Smith in branch '3.5':
Fix issue27146 - add stdio.h include to posixmodule.c for ctermid().
https://hg.python.org/cpython/rev/c8e113bf56ae

New changeset 74fcfc29187e by Gregory P. Smith in branch 'default':
Fix issue27146 - add stdio.h include to posixmodule.c for ctermid().
https://hg.python.org/cpython/rev/74fcfc29187e

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27146>
_______________________________________

From report at bugs.python.org  Sat May 28 17:08:17 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 28 May 2016 21:08:17 +0000
Subject: [issue27146] posixmodule.c needs stdio.h
In-Reply-To: <1464455007.27.0.77870799101.issue27146@psf.upfronthosting.co.za>
Message-ID: <1464469697.36.0.983273633367.issue27146@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27146>
_______________________________________

From report at bugs.python.org  Sat May 28 17:08:17 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sat, 28 May 2016 21:08:17 +0000
Subject: [issue25731] Assigning and deleting __new__ attr on the class does
 not allow to create instances of this class
In-Reply-To: <1448454590.41.0.350843358205.issue25731@psf.upfronthosting.co.za>
Message-ID: <20160528210814.16715.31920.88D5739E@psf.io>


Roundup Robot added the comment:

New changeset 3ff84a3eeb6b by Benjamin Peterson in branch '2.7':
Backed out changeset e7062dd9085e (#25731)
https://hg.python.org/cpython/rev/3ff84a3eeb6b

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25731>
_______________________________________

From report at bugs.python.org  Sat May 28 17:11:56 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 28 May 2016 21:11:56 +0000
Subject: [issue16182] readline: Wrong tab completion scope indices in Unicode
 terminals
In-Reply-To: <1349813384.06.0.615857426211.issue16182@psf.upfronthosting.co.za>
Message-ID: <1464469916.57.0.835254677619.issue16182@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16182>
_______________________________________

From report at bugs.python.org  Sat May 28 17:13:39 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 28 May 2016 21:13:39 +0000
Subject: [issue21084] IDLE can't deal with characters above the range
 (U+0000-U+FFFF)
In-Reply-To: <1396008065.84.0.00802001667749.issue21084@psf.upfronthosting.co.za>
Message-ID: <1464470019.16.0.607779154347.issue21084@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21084>
_______________________________________

From report at bugs.python.org  Sat May 28 17:14:38 2016
From: report at bugs.python.org (Mark Lawrence)
Date: Sat, 28 May 2016 21:14:38 +0000
Subject: [issue7951] Should str.format allow negative indexes when used for
 __getitem__ access?
In-Reply-To: <1266450859.13.0.906832569526.issue7951@psf.upfronthosting.co.za>
Message-ID: <1464470078.3.0.27946703495.issue7951@psf.upfronthosting.co.za>


Changes by Mark Lawrence <breamoreboy at yahoo.co.uk>:


----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7951>
_______________________________________

From report at bugs.python.org  Sat May 28 17:53:27 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 28 May 2016 21:53:27 +0000
Subject: [issue26372] Popen.communicate not ignoring BrokenPipeError
In-Reply-To: <1455672512.72.0.551664124622.issue26372@psf.upfronthosting.co.za>
Message-ID: <1464472407.78.0.675088911502.issue26372@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26372>
_______________________________________

From report at bugs.python.org  Sat May 28 17:58:00 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 28 May 2016 21:58:00 +0000
Subject: [issue27122] Hang with contextlib.ExitStack and subprocess.Popen
 (regression)
In-Reply-To: <1464176880.25.0.308106356091.issue27122@psf.upfronthosting.co.za>
Message-ID: <1464472680.0.0.977007547751.issue27122@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27122>
_______________________________________

From report at bugs.python.org  Sat May 28 18:19:07 2016
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Sat, 28 May 2016 22:19:07 +0000
Subject: [issue26526] In parsermodule.c,
 replace over 2KLOC of hand-crafted validation code, with a DFA
In-Reply-To: <1457600551.84.0.318395917649.issue26526@psf.upfronthosting.co.za>
Message-ID: <1464473947.63.0.781458682903.issue26526@psf.upfronthosting.co.za>


Fred L. Drake, Jr. added the comment:

I've read through this, but haven't applied the patch & run tests (that's what buildbots are for).

No objections.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26526>
_______________________________________

From report at bugs.python.org  Sat May 28 19:56:58 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 28 May 2016 23:56:58 +0000
Subject: [issue9363] data_files are not installed relative to sys.prefix
In-Reply-To: <1279926086.74.0.751307014326.issue9363@psf.upfronthosting.co.za>
Message-ID: <1464479818.85.0.671539995383.issue9363@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Issue 25592 is a duplicate of this and but it has a patch that almost ready to commit so I'm closing this one.

----------
nosy: +berker.peksag
resolution:  -> duplicate
stage: test needed -> resolved
status: open -> closed
superseder:  -> distutils docs: data_files always uses sys.prefix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9363>
_______________________________________

From report at bugs.python.org  Sat May 28 19:58:02 2016
From: report at bugs.python.org (Berker Peksag)
Date: Sat, 28 May 2016 23:58:02 +0000
Subject: [issue25592] distutils docs: data_files always uses sys.prefix
In-Reply-To: <1447135572.7.0.138478279434.issue25592@psf.upfronthosting.co.za>
Message-ID: <1464479882.6.0.384866682842.issue25592@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
components: +Distutils
nosy: +berker.peksag, dstufft, eric.araujo
stage:  -> patch review
type:  -> behavior
versions: +Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25592>
_______________________________________

From report at bugs.python.org  Sat May 28 20:06:11 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 29 May 2016 00:06:11 +0000
Subject: [issue27112] tokenize.__all__ list is incomplete
In-Reply-To: <1464123395.58.0.823594635343.issue27112@psf.upfronthosting.co.za>
Message-ID: <1464480371.21.0.0657202206242.issue27112@psf.upfronthosting.co.za>


Martin Panter added the comment:

Changing the names to tokenize.<name> does solve the problem of the tokenize module versus the tokenize() fuction, so I can accept this way since you prefer it.

So I think that just leaves what to do with the actual test case. I don?t think it matters too much, but I would lean toward ensuring the test fails if someone adds a new implementation detail without an underscore prefix. It is also good to be explicit that the ISTERMINAL() etc functions are special cases.

On the other hand, neither the original patch nor Jacek?s proposal for ?expected = token.__all__ + ...? would pick up the fact that the tok_name dictionary is another special case copied from the ?token? module. (See also Issue 25324.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27112>
_______________________________________

From report at bugs.python.org  Sat May 28 20:12:19 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 29 May 2016 00:12:19 +0000
Subject: [issue27109] plistlib.__all__ list is incomplete
In-Reply-To: <1464121972.25.0.312623599868.issue27109@psf.upfronthosting.co.za>
Message-ID: <1464480739.85.0.14683367261.issue27109@psf.upfronthosting.co.za>


Martin Panter added the comment:

I think this patch is okay

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27109>
_______________________________________

From report at bugs.python.org  Sat May 28 20:20:39 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 29 May 2016 00:20:39 +0000
Subject: [issue27105] cgi.__all__ is incomplete
In-Reply-To: <1464121575.73.0.75569808483.issue27105@psf.upfronthosting.co.za>
Message-ID: <1464481239.95.0.354582412789.issue27105@psf.upfronthosting.co.za>


Martin Panter added the comment:

For this particular case, there is only one existing test class called CgiTests, without any special setup or handling. It seems too arbitrary to have a second class called MiscTestCase, so I would prefer the new test be added to CgiTests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27105>
_______________________________________

From report at bugs.python.org  Sat May 28 21:10:37 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 May 2016 01:10:37 +0000
Subject: [issue27124] binascii.a2b_hex raises binascii.Error and ValueError,
 not TypeError
In-Reply-To: <1464190951.12.0.309980767012.issue27124@psf.upfronthosting.co.za>
Message-ID: <20160529011033.122114.86376.663BDDF6@psf.io>


Roundup Robot added the comment:

New changeset ef89ecb6debc by Martin Panter in branch '3.5':
Issue #27124: Fix documentation of exception raised by a2b_hex()
https://hg.python.org/cpython/rev/ef89ecb6debc

New changeset 85e6da63d73f by Martin Panter in branch 'default':
Issue #27124: Merge binascii doc from 3.5
https://hg.python.org/cpython/rev/85e6da63d73f

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27124>
_______________________________________

From report at bugs.python.org  Sat May 28 23:44:20 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 29 May 2016 03:44:20 +0000
Subject: [issue27124] binascii.a2b_hex raises binascii.Error and ValueError,
 not TypeError
In-Reply-To: <1464190951.12.0.309980767012.issue27124@psf.upfronthosting.co.za>
Message-ID: <1464493460.33.0.111005694315.issue27124@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27124>
_______________________________________

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: [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:36:13 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 29 May 2016 05:36:13 +0000
Subject: [issue27117] turtledemo does not work with IDLE's new dark theme.
In-Reply-To: <1464145339.77.0.706051446081.issue27117@psf.upfronthosting.co.za>
Message-ID: <1464500173.32.0.0252687033752.issue27117@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I was wrong about turtledemo's text pane.  Turtledemo only uses textview for help.  The text frame contains a plain Text widget.  I moved the text color-config code from editor to a function in colorizer, where it is also needed for the colorizer test.

----------
assignee:  -> terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27117>
_______________________________________

From report at bugs.python.org  Sun May 29 01:42:26 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 May 2016 05:42:26 +0000
Subject: [issue27117] turtledemo does not work with IDLE's new dark theme.
In-Reply-To: <1464145339.77.0.706051446081.issue27117@psf.upfronthosting.co.za>
Message-ID: <20160529054223.10658.63390.6F246219@psf.io>


Roundup Robot added the comment:

New changeset c95864a37ee2 by Terry Jan Reedy in branch 'default':
Issue #27117: Make colorizer htest and turtledemo work with dark theme.
https://hg.python.org/cpython/rev/c95864a37ee2

New changeset f383eaf207ca by Terry Jan Reedy in branch '3.5':
Issue #27117: Make ColorDelegator htest and turtledemo work with dark theme.
https://hg.python.org/cpython/rev/f383eaf207ca

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27117>
_______________________________________

From report at bugs.python.org  Sun May 29 01:44:08 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 29 May 2016 05:44:08 +0000
Subject: [issue27117] turtledemo does not work with IDLE's new dark theme.
In-Reply-To: <1464145339.77.0.706051446081.issue27117@psf.upfronthosting.co.za>
Message-ID: <1464500648.29.0.817344166746.issue27117@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> fixed
stage: test needed -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27117>
_______________________________________

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: [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 02:45:36 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 29 May 2016 06:45:36 +0000
Subject: [issue27137] functools.partial: Inconsistency between Python and C
 implementations
In-Reply-To: <1464464186.39.0.423703453541.issue27137@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwbzrL_7FHeb=UYvezSrYQ_LjVLrBjW=5UXGdm2WRoQDnw@mail.gmail.com>


STINNER Victor added the comment:

The PEP 399 requires that the Python implementation behaves like the C
accelerator, no? I didn't check the specific case of this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27137>
_______________________________________

From report at bugs.python.org  Sun May 29 03:02:17 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 May 2016 07:02:17 +0000
Subject: [issue27137] functools.partial: Inconsistency between Python and C
 implementations
In-Reply-To: <1464367158.87.0.208604382314.issue27137@psf.upfronthosting.co.za>
Message-ID: <1464505337.51.0.624924718503.issue27137@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

PEP 399 requires that the C code must pass the test suite used for the pure Python code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27137>
_______________________________________

From report at bugs.python.org  Sun May 29 03:04:21 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 May 2016 07:04:21 +0000
Subject: [issue27117] turtledemo does not work with IDLE's new dark theme.
In-Reply-To: <1464145339.77.0.706051446081.issue27117@psf.upfronthosting.co.za>
Message-ID: <1464505461.37.0.965504917611.issue27117@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Heads are not merged.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27117>
_______________________________________

From report at bugs.python.org  Sun May 29 03:06:03 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Sun, 29 May 2016 07:06:03 +0000
Subject: [issue16500] Add an 'atfork' module
In-Reply-To: <1353252005.31.0.454056781872.issue16500@psf.upfronthosting.co.za>
Message-ID: <1464505563.64.0.651263568053.issue16500@psf.upfronthosting.co.za>


Changes by ???? ????????? <socketpair at gmail.com>:


----------
nosy: +mmarkk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16500>
_______________________________________

From report at bugs.python.org  Sun May 29 03:17:25 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Sun, 29 May 2016 07:17:25 +0000
Subject: [issue16500] Add an 'atfork' module
In-Reply-To: <1353252005.31.0.454056781872.issue16500@psf.upfronthosting.co.za>
Message-ID: <1464506245.1.0.184410325499.issue16500@psf.upfronthosting.co.za>


???? ????????? added the comment:

Also I have to add, maybe you also add automatic file descriptor closing on fork. We already have O_CLOEXEC, we have no O_CLOFORK. So, maybe it useful to add such flag ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16500>
_______________________________________

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: [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 03:35:42 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Sun, 29 May 2016 07:35:42 +0000
Subject: [issue27150] PEP446 (CLOEXEC by default) violation with
 fcntl.fcntl(..., fcntl.F_DUPFD)
In-Reply-To: <1464507265.78.0.794599717766.issue27150@psf.upfronthosting.co.za>
Message-ID: <1464507342.86.0.725547109587.issue27150@psf.upfronthosting.co.za>


Changes by ???? ????????? <socketpair at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation, Library (Lib)
nosy: +docs at python
type:  -> behavior
versions: +Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27150>
_______________________________________

From report at bugs.python.org  Sun May 29 04:10:27 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 29 May 2016 08:10:27 +0000
Subject: [issue27150] PEP446 (CLOEXEC by default) violation with
 fcntl.fcntl(..., fcntl.F_DUPFD)
In-Reply-To: <1464507265.78.0.794599717766.issue27150@psf.upfronthosting.co.za>
Message-ID: <1464509427.68.0.396436938394.issue27150@psf.upfronthosting.co.za>


Martin Panter added the comment:

I don?t see any violation or anything needing fixing in the documentation or code. Can you elaborate?

The fcntl() documentation says ?The values used for ?cmd? [F_DUPFD, etc] are operating system dependent, and are available as constants in the ?fcntl? module, using the same names as used in the relevant C header files.? The newest version of Posix specifies both the F_DUPFD and F_DUPFD_CLOEXEC. It would be misleading for Python to use one when the user specified the other.

If you want a best-effort version of F_DUPFD_CLOEXEC for a single-threaded program, why not use os.dup()? I presume this uses F_DUPFD_CLOEXEC where appropriate, and uses some non-atomic fallback if necessary.

----------
nosy: +haypo, martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27150>
_______________________________________

From report at bugs.python.org  Sun May 29 05:09:16 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 May 2016 09:09:16 +0000
Subject: [issue27117] turtledemo does not work with IDLE's new dark theme.
In-Reply-To: <1464145339.77.0.706051446081.issue27117@psf.upfronthosting.co.za>
Message-ID: <20160529090859.30683.36959.78C6C011@psf.io>


Roundup Robot added the comment:

New changeset 169551a8d5d1 by Martin Panter in branch 'default':
Issue #27125: Merge typo fixes from 3.5
https://hg.python.org/cpython/rev/169551a8d5d1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27117>
_______________________________________

From report at bugs.python.org  Sun May 29 05:09:16 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 May 2016 09:09:16 +0000
Subject: [issue27125] Typo in Python 2 multiprocessing documentation
In-Reply-To: <1464216185.35.0.531405853541.issue27125@psf.upfronthosting.co.za>
Message-ID: <20160529090858.30683.24668.68E2D32A@psf.io>


Roundup Robot added the comment:

New changeset c817d1b5b937 by Martin Panter in branch '2.7':
Issue #27125: Fix various errors like ?will [be] inherited?
https://hg.python.org/cpython/rev/c817d1b5b937

New changeset f7c85accbde9 by Martin Panter in branch '3.5':
Issue #27125: Fix various errors like ?will [be] inherited?
https://hg.python.org/cpython/rev/f7c85accbde9

New changeset 169551a8d5d1 by Martin Panter in branch 'default':
Issue #27125: Merge typo fixes from 3.5
https://hg.python.org/cpython/rev/169551a8d5d1

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27125>
_______________________________________

From report at bugs.python.org  Sun May 29 05:11:49 2016
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 29 May 2016 09:11:49 +0000
Subject: [issue27150] PEP446 (CLOEXEC by default) violation with
 fcntl.fcntl(..., fcntl.F_DUPFD)
In-Reply-To: <1464509427.68.0.396436938394.issue27150@psf.upfronthosting.co.za>
Message-ID: <CAMpsgwZJbB8pT68y0QC+GRb2VN1c5R6jO9CpB=A79TGrZE8DMQ@mail.gmail.com>


STINNER Victor added the comment:

I don't think that it's possible nor worth it to wrap all fcntl() and all
ioctl() calls. I see these functions as very low-level APIs and so I
consider that the caller is responsible of what he/she does.

If you want to change something, explian in fcntl module doc that the PEP
466 is not implemented in this module znd it's a deliberate choice.

I agree with Martin, it's the responsability of the dev to use the right
command depending on the use case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27150>
_______________________________________

From report at bugs.python.org  Sun May 29 05:13:14 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 29 May 2016 09:13:14 +0000
Subject: [issue27117] turtledemo does not work with IDLE's new dark theme.
In-Reply-To: <1464145339.77.0.706051446081.issue27117@psf.upfronthosting.co.za>
Message-ID: <1464513194.34.0.320010378211.issue27117@psf.upfronthosting.co.za>


Martin Panter added the comment:

It looks like your commit to the ?default? branch already included the relevant changes, so I did the merge while keeping the files the same. If I missed something, it may need an extra update. But the tests seem to be working (is there a turtledemo test?)

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27117>
_______________________________________

From report at bugs.python.org  Sun May 29 06:43:00 2016
From: report at bugs.python.org (Martin Panter)
Date: Sun, 29 May 2016 10:43:00 +0000
Subject: [issue27125] Typo in Python 2 multiprocessing documentation
In-Reply-To: <1464216185.35.0.531405853541.issue27125@psf.upfronthosting.co.za>
Message-ID: <1464518580.03.0.683807792625.issue27125@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks for the report Phoenix

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27125>
_______________________________________

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: [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 09:36:43 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Sun, 29 May 2016 13:36:43 +0000
Subject: [issue27137] functools.partial: Inconsistency between Python and C
 implementations
In-Reply-To: <1464367158.87.0.208604382314.issue27137@psf.upfronthosting.co.za>
Message-ID: <1464529003.97.0.97954852434.issue27137@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

Functionally, both versions are equivalent, but one is a class and the other is not. From PEP 399:

"Technical details of the VM providing the accelerated code are allowed to differ as necessary, e.g., a class being a `type` when implemented in C."

It clearly states that it's an implementation detail. I've been beaten! However, the next paragraph also says this:

"Acting as a drop-in replacement also dictates that no public API be provided in accelerated code that does not exist in the pure Python code."

I think this contradicts itself, since IMO an object being a type is part of the public API (but obviously this thought isn't universal). Whatever happens with the pure Python implementation, shouldn't the PEP be clarified on that point?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27137>
_______________________________________

From report at bugs.python.org  Sun May 29 10:16:05 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 May 2016 14:16:05 +0000
Subject: [issue27137] functools.partial: Inconsistency between Python and C
 implementations
In-Reply-To: <1464367158.87.0.208604382314.issue27137@psf.upfronthosting.co.za>
Message-ID: <1464531365.4.0.400357128606.issue27137@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27137>
_______________________________________

From report at bugs.python.org  Sun May 29 11:25:21 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 May 2016 15:25:21 +0000
Subject: [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 11:29:29 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 May 2016 15:29:29 +0000
Subject: [issue27152] Additional assert methods for unittest
In-Reply-To: <1464535519.92.0.0853489345335.issue27152@psf.upfronthosting.co.za>
Message-ID: <1464535769.6.0.459883390973.issue27152@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Additional statistics that proves that specified checks are not specific for narrow group of tests:

assertHasAttr       121 times in 57 files
assertNotHasAttr     99 times in 31 files
assertIsSubclass    243 times in 30 files
assertNotIsSubclass  95 times in 5 files
assertStartsWith    131 times in 59 files
assertEndsWith       73 times in 36 files

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27152>
_______________________________________

From report at bugs.python.org  Sun May 29 12:26:50 2016
From: report at bugs.python.org (SilentGhost)
Date: Sun, 29 May 2016 16:26:50 +0000
Subject: [issue27151] multiprocessing.Process leaves read pipes open
 (Process.sentinel)
In-Reply-To: <1464519594.44.0.838880586419.issue27151@psf.upfronthosting.co.za>
Message-ID: <1464539210.74.0.378399056636.issue27151@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +jnoller, sbt
versions: +Python 3.6 -Python 3.3, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27151>
_______________________________________

From report at bugs.python.org  Sun May 29 12:27:56 2016
From: report at bugs.python.org (SilentGhost)
Date: Sun, 29 May 2016 16:27:56 +0000
Subject: [issue27148] Make VENV_DIR relative to Script directory
In-Reply-To: <1464494255.1.0.144712628992.issue27148@psf.upfronthosting.co.za>
Message-ID: <1464539276.08.0.76934762044.issue27148@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
components: +Library (Lib) -Demos and Tools
nosy: +vinay.sajip
versions:  -Python 3.2, Python 3.3, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27148>
_______________________________________

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: [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:25:51 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 29 May 2016 17:25:51 +0000
Subject: [issue27117] turtledemo does not work with IDLE's new dark theme.
In-Reply-To: <1464145339.77.0.706051446081.issue27117@psf.upfronthosting.co.za>
Message-ID: <1464542751.47.0.244514216717.issue27117@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I prepared and tested two slightly different patches for 3.5 and 3.6.  I committed the 3.6 patch, then the 3.5 patch, and prepared a null merge (in default), but did not hit the commit button before pushing.  I just finished the null merge, creating two heads (in default), which I merged (after updating to Martin's head) and pushed both.  Everything looks good here after re-pulling.  One of you could recheck in your clones.
---

turtledemo.__main__ creates a framework for running any of the demo files in the package.  There is no test_turtledemo unittest.  The test is to run it, either with python -m turtledemo in the console or Help => Turtle Demo in IDLE.  Two summers ago, before adding the IDLE menu item, I loaded and ran each of the demos, patched a few, as well as .__main__, and re-ran, more than once.

For this issue, I only needed to load one demo with the IDLE Dark theme, or a custom version thereof, as the current theme.  If someone has not customized the theme selection in IDLE, the default IDLE Classic, black on white, will be used.

Testing this issue also required running IDLE and loading a file to be sure the the revised editor still worked, and loading and running the colorizer file, to run its htest (which previously had the same problem as turtledemo).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27117>
_______________________________________

From report at bugs.python.org  Sun May 29 13:33:51 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 29 May 2016 17:33:51 +0000
Subject: [issue27129] Wordcode, part 2
In-Reply-To: <1464268387.83.0.862540030058.issue27129@psf.upfronthosting.co.za>
Message-ID: <1464543231.71.0.754753167325.issue27129@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I don't see how this is a simplification.   The additional /2 and *2 on the affected lines makes the code a little harder to reason about and it loses some of the cleanness achieved by the last patch.   To me, it also increases conceptual complexity because INSTR_OFFSET() no longer gives the byte address adjustment.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27129>
_______________________________________

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: [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 13:41:26 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 May 2016 17:41:26 +0000
Subject: [issue27125] Typo in Python 2 multiprocessing documentation
In-Reply-To: <1464216185.35.0.531405853541.issue27125@psf.upfronthosting.co.za>
Message-ID: <1464543686.73.0.0235130272554.issue27125@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Lib/tkinter/tix.py:

-    and a label into one mega widget. It can beused be used to simplify
+    and a label into one mega widget. It can be used be used to simplify

Isn't "be used" duplicated?

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27125>
_______________________________________

From report at bugs.python.org  Sun May 29 14:18:39 2016
From: report at bugs.python.org (A. Jesse Jiryu Davis)
Date: Sun, 29 May 2016 18:18:39 +0000
Subject: [issue16500] Add an 'atfork' module
In-Reply-To: <1353252005.31.0.454056781872.issue16500@psf.upfronthosting.co.za>
Message-ID: <1464545919.27.0.588740795235.issue16500@psf.upfronthosting.co.za>


Changes by A. Jesse Jiryu Davis <jesse at emptysquare.net>:


----------
nosy: +emptysquare

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16500>
_______________________________________

From report at bugs.python.org  Sun May 29 14:23:14 2016
From: report at bugs.python.org (Demur Rumed)
Date: Sun, 29 May 2016 18:23:14 +0000
Subject: [issue27129] Wordcode, part 2
In-Reply-To: <1464268387.83.0.862540030058.issue27129@psf.upfronthosting.co.za>
Message-ID: <1464546194.05.0.0785405030737.issue27129@psf.upfronthosting.co.za>


Demur Rumed added the comment:

Attached is the larger potential change of replacing GET_ITER/FOR_ITER with FOR_BEGIN/FOR_ITER. I took awhile to getting this put together due to missing that CONTINUE_LOOP was jumping to the top of the loop, skipping past FOR_ITER

----------
Added file: http://bugs.python.org/file43048/forbegin.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27129>
_______________________________________

From report at bugs.python.org  Sun May 29 14:24:07 2016
From: report at bugs.python.org (Demur Rumed)
Date: Sun, 29 May 2016 18:24:07 +0000
Subject: [issue27129] Wordcode, part 2
In-Reply-To: <1464268387.83.0.862540030058.issue27129@psf.upfronthosting.co.za>
Message-ID: <1464546247.19.0.669041440266.issue27129@psf.upfronthosting.co.za>


Demur Rumed added the comment:

Oops wrong issue, sorry. Please delete?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27129>
_______________________________________

From report at bugs.python.org  Sun May 29 14:24:18 2016
From: report at bugs.python.org (Demur Rumed)
Date: Sun, 29 May 2016 18:24:18 +0000
Subject: [issue27129] Wordcode, part 2
In-Reply-To: <1464268387.83.0.862540030058.issue27129@psf.upfronthosting.co.za>
Message-ID: <1464546258.17.0.0314941568061.issue27129@psf.upfronthosting.co.za>


Changes by Demur Rumed <gunkmute at gmail.com>:


Removed file: http://bugs.python.org/file43048/forbegin.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27129>
_______________________________________

From report at bugs.python.org  Sun May 29 14:24:31 2016
From: report at bugs.python.org (Demur Rumed)
Date: Sun, 29 May 2016 18:24:31 +0000
Subject: [issue27127] Never have GET_ITER not followed by FOR_ITER
In-Reply-To: <1464227064.89.0.81963094053.issue27127@psf.upfronthosting.co.za>
Message-ID: <1464546271.23.0.369684780396.issue27127@psf.upfronthosting.co.za>


Demur Rumed added the comment:

Attached is the larger potential change of replacing GET_ITER/FOR_ITER with FOR_BEGIN/FOR_ITER. I took awhile to getting this put together due to missing that CONTINUE_LOOP was jumping to the top of the loop, skipping past FOR_ITER

----------
Added file: http://bugs.python.org/file43049/forbegin.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27127>
_______________________________________

From report at bugs.python.org  Sun May 29 14:25:41 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Sun, 29 May 2016 18:25:41 +0000
Subject: [issue27129] Wordcode, part 2
In-Reply-To: <1464268387.83.0.862540030058.issue27129@psf.upfronthosting.co.za>
Message-ID: <1464546341.89.0.0160570126117.issue27129@psf.upfronthosting.co.za>


Changes by Emanuel Barry <barry at dadadata.net>:


----------
Removed message: http://bugs.python.org/msg266608

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27129>
_______________________________________

From report at bugs.python.org  Sun May 29 14:25:53 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Sun, 29 May 2016 18:25:53 +0000
Subject: [issue27129] Wordcode, part 2
In-Reply-To: <1464268387.83.0.862540030058.issue27129@psf.upfronthosting.co.za>
Message-ID: <1464546353.85.0.858473670688.issue27129@psf.upfronthosting.co.za>


Changes by Emanuel Barry <barry at dadadata.net>:


----------
Removed message: http://bugs.python.org/msg266607

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27129>
_______________________________________

From report at bugs.python.org  Sun May 29 14:26:37 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Sun, 29 May 2016 18:26:37 +0000
Subject: [issue27150] PEP446 (CLOEXEC by default) violation with
 fcntl.fcntl(..., fcntl.F_DUPFD)
In-Reply-To: <1464507265.78.0.794599717766.issue27150@psf.upfronthosting.co.za>
Message-ID: <1464546397.76.0.0587186832778.issue27150@psf.upfronthosting.co.za>


???? ????????? added the comment:

OK, it will be consistent, if docs mention that F_DUPFD will not set O_CLOEXEC automatically, mentiont that F_DUPFD_CLOEXEC should be used for that, and also mention PEP446 somewhere.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27150>
_______________________________________

From report at bugs.python.org  Sun May 29 14:33:57 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Sun, 29 May 2016 18:33:57 +0000
Subject: [issue27154] Regression in file.writelines behavior
In-Reply-To: <1464543679.71.0.415502254928.issue27154@psf.upfronthosting.co.za>
Message-ID: <1464546837.27.0.44116717993.issue27154@psf.upfronthosting.co.za>


Changes by ???? ????????? <socketpair at gmail.com>:


----------
nosy: +mmarkk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27154>
_______________________________________

From report at bugs.python.org  Sun May 29 14:40:47 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 May 2016 18:40:47 +0000
Subject: [issue27129] Wordcode, part 2
In-Reply-To: <1464268387.83.0.862540030058.issue27129@psf.upfronthosting.co.za>
Message-ID: <1464547247.03.0.841671491121.issue27129@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

word-jump-offsets.patch doesn't simplify the code, but rather complicates it, because this is minimal patch that doesn't include the refactoring. The main benefit of this patch is that it extends the range addressed by short jump instruction. The other benefit is that the target of jump instruction is now always point at instruction boundary.

wordcode2.patch includes refactoring and other changes:

* Changes jump offsets. This extends addressed range and can make co_code more compact.
* Changes co_lnotab. This can make co_lnotab more compact.
* Changes f_lasti.
* Changes the disassembler.
* Refactors the C code (makes it codeunit-oriented instead of byte-oriented). Simplifies the code complicated by other changes.

I can provide these steps by separate patches (word-jump-offsets.patch is the first of them), but every separate patch can temporary complicate the code. Three of these changes (except the disassembler changing and refactoring) break the compatibility of pyc-files and need incrementing the magic number.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27129>
_______________________________________

From report at bugs.python.org  Sun May 29 14:48:29 2016
From: report at bugs.python.org (Oren Milman)
Date: Sun, 29 May 2016 18:48:29 +0000
Subject: [issue27073] redundant checks in long_add and long_sub
In-Reply-To: <1463816500.87.0.013124059613.issue27073@psf.upfronthosting.co.za>
Message-ID: <1464547709.37.0.45192072923.issue27073@psf.upfronthosting.co.za>


Oren Milman added the comment:

I agree. This assert only indirectly verifies that something bad doesn't happen. 

The bad thing that might happen is an in-place negating of an element of small_ints, so the most direct assert should be 'assert(Py_REFCNT(z) == 1);'.
This is exactly what Victor did in long_lshift back in revision 84698...

What do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27073>
_______________________________________

From report at bugs.python.org  Sun May 29 15:01:05 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Sun, 29 May 2016 19:01:05 +0000
Subject: [issue27149] Implement socket.sendmsg() for Windows
In-Reply-To: <1464501034.91.0.597053336572.issue27149@psf.upfronthosting.co.za>
Message-ID: <1464548465.35.0.194003410618.issue27149@psf.upfronthosting.co.za>


???? ????????? added the comment:

https://github.com/pauldotknopf/WindowsSDK7-Samples/blob/master/netds/winsock/sendmsg/SendMsg.cpp

Seems, supported since Vista

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27149>
_______________________________________

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: [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 15:17:41 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 May 2016 19:17:41 +0000
Subject: [issue27127] Never have GET_ITER not followed by FOR_ITER
In-Reply-To: <1464227064.89.0.81963094053.issue27127@psf.upfronthosting.co.za>
Message-ID: <1464549461.09.0.914018079235.issue27127@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Interesting.

How it works with continue?

    for x in a:
        if x: continue
        f()

In this case we can use new FOR_ITER instead of JUMP_ABSOLUTE. I would rename FOR_ITER to something more appropriate (maybe containing NEXT or CONTINUE).

How it works with continue in the try block?

    for x in a:
        try:
            if x: continue
            f()
        except Error:
            e()

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27127>
_______________________________________

From report at bugs.python.org  Sun May 29 15:23:17 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Sun, 29 May 2016 19:23:17 +0000
Subject: [issue27155] '-' sign typo in example
In-Reply-To: <1464549329.65.0.961898669229.issue27155@psf.upfronthosting.co.za>
Message-ID: <1464549797.99.0.790982908427.issue27155@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

A negative return code generally means an error occurred. Negating retcode here is equivalent to abs(retcode), which shows you want a positive integer to appear in the message - it's not an error.

Could replace '-retcode' with 'abs(retcode)' to be more clear. Possibly also add a comment in the code example body to further clarify this.

----------
nosy: +ebarry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27155>
_______________________________________

From report at bugs.python.org  Sun May 29 15:31:37 2016
From: report at bugs.python.org (Demur Rumed)
Date: Sun, 29 May 2016 19:31:37 +0000
Subject: [issue27127] Never have GET_ITER not followed by FOR_ITER
In-Reply-To: <1464227064.89.0.81963094053.issue27127@psf.upfronthosting.co.za>
Message-ID: <1464550297.83.0.671906196351.issue27127@psf.upfronthosting.co.za>


Demur Rumed added the comment:

Currently it'll work since in an except it'll generate a CONTINUE_LOOP that'll jump to the end of the loop & either jump back to the start or to the end

Your example is incorrect. If the continue's JUMP_ABS were a FOR_ITER then if we were on the last iteration of the loop we would end up executing the loop body with an invalid stack. So you'd have to follow the FOR_ITER with a JUMP_ABS past the loop. Not sure if there's a speed advantage worth complexity/larger wordcode

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27127>
_______________________________________

From report at bugs.python.org  Sun May 29 15:37:33 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 May 2016 19:37:33 +0000
Subject: [issue27127] Never have GET_ITER not followed by FOR_ITER
In-Reply-To: <1464227064.89.0.81963094053.issue27127@psf.upfronthosting.co.za>
Message-ID: <1464550653.75.0.579407423968.issue27127@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Ah, sorry. You are right.

Do you have any microbenchmarks that shows the benefit?

----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27127>
_______________________________________

From report at bugs.python.org  Sun May 29 15:48:40 2016
From: report at bugs.python.org (R. David Murray)
Date: Sun, 29 May 2016 19:48:40 +0000
Subject: [issue27149] Implement socket.sendmsg() for Windows
In-Reply-To: <1464501034.91.0.597053336572.issue27149@psf.upfronthosting.co.za>
Message-ID: <1464551320.46.0.358536143808.issue27149@psf.upfronthosting.co.za>


R. David Murray added the comment:

Would you like to propose a patch?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27149>
_______________________________________

From report at bugs.python.org  Sun May 29 15:51:49 2016
From: report at bugs.python.org (R. David Murray)
Date: Sun, 29 May 2016 19:51:49 +0000
Subject: [issue27152] Additional assert methods for unittest
In-Reply-To: <1464535519.92.0.0853489345335.issue27152@psf.upfronthosting.co.za>
Message-ID: <1464551509.82.0.762351663623.issue27152@psf.upfronthosting.co.za>


R. David Murray added the comment:

Why a mixin?

(As an aside, there is a proposal to move all assert methods to a place where they can be accessed outside test cases.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27152>
_______________________________________

From report at bugs.python.org  Sun May 29 15:55:36 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Sun, 29 May 2016 19:55:36 +0000
Subject: [issue27149] Implement socket.sendmsg() for Windows
In-Reply-To: <1464501034.91.0.597053336572.issue27149@psf.upfronthosting.co.za>
Message-ID: <1464551736.28.0.363525074741.issue27149@psf.upfronthosting.co.za>


???? ????????? added the comment:

No, I hate Windows, Winapi and so on.

But I have problems in patching asyncio https://github.com/python/asyncio/pull/339

Since greate optimisation may be acheived using sendmsg()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27149>
_______________________________________

From report at bugs.python.org  Sun May 29 15:59:10 2016
From: report at bugs.python.org (Demur Rumed)
Date: Sun, 29 May 2016 19:59:10 +0000
Subject: [issue27127] Never have GET_ITER not followed by FOR_ITER
In-Reply-To: <1464227064.89.0.81963094053.issue27127@psf.upfronthosting.co.za>
Message-ID: <1464551950.06.0.963258142025.issue27127@psf.upfronthosting.co.za>


Demur Rumed added the comment:

Pretty small perf increase:

timeit("for a in range(256):pass", number=100000)
Without patch: ~2.1
With patch: ~1.84

pybench is 1-2% faster. Would prefer others' results. Especially a benchmark where it doesn't wrap payloads in for loops

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27127>
_______________________________________

From report at bugs.python.org  Sun May 29 16:01:47 2016
From: report at bugs.python.org (R. David Murray)
Date: Sun, 29 May 2016 20:01:47 +0000
Subject: [issue27153] Default value shown by
 argparse.ArgumentDefaultsHelpFormatter is backwards for action='store_false'
In-Reply-To: <1464539974.48.0.860363682331.issue27153@psf.upfronthosting.co.za>
Message-ID: <1464552107.28.0.579538272592.issue27153@psf.upfronthosting.co.za>


R. David Murray added the comment:

The message is correct.  The default value of foo is True.  It would be just as misleading to say default: False, since that would imply the default value of foo was false.  It also makes no sense to think it would mean the default value of 'no-foo' is False.

Instead, if you want to use ArgumentDefaultsHelpFormatter instead of controlling when defaults are displayed, change your help string to read something like: "Set foo to False".

----------
nosy: +r.david.murray
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27153>
_______________________________________

From report at bugs.python.org  Sun May 29 16:03:12 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Sun, 29 May 2016 20:03:12 +0000
Subject: [issue27151] multiprocessing.Process leaves read pipes open
 (Process.sentinel)
In-Reply-To: <1464519594.44.0.838880586419.issue27151@psf.upfronthosting.co.za>
Message-ID: <1464552192.87.0.899113613284.issue27151@psf.upfronthosting.co.za>


Changes by ???? ????????? <socketpair at gmail.com>:


----------
nosy: +mmarkk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27151>
_______________________________________

From report at bugs.python.org  Sun May 29 16:03:32 2016
From: report at bugs.python.org (Demur Rumed)
Date: Sun, 29 May 2016 20:03:32 +0000
Subject: [issue27127] Never have GET_ITER not followed by FOR_ITER
In-Reply-To: <1464227064.89.0.81963094053.issue27127@psf.upfronthosting.co.za>
Message-ID: <1464552212.35.0.748055745897.issue27127@psf.upfronthosting.co.za>


Demur Rumed added the comment:

Microbenchmark of continue regression: timeit("for a in range(256):\n\tif a:continue",number=100000)
Without patch: ~3.57
With patch: ~3.64

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27127>
_______________________________________

From report at bugs.python.org  Sun May 29 16:04:11 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 May 2016 20:04:11 +0000
Subject: [issue27033] Change the decode_data default in smtpd to False
In-Reply-To: <1463340039.51.0.670985844702.issue27033@psf.upfronthosting.co.za>
Message-ID: <1464552251.62.0.893280156779.issue27033@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Thank you for your review David. Updated patch addresses your doc comments.

As for bool calls, I think there are reasons to do this.

----------
Added file: http://bugs.python.org/file43050/smtpd_decode_data_false_doc2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27033>
_______________________________________

From report at bugs.python.org  Sun May 29 16:12:13 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 May 2016 20:12:13 +0000
Subject: [issue27033] Change the decode_data default in smtpd to False
In-Reply-To: <1463340039.51.0.670985844702.issue27033@psf.upfronthosting.co.za>
Message-ID: <1464552733.02.0.844839396195.issue27033@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Addressed other David's comment.

----------
Added file: http://bugs.python.org/file43051/smtpd_decode_data_false_doc3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27033>
_______________________________________

From report at bugs.python.org  Sun May 29 16:20:28 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 May 2016 20:20:28 +0000
Subject: [issue27152] Additional assert methods for unittest
In-Reply-To: <1464535519.92.0.0853489345335.issue27152@psf.upfronthosting.co.za>
Message-ID: <1464553228.73.0.447572648906.issue27152@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I have this proposal (issue19645) in mind. We can add these method just in TestCase.

In any case I'm going to add the ExtraAssertions mixin in test.support in maintained versions to help keeping branches in sync.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27152>
_______________________________________

From report at bugs.python.org  Sun May 29 16:21:36 2016
From: report at bugs.python.org (R. David Murray)
Date: Sun, 29 May 2016 20:21:36 +0000
Subject: [issue27154] Regression in file.writelines behavior
In-Reply-To: <1464543679.71.0.415502254928.issue27154@psf.upfronthosting.co.za>
Message-ID: <1464553296.68.0.0893821033161.issue27154@psf.upfronthosting.co.za>


R. David Murray added the comment:

Any chance you could bisect to figure out which changeset caused the problem?  I'm surprised that something like this would happen, we aren't in general making changes at that level to python2 any more.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27154>
_______________________________________

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: [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 16:28:46 2016
From: report at bugs.python.org (Alexey Borzenkov)
Date: Sun, 29 May 2016 20:28:46 +0000
Subject: [issue27154] Regression in file.writelines behavior
In-Reply-To: <1464543679.71.0.415502254928.issue27154@psf.upfronthosting.co.za>
Message-ID: <1464553726.28.0.767760708112.issue27154@psf.upfronthosting.co.za>


Alexey Borzenkov added the comment:

Didn't need to bisect, it's very easy to find the problematic commit, since writelines doesn't change that often:

https://hg.python.org/releases/2.7.11/rev/db842f730432

The old code was buggy in a sense that it always called PyObject_AsCharBuffer due to the way the condition is structured, but this bugginess was what allowed it to work correctly with unicode objects. After the commit unicode objects are treated like any other buffer, and that's why internal UCS2 or UCS4 representation gets written to the file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27154>
_______________________________________

From report at bugs.python.org  Sun May 29 16:29:22 2016
From: report at bugs.python.org (Demur Rumed)
Date: Sun, 29 May 2016 20:29:22 +0000
Subject: [issue27127] Never have GET_ITER not followed by FOR_ITER
In-Reply-To: <1464227064.89.0.81963094053.issue27127@psf.upfronthosting.co.za>
Message-ID: <1464553762.04.0.843411296176.issue27127@psf.upfronthosting.co.za>


Demur Rumed added the comment:

Summer heat is getting to me. Please ignore this issue until I've uploaded a fixed patch

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27127>
_______________________________________

From report at bugs.python.org  Sun May 29 16:29:48 2016
From: report at bugs.python.org (R. David Murray)
Date: Sun, 29 May 2016 20:29:48 +0000
Subject: [issue27155] '-' sign typo in example
In-Reply-To: <1464549329.65.0.961898669229.issue27155@psf.upfronthosting.co.za>
Message-ID: <1464553788.41.0.708846829559.issue27155@psf.upfronthosting.co.za>


R. David Murray added the comment:

The negative return code indicates the child was terminated by a signal, exactly as the example error message says.  The signal number is the positive value of the return code.  It makes more sense to negate it than it does to call abs, since we *know* it is negative.

IMO the example is correct as written.

----------
nosy: +r.david.murray
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27155>
_______________________________________

From report at bugs.python.org  Sun May 29 16:33:05 2016
From: report at bugs.python.org (R. David Murray)
Date: Sun, 29 May 2016 20:33:05 +0000
Subject: [issue27033] Change the decode_data default in smtpd to False
In-Reply-To: <1463340039.51.0.670985844702.issue27033@psf.upfronthosting.co.za>
Message-ID: <1464553985.8.0.524552835677.issue27033@psf.upfronthosting.co.za>


R. David Murray added the comment:

What reasons?  It's not a big deal, but like I say it isn't our normal style.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27033>
_______________________________________

From report at bugs.python.org  Sun May 29 16:33:49 2016
From: report at bugs.python.org (R. David Murray)
Date: Sun, 29 May 2016 20:33:49 +0000
Subject: [issue27033] Change the decode_data default in smtpd to False
In-Reply-To: <1463340039.51.0.670985844702.issue27033@psf.upfronthosting.co.za>
Message-ID: <1464554029.24.0.471513856934.issue27033@psf.upfronthosting.co.za>


R. David Murray added the comment:

Oh, I forgot to say that the revisions look good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27033>
_______________________________________

From report at bugs.python.org  Sun May 29 16:39:44 2016
From: report at bugs.python.org (R. David Murray)
Date: Sun, 29 May 2016 20:39:44 +0000
Subject: [issue21350] bug in file.writelines accepting buffers
In-Reply-To: <1398444021.42.0.983935463224.issue21350@psf.upfronthosting.co.za>
Message-ID: <1464554384.3.0.785267316541.issue21350@psf.upfronthosting.co.za>


R. David Murray added the comment:

Unfortunately this caused a regression in unicode handling.  See issue 27154.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue21350>
_______________________________________

From report at bugs.python.org  Sun May 29 16:40:11 2016
From: report at bugs.python.org (R. David Murray)
Date: Sun, 29 May 2016 20:40:11 +0000
Subject: [issue27154] Regression in file.writelines behavior
In-Reply-To: <1464543679.71.0.415502254928.issue27154@psf.upfronthosting.co.za>
Message-ID: <1464554411.13.0.167675470117.issue27154@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thanks.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27154>
_______________________________________

From report at bugs.python.org  Sun May 29 16:41:11 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 May 2016 20:41:11 +0000
Subject: [issue27033] Change the decode_data default in smtpd to False
In-Reply-To: <1463340039.51.0.670985844702.issue27033@psf.upfronthosting.co.za>
Message-ID: <1464554471.28.0.244739213167.issue27033@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Since these arguments are saved for multiple testing, it is worth to ensure that every test returns consistent result. For public attribute there is additional benefit, it looks as boolean.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27033>
_______________________________________

From report at bugs.python.org  Sun May 29 16:44:03 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 May 2016 20:44:03 +0000
Subject: [issue27033] Change the decode_data default in smtpd to False
In-Reply-To: <1463340039.51.0.670985844702.issue27033@psf.upfronthosting.co.za>
Message-ID: <20160529204359.6206.83300.67CB26ED@psf.io>


Roundup Robot added the comment:

New changeset 9abde519cc1e by Serhiy Storchaka in branch 'default':
Improved docs for issue27033. Based on comments by R. David Murray.
https://hg.python.org/cpython/rev/9abde519cc1e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27033>
_______________________________________

From report at bugs.python.org  Sun May 29 16:45:48 2016
From: report at bugs.python.org (R. David Murray)
Date: Sun, 29 May 2016 20:45:48 +0000
Subject: [issue27033] Change the decode_data default in smtpd to False
In-Reply-To: <1463340039.51.0.670985844702.issue27033@psf.upfronthosting.co.za>
Message-ID: <1464554748.03.0.0286019093444.issue27033@psf.upfronthosting.co.za>


R. David Murray added the comment:

Python uses duck typing, though.  Maybe someone is depending on those public attributes not getting coerced to boolean.  Probably not, granted, since they are newish, but a python programmer might expect the value to get passed through.  I'm of two minds about the advisability of that, but given that someone *could* be depending on it, I think it would be better to not do the bool call, since there is no bug fixed by doing the bool call, making it an unnecessary change in behavior.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27033>
_______________________________________

From report at bugs.python.org  Sun May 29 16:52:00 2016
From: report at bugs.python.org (Roundup Robot)
Date: Sun, 29 May 2016 20:52:00 +0000
Subject: [issue27033] Change the decode_data default in smtpd to False
In-Reply-To: <1463340039.51.0.670985844702.issue27033@psf.upfronthosting.co.za>
Message-ID: <20160529205156.10660.71914.38D151C9@psf.io>


Roundup Robot added the comment:

New changeset 71813a05e488 by Serhiy Storchaka in branch 'default':
Issue #27033: Removed unnecessary the bool calls.
https://hg.python.org/cpython/rev/71813a05e488

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27033>
_______________________________________

From report at bugs.python.org  Sun May 29 17:02:52 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 29 May 2016 21:02:52 +0000
Subject: [issue27154] Regression in file.writelines behavior
In-Reply-To: <1464543679.71.0.415502254928.issue27154@psf.upfronthosting.co.za>
Message-ID: <1464555772.2.0.236046269756.issue27154@psf.upfronthosting.co.za>


Changes by Serhiy Storchaka <storchaka+cpython at gmail.com>:


----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27154>
_______________________________________

From report at bugs.python.org  Sun May 29 18:08:25 2016
From: report at bugs.python.org (R. David Murray)
Date: Sun, 29 May 2016 22:08:25 +0000
Subject: [issue5252] 2to3 should detect and delete import of removed statvfs
 module
In-Reply-To: <1234549626.49.0.319241033357.issue5252@psf.upfronthosting.co.za>
Message-ID: <1464559705.52.0.840382595121.issue5252@psf.upfronthosting.co.za>


R. David Murray added the comment:

Closing based on Benjamin's comments.

----------
nosy: +r.david.murray
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5252>
_______________________________________

From report at bugs.python.org  Sun May 29 18:17:22 2016
From: report at bugs.python.org (R. David Murray)
Date: Sun, 29 May 2016 22:17:22 +0000
Subject: [issue10908] Improvements to trace._Ignore
In-Reply-To: <1295020376.03.0.967767300509.issue10908@psf.upfronthosting.co.za>
Message-ID: <1464560242.61.0.773074805521.issue10908@psf.upfronthosting.co.za>


R. David Murray added the comment:

SilentGhost: I don't see any discussion leading to closure here.  Did you just give up on getting a review, or was the rejection discussed somewhere else?  Since you have 10896 marked as being superceded by this, I'd like to know what you think we should do to resolve that issue, if you are still interested.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10908>
_______________________________________

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: [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: [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  Sun May 29 18:52:49 2016
From: report at bugs.python.org (ppperry)
Date: Sun, 29 May 2016 22:52:49 +0000
Subject: [issue27158] `isnstance` builtin does not handle types that are their
 own type
In-Reply-To: <1464562361.71.0.727466697005.issue27158@psf.upfronthosting.co.za>
Message-ID: <1464562369.94.0.325027640353.issue27158@psf.upfronthosting.co.za>


Changes by ppperry <mapreader at olum.org>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27158>
_______________________________________

From report at bugs.python.org  Sun May 29 18:53:01 2016
From: report at bugs.python.org (ppperry)
Date: Sun, 29 May 2016 22:53:01 +0000
Subject: [issue27158] `isnstance` function does not handle types that are
 their own type
In-Reply-To: <1464562361.71.0.727466697005.issue27158@psf.upfronthosting.co.za>
Message-ID: <1464562381.06.0.820867619555.issue27158@psf.upfronthosting.co.za>


Changes by ppperry <mapreader at olum.org>:


----------
title: `isnstance` builtin does not handle types that are their own type -> `isnstance` function does not handle types that are their own type

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27158>
_______________________________________

From report at bugs.python.org  Sun May 29 18:53:11 2016
From: report at bugs.python.org (ppperry)
Date: Sun, 29 May 2016 22:53:11 +0000
Subject: [issue27158] `isinstance` function does not handle types that are
 their own type
In-Reply-To: <1464562361.71.0.727466697005.issue27158@psf.upfronthosting.co.za>
Message-ID: <1464562391.04.0.679026722569.issue27158@psf.upfronthosting.co.za>


Changes by ppperry <mapreader at olum.org>:


----------
title: `isnstance` function does not handle types that are their own type -> `isinstance` function does not handle types that are their own type

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27158>
_______________________________________

From report at bugs.python.org  Sun May 29 18:55:05 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Sun, 29 May 2016 22:55:05 +0000
Subject: [issue27157] Unhelpful error message when one calls a subclass of type
In-Reply-To: <1464561968.54.0.551105312321.issue27157@psf.upfronthosting.co.za>
Message-ID: <1464562505.33.0.128066678236.issue27157@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

Works for me:

>>> class X(type): pass
...
>>> X(X)
<class 'type'>

----------
nosy: +ebarry
resolution:  -> works for me
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27157>
_______________________________________

From report at bugs.python.org  Sun May 29 18:56:03 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Sun, 29 May 2016 22:56:03 +0000
Subject: [issue27158] `isinstance` function does not handle types that are
 their own type
In-Reply-To: <1464562361.71.0.727466697005.issue27158@psf.upfronthosting.co.za>
Message-ID: <1464562563.91.0.55885438908.issue27158@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

Works for me:

>>> class meta(type): pass
...
>>> class X(type, metaclass=meta): pass
...
>>> X.__class__ = X
>>> type(X) is X
True
>>> isinstance(X, X)
True

----------
nosy: +ebarry
resolution:  -> works for me
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27158>
_______________________________________

From report at bugs.python.org  Sun May 29 19:04:16 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Sun, 29 May 2016 23:04:16 +0000
Subject: [issue27158] `isinstance` function does not handle types that are
 their own type
In-Reply-To: <1464562361.71.0.727466697005.issue27158@psf.upfronthosting.co.za>
Message-ID: <1464563056.18.0.222357405691.issue27158@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

This seems as though you might be using an older version of the interpreter (I tested in 3.4.3, 3.5.1 and 3.6.0a1+). Where did you get your interpreter? The official releases are on https://www.python.org/downloads/ - if you got it somewhere else, that might be something for whoever packaged your installer to fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27158>
_______________________________________

From report at bugs.python.org  Sun May 29 19:14:16 2016
From: report at bugs.python.org (ppperry)
Date: Sun, 29 May 2016 23:14:16 +0000
Subject: [issue27158] `isinstance` function does not handle types that are
 their own type
In-Reply-To: <1464562361.71.0.727466697005.issue27158@psf.upfronthosting.co.za>
Message-ID: <1464563656.4.0.251247878801.issue27158@psf.upfronthosting.co.za>


ppperry added the comment:

Never mind this issue, I was confused when reporting.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27158>
_______________________________________

From report at bugs.python.org  Sun May 29 19:23:40 2016
From: report at bugs.python.org (ppperry)
Date: Sun, 29 May 2016 23:23:40 +0000
Subject: [issue27157] Unhelpful error message when one calls a subclass of
 type with a custom metaclass
In-Reply-To: <1464561968.54.0.551105312321.issue27157@psf.upfronthosting.co.za>
Message-ID: <1464564220.21.0.321580163929.issue27157@psf.upfronthosting.co.za>


ppperry added the comment:

This issue only happens when the type in question has a custom metaclass:

>>> class meta(type):pass
>>> class X(type,metaclass=meta):pass
>>> X(X)
[Same unhelpful TypeError]

----------
resolution: works for me -> 
status: closed -> open
title: Unhelpful error message when one calls a subclass of type -> Unhelpful error message when one calls a subclass of type with a custom metaclass

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27157>
_______________________________________

From report at bugs.python.org  Sun May 29 19:26:03 2016
From: report at bugs.python.org (ppperry)
Date: Sun, 29 May 2016 23:26:03 +0000
Subject: [issue27157] Unhelpful error message when one calls a subclass of
 type with a custom metaclass
In-Reply-To: <1464561968.54.0.551105312321.issue27157@psf.upfronthosting.co.za>
Message-ID: <1464564363.51.0.00629391776848.issue27157@psf.upfronthosting.co.za>


ppperry added the comment:

Also happens on 2.7, although you have to declare the metaclass using  `__metaclass__ = meta` instead.

----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27157>
_______________________________________

From report at bugs.python.org  Sun May 29 20:12:08 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Mon, 30 May 2016 00:12:08 +0000
Subject: [issue27157] Unhelpful error message when one calls a subclass of
 type with a custom metaclass
In-Reply-To: <1464561968.54.0.551105312321.issue27157@psf.upfronthosting.co.za>
Message-ID: <1464567128.92.0.837750760047.issue27157@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

In Objects/typeobject.c#L2290, the code checks that the (meta?)class is exactly `type` and that there's one argument, then returns `Py_TYPE(x)`. Subclasses of `type` allowing a single argument is a side-effect of not overriding __new__, not a documented feature.

Changing the call from `PyType_CheckExact` to `PyType_Check` makes it work, but I'm assuming there may be something I didn't think of. Or maybe there isn't, but either way, I don't consider that this is worth fixing -- if you want to call your subclass with only one argument, override __new__ and do the logic in there. And if you want the type of an object, use type directly.

Also, there may be performance concerns here. `type` is heavily optimized in many places; I thought that `PyType_Check` called Python code, but after checking the macro definitions and testing a bit, it turns out I'm wrong. But if there *is* a negative performance impact, this probably can't go in -- this check runs everytime that type() is called, no matter how many arguments, and including in class creation; that's also probably why `PyType_CheckExact` was chosen to begin with.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27157>
_______________________________________

From report at bugs.python.org  Sun May 29 20:25:40 2016
From: report at bugs.python.org (ppperry)
Date: Mon, 30 May 2016 00:25:40 +0000
Subject: [issue27157] Unhelpful error message when one calls an instance of a
 subclass of type
In-Reply-To: <1464561968.54.0.551105312321.issue27157@psf.upfronthosting.co.za>
Message-ID: <1464567939.97.0.550274872446.issue27157@psf.upfronthosting.co.za>


ppperry added the comment:

Further testing reveals that this issue has nothing to do with metaclasses:

>>>class X(type):pass
>>>X()(X)

raises the same TypeError.
Even if the possibly dubious feature of being able to call instances of subclasses of type with one argument is rejected, the error message should definitely be improved. It is ridiculously unhelpful.

----------
title: Unhelpful error message when one calls a subclass of type with a custom metaclass -> Unhelpful error message when one calls an instance of a subclass of type

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27157>
_______________________________________

From report at bugs.python.org  Sun May 29 20:27:53 2016
From: report at bugs.python.org (ppperry)
Date: Mon, 30 May 2016 00:27:53 +0000
Subject: [issue27157] Unhelpful error message when one calls a subclass of
 type with a custom metaclass
In-Reply-To: <1464561968.54.0.551105312321.issue27157@psf.upfronthosting.co.za>
Message-ID: <1464568073.59.0.803978829964.issue27157@psf.upfronthosting.co.za>


ppperry added the comment:

Ignore the first part of my previous comment; I improperly tested that.

----------
title: Unhelpful error message when one calls an instance of a subclass of type -> Unhelpful error message when one calls a subclass of type with a custom metaclass

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27157>
_______________________________________

From report at bugs.python.org  Sun May 29 20:32:10 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 30 May 2016 00:32:10 +0000
Subject: =?utf-8?q?=5Bissue27043=5D_Describe_what_=E2=80=98inspect=2Ecleandoc?=
 =?utf-8?q?=E2=80=99_does_to_synopsis_line=2E?=
In-Reply-To: <1463445757.83.0.886794484792.issue27043@psf.upfronthosting.co.za>
Message-ID: <1464568330.98.0.170129574789.issue27043@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27043>
_______________________________________

From report at bugs.python.org  Sun May 29 20:39:08 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Mon, 30 May 2016 00:39:08 +0000
Subject: [issue27157] Unhelpful error message when one calls a subclass of
 type with a custom metaclass
In-Reply-To: <1464561968.54.0.551105312321.issue27157@psf.upfronthosting.co.za>
Message-ID: <1464568748.58.0.282100506486.issue27157@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

Yes, that would be preferable. The error message is at Objects/typeobject.c#l2301, but keep in mind that this message is shown for both faulty calls to type() as well as any of its subclasses that don't override __new__, and I'm lukewarm on adding e.g. a PyType_Check call before that; might as well replace the PyType_CheckExact call and make this work. I'm not knowledgeable enough in that field though, you'll need a core dev's advice.

----------
stage: resolved -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27157>
_______________________________________

From report at bugs.python.org  Sun May 29 20:58:52 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 30 May 2016 00:58:52 +0000
Subject: [issue18478] Class bodies: when does a name become local?
In-Reply-To: <1374017954.45.0.193690883208.issue18478@psf.upfronthosting.co.za>
Message-ID: <1464569932.41.0.511536538573.issue18478@psf.upfronthosting.co.za>


R. David Murray added the comment:

As far as I can see this has been fixed by explaining the special rules for class definitions at the end of the section.  Do you think there is anything left to do here, Terry?  Perhaps a 2.7 backport of some of the clarifications?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18478>
_______________________________________

From report at bugs.python.org  Sun May 29 21:07:55 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 30 May 2016 01:07:55 +0000
Subject: [issue24647] Document argparse.REMAINDER as being equal to "..."
In-Reply-To: <1437079645.1.0.921184801927.issue24647@psf.upfronthosting.co.za>
Message-ID: <1464570475.44.0.231341603054.issue24647@psf.upfronthosting.co.za>


R. David Murray added the comment:

I would say nargs='...' is borderline...it's meaning is *fairly* intuitive, but unlike the other three it does not, as paul.j3 points out, have a regex (or shell) counterpart.

I think we should respect the original author's decision in this case and leave well enough alone.

----------
nosy: +r.david.murray
resolution:  -> rejected
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24647>
_______________________________________

From report at bugs.python.org  Sun May 29 21:13:31 2016
From: report at bugs.python.org (Demur Rumed)
Date: Mon, 30 May 2016 01:13:31 +0000
Subject: [issue27127] Never have GET_ITER not followed by FOR_ITER
In-Reply-To: <1464227064.89.0.81963094053.issue27127@psf.upfronthosting.co.za>
Message-ID: <1464570811.85.0.520237440076.issue27127@psf.upfronthosting.co.za>


Demur Rumed added the comment:

Two issues:

One: `a = (i for i in 6)` does not throw until calling next(a). This applies to the first patch. If it's unacceptable to defer the throw then this whole issue should be closed unless there's interest in having a GET_ITER, FOR_ITER, FOR_BEGIN, FOR_NEXT set of opcodes between comprehensions & for loops. That seems excessive

Two: tracing is getting a bit confused by FOR_ITER being at the end of the loop body. The clearest example is that in test_pdb's test_pdb_until_command_generator it needs 3 steps instead of 2 to trace `print(i)` after the 'until 4' because whereas currently it traces the `for i in test_gen()` before calling into the iterator, it now calls into the iterator first & traces `for i in test_gen()` only after returning. Additionally it doesn't trace `for i in test_gen()` at the end of iteration, instead tracing the last line

It seems fragile to try fix this up by having the FOR_ITER tail receive a negative lnotab line offset to place it on the same line as the loop heading. My own research of the code base has been trying to determine if I can manually emit a trace in the FOR_ITER opcode, but I'd rather not muck with the frame to carry out this fa?ade

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27127>
_______________________________________

From report at bugs.python.org  Sun May 29 21:20:13 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 30 May 2016 01:20:13 +0000
Subject: [issue26589] Add HTTP Response code 451
In-Reply-To: <1458339796.0.0.55641326492.issue26589@psf.upfronthosting.co.za>
Message-ID: <1464571213.88.0.303494430733.issue26589@psf.upfronthosting.co.za>


R. David Murray added the comment:

Looks good to me.

----------
nosy: +r.david.murray
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26589>
_______________________________________

From report at bugs.python.org  Sun May 29 21:24:58 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 30 May 2016 01:24:58 +0000
Subject: [issue18478] Class bodies: when does a name become local?
In-Reply-To: <1374017954.45.0.193690883208.issue18478@psf.upfronthosting.co.za>
Message-ID: <1464571498.01.0.681143201138.issue18478@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The new language *and* organization introduced sometime during 3.4 is good enough for me. " with an exception that unbound local variables are looked up in the global namespace." covers my example. Thanks for the pointer.

----------
resolution:  -> out of date
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18478>
_______________________________________

From report at bugs.python.org  Sun May 29 21:29:05 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 30 May 2016 01:29:05 +0000
Subject: [issue27157] Unhelpful error message when one calls a subclass of
 type with a custom metaclass
In-Reply-To: <1464561968.54.0.551105312321.issue27157@psf.upfronthosting.co.za>
Message-ID: <1464571745.31.0.103909415307.issue27157@psf.upfronthosting.co.za>


Steven D'Aprano added the comment:

I am unable to replicate this in Python 2.7, 3.3 or 3.6. I haven't bothered to test against other versions, because I think that this is a PyShell issue, not a Python issue. (I think you are using PyShell, based on the traceback given.)

Before reporting bugs in the interpreter, please test using the vanilla Python interactive interpreter, and not in an enhanced shell or IDE (iPython, PyShell, Spyder, etc).

I'm closing the task, please don't re-open unless you can demonstrate the issue in the plain Python interpreter. But please do report it to the PyShell maintainers.

----------
nosy: +steven.daprano
resolution:  -> works for me
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27157>
_______________________________________

From report at bugs.python.org  Sun May 29 21:43:12 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 30 May 2016 01:43:12 +0000
Subject: [issue26667] Update importlib to accept pathlib.Path objects
In-Reply-To: <1459275774.9.0.416740988554.issue26667@psf.upfronthosting.co.za>
Message-ID: <1464572592.94.0.445714778993.issue26667@psf.upfronthosting.co.za>


R. David Murray added the comment:

Brett, is this made obsolete by PEP 519, or is its implementation informed by that PEP?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26667>
_______________________________________

From report at bugs.python.org  Sun May 29 21:43:22 2016
From: report at bugs.python.org (ppperry)
Date: Mon, 30 May 2016 01:43:22 +0000
Subject: [issue27157] Unhelpful error message when one calls a subclass of
 type with a custom metaclass
In-Reply-To: <1464561968.54.0.551105312321.issue27157@psf.upfronthosting.co.za>
Message-ID: <1464572602.56.0.110527124718.issue27157@psf.upfronthosting.co.za>


ppperry added the comment:

steven.daprano, you don't appear to have properly read the issue comments. I originally underspecified the conditions necessary to reproduce this, producing Emanuel Barry's closure. I then added a proper reproducer in the third comment, which does work in the vanilla python interpreter.

----------
resolution: works for me -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27157>
_______________________________________

From report at bugs.python.org  Sun May 29 21:51:02 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 30 May 2016 01:51:02 +0000
Subject: [issue27157] Unhelpful error message when one calls a subclass of
 type with a custom metaclass
In-Reply-To: <1464561968.54.0.551105312321.issue27157@psf.upfronthosting.co.za>
Message-ID: <1464573062.66.0.0873791865571.issue27157@psf.upfronthosting.co.za>


R. David Murray added the comment:

When I hit this recently I assumed that that error message meant I'd screwed up the metaclass definition.  But if there's a way to improve the error message that would be great.

I'll add this to the list of bugs I'm making for the sprints, perhaps one of the sprinters can convince a knowlegable core dev to look at it and render an opinion :)

----------
nosy: +r.david.murray
stage: resolved -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27157>
_______________________________________

From report at bugs.python.org  Sun May 29 22:22:02 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 30 May 2016 02:22:02 +0000
Subject: [issue27113] sqlite3 connect parameter "check_same_thread" not
 documented
In-Reply-To: <1464125789.84.0.570004715823.issue27113@psf.upfronthosting.co.za>
Message-ID: <1464574922.77.0.157239039824.issue27113@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Thank you for the patch, Dave.

Following the language style of rest of the docs, check_same_thread, should be explained in a passive voice.

Also, mentioning the version requirement at this place, does not seem suitable to me. When we provide this feature, it assumed that the underlying sqlite linked has the support for it.

Also, (3.3.1 alpha) of sqlite was released in 2006-01-16 
Database connections can now be used by multiple threads, not just the thread in which they were created.

Here is a modified patch which captures the main idea from your patch. Please review this and share your suggestions.

----------
nosy: +orsenthil
Added file: http://bugs.python.org/file43052/issue27113-rev1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27113>
_______________________________________

From report at bugs.python.org  Sun May 29 22:22:52 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 30 May 2016 02:22:52 +0000
Subject: [issue26589] Add HTTP Response code 451
In-Reply-To: <1458339796.0.0.55641326492.issue26589@psf.upfronthosting.co.za>
Message-ID: <1464574972.58.0.409458191379.issue26589@psf.upfronthosting.co.za>


Martin Panter added the comment:

It seems like this code does get used, so I agree to add it.

I think the table in the RST documentation should also be updated, possibly with a versionadded/versionchanged notice.

----------
nosy: +martin.panter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26589>
_______________________________________

From report at bugs.python.org  Sun May 29 23:01:26 2016
From: report at bugs.python.org (Steven D'Aprano)
Date: Mon, 30 May 2016 03:01:26 +0000
Subject: [issue27157] Unhelpful error message when one calls a subclass of
 type with a custom metaclass
In-Reply-To: <1464572602.56.0.110527124718.issue27157@psf.upfronthosting.co.za>
Message-ID: <20160530030115.GO12028@ando.pearwood.info>


Steven D'Aprano added the comment:

On Mon, May 30, 2016 at 01:43:22AM +0000, ppperry wrote:
> steven.daprano, you don't appear to have properly read the issue 
> comments.

Ack; I saw your comment about the metaclass, then saw your retraction 
of the metaclass issue, then misinterpreted your retraction of the 
retraction.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27157>
_______________________________________

From report at bugs.python.org  Sun May 29 23:09:19 2016
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 30 May 2016 03:09:19 +0000
Subject: [issue26526] In parsermodule.c,
 replace over 2KLOC of hand-crafted validation code, with a DFA
In-Reply-To: <1457600551.84.0.318395917649.issue26526@psf.upfronthosting.co.za>
Message-ID: <1464577759.34.0.49722954516.issue26526@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26526>
_______________________________________

From report at bugs.python.org  Sun May 29 23:17:17 2016
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 30 May 2016 03:17:17 +0000
Subject: [issue27157] Unhelpful error message when one calls a subclass of
 type with a custom metaclass
In-Reply-To: <1464561968.54.0.551105312321.issue27157@psf.upfronthosting.co.za>
Message-ID: <1464578237.33.0.0785742202227.issue27157@psf.upfronthosting.co.za>


Eryk Sun added the comment:

All types are instances of `type`, so the single argument case makes sense to me as a 'constructor'. It always returns an instance of `type`, just not a new instance. 

    >>> X = type('X', (type,), {})
    >>> type(X)
    <class 'type'>
    >>> isinstance(type(X), type)
    True

OTOH, implementing this for subclasses of `type` doesn't generally make sense to me. That this is allowed (sometimes) is I think a mistake:

    >>> X(X)
    <class 'type'>
    >>> isinstance(X(X), X)
    False

PyType_CheckExact(metatype) isn't checking that metatype is `type`. It's checking that the type of metatype is exactly `type`, which is true for `type` and immediate instances of type, i.e. normal metaclasses. But it's not the case for a metaclass that's an instance of another metaclass:

    >>> Y = X('Y', (X,), {})
    >>> Y(Y)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: type() takes 1 or 3 arguments

Maybe I'm missing something, but it makes more sense to me if metatype is required to be *exactly* `type`, i.e. metatype == &PyType_Type, and that this check is used to gate the entire special case:

    /* Special case: type(x) should return x->ob_type */
    if (metatype == &PyType_Type) {
        const Py_ssize_t nargs = PyTuple_GET_SIZE(args);
        const Py_ssize_t nkwds = kwds == NULL ? 0 : PyDict_Size(kwds);

        if (nargs == 1 && nkwds == 0) {
            PyObject *x = PyTuple_GET_ITEM(args, 0);
            Py_INCREF(Py_TYPE(x));
            return (PyObject *) Py_TYPE(x);
        }

        /* SF bug 475327 -- if that didn't trigger, we need 3
           arguments. but PyArg_ParseTupleAndKeywords below may give
           a msg saying type() needs exactly 3. */
        if (nargs + nkwds != 3) {
            PyErr_SetString(PyExc_TypeError,
                            "type() takes 1 or 3 arguments");
            return NULL;
        }
    }

This change yields the following behavior:

    >>> X = type('X', (type,), {})

    >>> type(X)
    <class 'type'>

    >>> type(1, 2)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: type() takes 1 or 3 arguments

    >>> X()
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: Required argument 'name' (pos 1) not found

    >>> X(X)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: type() argument 1 must be str, not type

----------
nosy: +eryksun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27157>
_______________________________________

From report at bugs.python.org  Sun May 29 23:34:19 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 30 May 2016 03:34:19 +0000
Subject: [issue27125] Typo in Python 2 multiprocessing documentation
In-Reply-To: <1464216185.35.0.531405853541.issue27125@psf.upfronthosting.co.za>
Message-ID: <1464579259.37.0.0941599948338.issue27125@psf.upfronthosting.co.za>


Martin Panter added the comment:

Indeed it is duplicated! I must have read this in my head many times before pushing it, and never picked it up.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27125>
_______________________________________

From report at bugs.python.org  Sun May 29 23:38:04 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 May 2016 03:38:04 +0000
Subject: =?utf-8?q?=5Bissue27043=5D_Describe_what_=E2=80=98inspect=2Ecleandoc?=
 =?utf-8?q?=E2=80=99_does_to_synopsis_line=2E?=
In-Reply-To: <1463445757.83.0.886794484792.issue27043@psf.upfronthosting.co.za>
Message-ID: <20160530033800.103233.68121.7FC75071@psf.io>


Roundup Robot added the comment:

New changeset c1eb32e183fd by Senthil Kumaran in branch '3.5':
issue27043 - Explain the inspect.cleandoc behavior on synopsis line and other lines.
https://hg.python.org/cpython/rev/c1eb32e183fd

New changeset 4d5a5d4e731d by Senthil Kumaran in branch 'default':
[merge from 3.5] issue27043 - Explain the inspect.cleandoc behavior on synopsis line and other lines.
https://hg.python.org/cpython/rev/4d5a5d4e731d

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27043>
_______________________________________

From report at bugs.python.org  Sun May 29 23:39:02 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 May 2016 03:39:02 +0000
Subject: =?utf-8?q?=5Bissue27043=5D_Describe_what_=E2=80=98inspect=2Ecleandoc?=
 =?utf-8?q?=E2=80=99_does_to_synopsis_line=2E?=
In-Reply-To: <1463445757.83.0.886794484792.issue27043@psf.upfronthosting.co.za>
Message-ID: <20160530033900.18944.45025.72DB0B36@psf.io>


Roundup Robot added the comment:

New changeset 8f841baa0e06 by Senthil Kumaran in branch '2.7':
issue27043 - Explain the inspect.cleandoc behavior on synopsis line and other lines.
https://hg.python.org/cpython/rev/8f841baa0e06

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27043>
_______________________________________

From report at bugs.python.org  Sun May 29 23:39:47 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 30 May 2016 03:39:47 +0000
Subject: =?utf-8?q?=5Bissue27043=5D_Describe_what_=E2=80=98inspect=2Ecleandoc?=
 =?utf-8?q?=E2=80=99_does_to_synopsis_line=2E?=
In-Reply-To: <1463445757.83.0.886794484792.issue27043@psf.upfronthosting.co.za>
Message-ID: <1464579587.74.0.409523265037.issue27043@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Thanks for the patch, Nathan.

----------
nosy: +orsenthil
resolution:  -> fixed
stage: commit review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27043>
_______________________________________

From report at bugs.python.org  Sun May 29 23:51:10 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 30 May 2016 03:51:10 +0000
Subject: [issue27113] sqlite3 connect parameter "check_same_thread" not
 documented
In-Reply-To: <1464125789.84.0.570004715823.issue27113@psf.upfronthosting.co.za>
Message-ID: <1464580270.8.0.569068980186.issue27113@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

We should be able to simplify this further based on the comments in the review for the first patch.

Please find my patch issue27113-rev2.patch attached.

----------
Added file: http://bugs.python.org/file43053/issue27113-rev2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27113>
_______________________________________

From report at bugs.python.org  Sun May 29 23:57:45 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Mon, 30 May 2016 03:57:45 +0000
Subject: [issue27157] Unhelpful error message when one calls a subclass of
 type with a custom metaclass
In-Reply-To: <1464561968.54.0.551105312321.issue27157@psf.upfronthosting.co.za>
Message-ID: <1464580665.19.0.121351620328.issue27157@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

+1. I prefer that change, as using subclasses of `type` as if they were type itself never made sense to me. This shouldn't break existing code, but if it does, it was either a concealed bug or a very bad idea to begin with, and should be fixed either way.

Attached patch implements Eryk's suggestion. I haven't found any tests that checked for subclasses of type specifically (except tests testing for metaclass stuff), and I haven't added any either.

----------
keywords: +patch
stage:  -> needs patch
Added file: http://bugs.python.org/file43054/type_one_argument_1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27157>
_______________________________________

From report at bugs.python.org  Sun May 29 23:58:31 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Mon, 30 May 2016 03:58:31 +0000
Subject: [issue27157] Unhelpful error message when one calls a subclass of
 type with a custom metaclass
In-Reply-To: <1464561968.54.0.551105312321.issue27157@psf.upfronthosting.co.za>
Message-ID: <1464580711.61.0.780755274185.issue27157@psf.upfronthosting.co.za>


Changes by Emanuel Barry <barry at dadadata.net>:


----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27157>
_______________________________________

From report at bugs.python.org  Mon May 30 01:27:38 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 May 2016 05:27:38 +0000
Subject: [issue27125] Typo in Python 2 multiprocessing documentation
In-Reply-To: <1464216185.35.0.531405853541.issue27125@psf.upfronthosting.co.za>
Message-ID: <20160530052705.23323.97728.A7C018E9@psf.io>


Roundup Robot added the comment:

New changeset 824d32436198 by Martin Panter in branch '2.7':
Issue #27125: Remove duplicated words from documentation and comments
https://hg.python.org/cpython/rev/824d32436198

New changeset fd0ac7ba091e by Martin Panter in branch '3.5':
Issue #27125: Remove duplicated words from documentation and comments
https://hg.python.org/cpython/rev/fd0ac7ba091e

New changeset e553b5ef7ff3 by Martin Panter in branch 'default':
Issue #27125: Merge typo fixes from 3.5
https://hg.python.org/cpython/rev/e553b5ef7ff3

New changeset bd0a12277a8e by Martin Panter in branch 'default':
Issue #27125: Remove duplicated words in exception message
https://hg.python.org/cpython/rev/bd0a12277a8e

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27125>
_______________________________________

From report at bugs.python.org  Mon May 30 01:37:43 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 30 May 2016 05:37:43 +0000
Subject: [issue27152] Additional assert methods for unittest
In-Reply-To: <1464535519.92.0.0853489345335.issue27152@psf.upfronthosting.co.za>
Message-ID: <1464586663.85.0.861436936397.issue27152@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I don't really like the assertEndsWith method which triggers a mental hiccup when taking a familiar method call, making it into function call, and giving an awkward looking camelcase name.

Also, Guido is usually opposed to broad, sweeping search/replace patches.  Instead, he has advocated "holistic refactoring" where updates are done by someone actively working on the module rather than a disinterested party churning the code without thinking deeply about the topic at hand.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27152>
_______________________________________

From report at bugs.python.org  Mon May 30 01:41:01 2016
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 30 May 2016 05:41:01 +0000
Subject: [issue27157] Unhelpful error message when one calls a subclass of
 type with a custom metaclass
In-Reply-To: <1464561968.54.0.551105312321.issue27157@psf.upfronthosting.co.za>
Message-ID: <1464586861.22.0.638282671955.issue27157@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Guido, this is your code.  Do you care to opine?

----------
nosy: +gvanrossum, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27157>
_______________________________________

From report at bugs.python.org  Mon May 30 01:52:10 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 30 May 2016 05:52:10 +0000
Subject: [issue27157] Unhelpful error message when one calls a subclass of
 type with a custom metaclass
In-Reply-To: <1464561968.54.0.551105312321.issue27157@psf.upfronthosting.co.za>
Message-ID: <1464587530.78.0.333018981207.issue27157@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I don't recall writing that any more, but that fix looks right. (Though why write `metatype == &PyType_Type` rather than `PyType_CheckExact(metatype)`?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27157>
_______________________________________

From report at bugs.python.org  Mon May 30 01:59:58 2016
From: report at bugs.python.org (Roundup Robot)
Date: Mon, 30 May 2016 05:59:58 +0000
Subject: [issue27156] IDLE: remove unused code
In-Reply-To: <1464553304.91.0.34770795987.issue27156@psf.upfronthosting.co.za>
Message-ID: <20160530055955.18946.55632.FF92E7C0@psf.io>


Roundup Robot added the comment:

New changeset 0945b9729734 by Terry Jan Reedy in branch 'default':
Issue #27156: Remove obsolete code not used by IDLE.
https://hg.python.org/cpython/rev/0945b9729734

----------
nosy: +python-dev

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27156>
_______________________________________

From report at bugs.python.org  Mon May 30 02:10:27 2016
From: report at bugs.python.org (Dave Sawyer)
Date: Mon, 30 May 2016 06:10:27 +0000
Subject: [issue27113] sqlite3 connect parameter "check_same_thread" not
 documented
In-Reply-To: <1464125789.84.0.570004715823.issue27113@psf.upfronthosting.co.za>
Message-ID: <1464588627.59.0.781836303705.issue27113@psf.upfronthosting.co.za>


Dave Sawyer added the comment:

The revised patch says "connections" plural for true and "connection" singular for false. How about "the connection" since the method returns a connection. I'm wondering though about the lack of explanation or WHY for this parameter. As written it seems like the default value was poorly chosen and everyone should just set it to true. Likewise, if everyone should set it to true, why is it even provided as an option?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27113>
_______________________________________

From report at bugs.python.org  Mon May 30 02:12:29 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 30 May 2016 06:12:29 +0000
Subject: [issue24671] idlelib 2.7: finish converting print statements
In-Reply-To: <1437344321.63.0.544143198256.issue24671@psf.upfronthosting.co.za>
Message-ID: <1464588749.41.0.486152931498.issue24671@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I no longer plan to backport enough patches to make further fixes worthwhile in the absence of otherwise working on a file.  In the absence of adequate tests, there is also the non-0 chance of introducing bugs.

----------
assignee:  -> terry.reedy
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24671>
_______________________________________

From report at bugs.python.org  Mon May 30 02:48:36 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 May 2016 06:48:36 +0000
Subject: [issue27125] Typo in Python 2 multiprocessing documentation
In-Reply-To: <1464216185.35.0.531405853541.issue27125@psf.upfronthosting.co.za>
Message-ID: <1464590916.29.0.137662043898.issue27125@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I'm impressed by the number of duplicates left after all past cleanups.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27125>
_______________________________________

From report at bugs.python.org  Mon May 30 02:58:39 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 May 2016 06:58:39 +0000
Subject: [issue27152] Additional assert methods for unittest
In-Reply-To: <1464535519.92.0.0853489345335.issue27152@psf.upfronthosting.co.za>
Message-ID: <1464591519.53.0.372530262918.issue27152@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Changes in tests are provided as a demonstration that these methods are useful. I propose to commit only the unittest part, and use new methods on a case-by-case basis. For example some tests already define methods like assertHasAttr or assertIsSubclass, They can now use standard methods.

assertEndsWith() can be used 73 times in 36 files. It produces more useful error report than assertTrue(a.endswith(b)).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27152>
_______________________________________

From report at bugs.python.org  Mon May 30 03:00:43 2016
From: report at bugs.python.org (SilentGhost)
Date: Mon, 30 May 2016 07:00:43 +0000
Subject: [issue10908] Improvements to trace._Ignore
In-Reply-To: <1295020376.03.0.967767300509.issue10908@psf.upfronthosting.co.za>
Message-ID: <1464591643.53.0.447470455623.issue10908@psf.upfronthosting.co.za>


SilentGhost added the comment:

I closed the issue because it's outdated: i) patch no longer applies cleanly; ii) changes to cmd line parsing where done in issue 22642; iii) remaining changes are largely cosmetic.

As for issue 10896, a much more trivial patch would have to be produced against the current tip.  And someone would have to test it on Windows.  But that's only if any of the committers are interested in committing it within the next few years.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10908>
_______________________________________

From report at bugs.python.org  Mon May 30 04:08:57 2016
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 30 May 2016 08:08:57 +0000
Subject: [issue27157] Unhelpful error message when one calls a subclass of
 type with a custom metaclass
In-Reply-To: <1464561968.54.0.551105312321.issue27157@psf.upfronthosting.co.za>
Message-ID: <1464595737.85.0.701957815861.issue27157@psf.upfronthosting.co.za>


Eryk Sun added the comment:

> why write `metatype == &PyType_Type` rather than 
> PyType_CheckExact(metatype)`?

If only `type` should implement this special case, then it needs to be `metatype == &PyType_Type`. This was actually how it was implemented in 2.2a3:

https://hg.python.org/cpython/file/v2.2a3/Objects/typeobject.c#l631

I don't know why the final release of 2.2 switched to using PyType_CheckExact, which is true for most metaclasses. That's why I feel like I'm missing something here.

Probably it used PyType_CheckExact instead of PyType_Check to ensure PyType_IsSubtype wouldn't be called. Nowadays that's optimized away via PyType_FastSubclass and the Py_TPFLAGS_TYPE_SUBCLASS flag (set up in inherit_special). If it's decided to retain this special case for metaclasses other than `type`, then I think it should use PyType_Check to consistently implement it for all metaclasses. Also, the error message should be more generic, e.g. maybe "__new__() takes 1 or 3 arguments".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27157>
_______________________________________

From report at bugs.python.org  Mon May 30 05:31:19 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 May 2016 09:31:19 +0000
Subject: [issue27140] Opcode for creating dict with constant keys
In-Reply-To: <1464381640.82.0.0689379791356.issue27140@psf.upfronthosting.co.za>
Message-ID: <1464600679.25.0.054376782296.issue27140@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Proposed patch adds the BUILD_MAP_EX opcode (maybe somebody propose better name?). It takes values from the stack and keys from the tuple on the top of the stack. Currently it affects only creating a dict with const keys and calling a function with keywords after the var-keyword argument.

$ echo "{'a': 1, 'b': 2, 'c': 3}" | ./python -m dis

Unpatched:

  1           0 LOAD_CONST               0 ('a')
              2 LOAD_CONST               1 (1)
              4 LOAD_CONST               2 ('b')
              6 LOAD_CONST               3 (2)
              8 LOAD_CONST               4 ('c')
             10 LOAD_CONST               5 (3)
             12 BUILD_MAP                3
             14 POP_TOP
             16 LOAD_CONST               6 (None)
             18 RETURN_VALUE

Patched:

  1           0 LOAD_CONST               0 (1)
              2 LOAD_CONST               1 (2)
              4 LOAD_CONST               2 (3)
              6 LOAD_CONST               7 (('a', 'b', 'c'))
              8 BUILD_MAP_EX             3
             10 POP_TOP
             12 LOAD_CONST               6 (None)
             14 RETURN_VALUE

$ echo "f(**kw, a=1, b=2, c=3)" | ./python -m dis

Unpatched:

  1           0 LOAD_NAME                0 (f)
              2 LOAD_NAME                1 (kw)
              4 LOAD_CONST               0 ('a')
              6 LOAD_CONST               1 (1)
              8 LOAD_CONST               2 ('b')
             10 LOAD_CONST               3 (2)
             12 LOAD_CONST               4 ('c')
             14 LOAD_CONST               5 (3)
             16 BUILD_MAP                3
             18 EXTENDED_ARG             1
             20 BUILD_MAP_UNPACK_WITH_CALL   258
             22 CALL_FUNCTION_KW         0 (0 positional, 0 keyword pair)
             24 POP_TOP
             26 LOAD_CONST               6 (None)
             28 RETURN_VALUE

Patched:

  1           0 LOAD_NAME                0 (f)
              2 LOAD_NAME                1 (kw)
              4 LOAD_CONST               0 (1)
              6 LOAD_CONST               1 (2)
              8 LOAD_CONST               2 (3)
             10 LOAD_CONST               7 (('a', 'b', 'c'))
             12 BUILD_MAP_EX             3
             14 EXTENDED_ARG             1
             16 BUILD_MAP_UNPACK_WITH_CALL   258
             18 CALL_FUNCTION_KW         0 (0 positional, 0 keyword pair)
             20 POP_TOP
             22 LOAD_CONST               6 (None)
             24 RETURN_VALUE

It could be more useful for new MAKE_FUNCTION opcode (issue27095) and maybe for new CALL_FUNCTION* opcodes.

The benefit of BUILD_MAP_EX is less LOAD_CONST instructions and less stack consuming.

----------
keywords: +patch
nosy: +benjamin.peterson, brett.cannon, georg.brandl, ncoghlan, yselivanov
stage: needs patch -> patch review
Added file: http://bugs.python.org/file43055/BUILD_MAP_EX.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27140>
_______________________________________

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: [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 06:46:27 2016
From: report at bugs.python.org (Sean Hunt)
Date: Mon, 30 May 2016 10:46:27 +0000
Subject: [issue25566] asyncio reference cycles after ConnectionResetError
In-Reply-To: <1446810215.4.0.896282956786.issue25566@psf.upfronthosting.co.za>
Message-ID: <1464605187.39.0.97325472452.issue25566@psf.upfronthosting.co.za>


Sean Hunt added the comment:

I am 1 of those people who want to handle the error with reconnect code as it happens when using discord.py when the stupid connection is aborted due to Cloudflare being stupid and them thinking a bot made in python is a DDoS like litterally. So, I know of this error as well.

----------
nosy: +Sean Hunt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25566>
_______________________________________

From report at bugs.python.org  Mon May 30 08:02:49 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 30 May 2016 12:02:49 +0000
Subject: [issue22331] test_io.test_interrupted_write_text() hangs on the
 buildbot FreeBSD 7.2
In-Reply-To: <1409779908.87.0.4046116696.issue22331@psf.upfronthosting.co.za>
Message-ID: <1464609769.47.0.929939295774.issue22331@psf.upfronthosting.co.za>


Martin Panter added the comment:

This recently hung AMD64 FreeBSD 9.x 3.5. The stack trace was different, and there is only one thread:

http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.x%203.5/builds/828/steps/test/logs/stdio
[398/398] test_io
Timeout (0:15:00)!
Thread 0x0000000801807400 (most recent call first):
  File "/usr/home/buildbot/python/3.5.koobs-freebsd9/build/Lib/unittest/case.py", line 176 in handle
  File "/usr/home/buildbot/python/3.5.koobs-freebsd9/build/Lib/unittest/case.py", line 727 in assertRaises
  File "/usr/home/buildbot/python/3.5.koobs-freebsd9/build/Lib/test/test_io.py", line 3714 in check_interrupted_write
  File "/usr/home/buildbot/python/3.5.koobs-freebsd9/build/Lib/test/test_io.py", line 3743 in test_interrupted_write_text

Also, x86 Ubuntu Shared 2.7 hung, but the only information I have is it was running test_io.

In my Free BSD case, the write() call is stuck, but in Victor?s original case, the background read() call is stuck. I could explain both cases as a race condition with the alarm signal being delivered:

Victor?s case: SIGALRM delivered somewhere inside assertRaises(), but before the write() system call, and Python has a chance to call the Python signal handler. No data is ever written, so the background read() hangs.

My case: SIGALRM delivered just before or as write() starts, so Python has no chance to interrupt the system call and call its own Python handler.

I wonder if we can change the test to only deliver a signal after first reading one byte, i.e. send the signal directly from the background thread. I think that should cover 99% of cases, though in theory it is possible for something else to interrupt write(), and our signal to be delivered while write() was restarting, causing it to hang. But the combination of those two events would be so unlikely it may not be worth worrying about.

Also, if you close the read end of the pipe before the write end, it should protect against flush() hanging without the EBADF hack by raising EPIPE instead.

I suggest rewriting the background thread like:

def _read():
    s = os.read(r, 1)
    read_results.append(s)
    # The main thread is very likely to be inside the write() syscall now, so interrupt it
    os.kill(os.getpid(), SIGALRM)

and cleaning up the pipe like:

finally:
    os.close(r)
    try:
        wio.close()
    except BrokenPipeError:
        pass

----------
nosy: +martin.panter
status: closed -> open
versions: +Python 2.7, Python 3.6 -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22331>
_______________________________________

From report at bugs.python.org  Mon May 30 08:14:52 2016
From: report at bugs.python.org (Demur Rumed)
Date: Mon, 30 May 2016 12:14:52 +0000
Subject: [issue27140] Opcode for creating dict with constant keys
In-Reply-To: <1464381640.82.0.0689379791356.issue27140@psf.upfronthosting.co.za>
Message-ID: <1464610492.7.0.981714634304.issue27140@psf.upfronthosting.co.za>


Demur Rumed added the comment:

Perhaps BUILD_CONST_KEY_MAP?

Ideally the opcode could ellide the LOAD_CONST for the tuple. ie have LOAD_CONST 2 (1, 2, 3), BUILD_CONST_KEY_MAP 3 be BUILD_CONST_KEY_MAP 2 (1, 2, 3). However that'd require stack_effect to somehow lookup the const tuple

Thinking to in the context of MAKE_FUNCTION, I'd like to create a function for ceval which takes stack_pointer & returns stack_pointer at new offset with dict at top of stack. Then use this both for this opcode & have MAKE_FUNCTION call it directly (ie, don't have to emit BUILD_MAP_EX). This too makes for a need to do some backtracking to figure out stack effect

Relying on the peepholer seems unideal; it does more work than generating the tuple the first time & doing it eagerly will produce a more compact stack depth & co_consts

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27140>
_______________________________________

From report at bugs.python.org  Mon May 30 08:41:43 2016
From: report at bugs.python.org (Martin Panter)
Date: Mon, 30 May 2016 12:41:43 +0000
Subject: [issue23680] Sporadic freeze in test_interrupted_write_retry_text
In-Reply-To: <1426521207.32.0.580722848653.issue23680@psf.upfronthosting.co.za>
Message-ID: <1464612103.94.0.434287895919.issue23680@psf.upfronthosting.co.za>


Martin Panter added the comment:

I found a relatively recent case of this failing on a buildbot:

http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.x%203.x/builds/4339/steps/test/logs/stdio
== CPython 3.6.0a1+ (default:eaee5aed6fbc, May 27 2016, 05:52:21) [GCC 4.2.1 20070831 patched [FreeBSD]]
0:19:34 [401/401/1] test_io crashed
Timeout (0:15:00)!
Thread 0x0000000801807400 (most recent call first):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/test_io.py", line 3808 in check_interrupted_write_retry
  File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/test_io.py", line 3834 in test_interrupted_write_retry_text

Line 3808 is the write() call, so it could be hanging if the second signal is delivered just before Python makes the write() syscall. Perhaps it might help to use setitimer() so that even if a signal is delivered at an inconvenient moment, the write() call will still be interrupted by a later signal, and read thread will still be spawned.

Also see Issue 22331 for an idea to avoid the EBADF hack.

----------
keywords: +buildbot
nosy: +martin.panter
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23680>
_______________________________________

From report at bugs.python.org  Mon May 30 08:47:45 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 May 2016 12:47:45 +0000
Subject: [issue22331] test_io.test_interrupted_write_text() hangs on the
 buildbot FreeBSD 7.2
In-Reply-To: <1409779908.87.0.4046116696.issue22331@psf.upfronthosting.co.za>
Message-ID: <1464612465.66.0.0237232967677.issue22331@psf.upfronthosting.co.za>


STINNER Victor added the comment:

When we talk about signals, we must always be careful of threads. Python unit tests are known (at least by me ;-)) to "leak" threads. IMO the first step to make the test more reliable is to start it in a fresh process to control exactly the number of threads.

A fresh process avoids also to inherit an expected signal and/or signal handler.

I modified test_eintr recently to do something similar.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22331>
_______________________________________

From report at bugs.python.org  Mon May 30 08:50:06 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 May 2016 12:50:06 +0000
Subject: [issue22331] test_io.test_interrupted_write_text() hangs on the
 buildbot FreeBSD 7.2
In-Reply-To: <1409779908.87.0.4046116696.issue22331@psf.upfronthosting.co.za>
Message-ID: <1464612606.42.0.800984201108.issue22331@psf.upfronthosting.co.za>


STINNER Victor added the comment:

I also modified Python 3.6 to run each test file in a fresh process to avoid leaking too much things between tests, to isolate them better.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22331>
_______________________________________

From report at bugs.python.org  Mon May 30 09:02:51 2016
From: report at bugs.python.org (ppperry)
Date: Mon, 30 May 2016 13:02:51 +0000
Subject: [issue27137] Python implementation of `functools.partial` is not a
 class
In-Reply-To: <1464367158.87.0.208604382314.issue27137@psf.upfronthosting.co.za>
Message-ID: <1464613371.23.0.400155976722.issue27137@psf.upfronthosting.co.za>


Changes by ppperry <mapreader at olum.org>:


----------
title: functools.partial: Inconsistency between Python and C implementations -> Python implementation of `functools.partial` is not a class

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27137>
_______________________________________

From report at bugs.python.org  Mon May 30 09:37:39 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Mon, 30 May 2016 13:37:39 +0000
Subject: [issue27157] Unhelpful error message when one calls a subclass of
 type with a custom metaclass
In-Reply-To: <1464561968.54.0.551105312321.issue27157@psf.upfronthosting.co.za>
Message-ID: <1464615459.94.0.982101885423.issue27157@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

Yes, `metatype == &PyType_Type` makes sure that only `type` itself is valid for the one-argument part, whereas subclasses can also do so right now. I clarified that in a comment in the new patch, so that someone doesn't accidentally revert this, thinking PyType_CheckExact is fine.

Before the patch:

>>> type(1, 2, 3)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: type() argument 1 must be str, not int

After the patch:

>>> type(1, 2, 3)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: type.__new__() argument 1 must be str, not int
>>> class X(type): pass
...
>>> X(1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: type.__new__() argument 1 must be str, not int

----------
Added file: http://bugs.python.org/file43056/type_one_argument_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27157>
_______________________________________

From report at bugs.python.org  Mon May 30 10:02:41 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 May 2016 14:02:41 +0000
Subject: [issue27140] Opcode for creating dict with constant keys
In-Reply-To: <1464381640.82.0.0689379791356.issue27140@psf.upfronthosting.co.za>
Message-ID: <1464616961.71.0.503051347327.issue27140@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

> Perhaps BUILD_CONST_KEY_MAP?

LGTM.

> Ideally the opcode could ellide the LOAD_CONST for the tuple. ie have LOAD_CONST 2 (1, 2, 3), BUILD_CONST_KEY_MAP 3 be BUILD_CONST_KEY_MAP 2 (1, 2, 3). However that'd require stack_effect to somehow lookup the const tuple

I like this idea. But PyCompile_OpcodeStackEffect() doesn't have an access to the consts dict.

> Relying on the peepholer seems unideal; it does more work than generating the tuple the first time & doing it eagerly will produce a more compact stack depth & co_consts

I thought that this would be not easy. But thanks to your encouraging I have tried to do this and the result is pretty simple.

In updated patch the opcode name was changed to BUILD_CONST_KEY_MAP, and the compiler no longer depends on the peephole optimizer for generating constant keys tuple. Thank you Demur.

----------
Added file: http://bugs.python.org/file43057/BUILD_CONST_KEY_MAP.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27140>
_______________________________________

From report at bugs.python.org  Mon May 30 10:08:26 2016
From: report at bugs.python.org (ppperry)
Date: Mon, 30 May 2016 14:08:26 +0000
Subject: [issue27159] Python 3.5.1's websocket's lib crashes in event that
 internet connection stops.
In-Reply-To: <1464604698.4.0.495142476658.issue27159@psf.upfronthosting.co.za>
Message-ID: <1464617306.09.0.128436173493.issue27159@psf.upfronthosting.co.za>


ppperry added the comment:

This issue should really be split into (at least) four seperate issues.

The third problem (reloading relatively imported modules), can be done by doing `someclass = getattr(importlib.reload(sys.modules[someclass.__module__]),someclass.__name__)`. It also has nothing to do with relative imports, instead involving reloading the modules of classes imported using the `from ... import ...` statement.

----------
nosy: +ppperry

_______________________________________
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: [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 10:56:42 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 May 2016 14:56:42 +0000
Subject: [issue27160] Silent truncation of kwargs when passing keywords
 containing colons
In-Reply-To: <1464619944.37.0.938540391114.issue27160@psf.upfronthosting.co.za>
Message-ID: <1464620202.19.0.888227053222.issue27160@psf.upfronthosting.co.za>


STINNER Victor added the comment:

IMHO the error is very explicit:

Traceback (most recent call last):
  File "poc.py", line 6, in <module>
    print(a.format(**r))
KeyError: 'HGNC'

Your "r" directory has no "HGNC" key. I think that you misunderstood the formatting of str.format:
https://docs.python.org/dev/library/string.html#formatstrings

The format string "{HGNC:11892}" is parsed as key="HGNC", format="11892".

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27160>
_______________________________________

From report at bugs.python.org  Mon May 30 10:56:47 2016
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 30 May 2016 14:56:47 +0000
Subject: [issue27160] str.format: Silent truncation of kwargs when passing
 keywords containing colons
In-Reply-To: <1464619944.37.0.938540391114.issue27160@psf.upfronthosting.co.za>
Message-ID: <1464620207.79.0.754998258262.issue27160@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
title: Silent truncation of kwargs when passing keywords containing colons -> str.format: Silent truncation of kwargs when passing keywords containing colons

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27160>
_______________________________________

From report at bugs.python.org  Mon May 30 10:59:41 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Mon, 30 May 2016 14:59:41 +0000
Subject: [issue27160] str.format: Silent truncation of kwargs when passing
 keywords containing colons
In-Reply-To: <1464619944.37.0.938540391114.issue27160@psf.upfronthosting.co.za>
Message-ID: <1464620381.33.0.400189524648.issue27160@psf.upfronthosting.co.za>


Changes by Emanuel Barry <barry at dadadata.net>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27160>
_______________________________________

From report at bugs.python.org  Mon May 30 11:02:36 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Mon, 30 May 2016 15:02:36 +0000
Subject: [issue27160] str.format: Silent truncation of kwargs when passing
 keywords containing colons
In-Reply-To: <1464619944.37.0.938540391114.issue27160@psf.upfronthosting.co.za>
Message-ID: <1464620556.57.0.438090732121.issue27160@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

In other words, you cannot use keys containing a colon in str.format - you'll need to replace the colons by something else (for example an underscore, that works fine).

----------
nosy: +ebarry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27160>
_______________________________________

From report at bugs.python.org  Mon May 30 11:10:11 2016
From: report at bugs.python.org (Yoni Lavi)
Date: Mon, 30 May 2016 15:10:11 +0000
Subject: [issue22558] Missing doc links to source code
In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za>
Message-ID: <1464621011.34.0.624036771921.issue22558@psf.upfronthosting.co.za>


Yoni Lavi added the comment:

Ping. Please advise on next step to get this submitted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22558>
_______________________________________

From report at bugs.python.org  Mon May 30 11:52:28 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Mon, 30 May 2016 15:52:28 +0000
Subject: [issue27137] Python implementation of `functools.partial` is not a
 class
In-Reply-To: <1464367158.87.0.208604382314.issue27137@psf.upfronthosting.co.za>
Message-ID: <1464623548.75.0.365268345618.issue27137@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

New patch after Serhiy's comments. I kept the __dict__ in pickling to properly pickle attributes that aren't defined by 'partial' itself; but if 'func', 'args' or 'keywords' are present and don't match the provided arguments, an error will be raised, as it should not be partial's responsibility to handle this; this is for the caller to do.

----------
Added file: http://bugs.python.org/file43059/functools_partial_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27137>
_______________________________________

From report at bugs.python.org  Mon May 30 12:06:43 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 30 May 2016 16:06:43 +0000
Subject: [issue27157] Unhelpful error message when one calls a subclass of
 type with a custom metaclass
In-Reply-To: <1464561968.54.0.551105312321.issue27157@psf.upfronthosting.co.za>
Message-ID: <1464624403.94.0.669803693945.issue27157@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

OK, the patch looks fine. Please treat this as a new feature (just in case) and only apply it to 3.6.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27157>
_______________________________________

From report at bugs.python.org  Mon May 30 12:10:47 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Mon, 30 May 2016 16:10:47 +0000
Subject: [issue27157] Unhelpful error message when one calls a subclass of
 type with a custom metaclass
In-Reply-To: <1464561968.54.0.551105312321.issue27157@psf.upfronthosting.co.za>
Message-ID: <1464624647.21.0.812298620991.issue27157@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

Fair enough. Should this get a note in What's new? Possibly in the "Changes in Python API" section.

----------
stage: patch review -> commit review
versions: +Python 3.6 -Python 2.7, Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27157>
_______________________________________

From report at bugs.python.org  Mon May 30 12:19:54 2016
From: report at bugs.python.org (Kenneth Lim)
Date: Mon, 30 May 2016 16:19:54 +0000
Subject: [issue27160] str.format: Silent truncation of kwargs when passing
 keywords containing colons
In-Reply-To: <1464620556.57.0.438090732121.issue27160@psf.upfronthosting.co.za>
Message-ID: <CA+6qxE2+_ThS8-1LSkCgvCOcC3pQ_y3o6DBHegng9jRtO01bdA@mail.gmail.com>


Kenneth Lim added the comment:

Hi Barry,

I was aware of that. However, I was alluding to the KeyError produced, and
the silent truncation of the text. Rather than failing at the colon step
(SyntaxError when on run), truncated arguments pass this step, causing
errors downstream.

On Mon, May 30, 2016 at 11:02 PM, Emanuel Barry <report at bugs.python.org>
wrote:

>
> Emanuel Barry added the comment:
>
> In other words, you cannot use keys containing a colon in str.format -
> you'll need to replace the colons by something else (for example an
> underscore, that works fine).
>
> ----------
> nosy: +ebarry
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue27160>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27160>
_______________________________________

From report at bugs.python.org  Mon May 30 12:21:46 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 30 May 2016 16:21:46 +0000
Subject: [issue5996] abstract class instantiable when subclassing dict
In-Reply-To: <1242050763.07.0.145569961651.issue5996@psf.upfronthosting.co.za>
Message-ID: <1464625306.13.0.546748437124.issue5996@psf.upfronthosting.co.za>


Xiang Zhang added the comment:

I think subclassing builtin types and making it abstract is rare. And when there is a need, we can mimic this in application level (this may also apply to types having custom __new__):

In [2]: class CustomDict(dict, metaclass=abc.ABCMeta):
   ...:     def __new__(cls, *args, **kwargs):
   ...:         if getattr(cls, '__abstractmethods__', None):
   ...:             raise TypeError
   ...:         return super().__new__(cls, *args, **kwargs)
   ...:     @abc.abstractmethod
   ...:     def f(self):
   ...:         pass

Adding the abstract class checking in tp_alloc or builtin types' tp_new maybe degrade performance.

Is it necessary to add this support?

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5996>
_______________________________________

From report at bugs.python.org  Mon May 30 12:23:38 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 30 May 2016 16:23:38 +0000
Subject: [issue27157] Unhelpful error message when one calls a subclass of
 type with a custom metaclass
In-Reply-To: <1464624647.21.0.812298620991.issue27157@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJLD2nh8ncSkfPXuJZbP74OW0DnitCtbjqV71Q-sMHxBJg@mail.gmail.com>


Guido van Rossum added the comment:

No, just an entry in Misc/NEWS.

--Guido (mobile)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27157>
_______________________________________

From report at bugs.python.org  Mon May 30 12:28:13 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 30 May 2016 16:28:13 +0000
Subject: [issue27157] Unhelpful error message when one calls a subclass of
 type with a custom metaclass
In-Reply-To: <1464561968.54.0.551105312321.issue27157@psf.upfronthosting.co.za>
Message-ID: <1464625693.26.0.495155862082.issue27157@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

Needed tests and updating the documentation.

----------
nosy: +serhiy.storchaka
stage: commit review -> test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27157>
_______________________________________

From report at bugs.python.org  Mon May 30 12:37:25 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Mon, 30 May 2016 16:37:25 +0000
Subject: [issue27160] str.format: Silent truncation of kwargs when passing
 keywords containing colons
In-Reply-To: <1464619944.37.0.938540391114.issue27160@psf.upfronthosting.co.za>
Message-ID: <1464626245.59.0.175151703579.issue27160@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

The behaviour is correct, it's your assumptions that aren't :)

The code for str.format only checks for what's before the colon (here, "HGNC") and checks if that's part of the dict provided. It isn't, so it raises a KeyError. It doesn't even get to the format spec part (which is a perfectly valid format specifier). Your dict can contain anything or be empty, str.format only checks for the existence of the key you asked for ("HGNC"). "{HGNC:11892}" is also a perfectly valid Python string.

P.S.: While I'm fine with people calling me by my last name, there's another developer whose name is Barry Warsaw, so let's try to avoid confusion here ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27160>
_______________________________________

From report at bugs.python.org  Mon May 30 12:42:20 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 30 May 2016 16:42:20 +0000
Subject: [issue25566] asyncio reference cycles after ConnectionResetError
In-Reply-To: <1464605187.39.0.97325472452.issue25566@psf.upfronthosting.co.za>
Message-ID: <CAP7+vJK-5uW08LNyyRRsab8nad+_91ZtV5qRnD41V1v_t47FGw@mail.gmail.com>


Guido van Rossum added the comment:

Please submit a patch to the upstream asyncio repo,
github.com/Python/asyncio.

--Guido (mobile)
On May 30, 2016 3:46 AM, "Sean Hunt" <report at bugs.python.org> wrote:

>
> Sean Hunt added the comment:
>
> I am 1 of those people who want to handle the error with reconnect code as
> it happens when using discord.py when the stupid connection is aborted due
> to Cloudflare being stupid and them thinking a bot made in python is a DDoS
> like litterally. So, I know of this error as well.
>
> ----------
> nosy: +Sean Hunt
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue25566>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25566>
_______________________________________

From report at bugs.python.org  Mon May 30 12:58:29 2016
From: report at bugs.python.org (Kenneth Lim)
Date: Mon, 30 May 2016 16:58:29 +0000
Subject: [issue27160] str.format: Silent truncation of kwargs when passing
 keywords containing colons
In-Reply-To: <1464626245.59.0.175151703579.issue27160@psf.upfronthosting.co.za>
Message-ID: <CA+6qxE1UB64TqmafRvd_fYaRZN67dY3umsr1-CWLLQgasYEGtQ@mail.gmail.com>


Kenneth Lim added the comment:

Ah, so the truncation is fully intended behavior.

As for the name, a touch too many comic-books in the past might be the
reason I latched onto "Barry" as a first name.

Thanks for the clarification.

On Tue, May 31, 2016 at 12:37 AM, Emanuel Barry <report at bugs.python.org>
wrote:

>
> Emanuel Barry added the comment:
>
> The behaviour is correct, it's your assumptions that aren't :)
>
> The code for str.format only checks for what's before the colon (here,
> "HGNC") and checks if that's part of the dict provided. It isn't, so it
> raises a KeyError. It doesn't even get to the format spec part (which is a
> perfectly valid format specifier). Your dict can contain anything or be
> empty, str.format only checks for the existence of the key you asked for
> ("HGNC"). "{HGNC:11892}" is also a perfectly valid Python string.
>
> P.S.: While I'm fine with people calling me by my last name, there's
> another developer whose name is Barry Warsaw, so let's try to avoid
> confusion here ;-)
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue27160>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27160>
_______________________________________

From report at bugs.python.org  Mon May 30 13:23:42 2016
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 30 May 2016 17:23:42 +0000
Subject: [issue27157] Unhelpful error message when one calls a subclass of
 type with a custom metaclass
In-Reply-To: <1464561968.54.0.551105312321.issue27157@psf.upfronthosting.co.za>
Message-ID: <1464629022.51.0.277958806273.issue27157@psf.upfronthosting.co.za>


Eryk Sun added the comment:

> Please treat this as a new feature (just in case) and only 
> apply it to 3.6.

How about changing PyType_CheckExact to PyType_Check for 2.7 and 3.5? It solves the original problem by expanding the single-argument case to metaclasses that aren't an exact instance of `type`. I think that's unlikely to break existing code. It also shouldn't cause a performance problem since the PyType_Check macro uses the Py_TPFLAGS_TYPE_SUBCLASS flag.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27157>
_______________________________________

From report at bugs.python.org  Mon May 30 13:26:58 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Mon, 30 May 2016 17:26:58 +0000
Subject: [issue27157] Unhelpful error message when one calls a subclass of
 type with a custom metaclass
In-Reply-To: <1464561968.54.0.551105312321.issue27157@psf.upfronthosting.co.za>
Message-ID: <1464629218.76.0.846852542986.issue27157@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

Let me just make sure I got you right - you're fine with `type` and only `type` being able to use the one-argument form in 3.6, but prefer 3.5 and 2.7 to be even more permissive than they currently are? Regardless, I don't think this should go into a bugfix release.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27157>
_______________________________________

From report at bugs.python.org  Mon May 30 13:31:19 2016
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 30 May 2016 17:31:19 +0000
Subject: [issue27157] Unhelpful error message when one calls a subclass of
 type with a custom metaclass
In-Reply-To: <1464561968.54.0.551105312321.issue27157@psf.upfronthosting.co.za>
Message-ID: <1464629479.8.0.566524430394.issue27157@psf.upfronthosting.co.za>


Changes by Eryk Sun <eryksun+pybugs at gmail.com>:


----------
Removed message: http://bugs.python.org/msg266710

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27157>
_______________________________________

From report at bugs.python.org  Mon May 30 13:32:43 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Mon, 30 May 2016 17:32:43 +0000
Subject: [issue27157] Unhelpful error message when one calls a subclass of
 type with a custom metaclass
In-Reply-To: <1464561968.54.0.551105312321.issue27157@psf.upfronthosting.co.za>
Message-ID: <1464629563.05.0.822024034732.issue27157@psf.upfronthosting.co.za>


Changes by Emanuel Barry <barry at dadadata.net>:


----------
Removed message: http://bugs.python.org/msg266711

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27157>
_______________________________________

From report at bugs.python.org  Mon May 30 13:57:36 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Mon, 30 May 2016 17:57:36 +0000
Subject: [issue27157] Unhelpful error message when one calls a subclass of
 type with a custom metaclass
In-Reply-To: <1464561968.54.0.551105312321.issue27157@psf.upfronthosting.co.za>
Message-ID: <1464631056.1.0.818718504488.issue27157@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

New patch with tests and documentation. I didn't really know where to put the tests; test_types seemed reasonable to me (other option was test_metaclass).

----------
stage: test needed -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27157>
_______________________________________

From report at bugs.python.org  Mon May 30 13:57:46 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Mon, 30 May 2016 17:57:46 +0000
Subject: [issue27157] Unhelpful error message when one calls a subclass of
 type with a custom metaclass
In-Reply-To: <1464561968.54.0.551105312321.issue27157@psf.upfronthosting.co.za>
Message-ID: <1464631066.5.0.551926224081.issue27157@psf.upfronthosting.co.za>


Changes by Emanuel Barry <barry at dadadata.net>:


Added file: http://bugs.python.org/file43060/type_one_argument_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27157>
_______________________________________

From report at bugs.python.org  Mon May 30 14:53:50 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 30 May 2016 18:53:50 +0000
Subject: [issue27159] Python 3.5.1's websocket's lib crashes in event that
 internet connection stops.
In-Reply-To: <1464604698.4.0.495142476658.issue27159@psf.upfronthosting.co.za>
Message-ID: <1464634430.09.0.648934129846.issue27159@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yes, please open only single focus issues.  

websockets is not part of the standard library, so that's not appropriate for this tracker ((unless you've found an underlying bug in python, in which case report that please).

For the bytecode questions you should ask on the python-list mailing list for help.  If there actually is a feature missing in python (from what you said I don't think there is), they could help you formulate an enhancement request to file here.

I believe there's an open issue about the reload question...if not, you can open one.

----------
nosy: +r.david.murray
resolution:  -> third party
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27159>
_______________________________________

From report at bugs.python.org  Mon May 30 15:09:48 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 30 May 2016 19:09:48 +0000
Subject: [issue12691] tokenize.untokenize is broken
In-Reply-To: <1312496489.46.0.0769213514508.issue12691@psf.upfronthosting.co.za>
Message-ID: <1464635388.53.0.507514454664.issue12691@psf.upfronthosting.co.za>


R. David Murray added the comment:

Is there anything left to do here?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12691>
_______________________________________

From report at bugs.python.org  Mon May 30 15:33:24 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 30 May 2016 19:33:24 +0000
Subject: [issue12691] tokenize.untokenize is broken
In-Reply-To: <1312496489.46.0.0769213514508.issue12691@psf.upfronthosting.co.za>
Message-ID: <1464636804.37.0.833535352826.issue12691@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

If there are, I can't remember.  This was one or 7 or 8 untokenize issues with about 5 separate bugs between them.  If there are any current untokenize issues not covered by some other open issue, then a new issue should be opened.

----------
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue12691>
_______________________________________

From report at bugs.python.org  Mon May 30 16:09:36 2016
From: report at bugs.python.org (Torsten Landschoff)
Date: Mon, 30 May 2016 20:09:36 +0000
Subject: [issue24882] ThreadPoolExecutor doesn't reuse threads until #threads
 == max_workers
In-Reply-To: <1439823540.4.0.657998470812.issue24882@psf.upfronthosting.co.za>
Message-ID: <1464638976.6.0.45968562993.issue24882@psf.upfronthosting.co.za>


Torsten Landschoff added the comment:

For demonstration purposes, here is a small example specifically for Linux which shows how each request starts a new thread even though the client blocks for each result.

----------
nosy: +torsten
Added file: http://bugs.python.org/file43061/many_threads.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24882>
_______________________________________

From report at bugs.python.org  Mon May 30 16:39:57 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 30 May 2016 20:39:57 +0000
Subject: [issue18117] Missing symlink:Current after Mac OS X 3.3.2 package
 installation
In-Reply-To: <1370161783.39.0.437072519867.issue18117@psf.upfronthosting.co.za>
Message-ID: <1464640797.78.0.77866804612.issue18117@psf.upfronthosting.co.za>


R. David Murray added the comment:

Ned, can this issue be closed or is there still something to discuss here?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue18117>
_______________________________________

From report at bugs.python.org  Mon May 30 17:08:19 2016
From: report at bugs.python.org (aixtools)
Date: Mon, 30 May 2016 21:08:19 +0000
Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not
 available (e.g., AIX)
In-Reply-To: <1464401098.89.0.898951604374.issue26439@psf.upfronthosting.co.za>
Message-ID: <bdd9d6b7-8c18-4879-9d5b-c5ebb790476f@gmail.com>


aixtools added the comment:

On 28-May-16 04:04, Martin Panter wrote:
> Martin Panter added the comment:
>
> Strictly speaking, Python 2.7 never had special support for RTLD_MEMBER or find_library(). That is why I am unsure about many of these changes being done in 2.7. They seem more like new features than bug fixes. Especially once you start talking about a smart CDLL() that tests for a file and then falls back to RTLD_MEMBER.
Well, actually, within AIX I was intending to "just use" RTLD_MEMBER 
when "the string" ended in a ")" as that is the correct additional mode 
bit for an established interface dlopen(). I perhaps do not understand 
(certainly did not) the goal of CDLL(), better Lib/ctypes

As far as Python-2.7 is concerned - I would like to see it "in" because 
there is a lot of Python-2(.7) code out there that will not work without 
manageling AIX at a low level (i.e., current practice is to extract .so 
members from archives so dlopen() will be able to open them.
>
> Whether you represent an archive member as an (archive, member) tuple, or as an "archive(member)" string, or something else, it is still an extension of the API of CDLL(), and arguably also of find_library().
I would want to disagree. A string is a string, regardless of the 
characters in it. And, I have verified - if a file 
/usr/lib/libFOO.a(libFoo.so.X) exists dlopen() will open it when 
RTLD_MEMBER is not ORed into the mode.
> I think I have already tried to explain that on Linux, find_library("libm.so") is far from normal usage (although may be technically legal if there was a library called liblibm.so.so).
find_library("libm.so") is far from normal usage: again, my 
misunderstanding - I was reading as much as possible from various 
sources - and my head was spinning.
In util.py there was no "libFOO.so", only "FOO" and "libFOO" - so my 
find_library() tests are not correct. Agreed.

>
> Also, on Linux I wouldn?t recommend CDLL("libcrypt.so"), which relies on a file only intended for build time. On Debian, the glibc library <https://packages.debian.org/source/jessie/glibc> has separate packages for shared libraries (libc6) and development libraries (libc6-dev). It should be possible to run programs with libc6 installed, but without libc6-dev. Looking at the file lists for ?i386? architecture, libc6-dev includes:
>
> /usr/lib/i386-linux-gnu/libcrypt.a
> /usr/lib/i386-linux-gnu/libcrypt.so
My expectation (misconception perhaps) is that Linux uses a .a archive 
for static linking, and .so shared-library for dynamic-loading. The AIX 
loader/linker looks first in .a archives for shared libraries (when 
static is not specified) and if no member is found (member name is not 
relevant for the search, only the symbol and the object size (32 or 64 
bit)). If not found in libFOO.a then a search for a specific file is 
done libFOO.so.

An assumption of mine is: if I specified (not usual on AIX, based on my 
experience) -lc.so.6 AIX would look for an archive named libc.so.6.a 
first. If found, would look for a member in that archive. If not found 
as a .a archive and/or not found as a file at all then it will look for 
a file libFOO.so.6

>
> It symbolically links to /lib/i386-linux-gnu/libcrypt.so.1, which is provided by libc6:
>
> /lib/i386-linux-gnu/libcrypt-2.19.so
> /lib/i386-linux-gnu/libcrypt.so.1
>
> So on Debian (and with Linux in general), CDLL("libcrypt.so") may work in some cases, but you should normally use CDLL("libcrypt.so.1") instead.
Agreed - CDLL("libFOO.so") is not preferred. But, should it be refused? 
Or, if it is accepted on Linux - and works when the (symbolic) file 
exists - must it be refused on AIX? If refusing it on AIX is what it 
takes to make the patch acceptable - then code it to refuse it is.
>
> Usually people just upload a new version of the original patch (original changes, plus new changes, in one file). I think it would be too confusing looking at differences between two patches.
So, just provide the new delta between "2.7.11(.0) and what I have, not 
the changes between patches. Coming up tomorrow.

In short, my head was spinning and I thought I saw problems that are not 
meant to exist, in particular find_library("libFOO.so") - that should be 
coded to reject I guess. I would still like to let something like 
"libc.so" be creative, as libc.so will never exist, by default, on AIX. 
My guess is that is a legacy thing from AIX4. (and I think the default 
name is shr.o when using the ld flag -G to create a shared object aka 
shared library)
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue26439>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26439>
_______________________________________

From report at bugs.python.org  Mon May 30 18:09:37 2016
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 30 May 2016 22:09:37 +0000
Subject: [issue26667] Update importlib to accept pathlib.Path objects
In-Reply-To: <1459275774.9.0.416740988554.issue26667@psf.upfronthosting.co.za>
Message-ID: <1464646177.73.0.99676206773.issue26667@psf.upfronthosting.co.za>


Brett Cannon added the comment:

It's informed. I need to go through the API and see what does or does not makes sense based on PEP 519.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26667>
_______________________________________

From report at bugs.python.org  Mon May 30 18:12:56 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Mon, 30 May 2016 22:12:56 +0000
Subject: [issue23459] Linux: expose the new execveat() syscall
In-Reply-To: <1423830759.75.0.255479243543.issue23459@psf.upfronthosting.co.za>
Message-ID: <1464646376.94.0.116118813216.issue23459@psf.upfronthosting.co.za>


???? ????????? added the comment:

It is actual to me due to it's AT_EMPTY_PATH feature (I download script, verify signature, and want to run it)

See also `man 3 fexecve`

Why not to add `dir_fd=None` ?  (as in `os.rmdir()` for example).

It should be very small patch, as I think.

Reopen please.

----------
nosy: +mmarkk
type:  -> enhancement
versions: +Python 3.6 -Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23459>
_______________________________________

From report at bugs.python.org  Mon May 30 19:57:43 2016
From: report at bugs.python.org (R. David Murray)
Date: Mon, 30 May 2016 23:57:43 +0000
Subject: [issue23459] Linux: expose the new execveat() syscall
In-Reply-To: <1423830759.75.0.255479243543.issue23459@psf.upfronthosting.co.za>
Message-ID: <1464652663.15.0.205967385871.issue23459@psf.upfronthosting.co.za>


R. David Murray added the comment:

You can currently call os.execve with a file pointer.  How is that different from adding an execveat with AS_EMPTY_PATH, functionally?  I think we don't need to add this syscall, because it is intended to allow more robust implementation of fexecve, and we are already effectvely exposing fexecve.  We should be able to assume that glibc will switch to using execveat under the hood, and not worry about it ourselves.  If that's not true, then we can revisit this.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23459>
_______________________________________

From report at bugs.python.org  Mon May 30 20:08:25 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 31 May 2016 00:08:25 +0000
Subject: [issue27157] Unhelpful error message when one calls a subclass of
 type with a custom metaclass
In-Reply-To: <1464561968.54.0.551105312321.issue27157@psf.upfronthosting.co.za>
Message-ID: <1464653305.85.0.143120628625.issue27157@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Please don't mark your own patch as 'commit review'.

----------
nosy: +berker.peksag
stage: commit review -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27157>
_______________________________________

From report at bugs.python.org  Mon May 30 20:10:04 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 31 May 2016 00:10:04 +0000
Subject: [issue22331] test_io.test_interrupted_write_text() hangs on the
 buildbot FreeBSD 7.2
In-Reply-To: <1409779908.87.0.4046116696.issue22331@psf.upfronthosting.co.za>
Message-ID: <1464653404.02.0.194966576779.issue22331@psf.upfronthosting.co.za>


Martin Panter added the comment:

Thanks, that is a very good point about threads. I remember that testing tkinter leaves an internal TK or TCL thread running in the background. And I understand Free BSD delivers process signals to arbitrary threads (not necessarily the main thread).

But the FreeBSD 3.5 buildbot looks like it ran test_io in a separate process (-j4 specified). Anyway it is another possible explanation of the hang (signal delivered to wrong thread, so write() call not interrupted).

Perhaps it is better to use signal.pthread_kill() instead of os.kill() in my proposal.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22331>
_______________________________________

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: [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  Mon May 30 20:29:39 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 31 May 2016 00:29:39 +0000
Subject: [issue22331] test_io.test_interrupted_write_text() hangs on the
 buildbot FreeBSD 7.2
In-Reply-To: <1409779908.87.0.4046116696.issue22331@psf.upfronthosting.co.za>
Message-ID: <1464654579.61.0.0135150756106.issue22331@psf.upfronthosting.co.za>


Martin Panter added the comment:

Found the same hang on the 3.6 branch, which was definitely running separate processes:

http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.x%203.x/builds/4210/steps/test/logs/stdio
== CPython 3.6.0a0 (default:ed6345cb08ab, Apr 29 2016, 18:35:36) [GCC 4.2.1 20070831 patched [FreeBSD]]
Run tests in parallel using 4 child processes

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22331>
_______________________________________

From report at bugs.python.org  Mon May 30 20:42:10 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 31 May 2016 00:42:10 +0000
Subject: [issue27157] Unhelpful error message when one calls a subclass of
 type with a custom metaclass
In-Reply-To: <1464561968.54.0.551105312321.issue27157@psf.upfronthosting.co.za>
Message-ID: <1464655330.09.0.252367720564.issue27157@psf.upfronthosting.co.za>


R. David Murray added the comment:

Berker, I don't mind if people mark their own patches for commit review *when they think it is ready for commit*.  (Just as with reviewers, if they start being consistently right, they are ready for commit privs :)  However, a non-committer setting a patch to commit review is waving a hand for attention from a core dev, and that should only be done *after* a patch has been *reviewed* and judged ready for final review before commit.

(I broke my own rule the other day and got in trouble, though...I set a patch to commit review to remind myself to review it rather than because I thought it was commit ready already, and it got committed...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27157>
_______________________________________

From report at bugs.python.org  Mon May 30 20:50:18 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 31 May 2016 00:50:18 +0000
Subject: [issue27161] Confusing exception in Path().with_name
In-Reply-To: <1464654135.6.0.522820749972.issue27161@psf.upfronthosting.co.za>
Message-ID: <1464655818.26.0.177939766892.issue27161@psf.upfronthosting.co.za>


R. David Murray added the comment:

I don't think so.  Python uses duck typing, and one of the consequences of that is you can get weird errors if you pass in a type that sort-of-works but doesn't really.  Arbitrarily restricting the input type is not something we do (that's what the whole static type checking thing is about...doing that as an external lint process.)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27161>
_______________________________________

From report at bugs.python.org  Mon May 30 21:21:29 2016
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 31 May 2016 01:21:29 +0000
Subject: [issue22558] Missing doc links to source code
In-Reply-To: <1412514337.47.0.069385783283.issue22558@psf.upfronthosting.co.za>
Message-ID: <1464657689.97.0.115908408772.issue22558@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
nosy:  -gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22558>
_______________________________________

From report at bugs.python.org  Mon May 30 21:59:01 2016
From: report at bugs.python.org (Berker Peksag)
Date: Tue, 31 May 2016 01:59:01 +0000
Subject: [issue27157] Unhelpful error message when one calls a subclass of
 type with a custom metaclass
In-Reply-To: <1464561968.54.0.551105312321.issue27157@psf.upfronthosting.co.za>
Message-ID: <1464659941.41.0.862251598289.issue27157@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the patch, Emanuel. I left some comments about Sphinx markup on Rietveld.

> Berker, I don't mind if people mark their own patches for commit review *when they think it is ready for commit*.

Is there any person who really thinks that their own patch is *not* ready for commit review? :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27157>
_______________________________________

From report at bugs.python.org  Mon May 30 22:13:04 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Tue, 31 May 2016 02:13:04 +0000
Subject: [issue27157] Unhelpful error message when one calls a subclass of
 type with a custom metaclass
In-Reply-To: <1464561968.54.0.551105312321.issue27157@psf.upfronthosting.co.za>
Message-ID: <1464660784.7.0.609554834591.issue27157@psf.upfronthosting.co.za>


Emanuel Barry added the comment:

New patch with Berker's comments. I'm really not used to Sphinx markup so thanks for that!

> Is there any person who really thinks that their own patch is *not* ready for commit review? :)

Partial patches aren't that uncommon in some projects. I also sometimes don't trust that I got everything right (especially if it's in a very large codebase like CPython), and having a few more pair of eyes taking a look at it helps.

----------
Added file: http://bugs.python.org/file43062/type_one_argument_4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27157>
_______________________________________

From report at bugs.python.org  Mon May 30 22:58:11 2016
From: report at bugs.python.org (Ethan Furman)
Date: Tue, 31 May 2016 02:58:11 +0000
Subject: [issue27161] Confusing exception in Path().with_name
In-Reply-To: <1464654135.6.0.522820749972.issue27161@psf.upfronthosting.co.za>
Message-ID: <1464663491.7.0.482817145245.issue27161@psf.upfronthosting.co.za>


Ethan Furman added the comment:

I think the request is to raise a single PathlibError instead of the broad range of possible errors.  Something like:

try:
   blah blah
except TypeError as e:
   raise PathlibError(str(e))

Since pathlib is a high level library this seems appropriate.

----------
nosy: +ethan.furman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27161>
_______________________________________

From report at bugs.python.org  Mon May 30 23:06:14 2016
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 31 May 2016 03:06:14 +0000
Subject: [issue27113] sqlite3 connect parameter "check_same_thread" not
 documented
In-Reply-To: <1464125789.84.0.570004715823.issue27113@psf.upfronthosting.co.za>
Message-ID: <1464663974.78.0.229948632909.issue27113@psf.upfronthosting.co.za>


Senthil Kumaran added the comment:

Thanks for the review. Made it both singular in the updated patch.

* As for why the default value was chosen to be to True, I think, the reason is pysqlite, from sqlite3 module was derived, did not support this option when it was introduced. I still do not find that in pysqlite external library.

That being said, if we want to change the default to looking into multiple threads, we could attempt that change and introduce it. This will be a separate feature request ticket.

----------
Added file: http://bugs.python.org/file43063/issue27113-rev2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27113>
_______________________________________

From report at bugs.python.org  Tue May 31 00:01:55 2016
From: report at bugs.python.org (Ben Kane)
Date: Tue, 31 May 2016 04:01:55 +0000
Subject: [issue27155] '-' sign typo in example
In-Reply-To: <1464549329.65.0.961898669229.issue27155@psf.upfronthosting.co.za>
Message-ID: <1464667315.96.0.496402660975.issue27155@psf.upfronthosting.co.za>


Ben Kane added the comment:

https://docs.python.org/3/library/subprocess.html#subprocess.Popen.returncode

does mention the negativeness about returncode in conjunction with POSIX signals. It would be helpful to mention this Python-specific (I think) behavior in a comment. 
However, returncode can also be set by poll() and wait(), which can also return errors. In the more realistic example, I would appreciate code that handles those errors as well (a check for returncode > 0), or a comment detailing that other errors aren't handled. I copied that code into mine, and didn't consider those cases initially, because "realistic" was in the description.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27155>
_______________________________________

From report at bugs.python.org  Tue May 31 00:18:27 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 31 May 2016 04:18:27 +0000
Subject: [issue27161] Confusing exception in Path().with_name
In-Reply-To: <1464654135.6.0.522820749972.issue27161@psf.upfronthosting.co.za>
Message-ID: <1464668307.91.0.261770291425.issue27161@psf.upfronthosting.co.za>


R. David Murray added the comment:

Again, I don't think so.  We don't generally wrap TypeErrors or ValueErrors.  On the other hand, if the try/except can *add* additional contextual information about the error, it might be worthwhile.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27161>
_______________________________________

From report at bugs.python.org  Tue May 31 01:44:34 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Tue, 31 May 2016 05:44:34 +0000
Subject: [issue23459] Linux: expose the new execveat() syscall
In-Reply-To: <1423830759.75.0.255479243543.issue23459@psf.upfronthosting.co.za>
Message-ID: <1464673474.12.0.652036135674.issue23459@psf.upfronthosting.co.za>


???? ????????? added the comment:

> we are already effectvely exposing fexecve

Did not found neither os.fexecve() nor os.execve() documentation about this. How I can use glibc's fexecve() ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23459>
_______________________________________

From report at bugs.python.org  Tue May 31 01:57:24 2016
From: report at bugs.python.org (Alecsandru Patrascu)
Date: Tue, 31 May 2016 05:57:24 +0000
Subject: [issue26359] CPython build options for out-of-the box performance
In-Reply-To: <1455445693.01.0.984013993837.issue26359@psf.upfronthosting.co.za>
Message-ID: <1464674244.89.0.888311144058.issue26359@psf.upfronthosting.co.za>


Alecsandru Patrascu added the comment:

Hello Brett, I saw that there was no other activity on this issue so far. Can you please update this, as I do not have rights?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26359>
_______________________________________

From report at bugs.python.org  Tue May 31 02:03:35 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 31 May 2016 06:03:35 +0000
Subject: [issue23459] Linux: expose the new execveat() syscall
In-Reply-To: <1423830759.75.0.255479243543.issue23459@psf.upfronthosting.co.za>
Message-ID: <1464674615.55.0.476200582117.issue23459@psf.upfronthosting.co.za>


R. David Murray added the comment:

By passing an fd to os.execve.  Under the hood it calls fexecve.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23459>
_______________________________________

From report at bugs.python.org  Tue May 31 02:08:43 2016
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Tue, 31 May 2016 06:08:43 +0000
Subject: [issue23459] Linux: expose the new execveat() syscall
In-Reply-To: <1423830759.75.0.255479243543.issue23459@psf.upfronthosting.co.za>
Message-ID: <1464674923.02.0.249714375522.issue23459@psf.upfronthosting.co.za>


???? ????????? added the comment:

Sorry, but still did not found that in official documentation. Pass fd in place of `path ` ?

https://docs.python.org/3.6/library/os.html#os.execve

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23459>
_______________________________________

From report at bugs.python.org  Tue May 31 02:35:50 2016
From: report at bugs.python.org (Antony Lee)
Date: Tue, 31 May 2016 06:35:50 +0000
Subject: [issue27161] Confusing exception in Path().with_name
In-Reply-To: <1464654135.6.0.522820749972.issue27161@psf.upfronthosting.co.za>
Message-ID: <1464676550.76.0.531878376267.issue27161@psf.upfronthosting.co.za>


Antony Lee added the comment:

Actually, a simpler approach may be the attached patch (pathlib-splitroot.patch), in which case the exception is

    AttributeError: 'dict' object has no attribute 'lstrip'

which is pretty commonly seen when a wrong type is passed to a function.

(Note that it is already possible to trigger this exception by passing in `{0: "/"}` so it's no worse than before)

----------
keywords: +patch
Added file: http://bugs.python.org/file43064/pathlib-splitroot.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27161>
_______________________________________

From report at bugs.python.org  Tue May 31 02:46:47 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 31 May 2016 06:46:47 +0000
Subject: [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:57:00 2016
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 31 May 2016 06:57:00 +0000
Subject: [issue27162] Add idlelib.interface module
In-Reply-To: <1464677206.97.0.125904884409.issue27162@psf.upfronthosting.co.za>
Message-ID: <1464677820.52.0.944231378509.issue27162@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
components: +IDLE -ctypes

_______________________________________
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: [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 03:03:53 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 31 May 2016 07:03:53 +0000
Subject: [issue27163] IDLE entry for What's New in Python 3.6
In-Reply-To: <1464677885.83.0.244887022976.issue27163@psf.upfronthosting.co.za>
Message-ID: <1464678233.76.0.567012614457.issue27163@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
dependencies: +Add idlelib.interface module, Idle: add ttk widgets as an option
priority: low -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27163>
_______________________________________

From report at bugs.python.org  Tue May 31 03:04:27 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 31 May 2016 07:04:27 +0000
Subject: [issue27163] IDLE entry for What's New in Python 3.6
In-Reply-To: <1464677885.83.0.244887022976.issue27163@psf.upfronthosting.co.za>
Message-ID: <1464678267.74.0.575685632385.issue27163@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
components: +Documentation, IDLE -ctypes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27163>
_______________________________________

From report at bugs.python.org  Tue May 31 03:24:11 2016
From: report at bugs.python.org (A. Skrobov)
Date: Tue, 31 May 2016 07:24:11 +0000
Subject: [issue26526] In parsermodule.c,
 replace over 2KLOC of hand-crafted validation code, with a DFA
In-Reply-To: <1457600551.84.0.318395917649.issue26526@psf.upfronthosting.co.za>
Message-ID: <1464679451.76.0.9188124138.issue26526@psf.upfronthosting.co.za>


A. Skrobov added the comment:

Thank you Fred for your review!

I don't have commit access myself; can anybody please commit it for me?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26526>
_______________________________________

From report at bugs.python.org  Tue May 31 03:24:18 2016
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 31 May 2016 07:24:18 +0000
Subject: [issue27148] Make VENV_DIR relative to Script directory
In-Reply-To: <1464494255.1.0.144712628992.issue27148@psf.upfronthosting.co.za>
Message-ID: <1464679458.42.0.438290797399.issue27148@psf.upfronthosting.co.za>


Vinay Sajip added the comment:

Thanks for the suggestion, but I don't propose to change the way things work in this area, for the following reasons:

1. pyvenv tries to use the same directory layout/location of scripts as virtualenv does. This allows users who are used to virtualenv to have less to think about when switching to pyvenv.
2. Virtual environments (venvs) aren't meant to be movable. Scripts installed into virtual environments have the venv's absolute path hard-coded into their shebang. This is true for both virtualenv and pyvenv. However, a venv can always be created at another location and have the same stuff installed into it, and the old venv discarded.
3. Making changes like this would not be backwards compatible - they would probably break existing code which relies on a common layout between virtualenv and pyvenv, or the existing relative locations of script files.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27148>
_______________________________________

From report at bugs.python.org  Tue May 31 03:31:36 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 31 May 2016 07:31:36 +0000
Subject: [issue24759] Idle: require tk 8.5 and ttk widgets,
 and drop unneeded code.
In-Reply-To: <1438294715.65.0.966229055462.issue24759@psf.upfronthosting.co.za>
Message-ID: <1464679896.24.0.466546781054.issue24759@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

In msg265349, Ned stated that running IDLE with 8.4 should no longer be a requirement in 3.6.  Hence the revised title and restriction to 3.6.

Serhiy, I read the code in your #24750 patch.  Should it not be enough to first check tkinter.Tkversion >= 8.5 before trying to import ttk. And is testing ttk then needed?  Is it possible for ttk to not work in 8.5/6)?

Tkversion (or a refinement thereof) is already checked in colorizer, config, editor, macosx, and pyshell.  With one check on startup, existing check can be eliminated, along with code only for older versions.

----------
title: Idle: add ttk widgets as an option -> Idle: require tk 8.5 and ttk widgets, and drop unneeded code.
versions:  -Python 2.7, Python 3.4, Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24759>
_______________________________________

From report at bugs.python.org  Tue May 31 04:49:02 2016
From: report at bugs.python.org (Julien)
Date: Tue, 31 May 2016 08:49:02 +0000
Subject: [issue26546] Provide translated french translation on docs.python.org
In-Reply-To: <1457794223.79.0.618185263259.issue26546@psf.upfronthosting.co.za>
Message-ID: <1464684542.75.0.48222571327.issue26546@psf.upfronthosting.co.za>


Julien added the comment:

Hi,

The thread on python-ideas did not raised a long conversation, I don't think many english speaking people are interested in this subject, and non-english people are not in this list.

BWT, we translated a lot since march: translated 23% of the strings (versus 14% in march), and we'd like to serve a greater number of readers by hitting docs.python.org/fr/, so this messages is a ... bump ?

If I can help in anything, don't hesitate, but I think there's almost nothing left to, I already provided a patch for https://github.com/python/docsbuild-scripts to build the internationalized versions of documentation, tested it as far as I can without knowing your production servers by replicating the same paths on my test machine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26546>
_______________________________________

From report at bugs.python.org  Tue May 31 05:00:57 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 May 2016 09:00:57 +0000
Subject: [issue26546] Provide translated french translation on docs.python.org
In-Reply-To: <1457794223.79.0.618185263259.issue26546@psf.upfronthosting.co.za>
Message-ID: <1464685257.26.0.610775522798.issue26546@psf.upfronthosting.co.za>


STINNER Victor added the comment:

About the URL, we are only talking about 4 languages:

* english
* french
* japanese
* spanish

For docs.python.org.ar, I don't know if it's "spanish" or "spanish of Argentina"?

For a technical documentation, I don't expect to have a flavor of the docuemntation for the USA, UK, Australia, etc. It's the same for french, I only expect one french version. Same for japanese. For spanish, maybe we might support to have other flavors?

We can take a look at PHP documentation since they already support a wide choice of languages. English is "en", french is "fr", japanese is "jp", spanish is "es". Only Brazilian Portuguese uses "pt_BR".

PHP uses the URL http://php.net/manual/<language code>/

I suggest to make english "implicit", the default, and don't break existing URLs since they are now hardcoded in many books, many websites, etc. I don't think that it's worth to add "/en/" and add many redirection pages.

What do you think?

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26546>
_______________________________________

From report at bugs.python.org  Tue May 31 05:24:38 2016
From: report at bugs.python.org (SilentGhost)
Date: Tue, 31 May 2016 09:24:38 +0000
Subject: [issue27145] long_add and long_sub might return a new int where
 &small_ints[x] could be returned
In-Reply-To: <1464451117.45.0.85462287723.issue27145@psf.upfronthosting.co.za>
Message-ID: <1464686678.63.0.4620044805.issue27145@psf.upfronthosting.co.za>


Changes by SilentGhost <ghost.adh at runbox.com>:


----------
nosy: +haypo, rhettinger
stage:  -> patch review
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27145>
_______________________________________

From report at bugs.python.org  Tue May 31 05:28:20 2016
From: report at bugs.python.org (Nofar Schnider)
Date: Tue, 31 May 2016 09:28:20 +0000
Subject: [issue25548] Show the address in the repr for class objects
In-Reply-To: <1446576011.58.0.372024983976.issue25548@psf.upfronthosting.co.za>
Message-ID: <1464686900.88.0.187679043561.issue25548@psf.upfronthosting.co.za>


Changes by Nofar Schnider <nofarsch at gmail.com>:


----------
nosy: +Nofar Schnider

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25548>
_______________________________________

From report at bugs.python.org  Tue May 31 05:39:00 2016
From: report at bugs.python.org (Franklin? Lee)
Date: Tue, 31 May 2016 09:39:00 +0000
Subject: [issue26632] __all__ decorator
In-Reply-To: <1458786797.31.0.0749407715279.issue26632@psf.upfronthosting.co.za>
Message-ID: <1464687540.12.0.883124945696.issue26632@psf.upfronthosting.co.za>


Franklin? Lee added the comment:

BIKESHEDDING

Here is another concern with decorators and `.__module__` (or `inspect.getmodule`). (Or is it the original concern?)

If an earlier decorator creates a wrapper and doesn't set .__module__, you'll make the function public in the wrong module.

    @public
    @bad_wrapper
    def f(...): ...


IMO, the correct solution is a new stdlib function, to get the currently-loading module. You wouldn't need explicit frame hacking, and it will be portable between different Python implementations because each implementation will have to define it correctly.

The problem with this solution is the lack of other usecases for such a function, though maybe someone in python-ideas can think of one.

Candidate owners: sys, importlib.

Candidate names:
- sys.getloadingmodule()
- importlib.currentimport()
- importlib.???()

Effect:
- Returns the "innermost" loading module. If no module is loading, returns None?
- In a thread, return the module being loaded in that thread (possibly None, even if other threads are loading modules).
- (I don't know what I'm talking about:) If a Python implementation uses multithreaded loading, each thread whose result could immediately be loaded into the module's namespace (i.e. it's close to the "surface" of the load) is considered to be loading that module.
- Needs to handle re-imports, such as from `importlib.reload`.

Other solutions include:
- Require explicit `@public(__all__)` (or `__module__`)
- Special `super()`-like treatment of `public` which automatically inserts the `__all__` (or whatever).
- Hope that bad wrappers don't come up.


----

I think nonexistence of module.__all__ should be an error.

The behavior with a module with __all__ is very different from one without, so I think that if you want your module to have __all__, you should be required to create it, even if it's empty.

Assuming that __all__ is, by convention, always near the top, someone reading your code would know whether the first dozen or so functions are part of the public interface, without searching for `@public`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26632>
_______________________________________

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: [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:03:02 2016
From: report at bugs.python.org (Julien)
Date: Tue, 31 May 2016 10:03:02 +0000
Subject: [issue26546] Provide translated french translation on docs.python.org
In-Reply-To: <1457794223.79.0.618185263259.issue26546@psf.upfronthosting.co.za>
Message-ID: <1464688982.26.0.635019104143.issue26546@psf.upfronthosting.co.za>


Julien added the comment:

> About the URL, we are only talking about 4 languages

Yes, and other are clearly not ready to be merged, I still don't know if they want it to happen soon.

> For docs.python.org.ar, I don't know if it's "spanish" or "spanish of Argentina"?

Same conclusion: I don't know either, but let them decide. In all cases, we'll not merge them until they ask for it, so, probably not even this year. Let's do things one by one, showing the way. (Personally I think we may propose them /es/, and if a es_ES version shows up, move `/es/` to `/es-ar/` and give `/es/` to es_ES, but that may just never happen...).

> For a technical documentation, I don't expect to have a flavor of the docuemntation [...] English is "en", french is "fr", japanese is "jp", spanish is "es". Only Brazilian Portuguese uses "pt_BR".

Yes [my proposition](https://mail.python.org/pipermail/python-ideas/2016-March/038879.html) has a whole paragraph about "Dropping the default locale of a language". Around the same subject, it's still undecided if we use a dash (IETF format) or an underscore (gettext format) to separate language and locale, but as we only have "fr" from now, we don't really have to decide today. We'll have to decide when we'll merge "pt-br" which does not even exists (one of some few languages having a "mandatory locale part").

> I suggest to make english "implicit", the default, and don't break existing URLs

+1, we do not need to break anything, let's just don't add `/en/` for "upstream" documentation, that's in fact what my proposed patch does.

> What do you think?

Look like we agree on all points.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26546>
_______________________________________

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: [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 06:33:32 2016
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 31 May 2016 10:33:32 +0000
Subject: [issue27164] zlib can't decompress DEFLATE using shared dictionary
In-Reply-To: <1464687663.75.0.126366287594.issue27164@psf.upfronthosting.co.za>
Message-ID: <1464690812.19.0.792517412982.issue27164@psf.upfronthosting.co.za>


Changes by Xiang Zhang <angwerzx at 126.com>:


----------
nosy: +xiang.zhang

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27164>
_______________________________________

From report at bugs.python.org  Tue May 31 06:59:35 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 31 May 2016 10:59:35 +0000
Subject: [issue24291] Many servers (wsgiref, http.server,
 etc) can truncate large output blobs
In-Reply-To: <1432671481.51.0.762064908488.issue24291@psf.upfronthosting.co.za>
Message-ID: <1464692375.03.0.604544162198.issue24291@psf.upfronthosting.co.za>


Martin Panter added the comment:

Here is a patch for just the wsgiref module, which I plan to commit in time for 3.5.2. I also updated the test case to avoid hanging due to a (theoretical) race with how signal handling works.

----------
Added file: http://bugs.python.org/file43066/wsgiref-only.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24291>
_______________________________________

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: [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 08:15:29 2016
From: report at bugs.python.org (Mirko Dziadzka)
Date: Tue, 31 May 2016 12:15:29 +0000
Subject: [issue26556] Update expat to 2.2.1
In-Reply-To: <1457951495.3.0.910401967595.issue26556@psf.upfronthosting.co.za>
Message-ID: <1464696929.86.0.29576036864.issue26556@psf.upfronthosting.co.za>


Changes by Mirko Dziadzka <mirko.dziadzka at gmail.com>:


----------
nosy: +mirko.dziadzka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26556>
_______________________________________

From report at bugs.python.org  Tue May 31 08:36:12 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Tue, 31 May 2016 12:36:12 +0000
Subject: [issue27166] interesting info
Message-ID: <1464698172.85.0.52327400994.issue27166@psf.upfronthosting.co.za>


Changes by Emanuel Barry <barry at dadadata.net>:


----------
Removed message: http://bugs.python.org/msg266751

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27166>
_______________________________________

From report at bugs.python.org  Tue May 31 08:36:31 2016
From: report at bugs.python.org (Emanuel Barry)
Date: Tue, 31 May 2016 12:36:31 +0000
Subject: [issue27166] interesting info
Message-ID: <1464698191.08.0.0215601692258.issue27166@psf.upfronthosting.co.za>


Changes by Emanuel Barry <barry at dadadata.net>:


----------
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27166>
_______________________________________

From report at bugs.python.org  Tue May 31 08:40:00 2016
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 31 May 2016 12:40:00 +0000
Subject: [issue27145] long_add and long_sub might return a new int where
 &small_ints[x] could be returned
In-Reply-To: <1464451117.45.0.85462287723.issue27145@psf.upfronthosting.co.za>
Message-ID: <1464698400.85.0.440708712636.issue27145@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at gmail.com>:


----------
nosy: +yselivanov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27145>
_______________________________________

From report at bugs.python.org  Tue May 31 09:19:27 2016
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 31 May 2016 13:19:27 +0000
Subject: [issue27166] Spam
Message-ID: <1464700767.07.0.728037178103.issue27166@psf.upfronthosting.co.za>


Changes by Zachary Ware <zachary.ware at gmail.com>:


----------
nosy:  -Rogi
title: interesting info -> Spam

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27166>
_______________________________________

From report at bugs.python.org  Tue May 31 09:51:44 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 31 May 2016 13:51:44 +0000
Subject: [issue16182] readline: Wrong tab completion scope indices in Unicode
 terminals
In-Reply-To: <1349813384.06.0.615857426211.issue16182@psf.upfronthosting.co.za>
Message-ID: <1464702704.36.0.814796487919.issue16182@psf.upfronthosting.co.za>


Martin Panter added the comment:

Attached patch adds a possible test, and fixes the truncation problem I mentioned above.

I tried testing set_completer_delims() with a UTF-8 locale, but I suspect Gnu Readline does not support it. I called set_completer_delims("\xF6"), which encodes as C3 B6, but it seems to be breaking any UTF-8 sequence in half at a C3 byte. In other words, it is treating the delimiter list as a list of bytes, not code points. So I changed to an ASCII delimiter.

----------
Added file: http://bugs.python.org/file43067/readline_locale.v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16182>
_______________________________________

From report at bugs.python.org  Tue May 31 09:52:46 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 31 May 2016 13:52:46 +0000
Subject: [issue16182] readline: Wrong tab completion scope indices in Unicode
 terminals
In-Reply-To: <1349813384.06.0.615857426211.issue16182@psf.upfronthosting.co.za>
Message-ID: <1464702766.69.0.557195871969.issue16182@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


Removed file: http://bugs.python.org/file43067/readline_locale.v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16182>
_______________________________________

From report at bugs.python.org  Tue May 31 09:53:07 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 31 May 2016 13:53:07 +0000
Subject: [issue16182] readline: Wrong tab completion scope indices in Unicode
 terminals
In-Reply-To: <1349813384.06.0.615857426211.issue16182@psf.upfronthosting.co.za>
Message-ID: <1464702787.91.0.457082969146.issue16182@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


Added file: http://bugs.python.org/file43068/readline_locale.v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue16182>
_______________________________________

From report at bugs.python.org  Tue May 31 10:55:05 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 31 May 2016 14:55:05 +0000
Subject: [issue23459] Linux: expose the new execveat() syscall
In-Reply-To: <1423830759.75.0.255479243543.issue23459@psf.upfronthosting.co.za>
Message-ID: <1464706505.58.0.917594414969.issue23459@psf.upfronthosting.co.za>


R. David Murray added the comment:

Yes, last paragraph of that section.  It doesn't mention fexecve explicitly because it doesn't need to, the functionality is what matters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue23459>
_______________________________________

From report at bugs.python.org  Tue May 31 11:03:10 2016
From: report at bugs.python.org (A. Skrobov)
Date: Tue, 31 May 2016 15:03:10 +0000
Subject: [issue26526] In parsermodule.c,
 replace over 2KLOC of hand-crafted validation code, with a DFA
In-Reply-To: <1457600551.84.0.318395917649.issue26526@psf.upfronthosting.co.za>
Message-ID: <1464706990.3.0.0744786289874.issue26526@psf.upfronthosting.co.za>


Changes by A. Skrobov <tyomitch at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file43069/issue26526_16704_63395.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26526>
_______________________________________

From report at bugs.python.org  Tue May 31 11:07:19 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 31 May 2016 15:07:19 +0000
Subject: [issue27161] Confusing exception in Path().with_name
In-Reply-To: <1464654135.6.0.522820749972.issue27161@psf.upfronthosting.co.za>
Message-ID: <1464707239.52.0.0961797386853.issue27161@psf.upfronthosting.co.za>


R. David Murray added the comment:

It's a resaonable approach, but I question if the gain is worth the chance of introducing bugs (behavior changes...for example, a None argument would be handled differently by the patch).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27161>
_______________________________________

From report at bugs.python.org  Tue May 31 12:04:58 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 31 May 2016 16:04:58 +0000
Subject: [issue26546] Provide translated french translation on docs.python.org
In-Reply-To: <1457794223.79.0.618185263259.issue26546@psf.upfronthosting.co.za>
Message-ID: <1464710698.13.0.247709460926.issue26546@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

>From what I know of regional and country variations in spanish, the main grammatical differences are in usages, such as the informal plural 2nd person, that need not appear in a techical manual.  I don't know about recently acquired technical terms.  From reading pyar for awhile, I also know that it has participants from all over latin america, so I suspect that their translation is not necessarily Argentina-specific.  Conclusion: we (pydev) should not worry until there is an actual conflict from competing translations.

The patch has this table:

+               # version, target, isdev
+               ('3.4', WWWROOT + "/3.4", False),
+               ('3.5', WWWROOT + "/3.5", False),
+               ('3.6', WWWROOT + "/3.6", True),
+               ('2.7', WWWROOT + "/2.7", False)

Why is 3.4 included, given that it now has the same status as 3.3?
Would it not be easier to default to False and only list 3.6?
Is it because you maintain separate branches for different 3.x branches?  Given the presence of Version Changed and Version Added paragraphs, that is almost unnecessary.  (Not having Version Deleted items is the main reason they might be.)

Is/are the main author/maintainer(s) of build_docs.py already nosy on the issue, to review?  I cannot even though at least mildly interested.
(The disconnect between interest and technical expertise is part of the problem with translation issues.)

There is no Rietveld review link for the patch.  I do not know if it is the form of the patch or the target file.  Viktor, do you?  If not, someone on the core-mentorship list would.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26546>
_______________________________________

From report at bugs.python.org  Tue May 31 12:10:36 2016
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 31 May 2016 16:10:36 +0000
Subject: [issue26632] @public - an __all__ decorator
In-Reply-To: <1458786797.31.0.0749407715279.issue26632@psf.upfronthosting.co.za>
Message-ID: <1464711036.65.0.247122663594.issue26632@psf.upfronthosting.co.za>


Barry A. Warsaw added the comment:

I'm going to go ahead and close this issue.  There wasn't much positive reception to @public in the Pycon 2016 language summit (where I presented it as a lightning talk).

https://gitlab.com/warsaw/public

Some of the other ideas for changes to Python may still be valid, but they would be best discussed under a new issue.

----------
resolution:  -> wont fix
status: open -> closed
title: __all__ decorator -> @public - an __all__ decorator

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26632>
_______________________________________

From report at bugs.python.org  Tue May 31 12:20:30 2016
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 31 May 2016 16:20:30 +0000
Subject: [issue26546] Provide translated french translation on docs.python.org
In-Reply-To: <1457794223.79.0.618185263259.issue26546@psf.upfronthosting.co.za>
Message-ID: <1464711630.29.0.182215757866.issue26546@psf.upfronthosting.co.za>


Zachary Ware added the comment:

I think you should submit this as a PR against docsbuild-scripts, it will be easier to review there.

----------
nosy: +zach.ware

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26546>
_______________________________________

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: [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 12:35:01 2016
From: report at bugs.python.org (Julien)
Date: Tue, 31 May 2016 16:35:01 +0000
Subject: [issue26546] Provide translated french translation on docs.python.org
In-Reply-To: <1457794223.79.0.618185263259.issue26546@psf.upfronthosting.co.za>
Message-ID: <1464712501.85.0.519007430633.issue26546@psf.upfronthosting.co.za>


Julien added the comment:

> From what I know of regional and country variations in spanish, [...] we (pydev) should not worry until there is an actual conflict from competing translations.

Totally agree.

> The patch has this table:

> +               # version, target, isdev
> +               ('3.4', WWWROOT + "/3.4", False),
> +               ('3.5', WWWROOT + "/3.5", False),
> +               ('3.6', WWWROOT + "/3.6", True),
> +               ('2.7', WWWROOT + "/2.7", False)

Yes, it sticks to the current style: https://github.com/python/docsbuild-scripts/blob/master/build_docs.py#L33

> Why is 3.4 included, given that it now has the same status as 3.3?

What do you mean with "the same status" ? From my translator point of view, they still diverges, like in `Doc/library/zlib.rst:233`:

< "If the optional parameter *max_length* is supplied then the return value "
---
> "If the optional parameter *max_length* is non-zero then the return value "

And I don't think we can rely on certain releases being theorically identical to others, it look like an exception, look like it's not always true. I still prefer having a [clear tree of versions](https://github.com/AFPy/python_doc_fr) but we're (humans) only translating the latest version, we have scripts replicating our work to others.

Yet, if you tell me that there's work ongoing (that I clearly missed) to have every documentations, like by major version, converge to single one, with just some paragraphs added, it may simplify my hierarchy.

> Would it not be easier to default to False and only list 3.6?

Again I stick to the current style of the script, so ease its reading as a whole, but I agree, if we change it, let change it in another commit?

> Is it because you maintain separate branches for different 3.x branches?  Given the presence of Version Changed and Version Added paragraphs, that is almost unnecessary.  (Not having Version Deleted items is the main reason they might be.)

I am not aware of "Version Added" and "Version Changed" paragraphs, I understand that this is a policy to only add new paragraphs and never modify them inside the `3` major version ? This is cool for me, as said in my last paragraph, it may reduce the number of versionned `.po`, but it will not change the human workload (script replicating between po files ...).

> Is/are the main author/maintainer(s) of build_docs.py already nosy on the issue, to review?

Yes, I soon `nosy`ed Benjamin Peterson, look like he's the father of this script, if we trust commits here: https://github.com/python/docsbuild-scripts/commits/master

I even mailed him personally to speak about it (and he even replied once), but he's probably highly busy, and this is something I can understand. So here is my call on the issue to try to move this issue forward (I try to push this project less than once a month, to avoid buzzing everyone ears with this non-critical issue...).

> I cannot even though at least mildly interested. (The disconnect between interest and technical expertise is part of the problem with translation issues.)

Yes I also fully understand that the french translation of the documentation is not a point of interest for most of you upstream ^^ don't worry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26546>
_______________________________________

From report at bugs.python.org  Tue May 31 12:43:02 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 31 May 2016 16:43:02 +0000
Subject: [issue27167] subprocess reports signal as negative exit status,
 not documented
In-Reply-To: <1464712500.44.0.979958949461.issue27167@psf.upfronthosting.co.za>
Message-ID: <1464712982.79.0.141748010466.issue27167@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

I'll take this as a documentation update for 3.5 and a feature request for better message text in 3.6.

----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith
versions: +Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27167>
_______________________________________

From report at bugs.python.org  Tue May 31 12:52:44 2016
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 31 May 2016 16:52:44 +0000
Subject: [issue26700] Make digest_size a class variable
In-Reply-To: <1459929550.45.0.656140899063.issue26700@psf.upfronthosting.co.za>
Message-ID: <1464713564.81.0.150807080265.issue26700@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

+cc Christian Heimes: do the upcoming standard hash functions amenable to a constant class attribute digest_size?

Are any of the expected future hashes variable length from a single class / constructor function?

----------
nosy: +christian.heimes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26700>
_______________________________________

From report at bugs.python.org  Tue May 31 13:01:22 2016
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 31 May 2016 17:01:22 +0000
Subject: [issue26700] Make digest_size a class variable
In-Reply-To: <1459929550.45.0.656140899063.issue26700@psf.upfronthosting.co.za>
Message-ID: <1464714082.5.0.251540780587.issue26700@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Not all hash functions have a fixed digest size, e.g. blake2 is a variable length hash algorithm. https://pythonhosted.org/pyblake2/examples.html#using-different-digest-sizes How about a new class attribute default_digest_size?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26700>
_______________________________________

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: [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:26:31 2016
From: report at bugs.python.org (Julien)
Date: Tue, 31 May 2016 18:26:31 +0000
Subject: [issue26546] Provide translated french translation on docs.python.org
In-Reply-To: <1457794223.79.0.618185263259.issue26546@psf.upfronthosting.co.za>
Message-ID: <1464719191.22.0.492307988366.issue26546@psf.upfronthosting.co.za>


Julien added the comment:

@zach.ware done: https://github.com/python/docsbuild-scripts/pull/1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26546>
_______________________________________

From report at bugs.python.org  Tue May 31 14:27:49 2016
From: report at bugs.python.org (Antony Lee)
Date: Tue, 31 May 2016 18:27:49 +0000
Subject: [issue27161] Confusing exception in Path().with_name
In-Reply-To: <1464654135.6.0.522820749972.issue27161@psf.upfronthosting.co.za>
Message-ID: <1464719269.16.0.336599514074.issue27161@psf.upfronthosting.co.za>


Antony Lee added the comment:

Would it?  Note that splitroot is not public, and some quick tests did not show any other behavior difference from the public API side.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27161>
_______________________________________

From report at bugs.python.org  Tue May 31 14:34:38 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 May 2016 18:34:38 +0000
Subject: [issue27161] Confusing exception in Path().with_name
In-Reply-To: <1464654135.6.0.522820749972.issue27161@psf.upfronthosting.co.za>
Message-ID: <1464719678.01.0.253436743894.issue27161@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

The "part and part[0] == sep" check is here for speed. pathlib-splitroot.patch removes this optimization.

----------
nosy: +pitrou, serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27161>
_______________________________________

From report at bugs.python.org  Tue May 31 14:46:51 2016
From: report at bugs.python.org (Antony Lee)
Date: Tue, 31 May 2016 18:46:51 +0000
Subject: [issue27161] Confusing exception in Path().with_name
In-Reply-To: <1464654135.6.0.522820749972.issue27161@psf.upfronthosting.co.za>
Message-ID: <1464720411.01.0.98390298035.issue27161@psf.upfronthosting.co.za>


Antony Lee added the comment:

First, I doubt that this optimization actually changes anything measurable, but if you want you can always replace that line by "if part.startswith(sep)" (also solving the original issue).

Additionally, note that `parse_parts` (the only function to call `splitroot` already (and redundantly) checks that `part` is truthy before calling `splitroot`.  There are a couple of other "optimizations" in the same function (`if x and x != '.'`, `if rel and rel != '.'`) for which I'd be surprised if they truly mattered.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27161>
_______________________________________

From report at bugs.python.org  Tue May 31 14:50:00 2016
From: report at bugs.python.org (Nathan Harold)
Date: Tue, 31 May 2016 18:50:00 +0000
Subject: [issue26176] EmailMessage example doesn't work
In-Reply-To: <1453427916.73.0.91814079944.issue26176@psf.upfronthosting.co.za>
Message-ID: <1464720600.49.0.6235522954.issue26176@psf.upfronthosting.co.za>


Nathan Harold added the comment:

emailexample.patch fixes the specific issue mentioned in #26426: the Address constructor is now used as documented.  It changes the final output of the two combined examples (as presented in the documentation) accordingly.

In general it seems as though these examples (the two in in 19.1.14.1) were meant to be read, not run.  To run them, the user would have to supply (1) their own roasted-asparagus.jpg, (2) their own local SMTP server, and (3) their own implementation of imaginary.magic_html_parser.  However, the Address constructor usage issue was real, and I was able to generate the relevant output without (2) and (3).

----------
keywords: +patch
nosy: +nharold
Added file: http://bugs.python.org/file43070/emailexample.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26176>
_______________________________________

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: [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 14:54:36 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Tue, 31 May 2016 18:54:36 +0000
Subject: [issue22091] __debug__ in compile(optimize=1)
In-Reply-To: <1406460720.31.0.52304616259.issue22091@psf.upfronthosting.co.za>
Message-ID: <1464720876.37.0.117346259903.issue22091@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

I just opened #27169: "__debug__ is not optimized out at compile time for anything but `if:` and `while:` blocks" as a more general case of this bug.

This bug covers inconsistent behavior, but ultimately, it's caused by incomplete optimization: `__debug__` doesn't act as a compile time constant outside of `if:` and `while:` blocks, so the behavior is inconsistent for all other uses in the `compile` case where `optimize` doesn't match the main interpreter session, and inefficient for all other uses whether or not `compile` is involved.

If #27169 is resolved as I suggested (or in some other similar way), it would also resolve this bug.

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22091>
_______________________________________

From report at bugs.python.org  Tue May 31 15:09:39 2016
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 31 May 2016 19:09:39 +0000
Subject: [issue27169] __debug__ is not optimized out at compile time for
 anything but `if:` and `while:` blocks
In-Reply-To: <1464720658.3.0.0366082537286.issue27169@psf.upfronthosting.co.za>
Message-ID: <1464721779.29.0.103686460459.issue27169@psf.upfronthosting.co.za>


Serhiy Storchaka added the comment:

I think that the complete solution of this problem is making __debug__ a named constant like None, True, False.

This needs changing the grammar of Python.

----------
nosy: +serhiy.storchaka

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27169>
_______________________________________

From report at bugs.python.org  Tue May 31 15:58:31 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Tue, 31 May 2016 19:58:31 +0000
Subject: [issue24882] ThreadPoolExecutor doesn't reuse threads until #threads
 == max_workers
In-Reply-To: <1439823540.4.0.657998470812.issue24882@psf.upfronthosting.co.za>
Message-ID: <1464724711.06.0.742073044147.issue24882@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

Is there a good reason to worry about overeager worker spawning? ProcessPoolExecutor spawns all workers when the first work item is submitted ( https://hg.python.org/cpython/file/3.4/Lib/concurrent/futures/process.py#l361 ), only ThreadPoolExecutor even makes an effort to limit the number of threads spawned. Threads are typically more lightweight than processes, and with the recent GIL improvements, the CPython specific costs associated with threads (particularly threads that are just sitting around waiting on a lock) are fairly minimal.

It just seems like if eager process spawning isn't a problem, neither is (cheaper) eager thread spawning.

----------
nosy: +josh.r

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24882>
_______________________________________

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: [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 16:17:43 2016
From: report at bugs.python.org (Lucas Wiman)
Date: Tue, 31 May 2016 20:17:43 +0000
Subject: [issue10109] itertools.product with infinite iterator cause
 MemoryError.
In-Reply-To: <1287103502.64.0.571191585998.issue10109@psf.upfronthosting.co.za>
Message-ID: <1464725863.38.0.683869193862.issue10109@psf.upfronthosting.co.za>


Lucas Wiman added the comment:

I realize this is an old (and closed!) thread, but here are a few notes from running into this issue recently, working on a search problem with infinite iterators.

First, note that yegle's recursive solution is not correct, since it exhausts the iterators:
>>> def product(*args):
...     if len(args) == 1:
...         for i in args[0]:
...             yield [i]
...     else:
...         for i in args[0]:
...             for j in product(*args[1:]):
...                 j.append(i)
...                 yield j
... 
>>> 
>>> assert len(list(itertools.product(*[iter(range(2)) for _ in range(10)]))) == 2 ** 10
>>> assert len(list(product(*[iter(range(2)) for _ in range(10)]))) == 2 ** 10
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AssertionError

This is fairly tricky to get right, and even a correct fully-lazy solution requires each iterator to eventually be fully stored in memory. For that reason, Sumudu's MemoryError is not something that can be easily escaped, though it can be delayed.

For infinite iterators, the naive "lexicographic" solution to product(count(0), count(0)) would never get to 1 on the first iterator, yielding (0, 0), (0, 1), (0, 2), ...  To fully explore the space, the user needs to think about how to iterate over that space, so IMO keeping infinite iterators as invalid arguments to itertools.product makes sense.

----------
nosy: +Lucas Wiman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10109>
_______________________________________

From report at bugs.python.org  Tue May 31 16:24:29 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 31 May 2016 20:24:29 +0000
Subject: [issue26546] Provide translated french translation on docs.python.org
In-Reply-To: <1457794223.79.0.618185263259.issue26546@psf.upfronthosting.co.za>
Message-ID: <1464726269.68.0.557911823397.issue26546@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

By 'same status', I meant that 3.4 is on 'security maintenance', just like 3.3 and 3.2.  But do whatever a reviewer wants.

Some people are busy at PyCon this week.  Anyway, I think Zack pointed you in the right direction.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26546>
_______________________________________

From report at bugs.python.org  Tue May 31 16:50:33 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 31 May 2016 20:50:33 +0000
Subject: [issue27161] Confusing exception in Path().with_name
In-Reply-To: <1464654135.6.0.522820749972.issue27161@psf.upfronthosting.co.za>
Message-ID: <1464727833.28.0.557587485423.issue27161@psf.upfronthosting.co.za>


R. David Murray added the comment:

Just because it isn't public doesn't mean no one calls it :).  But seriously, that's why I said "the risk".  Is the small benefit of the codechange worth the small risk of breaking something?  I'm not answering that question, I'm posing it.  Call me -0 on the change.

I agree that the optimization argument doesn't really seem relevant.  If someone cares about performance they aren't going to be using pathlib.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27161>
_______________________________________

From report at bugs.python.org  Tue May 31 16:53:13 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 31 May 2016 20:53:13 +0000
Subject: [issue27161] Confusing exception in Path().with_name
In-Reply-To: <1464654135.6.0.522820749972.issue27161@psf.upfronthosting.co.za>
Message-ID: <1464727993.36.0.522447182283.issue27161@psf.upfronthosting.co.za>


R. David Murray added the comment:

To clarify that performance statement: if someone is optimizing a tight loop, the first thing they'll likely do is drop down to the lower level calls to avoid all of the pathlib overhead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27161>
_______________________________________

From report at bugs.python.org  Tue May 31 16:53:43 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 31 May 2016 20:53:43 +0000
Subject: [issue27099] IDLE: turn builting extensions into regular modules
In-Reply-To: <1464055360.13.0.626532918919.issue27099@psf.upfronthosting.co.za>
Message-ID: <1464728023.1.0.167736395295.issue27099@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

The version conflict problem is why I reverted changing 'extension names' to match the new file names, before rebase collapsing my patches.  I was really glad most were in a separate patch.

Each time a feature ceases to be an extension, the (old) extension name will have to be added to a set of names ignored when calculating the set of extensions.  I will start with one until I have worked out and tested the details.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27099>
_______________________________________

From report at bugs.python.org  Tue May 31 17:03:53 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 31 May 2016 21:03:53 +0000
Subject: [issue26176] EmailMessage example doesn't work
In-Reply-To: <1453427916.73.0.91814079944.issue26176@psf.upfronthosting.co.za>
Message-ID: <1464728633.31.0.796522968953.issue26176@psf.upfronthosting.co.za>


R. David Murray added the comment:

Thank you for the patch.  I blame the mistake on too great a familiarity with the old API :)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26176>
_______________________________________

From report at bugs.python.org  Tue May 31 17:04:09 2016
From: report at bugs.python.org (R. David Murray)
Date: Tue, 31 May 2016 21:04:09 +0000
Subject: [issue26176] EmailMessage example doesn't work
In-Reply-To: <1453427916.73.0.91814079944.issue26176@psf.upfronthosting.co.za>
Message-ID: <1464728649.89.0.215999053738.issue26176@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
stage: needs patch -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26176>
_______________________________________

From report at bugs.python.org  Tue May 31 17:06:04 2016
From: report at bugs.python.org (Josh Rosenberg)
Date: Tue, 31 May 2016 21:06:04 +0000
Subject: [issue27169] __debug__ is not optimized out at compile time for
 anything but `if:` and `while:` blocks
In-Reply-To: <1464720658.3.0.0366082537286.issue27169@psf.upfronthosting.co.za>
Message-ID: <1464728764.53.0.982180239226.issue27169@psf.upfronthosting.co.za>


Josh Rosenberg added the comment:

That would also work. The argument I'd give in favor of performing a pass that replaces it with a literal True or False is that you don't have update as many places, don't have to worry about missing a place, and you don't have to decide if __debug__ is a reference to True or False, or a new object entirely.

It's just too easy to miss a case where __debug__ should be special and not notice (because optimizations aren't heavily tested for specific byte code outputs or anything), where a missed optimization for the True or False constant is much less likely to go unnoticed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27169>
_______________________________________

From report at bugs.python.org  Tue May 31 17:14:20 2016
From: report at bugs.python.org (Alexander Schrijver)
Date: Tue, 31 May 2016 21:14:20 +0000
Subject: [issue22232] str.splitlines splitting on non-\r\n characters
In-Reply-To: <1408528911.37.0.452679392827.issue22232@psf.upfronthosting.co.za>
Message-ID: <1464729260.07.0.544603757097.issue22232@psf.upfronthosting.co.za>


Alexander Schrijver added the comment:

This diff updates the cpython (tip) documentation to document the different behaviour when using splitlines on bytes objects or string objects.

----------
keywords: +patch
nosy: +Alexander Schrijver
Added file: http://bugs.python.org/file43071/cpython3.5_splitlines.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22232>
_______________________________________

From report at bugs.python.org  Tue May 31 17:16:10 2016
From: report at bugs.python.org (Alexander Schrijver)
Date: Tue, 31 May 2016 21:16:10 +0000
Subject: [issue22232] str.splitlines splitting on non-\r\n characters
In-Reply-To: <1408528911.37.0.452679392827.issue22232@psf.upfronthosting.co.za>
Message-ID: <1464729370.48.0.351675124485.issue22232@psf.upfronthosting.co.za>


Alexander Schrijver added the comment:

This diff synchronizes the cpython 2.7 with that from 3.5 and also describes the difference between bytes objects and unicode objects (from the other diff)

----------
Added file: http://bugs.python.org/file43072/cpython3.5_splitlines.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22232>
_______________________________________

From report at bugs.python.org  Tue May 31 17:19:00 2016
From: report at bugs.python.org (Michael Felt)
Date: Tue, 31 May 2016 21:19:00 +0000
Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not
 available (e.g., AIX)
In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za>
Message-ID: <1464729540.18.0.00334350944078.issue26439@psf.upfronthosting.co.za>


Michael Felt added the comment:

As a separate file in the hope it re-fits into Mercurial better

----------
Added file: http://bugs.python.org/file43073/aixutil.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26439>
_______________________________________

From report at bugs.python.org  Tue May 31 17:20:03 2016
From: report at bugs.python.org (Michael Felt)
Date: Tue, 31 May 2016 21:20:03 +0000
Subject: [issue26439] ctypes.util.find_library fails when ldconfig/glibc not
 available (e.g., AIX)
In-Reply-To: <1456413023.18.0.874865601403.issue26439@psf.upfronthosting.co.za>
Message-ID: <1464729603.07.0.0821940562407.issue26439@psf.upfronthosting.co.za>


Michael Felt added the comment:

without aixutil.py - hopefully better for Mercurial import

----------
Added file: http://bugs.python.org/file43074/Python2.Lib.ctypes.160531.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26439>
_______________________________________

From report at bugs.python.org  Tue May 31 17:20:36 2016
From: report at bugs.python.org (Alexander Schrijver)
Date: Tue, 31 May 2016 21:20:36 +0000
Subject: [issue22232] str.splitlines splitting on non-\r\n characters
In-Reply-To: <1408528911.37.0.452679392827.issue22232@psf.upfronthosting.co.za>
Message-ID: <1464729636.36.0.802797914432.issue22232@psf.upfronthosting.co.za>


Alexander Schrijver added the comment:

Oops, wrong diff. Sorry, this is the correct one for 2.7.

----------
Added file: http://bugs.python.org/file43075/cpython2.7_splitlines.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22232>
_______________________________________

From report at bugs.python.org  Tue May 31 17:24:55 2016
From: report at bugs.python.org (MICHAEL JACOBSON)
Date: Tue, 31 May 2016 21:24:55 +0000
Subject: [issue26739] idle: Errno 10035 a non-blocking socket operation could
 not be completed immediately
In-Reply-To: <1460409859.89.0.789703447955.issue26739@psf.upfronthosting.co.za>
Message-ID: <1464729895.71.0.811510810294.issue26739@psf.upfronthosting.co.za>


MICHAEL JACOBSON added the comment:

Kristj?n, when you say 'dead or dying code', it worries me a lot.  Can you tell me what you mean because I do NOT want to reinstall IDLE.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26739>
_______________________________________

From report at bugs.python.org  Tue May 31 17:35:57 2016
From: report at bugs.python.org (MICHAEL JACOBSON)
Date: Tue, 31 May 2016 21:35:57 +0000
Subject: [issue26739] idle: Errno 10035 a non-blocking socket operation could
 not be completed immediately
In-Reply-To: <1460409859.89.0.789703447955.issue26739@psf.upfronthosting.co.za>
Message-ID: <1464730557.87.0.118111203428.issue26739@psf.upfronthosting.co.za>


MICHAEL JACOBSON added the comment:

I also do not want to change something in the /lib folder because that is like going into the Windows Registry and 'fixing' a bunch of stuff.

I've made other games with PyGame and they generate errno 10035, too.
I've also installed the same version of Python, on a newer computer.
It is a Windows 10, ex-8.1
I haven't finished the program on my newer computer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26739>
_______________________________________

From report at bugs.python.org  Tue May 31 17:42:30 2016
From: report at bugs.python.org (Zachary Ware)
Date: Tue, 31 May 2016 21:42:30 +0000
Subject: [issue26739] idle: Errno 10035 a non-blocking socket operation could
 not be completed immediately
In-Reply-To: <1460409859.89.0.789703447955.issue26739@psf.upfronthosting.co.za>
Message-ID: <1464730950.72.0.309754738575.issue26739@psf.upfronthosting.co.za>


Zachary Ware added the comment:

If you're still using 2.7.5, we can't help you.  If you can reproduce the issue with 2.7.11 or 3.5.1, please reopen.

----------
resolution:  -> out of date
stage:  -> resolved
status: open -> closed
type: resource usage -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26739>
_______________________________________

From report at bugs.python.org  Tue May 31 19:05:51 2016
From: report at bugs.python.org (Martin Panter)
Date: Tue, 31 May 2016 23:05:51 +0000
Subject: [issue22232] str.splitlines splitting on non-\r\n characters
In-Reply-To: <1408528911.37.0.452679392827.issue22232@psf.upfronthosting.co.za>
Message-ID: <1464735951.06.0.260772011418.issue22232@psf.upfronthosting.co.za>


Martin Panter added the comment:

For Python 3, the bytes.splitlines() and bytearray.splitlines() documentation has been moved to a separate section out (Issue 21777). I don?t think it is good to add much detail of bytes.splitlines() in the str.splitlines() documentation.

For Python 2, perhaps see Matthew?s patches for 2.7 in Issue 12855. IMO we could reopen that bug if that helps, because only the Python 3 branches were comitted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue22232>
_______________________________________

From report at bugs.python.org  Tue May 31 19:54:54 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 31 May 2016 23:54:54 +0000
Subject: [issue26739] idle: Errno 10035 a non-blocking socket operation could
 not be completed immediately
In-Reply-To: <1460409859.89.0.789703447955.issue26739@psf.upfronthosting.co.za>
Message-ID: <1464738894.39.0.727111358748.issue26739@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Michael, IDLE is not dead, and I am working steadily to modernize it inside and out for 3.6.  There have even been improvements for 2.7 since 2.7.5.  For his work, Kristj?n has had no reason to keep up to date on IDLE's progress.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue26739>
_______________________________________

From report at bugs.python.org  Tue May 31 19:55:28 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 31 May 2016 23:55:28 +0000
Subject: [issue27170] IDLE: remove Toggle Auto Coloring or add to edit menu &
 doc
In-Reply-To: <1464724931.74.0.507384074731.issue27170@psf.upfronthosting.co.za>
Message-ID: <1464738928.35.0.421963183446.issue27170@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

Looking more, there are lots of editor bindings that are not on the menu that are more important than this.  Example: Center insert, ^L, scrolls text to bring insert cursor as close to the middle of the window as possible.  It does move the position of the cursor within the doc.  I discovered the existence of this and determined its actual behavior by reading the code.

Some are listed in the doc, section '2. Editing and navigation'. Anything that can be user configured can be discovered, but not everything is.

If this feature is kept, it should be on a submenu with other missing items.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27170>
_______________________________________

From report at bugs.python.org  Tue May 31 20:18:27 2016
From: report at bugs.python.org (Roundup Robot)
Date: Wed, 01 Jun 2016 00:18:27 +0000
Subject: [issue24225] Idlelib: changing file names
In-Reply-To: <1431934587.56.0.38760352205.issue24225@psf.upfronthosting.co.za>
Message-ID: <20160601001816.17677.86291.32FCB631@psf.io>


Roundup Robot added the comment:

New changeset 20bd4c23cfe4 by Terry Jan Reedy in branch 'default':
Issue # 24225: Update idlelib.README.txt with new file names and event handlers.
https://hg.python.org/cpython/rev/20bd4c23cfe4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24225>
_______________________________________

From report at bugs.python.org  Tue May 31 20:20:45 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 01 Jun 2016 00:20:45 +0000
Subject: [issue25570] urllib.request > Request.add_header("abcd",
 "efgh") fails with character ":" in first parameter string
In-Reply-To: <1446842352.31.0.869437789925.issue25570@psf.upfronthosting.co.za>
Message-ID: <1464740445.35.0.170835624069.issue25570@psf.upfronthosting.co.za>


Berker Peksag added the comment:

add_header.patch looks good to me. Thanks Martin.

----------
nosy: +berker.peksag
stage: patch review -> commit review
versions:  -Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue25570>
_______________________________________

From report at bugs.python.org  Tue May 31 20:24:38 2016
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 01 Jun 2016 00:24:38 +0000
Subject: [issue24225] Idlelib: changing file names
In-Reply-To: <1431934587.56.0.38760352205.issue24225@psf.upfronthosting.co.za>
Message-ID: <1464740678.95.0.222844882343.issue24225@psf.upfronthosting.co.za>


Terry J. Reedy added the comment:

I brought IDLE news entries up to date 2 days ago.  This patch updates README.txt with the new names and many new entries for event handlers.  A What's New entry needs to wait for more patches, and is the subject of #27163.  This completes the 'still to do' list in msg266572.

----------
resolution:  -> fixed
stage: needs patch -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue24225>
_______________________________________

From report at bugs.python.org  Tue May 31 22:16:21 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 01 Jun 2016 02:16:21 +0000
Subject: [issue20683] Add example to tutorial namespace doc, section 9.2
In-Reply-To: <1392798452.78.0.903259935516.issue20683@psf.upfronthosting.co.za>
Message-ID: <1464747381.43.0.57393828763.issue20683@psf.upfronthosting.co.za>


Berker Peksag added the comment:

Thanks for the report, Karl. Could you give more details about what's missing? The section gives some examples of namespaces:

    [...] the set of built-in names (containing functions such as abs(), and built-in exception names); the global names in a module; and the local names in a function invocation.

I'm not sure if it's worth to convert them to code examples.

----------
nosy: +berker.peksag
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20683>
_______________________________________

From report at bugs.python.org  Tue May 31 22:40:48 2016
From: report at bugs.python.org (Luiz Poleto)
Date: Wed, 01 Jun 2016 02:40:48 +0000
Subject: [issue5996] abstract class instantiable when subclassing dict
In-Reply-To: <1242050763.07.0.145569961651.issue5996@psf.upfronthosting.co.za>
Message-ID: <1464748848.59.0.206862051685.issue5996@psf.upfronthosting.co.za>


Changes by Luiz Poleto <luiz.poleto at gmail.com>:


----------
nosy: +luiz.poleto

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5996>
_______________________________________

From report at bugs.python.org  Tue May 31 23:17:27 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 01 Jun 2016 03:17:27 +0000
Subject: [issue20496] function definition tutorial encourages bad practice
In-Reply-To: <1391404187.28.0.545168168954.issue20496@psf.upfronthosting.co.za>
Message-ID: <1464751047.67.0.519709443879.issue20496@psf.upfronthosting.co.za>


Berker Peksag added the comment:

I agree with Terry. The print example is also useful to show the implicit return value of fib(). Quoting from the same section:

    [...] In fact, even functions without a return statement do return a value, albeit a rather boring one. This value is called None [...]

----------
nosy: +berker.peksag
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue20496>
_______________________________________

From report at bugs.python.org  Tue May 31 23:35:09 2016
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 01 Jun 2016 03:35:09 +0000
Subject: [issue17383] Possibly ambiguous phrasing in
 tutorial/modules#more-on-modules
In-Reply-To: <1362700500.92.0.448355159104.issue17383@psf.upfronthosting.co.za>
Message-ID: <1464752109.1.0.705573412124.issue17383@psf.upfronthosting.co.za>


Changes by Berker Peksag <berker.peksag at gmail.com>:


----------
nosy: +berker.peksag
stage: patch review -> needs patch
type:  -> behavior
versions: +Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue17383>
_______________________________________

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: [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>
_______________________________________

From report at bugs.python.org  Tue May 31 23:58:22 2016
From: report at bugs.python.org (Martin Panter)
Date: Wed, 01 Jun 2016 03:58:22 +0000
Subject: [issue27171] Fix various typos
In-Reply-To: <1464753470.11.0.0270588746388.issue27171@psf.upfronthosting.co.za>
Message-ID: <1464753502.07.0.291195787316.issue27171@psf.upfronthosting.co.za>


Changes by Martin Panter <vadmium+py at gmail.com>:


Added file: http://bugs.python.org/file43077/typos.py2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue27171>
_______________________________________

From dclarke at blastwave.org  Mon May 30 18:49:00 2016
From: dclarke at blastwave.org (Dennis Clarke)
Date: Mon, 30 May 2016 18:49:00 -0400
Subject: [issue23459] Linux: expose the new execveat() syscall
In-Reply-To: <1464646376.94.0.116118813216.issue23459@psf.upfronthosting.co.za>
References: <1464646376.94.0.116118813216.issue23459@psf.upfronthosting.co.za>
Message-ID: <7e2180a0-b895-14cb-9fc5-0d1247f83ba7@blastwave.org>

On 05/30/2016 06:12 PM, ???? ????????? wrote:
>
> ???? ????????? added the comment:
>
> It is actual to me due to it's AT_EMPTY_PATH feature (I download script, verify signature, and want to run it)
>
> See also `man 3 fexecve`
>
> Why not to add `dir_fd=None` ?  (as in `os.rmdir()` for example).
>
> It should be very small patch, as I think.

This system call only exists in some recent versions of Linux :

   #include <unistd.h>

        int execveat(int dirfd, const char *pathname,
                     char *const argv[], char *const envp[],
                     int flags);


Using code that depends on it will break portability.

Dennis Clarke