From report at bugs.python.org  Mon Jan  1 00:47:34 2018
From: report at bugs.python.org (Yahya Abou Imran)
Date: Mon, 01 Jan 2018 05:47:34 +0000
Subject: [New-bugs-announce] [issue32471] Add an UML class diagram to the
 collections.abc module documentation
Message-ID: <1514785654.69.0.467229070634.issue32471@psf.upfronthosting.co.za>


New submission from Yahya Abou Imran <yahya-abou-imran at protonmail.com>:

>From python-ideas: https://mail.python.org/pipermail/python-ideas/2017-December/048492.html

In this page of the documentation:
https://docs.python.org/3/library/collections.abc.html

The table could be difficult to understand, a diagram help visualize things.

I'm joining the last version of my work, and the .puml I used to generate it.

Opinions about details (fonts, displaying...) are being discussed on the mailist right now.

----------
assignee: docs at python
components: Documentation
files: base.png
messages: 309318
nosy: docs at python, yahya-abou-imran
priority: normal
severity: normal
status: open
title: Add an UML class diagram to the collections.abc module documentation
type: enhancement
versions: Python 3.6, Python 3.7
Added file: https://bugs.python.org/file47357/base.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32471>
_______________________________________

From report at bugs.python.org  Mon Jan  1 01:06:41 2018
From: report at bugs.python.org (Yahya Abou Imran)
Date: Mon, 01 Jan 2018 06:06:41 +0000
Subject: [New-bugs-announce] [issue32472] Mention of __await__ missing in
 Coroutine Abstract Methods
Message-ID: <1514786801.71.0.467229070634.issue32472@psf.upfronthosting.co.za>


New submission from Yahya Abou Imran <yahya-abou-imran at protonmail.com>:

In the collections.abc documentation:

https://docs.python.org/3/library/collections.abc.html

__await__() doesn't appear in the abstract methods of Coroutine, we see only send() and throw().

But since Coroutine inherit from Awaitable, it's required:


from collections.abc import Coroutine

class MyCoroutine(Coroutine):
    def send(self, value):
        raise StopIteration
    def throw(self, err):
        raise err

mc = MyCoroutine()

Traceback (most recent call last):
  File "_tmp.py", line 9, in <module>
    mc = MyCoroutine()
TypeError: Can't instantiate abstract class MyCoroutine with abstract methods __await__


To be consistent with the rest of the document, this method should appear here to show all the abstract methods, even the inherited ones.

----------
assignee: docs at python
components: Documentation
messages: 309320
nosy: docs at python, yahya-abou-imran
priority: normal
severity: normal
status: open
title: Mention of __await__ missing in Coroutine Abstract Methods
type: enhancement
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32472>
_______________________________________

From report at bugs.python.org  Mon Jan  1 01:09:25 2018
From: report at bugs.python.org (Yahya Abou Imran)
Date: Mon, 01 Jan 2018 06:09:25 +0000
Subject: [New-bugs-announce] [issue32473] Readibility of
 ABCMeta._dump_registry()
Message-ID: <1514786965.88.0.467229070634.issue32473@psf.upfronthosting.co.za>


New submission from Yahya Abou Imran <yahya-abou-imran at protonmail.com>:

>From python-ideas:
https://mail.python.org/pipermail/python-ideas/2017-December/048504.html

In python 2.7, ABCs's caches and registries are sets. But in python 3.6 they are WeakSet.
In consequence, the output of _dump_registry() is almost useless:

>>> from collections import abc
>>> abc.Iterator._dump_registry()
Class: collections.abc.Iterator
Inv.counter: 40
_abc_cache: <_weakrefset.WeakSet object at 0x7f4b58fe2668>
_abc_negative_cache: <_weakrefset.WeakSet object at 0x7f4b53283780>
_abc_negative_cache_version: 40
_abc_registry: <_weakrefset.WeakSet object at 0x7f4b58fe2630>

We could convert them into a regular set before printing:

if isinstance(value, WeakSet):
    value = set(value)

The result:

>>> abc.Iterator._dump_registry()
Class: collections.abc.Iterator
Inv.counter: 40
_abc_cache: {<class 'dict_valueiterator'>, <class 'bytearray_iterator'>, <class 'tuple_iterator'>, <class 'dict_itemiterator'>, <class 'dict_keyiterator'>, <class 'str_iterator'>, <class 'zip'>, <class 'set_iterator'>, <class 'list_reverseiterator'>, <class 'range_iterator'>, <class 'longrange_iterator'>, <class 'list_iterator'>, <class 'bytes_iterator'>}
_abc_negative_cache: set()
_abc_negative_cache_version: 40
_abc_registry: set()

----------
messages: 309321
nosy: yahya-abou-imran
priority: normal
severity: normal
status: open
title: Readibility of ABCMeta._dump_registry()
type: enhancement
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32473>
_______________________________________

From report at bugs.python.org  Mon Jan  1 01:47:30 2018
From: report at bugs.python.org (Shubham Sharma)
Date: Mon, 01 Jan 2018 06:47:30 +0000
Subject: [New-bugs-announce] [issue32474] argparse nargs should support
 string wrapped integers too
Message-ID: <1514789250.22.0.467229070634.issue32474@psf.upfronthosting.co.za>


Change by Shubham Sharma <shubhamsharma1172 at gmail.com>:


----------
components: Library (Lib)
nosy: shubham1172
priority: normal
severity: normal
status: open
title: argparse nargs should support string wrapped integers too
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32474>
_______________________________________

From report at bugs.python.org  Mon Jan  1 03:31:45 2018
From: report at bugs.python.org (Tim Savannah)
Date: Mon, 01 Jan 2018 08:31:45 +0000
Subject: [New-bugs-announce] [issue32475] Add ability to query number of
 buffered bytes available on buffered I/O
Message-ID: <1514795505.19.0.467229070634.issue32475@psf.upfronthosting.co.za>


New submission from Tim Savannah <kata198 at gmail.com>:

Hello!

This is my first time submitting to Python bug tracker, so please bear with me if I miss/mess something.

So a little bit of relevant background, I'm an avid python developer with many open-source projects.

One of the projects I wrote and maintain is called "python-nonblock", which provides pure-python non-blocking I/O methods. It is available at:

https://github.com/kata198/python-nonblock


I'll only include the relevant details to this topic.

So, one of the features provided by the python-nonblock in the nonblock_read function. This allows you to read from a stream whilst ensuring the operation does not block.

It achieves this by basically following this pattern:

1. Call "select" on the stream and see if any data is available. If not, sleep and reiterate.

2. If there is data available, it reads a single byte from the stream and stores is to return at the end.

It supports most streams and sockets which have a real fd backing (and thus support "select").


There are a couple reasons you may need to do this, e.x. certain interactive scenarios, I won't go into it too much.


The python-nonblock library also bundles a layer which sits on top of that method, called BackgroundRead. This interface launches a thread into the background, which reads blocks of arbitrary (user-provided) size into a variable on an object. So you could have a processing app which reads blocks of data from a source, processes them in the foreground whilst they continue to load up in the background.


That's all well and good, but we are getting to the meat of the issue: for large sources of available data (like a file on disk), while this method of operation is effective, it is SLOW, due to the overhead of a select syscall and libpython for every single byte. This is especially true on a loaded system, as it makes us a prime candidate for the scheduler to preempt our task and context switch us off the cpu!


I've been looking into ways to improve this, and have actually seemed to have struck gold. So on a standard linux HDD filesystem, the I/O block size is 4096. So, thanks to readahead, on a non-fragmented file, a read call for 1 byte will actually load up to 4096 bytes. libpython has this extra data, and calls like read1 will return it if available, but it does not expose this number. Thus, libraries like mine can't take advantage of it, which means that for a filesystem I/O read on linux, 4095 out of 4096 iterations of the two-step loop above are wasted effort.

So I've written up an additional function to the C code for BufferedReader, "getbuffn", which returns the number bytes currently buffered in libpython, but not yet returned to the application, and modified python-nonblock ( in the 4.0branch_getbuffn branch ) with simple additions to take advantage of this extra information, when available. So if we detect that there are 4095 bytes already read and pending, we know for certain we can grab all 4095 bytes at once without blocking, or even needing a call to select!

So the new pattern for buffered streams that have getbuffn available, we can:

1. Select to see if data is available, if not rest and reiterate

2. Read a single byte off the stream

3. Check getbuffn, and if it returns >0 read that many bytes off the stream (Guaranteed to not block)


The performance improvements are * MASSIVE * with this change in place.

   On a 5 meg file from a VM which is running on an SSD, I average the following:
 
     Loaded system, non-cached I/O:
 
        One-Fell-Swoop file.read() - .3 seconds
 
        getbuffn-patched python and this impl - 3.1 seconds
 
        unpatched python and this impl - 41 to 55 = 44 seconds. ( avg min - avg max)
 
     Unloaded system, cached I/O:
 
        One-Fell-Swoop file.read() - .0017 seconds
 
        getbuffn-patched python and this impl - .034 seconds
 
        unpatched python and this impl - 45 seconds. ( not as variable as loaded system )

That's a 13,235% (thirteen-thousand two-hundred and five percent) performance boost on just a 5MB file, which just grows exponentially as the size of the dataset increases. These gains are just simply not possible without this information available (the amount remaining in the buffer).


So I've attached the simple patch (only additions, no modifications to existing functions) against python 3.6.4. The version of python-nonblock which supports this enhanced approach when available (and more details at the top of the README) can be found here: 

https://github.com/kata198/python-nonblock/tree/4.0branch_getbuffn

I've looked at the python 2.7 code too, and it seems that with minimal effort this same functionality can be provided there as well!


So, I'm an experienced developer who is willing to put in the legwork. Is this something that is possible to get merged upstream? If so, what are the steps I would need to take in order to make it so?


Thanks in advance,
Tim Savannah

----------
components: IO, Library (Lib)
files: Python_3_6_4_getbuffn.patch
keywords: patch
messages: 309328
nosy: kata198
priority: normal
severity: normal
status: open
title: Add ability to query number of buffered bytes available on buffered I/O
type: enhancement
versions: Python 3.6
Added file: https://bugs.python.org/file47359/Python_3_6_4_getbuffn.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32475>
_______________________________________

From report at bugs.python.org  Mon Jan  1 14:19:06 2018
From: report at bugs.python.org (John Jolly)
Date: Mon, 01 Jan 2018 19:19:06 +0000
Subject: [New-bugs-announce] [issue32476] Add concat functionality to
 ElementTree xpath find
Message-ID: <1514834346.9.0.467229070634.issue32476@psf.upfronthosting.co.za>


New submission from John Jolly <jjolly at suse.com>:

The current implementation of the xpath specification in ElementTree does not allow for predicates that may contain both an apostrophe and a quote. Either one or the other is allowed, but escaping (either string escaping using the backslash or html escaping) is not supported.

A simple solution would be to implement the xpath concat function for predicates. This would allow the combination of quote types in the predicate. Attached is a proposed patch for this fix.

----------
components: Library (Lib)
files: etree-concat.patch
keywords: patch
messages: 309344
nosy: jjolly
priority: normal
severity: normal
status: open
title: Add concat functionality to ElementTree xpath find
type: enhancement
versions: Python 3.7
Added file: https://bugs.python.org/file47360/etree-concat.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32476>
_______________________________________

From report at bugs.python.org  Mon Jan  1 17:03:27 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 01 Jan 2018 22:03:27 +0000
Subject: [New-bugs-announce] [issue32477] Move jumps optimization from the
 peepholer to the compiler
Message-ID: <1514844207.77.0.467229070634.issue32477@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

The proposed patch moves jumps optimization from the peepholer to the compiler. The optimization is performed for lists of instructions before generating concrete bytecode and is not restricted by the size of bytecode instructions. It allows to optimize more long chains of jumps.

This is a step to getting rid of the peepholer.

----------
components: Interpreter Core
messages: 309351
nosy: benjamin.peterson, brett.cannon, ncoghlan, serhiy.storchaka, yselivanov
priority: normal
severity: normal
status: open
title: Move jumps optimization from the peepholer to the compiler
type: performance
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32477>
_______________________________________

From report at bugs.python.org  Mon Jan  1 17:52:03 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 01 Jan 2018 22:52:03 +0000
Subject: [New-bugs-announce] [issue32478] Add tests for 'break' and 'return'
 inside 'finally' clause
Message-ID: <1514847123.41.0.467229070634.issue32478@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

'break' and 'return' are never used inside 'finally' clause in the stdlib. Therefore these cases are not covered by tests even implicitly. The proposed patch adds explicit tests for them.

'continue' inside 'finally' clause currently is prohibited (see issue1542451) and there are tests for this.

----------
components: Tests
messages: 309352
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Add tests for 'break' and 'return' inside 'finally' clause
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32478>
_______________________________________

From report at bugs.python.org  Tue Jan  2 03:48:08 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 02 Jan 2018 08:48:08 +0000
Subject: [New-bugs-announce] [issue32479] inconsistent ImportError message
 executing same import statement
Message-ID: <1514882888.25.0.467229070634.issue32479@psf.upfronthosting.co.za>


New submission from Xiang Zhang <angwerzx at 126.com>:

While debugging a problem in my job I find an odd case about import, it could be reduced to the following tracebacks:

>>> from keystone.assignment import schema
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/site-packages/keystone/assignment/__init__.py", line 15, in <module>
    from keystone.assignment import controllers  # noqa
  File "/usr/lib/python2.7/site-packages/keystone/assignment/controllers.py", line 26, in <module>
    from keystone.common import controller
  File "/usr/lib/python2.7/site-packages/keystone/common/controller.py", line 24, in <module>
    from keystone.common import authorization
  File "/usr/lib/python2.7/site-packages/keystone/common/authorization.py", line 23, in <module>
    from keystone.models import token_model
  File "/usr/lib/python2.7/site-packages/keystone/models/token_model.py", line 15, in <module>
    from keystoneclient.common import cms
ImportError: No module named keystoneclient.common
>>> from keystone.assignment import schema
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/site-packages/keystone/assignment/__init__.py", line 15, in <module>
    from keystone.assignment import controllers  # noqa
  File "/usr/lib/python2.7/site-packages/keystone/assignment/controllers.py", line 25, in <module>
    from keystone.assignment import schema
ImportError: cannot import name schema

keystoneclient is deliberately not installed. I think it should always report keystoneclient.common could not be found which reveals the root causes. But only the first time it does so. Later tries it always report cannot import schema.

The reason of this behaviour is that first time although keystone.assignment import fails but keystone.assignment.schema is successfully installed in sys.modules. And then, in ensure_fromlist, it calls import_submodule which returns the module in sys.modules, without set schema attribute to keystone.assignment. So it then fails in import_from for not able to get the attribute.

It could be simply reproduced by the following package structure:

test
|-- a.py
|-- b.py
`-- __init__.py

__init__.py:
from test import a

a.py: 
from test import b
import modulenotexisting

b.py: #emtpy

>>> import test
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "test/__init__.py", line 1, in <module>
    from test import a
  File "test/a.py", line 2, in <module>
    import dddddddddd
ImportError: No module named dddddddddd
>>> import test
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "test/__init__.py", line 1, in <module>
    from test import a
  File "test/a.py", line 1, in <module>
    from test import b
ImportError: cannot import name b

Python3 doesn't suffer this problem, at least for 3.7.

I don't know this should be identified as a bug or not. But this does bring me trouble debugging problems and lead to confusions because it doesn't  tell users the real module can't be imported.

----------
components: Interpreter Core
messages: 309360
nosy: brett.cannon, eric.snow, ncoghlan, xiang.zhang
priority: normal
severity: normal
status: open
title: inconsistent ImportError message executing same import statement
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32479>
_______________________________________

From report at bugs.python.org  Tue Jan  2 04:56:21 2018
From: report at bugs.python.org (Ajay)
Date: Tue, 02 Jan 2018 09:56:21 +0000
Subject: [New-bugs-announce] [issue32480] czipfile installation failure
Message-ID: <1514886981.07.0.467229070634.issue32480@psf.upfronthosting.co.za>


New submission from Ajay <mail2.hn at gmail.com>:

pip installation for czipfile is failing with compilation error (as below)

Command Execute:
pip install --no-cache-dir czipfile

Error:
Collecting czipfile
  Downloading czipfile-1.0.0.tar.gz (144kB)
    100% |????????????????????????????????| 153kB 726kB/s
    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):
      File "<string>", line 1, in <module>
      File "C:\Users\503022~1\AppData\Local\Temp\pip-build-3uthum1g\czipfile\setup.py", line 18
        print "cython not found, using previously-cython'd .c file."
                                                                   ^
    SyntaxError: Missing parentheses in call to 'print'. Did you mean print(int "cython not found, using previously-cython'd .c file.")?

    ----------------------------------------
Command "python setup.py egg_info" failed with error code 1 in...

----------
components: Library (Lib)
messages: 309364
nosy: ajayhn
priority: normal
severity: normal
status: open
title: czipfile installation failure
type: compile error
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32480>
_______________________________________

From report at bugs.python.org  Tue Jan  2 05:42:25 2018
From: report at bugs.python.org (Jacob Jorvang)
Date: Tue, 02 Jan 2018 10:42:25 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue32481=5D_Hitting_the_acute?=
 =?utf-8?q?_accent_=C2=B4_button_on_a_Danish_keyboard_causes_Python_with_t?=
 =?utf-8?q?kinter_to_crash_immediately=2E?=
Message-ID: <1514889745.69.0.467229070634.issue32481@psf.upfronthosting.co.za>


New submission from Jacob Jorvang <jacobjorvang at gmail.com>:

Hitting the acute accent ? button on a Danish keyboard causes Python with tkinter to crash immediately. This is a problem because the key is just left of the backspace key.
Using:
Python 3.6.3
MacOS version of tkinter
ActiveTCL 8.6.4.1

MacBook-Pro:~ username$ python3 --version
Python 3.6.3
MacBook-Pro:~ username$ pip3 list
DEPRECATION: The default format will switch to columns in the future. You can use --format=(legacy|columns) (or define a format=(legacy|columns) in your pip.conf under the [list] section) to disable this warning.
altgraph (0.15)
future (0.16.0)
lxml (4.1.1)
macholib (1.9)
modulegraph (0.16)
pefile (2017.11.5)
pip (9.0.1)
py2app (0.14)
PyInstaller (3.4.dev0+ab8fd9753)
setuptools (28.8.0)
xmltodict (0.11.0)
MacBook-Pro:~ username$ python3 -c 'import tkinter; tkinter.Text().pack(); tkinter.mainloop()'
2018-01-02 11:31:53.488 Python[80562:5642430] *** Terminating app due to uncaught exception 'NSRangeException', reason: '-[__NSCFConstantString characterAtIndex:]: Range or index out of bounds'
*** First throw call stack:
(
	0   CoreFoundation                      0x000000010010e00b __exceptionPreprocess + 171
	1   libobjc.A.dylib                     0x0000000100de0c76 objc_exception_throw + 48
	2   CoreFoundation                      0x000000010019fc9d +[NSException raise:format:] + 205
	3   CoreFoundation                      0x0000000100089f26 -[__NSCFString characterAtIndex:] + 102
	4   Tk                                  0x0000000103ef1353 TkpInitKeymapInfo + 731
	5   Tk                                  0x0000000103ef71b1 Tk_MacOSXSetupTkNotifier + 798
	6   Tcl                                 0x0000000103dd1a50 Tcl_DoOneEvent + 300
	7   _tkinter.cpython-36m-darwin.so      0x0000000101fedaa1 _tkinter_tkapp_mainloop + 209
	8   Python                              0x00000001007bd7b8 _PyCFunction_FastCallDict + 552
	9   Python                              0x0000000100847164 call_function + 612
	10  Python                              0x0000000100848b74 _PyEval_EvalFrameDefault + 5604
	11  Python                              0x0000000100846e21 fast_function + 465
	12  Python                              0x000000010084714b call_function + 587
	13  Python                              0x0000000100848b74 _PyEval_EvalFrameDefault + 5604
	14  Python                              0x0000000100846500 _PyEval_EvalCodeWithName + 2720
	15  Python                              0x00000001008466a4 PyEval_EvalCode + 100
	16  Python                              0x0000000100883747 PyRun_StringFlags + 183
	17  Python                              0x00000001008837d1 PyRun_SimpleStringFlags + 65
	18  Python                              0x000000010089c304 Py_Main + 1812
	19  Python                              0x0000000100000dfe Python + 3582
	20  Python                              0x0000000100000c34 Python + 3124
	21  ???                                 0x0000000000000003 0x0 + 3
)
libc++abi.dylib: terminating with uncaught exception of type NSException
Abort trap: 6

----------
components: Tkinter
messages: 309365
nosy: Jacob Jorvang
priority: normal
severity: normal
status: open
title: Hitting the acute accent ? button on a Danish keyboard causes Python with tkinter to crash immediately.
type: crash
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32481>
_______________________________________

From report at bugs.python.org  Tue Jan  2 10:20:43 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 02 Jan 2018 15:20:43 +0000
Subject: [New-bugs-announce] [issue32482] Improve tests for syntax and
 grammar in 2.7
Message-ID: <1514906443.05.0.467229070634.issue32482@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

The proposed PR:

* Fixes Py3k warnings introduced by recent backports.
* Backports tests from Python 3.
* Improve handling of Py3k warnings. They are now checked only for statements that emit them instead of silencing for the whole module.
* Fixes few minor defects that can lead to hiding expected errors.

----------
components: Tests
messages: 309374
nosy: benjamin.peterson, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Improve tests for syntax and grammar in 2.7
type: enhancement
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32482>
_______________________________________

From report at bugs.python.org  Tue Jan  2 11:07:22 2018
From: report at bugs.python.org (Iago-lito -)
Date: Tue, 02 Jan 2018 16:07:22 +0000
Subject: [New-bugs-announce] [issue32483] Misleading reflective behaviour
 due to PEP 3131 NFKC identifiers normalization.
Message-ID: <1514909242.99.0.467229070634.issue32483@psf.upfronthosting.co.za>


New submission from Iago-lito - <iago.bonnici at gmail.com>:

Consistent with [PEP 3131](https://www.python.org/dev/peps/pep-3131/) and NFKC normalization of identifiers, these two last lines yield an error, since `?` (U+1D70F) is automatically converted to `?` (U+03C4).

    class Base(object):
        def __init__(self):
            self.? = 5 # defined with U+1D70F

    a = Base()
    print(a.?)     # 5             # (U+1D70F) expected and intuitive
    print(a.?)     # 5 as well     # (U+03C4)  normalized version, okay.
    d = a.__dict__ # {'?':  5}     # (U+03C4)  still normalized version
    print(d['?'])  # 5             # (U+03C4)  consistent with normalization
    assert hasattr(a, '?')         # (U+03C4)  consistent with normalization
    # But if I want to retrieve it the way I entered it because I can type (U+1D70F)
    print(d['?'])  # KeyError: '?' # (U+1D70F) counterintuitive
    assert hasattr(a, '?') # Fails # (U+1D70F) counterintuitive

I've described and undestood the problem in [this post](https://stackoverflow.com/questions/48063082/).

Nothing is unconsistent here. However, I am worried that:

- this behaviour might be counterintuitive and misleading, especially if it occurs that the character user can easily enter for some reason (e.g. U+1D70F) is not equivalent to its NFKC normalization (e.g. U+03C4)

- this behaviours makes it more difficult to enjoy python's reflective `__dict__`, `hasattr` and `getattr` features in this particular case.

Maybe it is user's responsibility to be aware of this limitation, and to keep considering utf-8 coding a bad practice. In this case, maybe this particular reflective limitation could be made explicit in PEP 3131.

Or maybe it is python's responsibility to ensure intuitive and consistent behaviour even in tricky-unicode-cases. So reflective features like `__dict__.__getitem__`, `hasattr` or `getattr` would NFKC-convert their arguments before searching just like `a.?` does, so that:

    getattr(a, '?') is gettatr(a, '?')

always yields True.

I actually have no idea of the philosophy to stick to. And the only purpose of this post is to inform the community about this particular, low-priority case.

Thank you for supporting Python anyway, cheers for your patience.. and happy 2018 to everyone :)


--
Iago-lito

----------
components: Unicode
messages: 309382
nosy: Iago-lito -, ezio.melotti, vstinner
priority: normal
severity: normal
status: open
title: Misleading reflective behaviour due to PEP 3131 NFKC identifiers normalization.
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32483>
_______________________________________

From report at bugs.python.org  Tue Jan  2 14:39:18 2018
From: report at bugs.python.org (sds)
Date: Tue, 02 Jan 2018 19:39:18 +0000
Subject: [New-bugs-announce] [issue32484] ImportError for gdbm 1.14
Message-ID: <1514921958.6.0.467229070634.issue32484@psf.upfronthosting.co.za>


New submission from sds <sds at gnu.org>:

After upgrading to gdbm stable 1.14, I get this:
```
>>> import gdbm
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: dlopen(/.../lib/python2.7/lib-dynload/gdbm.so, 2): Symbol not found: _gdbm_errno
  Referenced from: /.../lib/python2.7/lib-dynload/gdbm.so
  Expected in: /usr/local/opt/gdbm/lib/libgdbm.4.dylib
 in /.../lib/python2.7/lib-dynload/gdbm.so
```
This is probably related to this change:
```
* Make gdbm_error global thread safe.
```
(https://lists.gnu.org/archive/html/info-gnu/2018-01/msg00000.html)

----------
components: Library (Lib)
messages: 309392
nosy: sam-s
priority: normal
severity: normal
status: open
title: ImportError for gdbm 1.14
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32484>
_______________________________________

From report at bugs.python.org  Wed Jan  3 04:44:21 2018
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9_Neto?=)
Date: Wed, 03 Jan 2018 09:44:21 +0000
Subject: [New-bugs-announce] [issue32485] Multiprocessing dict sharing
 between forked processes
Message-ID: <1514972661.4.0.467229070634.issue32485@psf.upfronthosting.co.za>


New submission from Andr? Neto <andre.c.neto at gmail.com>:

I'm working on a project where I need to share state between several processes (forked using gunicorn). I'm using dictionaries obtained from a multiprocessing SyncManager to achieve this.

The issue is that if I have multiple forked processes concurrently accessing to different dictionaries created by the same SyncManager, the code will randomly crash while accessing (read-only and read-write) to any of the dictionaries. This behaviour is independent of the way I access the dictionary (i.e. it happens both using the dictionary functions (e.g. has_key) or the built-in keywords (e.g. key in dict).

The attached snippet demonstrates the issue (tested only in python2.7): the function test_manyForkedProcessesSingleThreaded will crash.

The issue is also being discussed here: https://stackoverflow.com/questions/48052148/python-multiprocessing-dict-sharing-between-processes

----------
files: multiprocessing_crash.py
messages: 309402
nosy: Andr? Neto
priority: normal
severity: normal
status: open
title: Multiprocessing dict sharing between forked processes
type: crash
versions: Python 2.7
Added file: https://bugs.python.org/file47361/multiprocessing_crash.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32485>
_______________________________________

From report at bugs.python.org  Wed Jan  3 05:47:38 2018
From: report at bugs.python.org (Robert Smart)
Date: Wed, 03 Jan 2018 10:47:38 +0000
Subject: [New-bugs-announce] [issue32486] tail optimization for 'yield from'
Message-ID: <1514976458.2.0.467229070634.issue32486@psf.upfronthosting.co.za>


New submission from Robert Smart <robert.kenneth.smart at gmail.com>:

When a generator procedure ends with "yield from" it would be nice if this was handled efficiently (just replace the generator with the new source). Because it is natural to push things back into a generator with

def prependGen(hd,tl):
    yield hd
    yield from tl

----------
messages: 309407
nosy: Robert Smart
priority: normal
severity: normal
status: open
title: tail optimization for 'yield from'
type: resource usage
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32486>
_______________________________________

From report at bugs.python.org  Wed Jan  3 10:41:56 2018
From: report at bugs.python.org (Facundo Batista)
Date: Wed, 03 Jan 2018 15:41:56 +0000
Subject: [New-bugs-announce] [issue32487] assertRaises should return the
 "captured" exception
Message-ID: <1514994116.04.0.467229070634.issue32487@psf.upfronthosting.co.za>


New submission from Facundo Batista <facundo at taniquetil.com.ar>:

Sometimes it's nice to do extra checks on the error raised and captured by self.assertRaises call.

Yes, the same can be achieved using assertRaises as a context manager and then accessing the `exception` attribute in the context manager, but it looks too cumbersome to just get the exception, when it can be simply returned by the assertRaises call.

Note 1: Currently it returns None, so no backward compatibility problem.

Note 2: assertRaises in testtools does this and is very useful

----------
messages: 309414
nosy: facundobatista
priority: normal
severity: normal
stage: needs patch
status: open
title: assertRaises should return the "captured" exception
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32487>
_______________________________________

From report at bugs.python.org  Wed Jan  3 12:49:03 2018
From: report at bugs.python.org (Dave Opstad)
Date: Wed, 03 Jan 2018 17:49:03 +0000
Subject: [New-bugs-announce] [issue32488] Fatal error using pydoc
Message-ID: <1515001743.82.0.467229070634.issue32488@psf.upfronthosting.co.za>


New submission from Dave Opstad <dave.opstad at monotypeimaging.com>:

I'm running 3.6.4 on Mac OS X 10.13.2, bash shell. Doing:

$ pydoc modules

causes:

Please wait a moment while I gather a list of all available modules...

Fatal Python error: PyThreadState_Get: no current thread
Abort trap: 6

Reproduced this several times with the same result.

----------
components: Demos and Tools
messages: 309422
nosy: opstad
priority: normal
severity: normal
status: open
title: Fatal error using pydoc
type: crash
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32488>
_______________________________________

From report at bugs.python.org  Wed Jan  3 16:11:07 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 03 Jan 2018 21:11:07 +0000
Subject: [New-bugs-announce] [issue32489] Allow 'continue' in 'finally'
 clause
Message-ID: <1515013867.94.0.467229070634.issue32489@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

A 'continue' statement is illegal in the 'finally' clause due to a problem with the current implementation. After resolving issue17611 it will be easy to remove this restriction.

----------
assignee: serhiy.storchaka
components: Interpreter Core
messages: 309434
nosy: gvanrossum, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Allow 'continue' in 'finally' clause
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32489>
_______________________________________

From report at bugs.python.org  Wed Jan  3 16:34:31 2018
From: report at bugs.python.org (Jakub Wilk)
Date: Wed, 03 Jan 2018 21:34:31 +0000
Subject: [New-bugs-announce] [issue32490] subprocess: duplicate filename in
 exception message
Message-ID: <1515015271.6.0.467229070634.issue32490@psf.upfronthosting.co.za>


New submission from Jakub Wilk <jwilk at jwilk.net>:

Python 3.6.4 (default, Jan  3 2018, 21:10:22) 
[GCC 4.8.4] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess
>>> subprocess.call('nonexistent')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.6/subprocess.py", line 267, in call
    with Popen(*popenargs, **kwargs) as p:
  File "/usr/local/lib/python3.6/subprocess.py", line 709, in __init__
    restore_signals, start_new_session)
  File "/usr/local/lib/python3.6/subprocess.py", line 1344, in _execute_child
    raise child_exception_type(errno_num, err_msg, err_filename)
FileNotFoundError: [Errno 2] No such file or directory: 'nonexistent': 'nonexistent'


Note that the name of the missing file is mentioned twice in the error message.
(Strictly speaking it's once in the message, and once in the filename attribute, but for a casual observer, the effect is the same.)

----------
components: Library (Lib)
messages: 309438
nosy: jwilk
priority: normal
severity: normal
status: open
title: subprocess: duplicate filename in exception message
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32490>
_______________________________________

From report at bugs.python.org  Wed Jan  3 18:35:25 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 03 Jan 2018 23:35:25 +0000
Subject: [New-bugs-announce] [issue32491] base64.decode: linebreaks are not
 ignored
Message-ID: <1515022525.85.0.467229070634.issue32491@psf.upfronthosting.co.za>


New submission from Gregory P. Smith <greg at krypto.org>:

I've tried reading various RFCs around Base64 encoding, but I couldn't make the ends meet.  Yet there is an inconsistency between base64.decodebytes() and base64.decode() in that how they handle linebreaks that were used to collate the encoded text.  Below is an example of what I'm talking about:

>>> import base64
>>> foo = base64.encodebytes(b'123456789')
>>> foo
b'MTIzNDU2Nzg5\n'
>>> foo = b'MTIzND\n' + b'U2Nzg5\n'
>>> foo
b'MTIzND\nU2Nzg5\n'
>>> base64.decodebytes(foo)
b'123456789'
>>> from io import BytesIO
>>> bytes_in = BytesIO(foo)
>>> bytes_out = BytesIO()
>>> bytes_in.seek(0)
0
>>> base64.decode(bytes_in, bytes_out)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/somewhere/lib/python3.6/base64.py", line 512, in decode
    s = binascii.a2b_base64(line)
binascii.Error: Incorrect padding
>>> bytes_in = BytesIO(base64.encodebytes(b'123456789'))
>>> bytes_in.seek(0)
0
>>> base64.decode(bytes_in, bytes_out)
>>> bytes_out.getvalue()
b'123456789'

Obviously, I'd expect encodebytes() and encode both to either accept or to reject the same input.

Thanks.

Oleg

via Oleg Sivokon on python-dev (who was having trouble getting bugs.python.org account creation to work)

----------
components: Library (Lib)
messages: 309449
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: base64.decode: linebreaks are not ignored
type: behavior
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32491>
_______________________________________

From report at bugs.python.org  Thu Jan  4 13:05:43 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 04 Jan 2018 18:05:43 +0000
Subject: [New-bugs-announce] [issue32492] C Fast path for namedtuple's
 property/itemgetter pair
Message-ID: <1515089143.43.0.467229070634.issue32492@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

Attribute access for named tuples can be made as fast as attribute access of instances of classes with slots.  All that is needed is a C subclass of property with it own __get__ that directly look's up the tuple field using PyTuple_GET_ITEM using an index stored in a C struct rather than as an integer object.

----------
components: Extension Modules
messages: 309477
nosy: rhettinger
priority: normal
severity: normal
status: open
title: C Fast path for namedtuple's property/itemgetter pair
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32492>
_______________________________________

From report at bugs.python.org  Thu Jan  4 13:57:50 2018
From: report at bugs.python.org (David Carlier)
Date: Thu, 04 Jan 2018 18:57:50 +0000
Subject: [New-bugs-announce] [issue32493] UUID Module - FreeBSD build failure
Message-ID: <1515092270.67.0.467229070634.issue32493@psf.upfronthosting.co.za>


New submission from David Carlier <dcarlier at afilias.info>:

UUID module build fails on FreeBSD since it supports uuid_create function.

----------
components: FreeBSD
messages: 309479
nosy: David Carlier, koobs
priority: normal
pull_requests: 4970
severity: normal
status: open
title: UUID Module - FreeBSD build failure
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32493>
_______________________________________

From report at bugs.python.org  Thu Jan  4 16:41:33 2018
From: report at bugs.python.org (sds)
Date: Thu, 04 Jan 2018 21:41:33 +0000
Subject: [New-bugs-announce] [issue32494] interface to gdbm_count
Message-ID: <1515102093.85.0.467229070634.issue32494@psf.upfronthosting.co.za>


New submission from sds <sds at gnu.org>:

gdbm offers a function to quickly find number of records: gdbm_count()
http://www.gnu.org/software/gdbm/manual/html_node/Count.html
It would be nice to be able to call it.

----------
components: Library (Lib)
messages: 309483
nosy: sam-s
priority: normal
severity: normal
status: open
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32494>
_______________________________________

From report at bugs.python.org  Thu Jan  4 17:57:15 2018
From: report at bugs.python.org (Jay Crotts)
Date: Thu, 04 Jan 2018 22:57:15 +0000
Subject: [New-bugs-announce] [issue32495] Adding Timer to multiprocessing
Message-ID: <1515106635.63.0.467229070634.issue32495@psf.upfronthosting.co.za>


New submission from Jay Crotts <crotts.jay at gmail.com>:

I wanted to propose the addition of a Timer class to the multiprocessing library similar to the one that exists in the Threading module.

Timer provides an example of how to extend the Process class that might be helpful to beginners. 

The current lack of a Timer in the multiprocessing library could encourage newer programmers to use threads where processes would be more appropriate.

In the implementation below I have added the ability to specify a # of iterations that the timed function should execute, and an additional infinite argument that would make the process execute the given function until the Timer is explicitly stopped.

----------
components: Library (Lib)
files: Timer.py
messages: 309487
nosy: davin, jcrotts, pitrou
priority: normal
severity: normal
status: open
title: Adding Timer to multiprocessing
type: enhancement
versions: Python 3.7
Added file: https://bugs.python.org/file47364/Timer.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32495>
_______________________________________

From report at bugs.python.org  Thu Jan  4 18:28:09 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 04 Jan 2018 23:28:09 +0000
Subject: [New-bugs-announce] [issue32496] lib2to3 fails to parse a ** of a
 conditional expression
Message-ID: <1515108489.44.0.467229070634.issue32496@psf.upfronthosting.co.za>


New submission from Gregory P. Smith <greg at krypto.org>:

see the attached sample code demonstrating the problem.

basically lib2to3 fails to parse:

  dummy(**kwargs if kwargs else dict())

with an error like:

    raise ParseError("bad input", type, value, context)
lib2to3.pgen2.parse.ParseError: bad input: type=1, value='if', context=(' ', (3, 21))

----------
components: 2to3 (2.x to 3.x conversion tool)
files: repro_2to3_prob.py
messages: 309488
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: lib2to3 fails to parse a ** of a conditional expression
versions: Python 2.7, Python 3.6, Python 3.7
Added file: https://bugs.python.org/file47365/repro_2to3_prob.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32496>
_______________________________________

From report at bugs.python.org  Fri Jan  5 07:24:22 2018
From: report at bugs.python.org (Arjan Keeman)
Date: Fri, 05 Jan 2018 12:24:22 +0000
Subject: [New-bugs-announce] [issue32497] datetime.strptime creates tz naive
 object from value containing a tzname
Message-ID: <1515155062.37.0.467229070634.issue32497@psf.upfronthosting.co.za>


New submission from Arjan Keeman <arjan.keeman at gmail.com>:

Consider the following:

tz_naive_object = datetime.strptime("2018-01-05 13:10:00 CET", "%Y-%m-%d %H:%M:%S %Z")

Python's standard library is not capable of converting the timezone name CET to a tzinfo object. Therefore the case made above returns a timezone naive datetime object.

I propose to add an extra optional argument to _strptime.py's _strptime_datetime function, and to datetime.strptime: tzname_to_tzinfo:Optional[Callable[[str],Optional[tzinfo]]]=None. This parameter can be set with a function that accepts the timezone name and returns a tzinfo object or None (like pytz.timezone). None will mean that a timezone naive object will be created.

Usage:
tz_aware_object = datetime.strptime("2018-01-05 13:10:00 CET", "%Y-%m-%d %H:%M:%S %Z", pytz.timezone)

----------
components: Library (Lib)
messages: 309502
nosy: akeeman
priority: normal
severity: normal
status: open
title: datetime.strptime creates tz naive object from value containing a tzname
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32497>
_______________________________________

From report at bugs.python.org  Fri Jan  5 14:15:10 2018
From: report at bugs.python.org (stein-k)
Date: Fri, 05 Jan 2018 19:15:10 +0000
Subject: [New-bugs-announce] [issue32498] urllib.parse.unquote raises
 incorrect errormessage when string parameter is bytes
Message-ID: <1515179710.49.0.467229070634.issue32498@psf.upfronthosting.co.za>


New submission from stein-k <karlsen.stein at gmail.com>:

urllib.parse.unquote(b'abc%20def')
...
TypeError: a bytes-like object is required, not 'str'

----------
components: Library (Lib)
messages: 309517
nosy: stein-k
priority: normal
severity: normal
status: open
title: urllib.parse.unquote raises incorrect errormessage when string parameter is bytes
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32498>
_______________________________________

From report at bugs.python.org  Fri Jan  5 15:50:22 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Fri, 05 Jan 2018 20:50:22 +0000
Subject: [New-bugs-announce] [issue32499] Add dataclasses.is_dataclass(obj)
Message-ID: <1515185422.79.0.467229070634.issue32499@psf.upfronthosting.co.za>


New submission from Eric V. Smith <eric at trueblade.com>:

See https://mail.python.org/pipermail/python-dev/2018-January/151628.html and prior for the discussion.

Add dataclasses.is_dataclass(obj) that returns True if obj is a dataclass class or instance, else returns False.

----------
assignee: eric.smith
components: Library (Lib)
messages: 309523
nosy: eric.smith
priority: normal
severity: normal
status: open
title: Add dataclasses.is_dataclass(obj)
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32499>
_______________________________________

From report at bugs.python.org  Fri Jan  5 19:38:27 2018
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBHw7Nybnk=?=)
Date: Sat, 06 Jan 2018 00:38:27 +0000
Subject: [New-bugs-announce] [issue32500] PySequence_Length() raises
 TypeError on dict type
Message-ID: <1515199107.36.0.467229070634.issue32500@psf.upfronthosting.co.za>


New submission from Micha? G?rny <mgorny at gentoo.org>:

While debugging PyPy test failure on backports.lzma [1], I've noticed that PySequence_Check() on a dict type raises TypeError, e.g.:

  Traceback (most recent call last):
    File "test/test_lzma.py", line 273, in test_bad_args
      b"", format=lzma.FORMAT_RAW, filters={})
    File "/home/mgorny/git/backports.lzma/build/lib.linux-x86_64-3.6/backports/lzma/__init__.py", line 463, in decompress
      decomp = LZMADecompressor(format, memlimit, filters)
  TypeError: object of type 'dict' has no len()

The relevant C code is:

  static int
  parse_filter_chain_spec(lzma_filter filters[], PyObject *filterspecs)
  {
    Py_ssize_t i, num_filters;

    num_filters = PySequence_Length(filterspecs);
    ...

where filterspecs is the object corresponding to the {} dict in Python snippet.

According to the documentation [2], PySequence_Length() should be 'equivalent to the Python expression len(o).' The Python expression obviously does not raise TypeError:

  >>> len({})
  0

Therefore, I think that the behavior of PySequence_Length() is a bug, and the function should successfully return the dict length instead.

[1]:https://github.com/peterjc/backports.lzma
[2]:https://docs.python.org/3/c-api/sequence.html#c.PySequence_Length

----------
components: Extension Modules
messages: 309534
nosy: mgorny
priority: normal
severity: normal
status: open
title: PySequence_Length() raises TypeError on dict type
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32500>
_______________________________________

From report at bugs.python.org  Sat Jan  6 03:54:03 2018
From: report at bugs.python.org (Vladislavs Burakovs)
Date: Sat, 06 Jan 2018 08:54:03 +0000
Subject: [New-bugs-announce] [issue32501] Documentation for dir([object])
Message-ID: <1515228843.27.0.467229070634.issue32501@psf.upfronthosting.co.za>


New submission from Vladislavs Burakovs <solomonchild at gmail.com>:

Documentation page [1]  says "If the object has a method named __dir__(), this method will be called and must return the list of attributes.". 

It seems that on Python 3.6 it only works if the *class* has a method named __dir__. Should the documentation be changed?

Microsoft Windows [Version 10.0.16299.192]
(c) 2017 Microsoft Corporation. All rights reserved.

D:\Users\wlad>python
Python 3.6.4 (v3.6.4:d48eceb, Dec 19 2017, 06:04:45) [MSC v.1900 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> class C: pass
...
>>> x = C()
>>> import types
>>> x.__dir__ = types.MethodType(lambda _:[], x)
>>> dir(x)
['__class__', '__delattr__', '__dict__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', '__init_subclass__', '__le__', '__lt__', '__module__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', '__weakref__']
>>> C.__dir__ = types.MethodType(lambda _:[], x)
>>> dir(x)
[]

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

----------
assignee: docs at python
components: Documentation
messages: 309544
nosy: Vladislavs Burakovs, docs at python
priority: normal
severity: normal
status: open
title: Documentation for dir([object])
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32501>
_______________________________________

From report at bugs.python.org  Sat Jan  6 11:26:25 2018
From: report at bugs.python.org (Andres Petralli)
Date: Sat, 06 Jan 2018 16:26:25 +0000
Subject: [New-bugs-announce] [issue32502] uuid1() broken on macos high sierra
Message-ID: <1515255985.98.0.467229070634.issue32502@psf.upfronthosting.co.za>


New submission from Andres Petralli <anpetral at microsoft.com>:

uuid.py is getting a 64 bit hardware address for the loopback adapter in High Sierra, specifically in _ifconfig_getnode(). The function expects a 48 bit mac address, but is instead getting 64 bits back and converting it to an int value that is too long for the subsequent call in uuid.py. Apple must have moved to using EUI-64 for the loopback adapters.

This is a sample output of the call to ifconfig that is being parsed:

b'lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384\n'
b'\toptions=1203<RXCSUM,TXCSUM,TXSTATUS,SW_TIMESTAMP>\n'
b'\tinet 127.0.0.1 netmask 0xff000000 \n'
b'\tinet6 ::1 prefixlen 128 \n'
b'\tlladdr 70:cd:60:ff:ab:cd:ef:12 \n'

As you can see, the lladdr is longer than the usual 48 bit mac address but is nontheless returned for the node value, which then triggers

ValueError('field 6 out of range (need a 48-bit value)')


Full traceback:


Traceback (most recent call last):
  File "/Users/andy/Desktop/test.py", line 3, in <module>
    str(uuid.uuid1())
  File "/usr/local/Cellar/python3/3.6.4_2/Frameworks/Python.framework/Versions/3.6/lib/python3.6/uuid.py", line 607, in uuid1
    clock_seq_hi_variant, clock_seq_low, node), version=1)
  File "/usr/local/Cellar/python3/3.6.4_2/Frameworks/Python.framework/Versions/3.6/lib/python3.6/uuid.py", line 168, in __init__
    raise ValueError('field 6 out of range (need a 48-bit value)')
ValueError: field 6 out of range (need a 48-bit value)

----------
components: macOS
messages: 309554
nosy: anpetral, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: uuid1() broken on macos high sierra
type: crash
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32502>
_______________________________________

From barry at python.org  Sat Jan  6 12:01:37 2018
From: barry at python.org (Barry Warsaw)
Date: Sat, 6 Jan 2018 12:01:37 -0500
Subject: [New-bugs-announce] [issue32502] uuid1() broken on macos high
 sierra
In-Reply-To: <1515255985.98.0.467229070634.issue32502@psf.upfronthosting.co.za>
References: <1515255985.98.0.467229070634.issue32502@psf.upfronthosting.co.za>
Message-ID: <65C933AA-5559-4BE8-A653-DC4CA9D8FDE4@python.org>

On Jan 6, 2018, at 11:26, Andres Petralli <report at bugs.python.org> wrote:
> 
> Traceback (most recent call last):
>  File "/Users/andy/Desktop/test.py", line 3, in <module>
>    str(uuid.uuid1())
>  File "/usr/local/Cellar/python3/3.6.4_2/Frameworks/Python.framework/Versions/3.6/lib/python3.6/uuid.py", line 607, in uuid1
>    clock_seq_hi_variant, clock_seq_low, node), version=1)
>  File "/usr/local/Cellar/python3/3.6.4_2/Frameworks/Python.framework/Versions/3.6/lib/python3.6/uuid.py", line 168, in __init__
>    raise ValueError('field 6 out of range (need a 48-bit value)')
> ValueError: field 6 out of range (need a 48-bit value)

Interesting.  This doesn?t fail for me on 10.13.2.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.python.org/pipermail/new-bugs-announce/attachments/20180106/485c97af/attachment.sig>

From report at bugs.python.org  Sat Jan  6 13:36:38 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sat, 06 Jan 2018 18:36:38 +0000
Subject: [New-bugs-announce] [issue32503] Avoid creating small frames in
 pickle protocol 4
Message-ID: <1515263798.96.0.467229070634.issue32503@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

Pickle protocol 4 uses framing for reducing the overhead of calling the read() method for small chunks of data. Most read chunks are small -- opcodes, small integers, short strings, etc, and calling read() for every 1 or 4 bytes is too expensive. But using framing itself adds an overhead. It increases the size of pickled data by 9 bytes. A frame  itself needs 3 reads -- the opcode, the frame size, and a payload. Thus it doesn't make sense to create a frame containing less than 3 chunks of data.

For example after issue31993 pickling the list [b'a'*70000, b'b'*70000] with the Python implementation produces a data containing 3 frames of sizes 3, 1 and 3. Using frames here is completely redundant.

----------
components: Library (Lib)
messages: 309564
nosy: Olivier.Grisel, alexandre.vassalotti, pitrou, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Avoid creating small frames in pickle protocol 4
type: performance
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32503>
_______________________________________

From report at bugs.python.org  Sat Jan  6 14:02:08 2018
From: report at bugs.python.org (atya)
Date: Sat, 06 Jan 2018 19:02:08 +0000
Subject: [New-bugs-announce] [issue32504] Wheel failed include data_files
Message-ID: <1515265328.42.0.467229070634.issue32504@psf.upfronthosting.co.za>


New submission from atya <newatar51 at gmail.com>:

Hi,

I created a  wheel using python3.4 install bdist_wheel command.

I have data dir and in contains files Test.png.

in setup.py I added
data_files=[
        ('/usr/share', ['data/Test.png'])
        ]

when I am instaating the wheel the data files did not copy.

----------
components: Build
messages: 309569
nosy: atya
priority: normal
severity: normal
status: open
title: Wheel failed include data_files
versions: Python 3.4

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32504>
_______________________________________

From report at bugs.python.org  Sat Jan  6 17:21:04 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 06 Jan 2018 22:21:04 +0000
Subject: [New-bugs-announce] [issue32505] dataclasses: make field() with no
 annotation an error
Message-ID: <1515277264.9.0.467229070634.issue32505@psf.upfronthosting.co.za>


New submission from Eric V. Smith <eric at trueblade.com>:

This is an attractive nuisance, especially when coming from attrs. Make it an error, since it's using field() with no annotation:

@dataclass
class C:
    x = field()

----------
assignee: eric.smith
messages: 309586
nosy: eric.smith, gvanrossum, levkivskyi
priority: normal
severity: normal
status: open
title: dataclasses: make field() with no annotation an error
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32505>
_______________________________________

From report at bugs.python.org  Sat Jan  6 17:23:30 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sat, 06 Jan 2018 22:23:30 +0000
Subject: [New-bugs-announce] [issue32506] dataclasses: no need for
 OrderedDict now that dict guarantees to keep insertion order
Message-ID: <1515277410.84.0.467229070634.issue32506@psf.upfronthosting.co.za>


New submission from Eric V. Smith <eric at trueblade.com>:

There are several places where OrderedDict escapes from dataclasses. Switching to dict means we don't have to use OrderedDict forever.

For the 3.6 backport, I'm also going to use dict. I saw an analysis (from Raymond, maybe?) that says there are no 3.6 implementations that don't guarantee insertion order for dict.

----------
assignee: eric.smith
messages: 309587
nosy: eric.smith
priority: normal
severity: normal
status: open
title: dataclasses: no need for OrderedDict now that dict guarantees to keep insertion order
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32506>
_______________________________________

From report at bugs.python.org  Sat Jan  6 18:59:01 2018
From: report at bugs.python.org (Steve Dower)
Date: Sat, 06 Jan 2018 23:59:01 +0000
Subject: [New-bugs-announce] [issue32507] Change Windows install to applocal
 UCRT
Message-ID: <1515283141.58.0.467229070634.issue32507@psf.upfronthosting.co.za>


New submission from Steve Dower <steve.dower at python.org>:

There's enough instability due to using the proper UCRT installer (e.g. issue25546, issue25954, also others not reported on bpo) and good enough install base that we can simplify things by just installing it locally on machines that require it.

This may also require updating venv (though I think we're fine) and virtualenv (I'll ping).

My proposal is to bundle the UCRT redistributable DLLs into their own MSI and install them alongside the main executable when required. If a user later installs it properly, the up-to-date version will be used instead. This should be good enough to cover people still on Windows 7/8, and will also reduce the installer size slightly (though at the cost of potentially breaking non-standard virtual environments or entrypoint stubs that link to the CRT dynamically).

----------
assignee: steve.dower
components: Windows
messages: 309589
nosy: paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Change Windows install to applocal UCRT
type: enhancement
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32507>
_______________________________________

From report at bugs.python.org  Sat Jan  6 21:37:23 2018
From: report at bugs.python.org (J Viswanathan)
Date: Sun, 07 Jan 2018 02:37:23 +0000
Subject: [New-bugs-announce] [issue32508] Problem while reading back from a
 list of lists
Message-ID: <CAPsjwoCgBoN=o=ZPyzM_1prYvRW2+5vivak3ZOUEU4nBiz+COw@mail.gmail.com>


New submission from J Viswanathan <Viswanathan10 at gmail.com>:

Please see the attached source file,  the related data file and the log
file.

When run with

 python hksu_copy.py  check_su.dat

the following is the output (which is incorrect):

-*- mode: compilation; default-directory: "c:/Users/J V/Documents/gamsdir/"
-*-
Compilation started at Sun Jan  7 07:54:52

python hksu_copy.py check_su.dat
nedge, check_k 1 1
nedge, check_k 2 2
nedge, check_k 3 4
nedge, check_k 4 2
nedge, klist 4 [1, 2, 4]
nedge, check_k 5 4
nedge, check_k 6 7
nedge, check_k 7 2
nedge, klist 7 [2, 4, 7]
nedge, check_k 8 4
nedge, check_k 9 7
nedge, check_k 10 1
nedge, klist 10 [2, 4, 7]
nedge, check_k 11 2
nedge, check_k 12 2
nedge, klist 12 [1, 2]
nedge, check_k 13 6
nedge, check_k 14 2
nedge, klist 14 [2, 6]
nedge, check_k 15 4
nedge, check_k 16 6
nedge, check_k 17 8
nedge, check_k 18 2
nedge, klist 18 [2, 4, 6, 8]
nedge, check_k 19 3
nedge, check_k 20 3
nedge, klist 20 [2, 3]
nedge, check_k 21 4
nedge, check_k 22 2
nedge, klist 22 [3, 4]
nedge, check_k 23 4
nedge, check_k 24 1
nedge, klist 24 [2, 4]
nedge, check_k 25 4
nedge, check_k 26 8
nedge, check_k 27 9
nedge, check_k 28 1
nedge, klist 28 [1, 4, 8, 9]
nedge, check_k 29 2
nedge, check_k 30 4
nedge, check_k 31 9
nedge, check_k 32 2
nedge, klist 32 [1, 2, 4, 9]
nedge, check_k 33 4
nedge, check_k 34 8
nedge, check_k 35 3
nedge, klist 35 [2, 4, 8]
nedge, check_k 36 4
nedge, check_k 37 7
nedge, check_k 38 8
nedge, check_k 39 2
nedge, klist 39 [3, 4, 7, 8]
nedge, check_k 40 3
nedge, check_k 41 4
nedge, check_k 42 2
nedge, klist 42 [2, 3, 4]
nedge, check_k 43 4
nedge, check_k 44 7
nedge, check_k 45 8
nedge, check_k 46 1
nedge, klist 46 [2, 4, 7, 8]
nedge, check_k 47 3
nedge, check_k 48 4
nedge, check_k 49 5
nedge, check_k 50 7
nedge, check_k 51 2
nedge, klist 51 [1, 3, 4, 5, 7]
nedge, check_k 52 4
nedge, check_k 53 7
nedge, check_k 54 1
nedge, klist 54 [2, 4, 7]
nedge, check_k 55 2
nedge, check_k 56 5
nedge, check_k 57 1
nedge, klist 57 [1, 2, 5]
nedge, check_k 58 2
nedge, check_k 59 5
nedge, check_k 60 9
nedge, check_k 61 2
nedge, klist 61 [1, 2, 5, 9]
nedge, check_k 62 5
nedge, check_k 63 2
nedge, klist 63 [2, 5]
nedge, check_k 64 5
nedge, check_k 65 6
nedge, check_k 66 9
nedge, check_k 67 1
nedge, klist 67 [2, 5, 6, 9]
nedge, check_k 68 5
nedge, check_k 69 1
nedge, klist 69 [1, 5]
nedge, check_k 70 3
nedge, check_k 71 5
nedge, check_k 72 9
nedge, check_k 73 5
nedge, klist 73 [1, 3, 5, 9]
nedge, check_k 74 7
nedge, check_k 75 9
nedge, check_k 76 1
nedge, klist 76 [5, 7, 9]
nedge, check_k 77 4
nedge, check_k 78 7
nedge, check_k 79 5
nedge, klist 79 [1, 4, 7]
nedge, check_k 80 5
nedge, klist 80 [5]
nedge, check_k 81 9
nedge, check_k 82 1
nedge, klist 82 [5, 9]
nedge, check_k 83 4
nedge, check_k 84 4
nedge, klist 84 [1, 4]
nedge, check_k 85 5
nedge, check_k 86 7
nedge, check_k 87 9
nedge, check_k 88 2
nedge, klist 88 [4, 5, 7, 9]
nedge, check_k 89 4
nedge, check_k 90 5
nedge, check_k 91 9
nedge, check_k 92 5
nedge, klist 92 [2, 4, 5, 9]
nedge, check_k 93 7
nedge, check_k 94 9
nedge, check_k 95 2
nedge, klist 95 [5, 7, 9]
nedge, check_k 96 5
nedge, check_k 97 9
nedge, check_k 98 4
nedge, klist 98 [2, 5, 9]
nedge, check_k 99 5
nedge, check_k 100 8
nedge, check_k 101 9
nedge, check_k 102 4
nedge, klist 102 [4, 5, 8, 9]
nedge, check_k 103 5
nedge, check_k 104 9
nedge, check_k 105 1
nedge, klist 105 [4, 5, 9]
nedge, check_k 106 3
nedge, check_k 107 9
nedge, check_k 108 1
nedge, klist 108 [1, 3, 9]
nedge, check_k 109 3
nedge, check_k 110 4
nedge, check_k 111 5
nedge, check_k 112 7
nedge, check_k 113 9
nedge, check_k 114 2
nedge, klist 114 [1, 3, 4, 5, 7, 9]
nedge, check_k 115 3
nedge, check_k 116 2
nedge, klist 116 [2, 3]
nedge, check_k 117 7
nedge, check_k 118 8
nedge, check_k 119 2
nedge, klist 119 [2, 7, 8]
nedge, check_k 120 3
nedge, check_k 121 7
nedge, check_k 122 1
nedge, klist 122 [2, 3, 7]
nedge, check_k 123 2
nedge, check_k 124 3
nedge, check_k 125 1
nedge, klist 125 [1, 2, 3]
nedge, check_k 126 2
nedge, check_k 127 4
nedge, check_k 128 5
nedge, check_k 129 1
nedge, klist 129 [1, 2, 4, 5]
nedge, check_k 130 2
nedge, check_k 131 3
nedge, check_k 132 4
nedge, check_k 133 5
nedge, check_k 134 3
nedge, klist 134 [1, 2, 3, 4, 5]
nedge, check_k 135 5
nedge, check_k 136 7
nedge, check_k 137 3
nedge, klist 137 [3, 5, 7]
nedge, check_k 138 5
nedge, check_k 139 7
nedge, klist 139 [3, 5]
nedge, check_k 140 2
nedge, klist 140 [7]
nedge, check_k 141 3
nedge, check_k 142 5
nedge, check_k 143 6
nedge, check_k 144 2
nedge, klist 144 [2, 3, 5, 6]
nedge, check_k 145 6
nedge, check_k 146 4
nedge, klist 146 [2, 6]
nedge, check_k 147 3
nedge, klist 147 [4]
nedge, check_k 148 6
nedge, check_k 149 3
nedge, klist 149 [3, 6]
nedge, check_k 150 1
nedge, klist 150 [3]
nedge, check_k 151 3
nedge, check_k 152 4
nedge, check_k 153 6
 No. of edges:  153
The last of the klists : nedge, klist 153 [1, 3, 4, 6]
 No. of left vertices :  51  No. of right vertices :  51
x :  0  klist :  [1, 3, 4, 6]
x :  1  klist :  [1, 3, 4, 6]
x :  2  klist :  [1, 3, 4, 6]
x :  3  klist :  [1, 3, 4, 6]
x :  4  klist :  [1, 3, 4, 6]
x :  5  klist :  [1, 3, 4, 6]
x :  6  klist :  [1, 3, 4, 6]
x :  7  klist :  [1, 3, 4, 6]
x :  8  klist :  [1, 3, 4, 6]
x :  9  klist :  [1, 3, 4, 6]
x :  10  klist :  [1, 3, 4, 6]
x :  11  klist :  [1, 3, 4, 6]
x :  12  klist :  [1, 3, 4, 6]
x :  13  klist :  [1, 3, 4, 6]
x :  14  klist :  [1, 3, 4, 6]
x :  15  klist :  [1, 3, 4, 6]
x :  16  klist :  [1, 3, 4, 6]
x :  17  klist :  [1, 3, 4, 6]
x :  18  klist :  [1, 3, 4, 6]
x :  19  klist :  [1, 3, 4, 6]
x :  20  klist :  [1, 3, 4, 6]
x :  21  klist :  [1, 3, 4, 6]
x :  22  klist :  [1, 3, 4, 6]
x :  23  klist :  [1, 3, 4, 6]
x :  24  klist :  [1, 3, 4, 6]
x :  25  klist :  [1, 3, 4, 6]
x :  26  klist :  [1, 3, 4, 6]
x :  27  klist :  [1, 3, 4, 6]
x :  28  klist :  [1, 3, 4, 6]
x :  29  klist :  [1, 3, 4, 6]
x :  30  klist :  [1, 3, 4, 6]
x :  31  klist :  [1, 3, 4, 6]
x :  32  klist :  [1, 3, 4, 6]
x :  33  klist :  [1, 3, 4, 6]
x :  34  klist :  [1, 3, 4, 6]
x :  35  klist :  [1, 3, 4, 6]
x :  36  klist :  [1, 3, 4, 6]
x :  37  klist :  [1, 3, 4, 6]
x :  38  klist :  [1, 3, 4, 6]
x :  39  klist :  [1, 3, 4, 6]
x :  40  klist :  [1, 3, 4, 6]
x :  41  klist :  [1, 3, 4, 6]
x :  42  klist :  [1, 3, 4, 6]
x :  43  klist :  [1, 3, 4, 6]
x :  44  klist :  [1, 3, 4, 6]
x :  45  klist :  [1, 3, 4, 6]
x :  46  klist :  [1, 3, 4, 6]
x :  47  klist :  [1, 3, 4, 6]
x :  48  klist :  [1, 3, 4, 6]
x :  49  klist :  [1, 3, 4, 6]
x :  50  klist :  [1, 3, 4, 6]

Compilation finished at Sun Jan  7 07:54:52

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

The correct  results are:

x: 0    klist: [1,2,4]
x: 1    klist  [2,4,7]
x:2     klist: [2,4,7]

etc.

----------
files: check_su.dat, compilation_log, hksu_copy.py
messages: 309597
nosy: JHari
priority: normal
severity: normal
status: open
title: Problem while reading back from a list of lists
Added file: https://bugs.python.org/file47367/hksu_copy.py
Added file: https://bugs.python.org/file47368/check_su.dat
Added file: https://bugs.python.org/file47369/compilation_log

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32508>
_______________________________________
-------------- next part --------------

from re import compile, findall

from locale import atoi

uids = []
klists = []

def read_input(input):
    nedge = 0
    check_uid =[0,0,0,0]
    klist = []
    regex = compile('[^ \t\n]+')

    with  open(input, 'r') as f:

        for line in f:

            indices = findall(regex, line)
            if len(indices) != 5 :
                print ('read input: len(indices)', len(indices))
                exit
                
            nedge += 1

            lid = indices[0:4]
            check_k = atoi(indices[4])

            print ('nedge, check_k', nedge, check_k)

            if (lid == check_uid): #an existing uid
                klist.append(check_k)
            else:
                check_uid = lid
                uids.append(check_uid) # a new
                if len(klist):
                    klists.append(klist)
                    print ('nedge, klist', nedge, klist)
                    klist.clear()
                klist.append(check_k)
            #end of if block
        #end of for block
        
    print(' No. of edges: ', nedge)
    print ('The last of the klists : nedge, klist', nedge, klist)
    klists.append(klist)   # The last of the klists
    
def generate_sudoku_data():
    nleft = len(uids)
    nright = len(klists)
    print( ' No. of left vertices : ', nleft,
           ' No. of right vertices : ', nright)
    if nleft != nright:
        print ('generate_sudoku_data: nright', nright)
        exit

    for x in range(0, nleft, 1):
        klist = klists[x]
        print('x : ', x, ' klist : ', klist)



def HK(input):
    read_input(input)
    generate_sudoku_data()

if __name__ == "__main__":
    import sys
    HK(sys.argv[1])
-------------- next part --------------
1 1 1 3 1
1 1 1 3 2
1 1 1 3 4
1 1 2 2 2
1 1 2 2 4
1 1 2 2 7
1 1 2 3 2
1 1 2 3 4
1 1 2 3 7
1 1 3 1 1
1 1 3 1 2
1 2 1 4 2
1 2 1 4 6
1 2 1 6 2
1 2 1 6 4
1 2 1 6 6
1 2 1 6 8
1 2 3 4 2
1 2 3 4 3
1 2 3 5 3
1 2 3 5 4
1 2 3 6 2
1 2 3 6 4
1 3 1 7 1
1 3 1 7 4
1 3 1 7 8
1 3 1 7 9
1 3 1 8 1
1 3 1 8 2
1 3 1 8 4
1 3 1 8 9
1 3 1 9 2
1 3 1 9 4
1 3 1 9 8
1 3 2 7 3
1 3 2 7 4
1 3 2 7 7
1 3 2 7 8
1 3 2 8 2
1 3 2 8 3
1 3 2 8 4
1 3 2 9 2
1 3 2 9 4
1 3 2 9 7
1 3 2 9 8
1 3 3 7 1
1 3 3 7 3
1 3 3 7 4
1 3 3 7 5
1 3 3 7 7
1 3 3 9 2
1 3 3 9 4
1 3 3 9 7
2 1 4 2 1
2 1 4 2 2
2 1 4 2 5
2 1 4 3 1
2 1 4 3 2
2 1 4 3 5
2 1 4 3 9
2 1 5 2 2
2 1 5 2 5
2 1 5 3 2
2 1 5 3 5
2 1 5 3 6
2 1 5 3 9
2 1 6 2 1
2 1 6 2 5
2 1 6 3 1
2 1 6 3 3
2 1 6 3 5
2 1 6 3 9
2 2 4 4 5
2 2 4 4 7
2 2 4 4 9
2 2 4 6 1
2 2 4 6 4
2 2 4 6 7
2 2 5 5 5
2 2 6 4 5
2 2 6 4 9
2 2 6 6 1
2 2 6 6 4
2 3 4 7 4
2 3 4 7 5
2 3 4 7 7
2 3 4 7 9
2 3 4 8 2
2 3 4 8 4
2 3 4 8 5
2 3 4 8 9
2 3 5 7 5
2 3 5 7 7
2 3 5 7 9
2 3 5 8 2
2 3 5 8 5
2 3 5 8 9
2 3 6 7 4
2 3 6 7 5
2 3 6 7 8
2 3 6 7 9
2 3 6 8 4
2 3 6 8 5
2 3 6 8 9
3 1 7 1 1
3 1 7 1 3
3 1 7 1 9
3 1 7 3 1
3 1 7 3 3
3 1 7 3 4
3 1 7 3 5
3 1 7 3 7
3 1 7 3 9
3 1 8 1 2
3 1 8 1 3
3 1 8 2 2
3 1 8 2 7
3 1 8 2 8
3 1 8 3 2
3 1 8 3 3
3 1 8 3 7
3 1 9 1 1
3 1 9 1 2
3 1 9 1 3
3 1 9 2 1
3 1 9 2 2
3 1 9 2 4
3 1 9 2 5
3 1 9 3 1
3 1 9 3 2
3 1 9 3 3
3 1 9 3 4
3 1 9 3 5
3 2 7 4 3
3 2 7 4 5
3 2 7 4 7
3 2 7 5 3
3 2 7 5 5
3 2 7 6 7
3 2 9 4 2
3 2 9 4 3
3 2 9 4 5
3 2 9 4 6
3 2 9 6 2
3 2 9 6 6
3 3 7 9 4
3 3 8 7 3
3 3 8 7 6
3 3 8 8 3
3 3 9 7 1
3 3 9 7 3
3 3 9 7 4
3 3 9 7 6
-------------- next part --------------
-*- mode: compilation; default-directory: "c:/Users/J V/Documents/gamsdir/" -*-
Compilation started at Sun Jan  7 07:54:52

python hksu_copy.py check_su.dat
nedge, check_k 1 1
nedge, check_k 2 2
nedge, check_k 3 4
nedge, check_k 4 2
nedge, klist 4 [1, 2, 4]
nedge, check_k 5 4
nedge, check_k 6 7
nedge, check_k 7 2
nedge, klist 7 [2, 4, 7]
nedge, check_k 8 4
nedge, check_k 9 7
nedge, check_k 10 1
nedge, klist 10 [2, 4, 7]
nedge, check_k 11 2
nedge, check_k 12 2
nedge, klist 12 [1, 2]
nedge, check_k 13 6
nedge, check_k 14 2
nedge, klist 14 [2, 6]
nedge, check_k 15 4
nedge, check_k 16 6
nedge, check_k 17 8
nedge, check_k 18 2
nedge, klist 18 [2, 4, 6, 8]
nedge, check_k 19 3
nedge, check_k 20 3
nedge, klist 20 [2, 3]
nedge, check_k 21 4
nedge, check_k 22 2
nedge, klist 22 [3, 4]
nedge, check_k 23 4
nedge, check_k 24 1
nedge, klist 24 [2, 4]
nedge, check_k 25 4
nedge, check_k 26 8
nedge, check_k 27 9
nedge, check_k 28 1
nedge, klist 28 [1, 4, 8, 9]
nedge, check_k 29 2
nedge, check_k 30 4
nedge, check_k 31 9
nedge, check_k 32 2
nedge, klist 32 [1, 2, 4, 9]
nedge, check_k 33 4
nedge, check_k 34 8
nedge, check_k 35 3
nedge, klist 35 [2, 4, 8]
nedge, check_k 36 4
nedge, check_k 37 7
nedge, check_k 38 8
nedge, check_k 39 2
nedge, klist 39 [3, 4, 7, 8]
nedge, check_k 40 3
nedge, check_k 41 4
nedge, check_k 42 2
nedge, klist 42 [2, 3, 4]
nedge, check_k 43 4
nedge, check_k 44 7
nedge, check_k 45 8
nedge, check_k 46 1
nedge, klist 46 [2, 4, 7, 8]
nedge, check_k 47 3
nedge, check_k 48 4
nedge, check_k 49 5
nedge, check_k 50 7
nedge, check_k 51 2
nedge, klist 51 [1, 3, 4, 5, 7]
nedge, check_k 52 4
nedge, check_k 53 7
nedge, check_k 54 1
nedge, klist 54 [2, 4, 7]
nedge, check_k 55 2
nedge, check_k 56 5
nedge, check_k 57 1
nedge, klist 57 [1, 2, 5]
nedge, check_k 58 2
nedge, check_k 59 5
nedge, check_k 60 9
nedge, check_k 61 2
nedge, klist 61 [1, 2, 5, 9]
nedge, check_k 62 5
nedge, check_k 63 2
nedge, klist 63 [2, 5]
nedge, check_k 64 5
nedge, check_k 65 6
nedge, check_k 66 9
nedge, check_k 67 1
nedge, klist 67 [2, 5, 6, 9]
nedge, check_k 68 5
nedge, check_k 69 1
nedge, klist 69 [1, 5]
nedge, check_k 70 3
nedge, check_k 71 5
nedge, check_k 72 9
nedge, check_k 73 5
nedge, klist 73 [1, 3, 5, 9]
nedge, check_k 74 7
nedge, check_k 75 9
nedge, check_k 76 1
nedge, klist 76 [5, 7, 9]
nedge, check_k 77 4
nedge, check_k 78 7
nedge, check_k 79 5
nedge, klist 79 [1, 4, 7]
nedge, check_k 80 5
nedge, klist 80 [5]
nedge, check_k 81 9
nedge, check_k 82 1
nedge, klist 82 [5, 9]
nedge, check_k 83 4
nedge, check_k 84 4
nedge, klist 84 [1, 4]
nedge, check_k 85 5
nedge, check_k 86 7
nedge, check_k 87 9
nedge, check_k 88 2
nedge, klist 88 [4, 5, 7, 9]
nedge, check_k 89 4
nedge, check_k 90 5
nedge, check_k 91 9
nedge, check_k 92 5
nedge, klist 92 [2, 4, 5, 9]
nedge, check_k 93 7
nedge, check_k 94 9
nedge, check_k 95 2
nedge, klist 95 [5, 7, 9]
nedge, check_k 96 5
nedge, check_k 97 9
nedge, check_k 98 4
nedge, klist 98 [2, 5, 9]
nedge, check_k 99 5
nedge, check_k 100 8
nedge, check_k 101 9
nedge, check_k 102 4
nedge, klist 102 [4, 5, 8, 9]
nedge, check_k 103 5
nedge, check_k 104 9
nedge, check_k 105 1
nedge, klist 105 [4, 5, 9]
nedge, check_k 106 3
nedge, check_k 107 9
nedge, check_k 108 1
nedge, klist 108 [1, 3, 9]
nedge, check_k 109 3
nedge, check_k 110 4
nedge, check_k 111 5
nedge, check_k 112 7
nedge, check_k 113 9
nedge, check_k 114 2
nedge, klist 114 [1, 3, 4, 5, 7, 9]
nedge, check_k 115 3
nedge, check_k 116 2
nedge, klist 116 [2, 3]
nedge, check_k 117 7
nedge, check_k 118 8
nedge, check_k 119 2
nedge, klist 119 [2, 7, 8]
nedge, check_k 120 3
nedge, check_k 121 7
nedge, check_k 122 1
nedge, klist 122 [2, 3, 7]
nedge, check_k 123 2
nedge, check_k 124 3
nedge, check_k 125 1
nedge, klist 125 [1, 2, 3]
nedge, check_k 126 2
nedge, check_k 127 4
nedge, check_k 128 5
nedge, check_k 129 1
nedge, klist 129 [1, 2, 4, 5]
nedge, check_k 130 2
nedge, check_k 131 3
nedge, check_k 132 4
nedge, check_k 133 5
nedge, check_k 134 3
nedge, klist 134 [1, 2, 3, 4, 5]
nedge, check_k 135 5
nedge, check_k 136 7
nedge, check_k 137 3
nedge, klist 137 [3, 5, 7]
nedge, check_k 138 5
nedge, check_k 139 7
nedge, klist 139 [3, 5]
nedge, check_k 140 2
nedge, klist 140 [7]
nedge, check_k 141 3
nedge, check_k 142 5
nedge, check_k 143 6
nedge, check_k 144 2
nedge, klist 144 [2, 3, 5, 6]
nedge, check_k 145 6
nedge, check_k 146 4
nedge, klist 146 [2, 6]
nedge, check_k 147 3
nedge, klist 147 [4]
nedge, check_k 148 6
nedge, check_k 149 3
nedge, klist 149 [3, 6]
nedge, check_k 150 1
nedge, klist 150 [3]
nedge, check_k 151 3
nedge, check_k 152 4
nedge, check_k 153 6
 No. of edges:  153
The last of the klists : nedge, klist 153 [1, 3, 4, 6]
 No. of left vertices :  51  No. of right vertices :  51
x :  0  klist :  [1, 3, 4, 6]
x :  1  klist :  [1, 3, 4, 6]
x :  2  klist :  [1, 3, 4, 6]
x :  3  klist :  [1, 3, 4, 6]
x :  4  klist :  [1, 3, 4, 6]
x :  5  klist :  [1, 3, 4, 6]
x :  6  klist :  [1, 3, 4, 6]
x :  7  klist :  [1, 3, 4, 6]
x :  8  klist :  [1, 3, 4, 6]
x :  9  klist :  [1, 3, 4, 6]
x :  10  klist :  [1, 3, 4, 6]
x :  11  klist :  [1, 3, 4, 6]
x :  12  klist :  [1, 3, 4, 6]
x :  13  klist :  [1, 3, 4, 6]
x :  14  klist :  [1, 3, 4, 6]
x :  15  klist :  [1, 3, 4, 6]
x :  16  klist :  [1, 3, 4, 6]
x :  17  klist :  [1, 3, 4, 6]
x :  18  klist :  [1, 3, 4, 6]
x :  19  klist :  [1, 3, 4, 6]
x :  20  klist :  [1, 3, 4, 6]
x :  21  klist :  [1, 3, 4, 6]
x :  22  klist :  [1, 3, 4, 6]
x :  23  klist :  [1, 3, 4, 6]
x :  24  klist :  [1, 3, 4, 6]
x :  25  klist :  [1, 3, 4, 6]
x :  26  klist :  [1, 3, 4, 6]
x :  27  klist :  [1, 3, 4, 6]
x :  28  klist :  [1, 3, 4, 6]
x :  29  klist :  [1, 3, 4, 6]
x :  30  klist :  [1, 3, 4, 6]
x :  31  klist :  [1, 3, 4, 6]
x :  32  klist :  [1, 3, 4, 6]
x :  33  klist :  [1, 3, 4, 6]
x :  34  klist :  [1, 3, 4, 6]
x :  35  klist :  [1, 3, 4, 6]
x :  36  klist :  [1, 3, 4, 6]
x :  37  klist :  [1, 3, 4, 6]
x :  38  klist :  [1, 3, 4, 6]
x :  39  klist :  [1, 3, 4, 6]
x :  40  klist :  [1, 3, 4, 6]
x :  41  klist :  [1, 3, 4, 6]
x :  42  klist :  [1, 3, 4, 6]
x :  43  klist :  [1, 3, 4, 6]
x :  44  klist :  [1, 3, 4, 6]
x :  45  klist :  [1, 3, 4, 6]
x :  46  klist :  [1, 3, 4, 6]
x :  47  klist :  [1, 3, 4, 6]
x :  48  klist :  [1, 3, 4, 6]
x :  49  klist :  [1, 3, 4, 6]
x :  50  klist :  [1, 3, 4, 6]

Compilation finished at Sun Jan  7 07:54:52

From report at bugs.python.org  Sat Jan  6 23:05:17 2018
From: report at bugs.python.org (Jason R. Coombs)
Date: Sun, 07 Jan 2018 04:05:17 +0000
Subject: [New-bugs-announce] [issue32509] doctest syntax ambiguity between
 continuation line and ellipsis
Message-ID: <1515297917.31.0.467229070634.issue32509@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

I'm trying to write a doctest that prints the hash and filename of a directory. The input is the test dir, but due to the unordered nature of file systems, the doctest checks for one known file:

def hash_files(root):
	"""
	>>> res = hash_files(Path(__file__).dirname())
	Discovering documents
	Hashing documents
	...
	>>> print(res)
	...
	d41d8cd98f00b204e9800998ecf8427e __init__.py
	...
	"""

However, this test fails with:

????????????????????????? [doctest] jaraco.financial.records.hash_files ??????????????????????????
047 
048 	>>> res = hash_files(Path(__file__).dirname())
049 	Discovering documents
050 	Hashing documents
051 	...
052 	>>> print(res)
Expected:
    d41d8cd98f00b204e9800998ecf8427e __init__.py
    ...
Got:
    e1f9390d13c90c7ed601afffd1b9a9f9 records.py
    6a116973e8f29c923a08c2be69b11859 ledger.py
    d41d8cd98f00b204e9800998ecf8427e __init__.py
    b83c8a54d6b71e28ccb556a828e3fa5e qif.py
    ac2d598f65b6debe9888aafe51e9570f ofx.py
    9f2572f761342d38239a1394f4337165 msmoney.py
    <BLANKLINE>



The first ellipsis is interpreted as a degenerate continuation of the input line, and it seems it's not possible to have an ellipsis at the beginning of the expected input.

Is there any workaround for this issue?

----------
messages: 309599
nosy: jason.coombs
priority: normal
severity: normal
status: open
title: doctest syntax ambiguity between continuation line and ellipsis
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32509>
_______________________________________

From report at bugs.python.org  Sun Jan  7 09:15:32 2018
From: report at bugs.python.org (Thermi)
Date: Sun, 07 Jan 2018 14:15:32 +0000
Subject: [New-bugs-announce] [issue32510] Broken comparisons (probably
 caused by wrong caching of values)
Message-ID: <1515334532.4.0.467229070634.issue32510@psf.upfronthosting.co.za>


New submission from Thermi <noel.kuntze+bugs-python-org at thermi.consulting>:

With Python 3.6.4 on Arch Linux, on three different hosts (one Skylake CPU, one i7-3820, one Xeon E5-2680, all running Arch Linux with the same Python version), the Python 3 interpreter behaves erratically in a script of mine.

The following symptoms occur:
1) Comparisons fail, although they logically need to succeed. The comparisons work a lot of the times, but sometimes, they don't.
2) Integers magically increase without ever being written to in the code after initially assigned in the constructor.

The behaviour changes if code is rearranged, variables and lines are added that do not pertain the broken comparisons, making accidental writes to memory or reads from unitialized memory likely.

The breakage occurs in the code between line 114 and the execution of the code in the recurse() method of the class Branch.

The script is here (https://gist.github.com/Thermi/05bc671436841670ac81b3b86217dd62). It basically only does some arithmetic with translation tables.

----------
components: Interpreter Core
messages: 309619
nosy: Thermi
priority: normal
severity: normal
status: open
title: Broken comparisons (probably caused by wrong caching of values)
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32510>
_______________________________________

From report at bugs.python.org  Sun Jan  7 10:50:08 2018
From: report at bugs.python.org (Zack Weinberg)
Date: Sun, 07 Jan 2018 15:50:08 +0000
Subject: [New-bugs-announce] [issue32511] Thread primitives do not report
 the OS-level error on failure
Message-ID: <1515340208.41.0.467229070634.issue32511@psf.upfronthosting.co.za>


New submission from Zack Weinberg <zackw at panix.com>:

[_]thread.start_new_thread can fail if the underlying OS primitive fails (pthread_create / _beginthreadex), but the exception that is thrown when this happens is a generic RuntimeError (it's _called_ ThreadError in the source code, but it doesn't have its own subtype, so you can't even catch it specifically) and the OS-level error code is lost.  It should instead throw (an appropriate subclass of) OSError and capture the error code, like when other OS primitives fail.

Reading through the code, it looks like _all_ of the threading code has this problem - throughout [_]threadmodule.c, thread.c, and thread_pthread.h, I see error codes being dropped on the floor or at best reported with perror or dprintf, not properly captured in an OSError.

This affects all maintained versions of Python, but sadly I expect it's messy enough to fix that it's only practical to do so on trunk.

----------
components: Library (Lib)
messages: 309623
nosy: zwol
priority: normal
severity: normal
status: open
title: Thread primitives do not report the OS-level error on failure
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32511>
_______________________________________

From report at bugs.python.org  Sun Jan  7 12:00:27 2018
From: report at bugs.python.org (Mario Corchero)
Date: Sun, 07 Jan 2018 17:00:27 +0000
Subject: [New-bugs-announce] [issue32512] Add an option to profile to run
 library module as a script
Message-ID: <1515344427.94.0.467229070634.issue32512@psf.upfronthosting.co.za>


New submission from Mario Corchero <mariocj89 at gmail.com>:

Add an option to profile to be able to do `python3 -m profile -m my.module.name` to be able to profile the module the same way cProfile allows since issue 21862

----------
components: Library (Lib)
messages: 309627
nosy: mariocj89
priority: normal
severity: normal
status: open
title: Add an option to profile to run library module as a script
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32512>
_______________________________________

From report at bugs.python.org  Sun Jan  7 12:06:05 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 07 Jan 2018 17:06:05 +0000
Subject: [New-bugs-announce] [issue32513] dataclasses: make it easier to use
 user-supplied special methods
Message-ID: <1515344765.63.0.467229070634.issue32513@psf.upfronthosting.co.za>


New submission from Eric V. Smith <eric at trueblade.com>:

Modify dataclasses to make it easier to specify special methods.

For example: currently, if you want to override __repr__, you need to specify @dataclass(repr=False), and also provide your own __repr__. Also, it's current an error to not specify repr=False and to also provide your own __repr__.  @dataclass should be able to determine that if you provide __repr__, you don't want it to provide it's own __repr__.

The methods that @dataclass will provide for you are:
__init__
__repr__
__eq__
__ne__
__lt__
__le__
__gt__
__ge__
_hash__
and if using frozen=True, also:
__setattr__
__delattr__

Per the discussion that started at https://mail.python.org/pipermail/python-dev/2017-December/151487.html, the change will be to override these methods only if:
1. the method would have been generated based on @dataclass params, and
2. the method is not present in the class's __dict__.

The first item is to allow the user to continue to suppress method generation, and the second item is so that base-class methods are not considered in the decision.

I'm still thinking through how __eq__ and __ne__ should be handled (as well as the ordering comparisons, too). I'll raise an issue on python-dev and point it here.

----------
assignee: eric.smith
messages: 309628
nosy: eric.smith
priority: normal
severity: normal
status: open
title: dataclasses: make it easier to use user-supplied special methods
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32513>
_______________________________________

From report at bugs.python.org  Sun Jan  7 15:54:56 2018
From: report at bugs.python.org (Tylor)
Date: Sun, 07 Jan 2018 20:54:56 +0000
Subject: [New-bugs-announce] [issue32514] 0x80070002 - The system cannot
 find the file specified
Message-ID: <1515358496.6.0.467229070634.issue32514@psf.upfronthosting.co.za>


New submission from Tylor <TylorBeatty1 at gmail.com>:

When attempting to install Python 3.6.4, I get the error "0x80070002 - The system cannot find the file specified." I am able to install on a different Windows User, just not the current one I am using. The account has administrator privileges as well.

----------
components: Windows
files: Python 3.6.4 (32-bit)_20180107153053[3191].log
messages: 309636
nosy: Beatty0111, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: 0x80070002 - The system cannot find the file specified
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file47370/Python 3.6.4 (32-bit)_20180107153053[3191].log

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32514>
_______________________________________

From report at bugs.python.org  Sun Jan  7 15:58:47 2018
From: report at bugs.python.org (Mario Corchero)
Date: Sun, 07 Jan 2018 20:58:47 +0000
Subject: [New-bugs-announce] [issue32515] Add an option to trace to run
 module as a script
Message-ID: <1515358727.93.0.467229070634.issue32515@psf.upfronthosting.co.za>


New submission from Mario Corchero <mariocj89 at gmail.com>:

Add an option to trace to be able to do `python3 -m trace -t --module my.module.name` to be able to trace a runnable module the same way we can do with scripts.

As we want trace to not include the lines in runpy I am going to with the approach of pdb (issue32206) over the one on profiler(issue32512). As Nick raised before this hits a private API in runpy but it is within the stdlib. Alternatives are welcomed as well! :)

Additionally, '-m' is already in use, I have added --module.

Related issue for improved executable module support for standard library modules that run other scripts: https://bugs.python.org/issue9325

----------
components: Library (Lib)
messages: 309638
nosy: mariocj89
priority: normal
severity: normal
status: open
title: Add an option to trace to run module as a script
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32515>
_______________________________________

From report at bugs.python.org  Sun Jan  7 17:41:46 2018
From: report at bugs.python.org (xoviat)
Date: Sun, 07 Jan 2018 22:41:46 +0000
Subject: [New-bugs-announce] [issue32516] Add a shared library mechanism for
 win32
Message-ID: <1515364906.74.0.467229070634.issue32516@psf.upfronthosting.co.za>


New submission from xoviat <xoviat at gmail.com>:

On linux and macOS, a mechanism exists to relocate shared libraries inside of a wheel. Auditwheel creates a .libs folder and places the shared libraries inside of it. The problem is that on Windows, the rpath mechanism doesn't exist. We've attempted to ameliorate the situation with NumPy by modifying the DLL search path ourselves. I think this should be done in Python itself.

Here is what I propose: for each folder in site packages that matches the foldername created by auditwheel, specifically:

1. A folder directly inside site-packages that ends with '.libs'
2. A folder two levels under site-packages that is named 'libs'

Python should add these folders to the DLL search path at some point before the matching extensions are imported, so that DLLs located in these paths can be imported by a call to LoadLibrary.

The reason that this should be done in Python is that packages shouldn't be modifying the DLL search path, but that's currently what's required.

The alternative, current, recommendation is to place shared libraries in the same folder as the extension, but this approach fails when the shared library needs to be shared between more than one extension in different subpackages, but in the same distribution package.

----------
components: Extension Modules
messages: 309642
nosy: xoviat
priority: normal
severity: normal
status: open
title: Add a shared library mechanism for win32
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32516>
_______________________________________

From report at bugs.python.org  Sun Jan  7 18:03:38 2018
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 07 Jan 2018 23:03:38 +0000
Subject: [New-bugs-announce] [issue32517] test_read_pty_output() of
 test_asyncio hangs on x86-64 Sierra 3.6
Message-ID: <1515366218.51.0.467229070634.issue32517@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

On buildbot x86-64 Sierra 3.6, since build 163, test_read_pty_output() of test_asyncio started to hang:

http://buildbot.python.org/all/#/builders/20/builds/163/steps/4/logs/stdio

0:22:40 load avg: 1.73 [329/406/1] test_asyncio crashed (Exit code 1)
Timeout (0:15:00)!
Thread 0x00007fffb5eee340 (most recent call first):
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/selectors.py", line 577 in select
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/asyncio/base_events.py", line 1396 in _run_once
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/asyncio/base_events.py", line 422 in run_forever
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/asyncio/base_events.py", line 455 in run_until_complete
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/test_asyncio/test_events.py", line 1536 in test_read_pty_output
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/support/__init__.py", line 555 in wrapper
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/support/__init__.py", line 600 in wrapper
(...)

Difference between pythoninfo of build 162 and 163:

-os.login: buildbot
+os.login: _timed

-os.uname: posix.uname_result(sysname='Darwin', nodename='mattb-mbp2.local', release='17.2.0', version='Darwin Kernel Version 17.2.0: Fri Sep 29 18:27:05 PDT 2017; root:xnu-4570.20.62~3/RELEASE_X86_64', machine='x86_64')
+os.uname: posix.uname_result(sysname='Darwin', nodename='mattb-mbp2.local', release='17.3.0', version='Darwin Kernel Version 17.3.0: Thu Nov  9 18:09:22 PST 2017; root:xnu-4570.31.3~1/RELEASE_X86_64', machine='x86_64')

-platform.platform: Darwin-17.2.0-x86_64-i386-64bit
+platform.platform: Darwin-17.3.0-x86_64-i386-64bit

-sys.version: 3.6.4+ (heads/3.6:aea95c2fbd, Jan  2 2018, 00:22:06)  [GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.39.2)]
+sys.version: 3.6.4+ (heads/3.6:a70d5ff992, Jan  4 2018, 01:35:13)  [GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.39.2)]

-sysconfig[HOST_GNU_TYPE]: x86_64-apple-darwin17.2.0
+sysconfig[HOST_GNU_TYPE]: x86_64-apple-darwin17.3.0

The os.login change is interesting and curious, and it also looks like a macOS upgrade from Darwin 17.2.0 to 17.3.0.

----------
components: Tests, asyncio, macOS
messages: 309650
nosy: asvetlov, ned.deily, ronaldoussoren, vstinner, yselivanov
priority: normal
severity: normal
status: open
title: test_read_pty_output() of test_asyncio hangs on x86-64 Sierra 3.6
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32517>
_______________________________________

From report at bugs.python.org  Mon Jan  8 03:09:03 2018
From: report at bugs.python.org (=?utf-8?b?5p2o6bmP?=)
Date: Mon, 08 Jan 2018 08:09:03 +0000
Subject: [New-bugs-announce] [issue32518] HTTPServer can't deal with
 persistent connection properly
Message-ID: <1515398943.33.0.467229070634.issue32518@psf.upfronthosting.co.za>


New submission from ?? <yangpengxdu at gmail.com>:

when client is using persistent connection, HTTPServer will hang with that connection. As a result, it can't deal with other clients.

----------
components: Library (Lib)
messages: 309659
nosy: ??
priority: normal
pull_requests: 4996
severity: normal
status: open
title: HTTPServer can't deal with persistent connection properly
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32518>
_______________________________________

From report at bugs.python.org  Mon Jan  8 09:58:36 2018
From: report at bugs.python.org (Jason R. Coombs)
Date: Mon, 08 Jan 2018 14:58:36 +0000
Subject: [New-bugs-announce] [issue32519] venv API docs - symlinks default
 incorrect
Message-ID: <1515423516.58.0.467229070634.issue32519@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

In the API docs for EnvBuilder.symlinks, it states "Defaults to True on Linux and Unix systems, but False on Windows." But in fact, the implementation takes the value passed, which always defaults to False. It's only on the command-line that the default is inferred from the system. Presumably, the fix is to strike that sentence from the docs.

----------
components: Library (Lib)
messages: 309667
nosy: jason.coombs
priority: normal
severity: normal
status: open
title: venv API docs - symlinks default incorrect

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32519>
_______________________________________

From report at bugs.python.org  Mon Jan  8 10:55:31 2018
From: report at bugs.python.org (jeff deifik)
Date: Mon, 08 Jan 2018 15:55:31 +0000
Subject: [New-bugs-announce] [issue32520] error writing to file in binary
 mode - python 3.6.3
Message-ID: <1515426931.81.0.467229070634.issue32520@psf.upfronthosting.co.za>


New submission from jeff deifik <jeff at jeffunit.com>:

I am running python 3.6.3 on cygwin / windows.

Here is a test program to demonstrate the bug:

#!/usr/bin/env python3

fp = open("bug_out.txt", "ab")
buff = 'Hello world'
print('type of buff is', type(buff))
bin_buff = bytes(buff,  'utf-8')
print('type of bin_buff is', type(bin_buff))
print(bin_buff, file=fp)

Here is the output:
./bug.py
type of buff is <class 'str'>
type of bin_buff is <class 'bytes'>
Traceback (most recent call last):
  File "./bug.py", line 8, in <module>
    print(bin_buff, file=fp)
TypeError: a bytes-like object is required, not 'str'

The python type system things bin_buff has type bytes, but when I try to print it, the print function thinks it is of type str.

----------
components: IO
messages: 309669
nosy: lopgok
priority: normal
severity: normal
status: open
title: error writing to file in binary mode - python 3.6.3
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32520>
_______________________________________

From report at bugs.python.org  Mon Jan  8 11:35:03 2018
From: report at bugs.python.org (Charalampos Stratakis)
Date: Mon, 08 Jan 2018 16:35:03 +0000
Subject: [New-bugs-announce] [issue32521] NIS module fails to build due to
 the remove of interfaces related to Sun RPC from glibc.
Message-ID: <1515429303.77.0.467229070634.issue32521@psf.upfronthosting.co.za>


New submission from Charalampos Stratakis <cstratak at redhat.com>:

Currently on the development branch of Fedora (28), an upstream change of glibc is being pushed where the Sun RPC support is removed from our downstream glibc package in favor of the libtirpc library. More details [0].

As a result, when python is trying to build the nis extension, it will complain with:
fatal error: rpc/rpc.h: No such file or directory
#include <rpc/rpc.h>
          ^~~~~~~~~~~
compilation terminated.
 
[0] https://fedoraproject.org/wiki/Changes/SunRPCRemoval

----------
components: Extension Modules
messages: 309674
nosy: cstratak
priority: normal
severity: normal
status: open
title: NIS module fails to build due to the remove of interfaces related to Sun RPC from glibc.
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32521>
_______________________________________

From report at bugs.python.org  Tue Jan  9 10:46:50 2018
From: report at bugs.python.org (Paul Ganssle)
Date: Tue, 09 Jan 2018 15:46:50 +0000
Subject: [New-bugs-announce] [issue32522] Add precision argument to
 datetime.now
Message-ID: <1515512810.75.0.467229070634.issue32522@psf.upfronthosting.co.za>


New submission from Paul Ganssle <p.ganssle at gmail.com>:

One thing I think that is fairly common is the desire to get the current datetime only up to a current precision, so you see a lot of things in, say, `dateutil` like this:

    dt = datetime.now().replace(hours=0, minutes=0, seconds=0, microseconds=0)

Or:

    dt = datetime.now().replace(microseconds=0)

I think it would make sense to add a `precision` keyword argument, similar to the `timespec` argument to isoformat (https://docs.python.org/3/library/datetime.html#datetime.datetime.isoformat), then you could just do:

dt = datetime.now(precision='day')

And get the current date as a datetime.

----------
components: Library (Lib)
messages: 309703
nosy: belopolsky, p-ganssle, tim.peters
priority: normal
severity: normal
status: open
title: Add precision argument to datetime.now
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32522>
_______________________________________

From report at bugs.python.org  Tue Jan  9 11:21:22 2018
From: report at bugs.python.org (Ned Deily)
Date: Tue, 09 Jan 2018 16:21:22 +0000
Subject: [New-bugs-announce] [issue32523] inconsistent spacing in
 changelog.html
Message-ID: <1515514882.86.0.467229070634.issue32523@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at python.org>:

The rendered changelog.html files produced "make html" have inconsistent spacing between items. Usually, the first changelog topic section (e.g. Security) starts with no blank lines between items but occasionally some subsequent sections will render with a blank link between items; this seems to be often true for the Library section, but not always. This is visible across the recent 3.x branches; here's an example with the stable 3.5 docs:

Library section has blank line separator:
https://docs.python.org/3.5/whatsnew/changelog.html#id5

Library section has no blank separators:
https://docs.python.org/3.5/whatsnew/changelog.html#id11

----------
assignee: docs at python
components: Documentation
messages: 309711
nosy: docs at python, ned.deily
priority: normal
severity: normal
status: open
title: inconsistent spacing in changelog.html
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32523>
_______________________________________

From report at bugs.python.org  Tue Jan  9 16:12:50 2018
From: report at bugs.python.org (Segev Finer)
Date: Tue, 09 Jan 2018 21:12:50 +0000
Subject: [New-bugs-announce] [issue32524] Python 2.7 leaks a packages
 __init__.py module object on SyntaxError
Message-ID: <1515532370.23.0.467229070634.issue32524@psf.upfronthosting.co.za>


New submission from Segev Finer <segev208 at gmail.com>:

With the file hello/__init__.py:

    ham = 123
    spam()spam()

I get the following:

    Python 2.7.14 (v2.7.14:84471935ed, Sep 16 2017, 20:19:30) [MSC v.1500 32 bit (Intel)] on win32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import hello
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "hello\__init__.py", line 2
        spam()spam()
                 ^
    SyntaxError: invalid syntax
    >>> import hello
    >>> print hello
    <module 'hello' from 'hello'>
    >>> print dir(hello)
    ['__doc__', '__file__', '__name__', '__package__', '__path__']
    >>>

I'd expect to get the SyntaxError twice, which is indeed what happens on at least Python 3.6 (Possibly earlier Python 3 versions).

Originally found here https://github.com/pallets/flask/issues/2423 & https://github.com/pallets/flask/pull/2588

I'm going to submit a PR with a fix.

----------
components: Interpreter Core
messages: 309736
nosy: Segev Finer
priority: normal
severity: normal
status: open
title: Python 2.7 leaks a packages __init__.py module object on SyntaxError
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32524>
_______________________________________

From report at bugs.python.org  Tue Jan  9 16:49:13 2018
From: report at bugs.python.org (benrg)
Date: Tue, 09 Jan 2018 21:49:13 +0000
Subject: [New-bugs-announce] [issue32525] Empty tuples are not optimized as
 constant expressions
Message-ID: <1515534553.56.0.467229070634.issue32525@psf.upfronthosting.co.za>


New submission from benrg <benrudiak at gmail.com>:

>From 3.3 on, the expression () is compiled to BUILD_TUPLE 0 instead of LOAD_CONST. That's probably fine and I suppose it's slightly more efficient to avoid adding an entry to the constant table.

The problem is that BUILD_TUPLE 0 is not treated as a constant for folding purposes, so any otherwise constant expression that contain () ends up compiling into O(n) bytecode instructions instead of 1. I think this is a bug (rather than an enhancement) because it seems unlikely to be the intended behavior.

In 3.2 an earlier, and in 2.7, the constant-folding behavior is different, and many constant tuples aren't recognized at compile time for reasons unclear to me, but there are definitely cases it will fold that 3.3+ won't. For example, "x in {(), None}" tests a frozenset in 3.2, but builds a set at run time in 3.3+.

----------
components: Interpreter Core
messages: 309739
nosy: benrg
priority: normal
severity: normal
status: open
title: Empty tuples are not optimized as constant expressions
type: performance
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32525>
_______________________________________

From report at bugs.python.org  Wed Jan 10 04:31:53 2018
From: report at bugs.python.org (Joongi Kim)
Date: Wed, 10 Jan 2018 09:31:53 +0000
Subject: [New-bugs-announce] [issue32526] Closing async generator while it
 is running does not raise an exception
Message-ID: <1515576713.82.0.467229070634.issue32526@psf.upfronthosting.co.za>


Change by Joongi Kim <me at daybreaker.info>:


----------
components: asyncio
nosy: achimnol, asvetlov, njs, yselivanov
priority: normal
severity: normal
status: open
title: Closing async generator while it is running does not raise an exception
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32526>
_______________________________________

From report at bugs.python.org  Wed Jan 10 08:53:19 2018
From: report at bugs.python.org (Saba Kauser)
Date: Wed, 10 Jan 2018 13:53:19 +0000
Subject: [New-bugs-announce] [issue32527] windows 7 python 3.6 : after some
 security updates, import ibm_db fails
Message-ID: <1515592399.24.0.467229070634.issue32527@psf.upfronthosting.co.za>


New submission from Saba Kauser <skauseribmdb at gmail.com>:

Hello,
I have a user who is complaining that python ibm_db module import fails after some windows 7 security update. I am not sure if this is a bug or some other setup issue but I could not find any other forum where I can post this query. Please feel free to point me to correct forum if this is not the correct place.

The error as reported by him is available here : https://github.com/ibmdb/python-ibmdb/issues/294#issuecomment-356254726

When run through pdb, the stack shows this:
C:\Users\IBM_ADMIN\Documents\Python>python -m pdb "test DB2 connection.py"
> c:\users\ibm_admin\documents\python\test db2 connection.py(3)<module>()
-> import ibm_db
(Pdb) continue
Traceback (most recent call last):
  File "C:\Users\IBM_ADMIN\AppData\Local\Programs\Python\Python36-32\lib\pdb.py", line 1667, in main
    pdb._runscript(mainpyfile)
  File "C:\Users\IBM_ADMIN\AppData\Local\Programs\Python\Python36-32\lib\pdb.py", line 1548, in _runscript
    self.run(statement)
  File "C:\Users\IBM_ADMIN\AppData\Local\Programs\Python\Python36-32\lib\bdb.py", line 431, in run
    exec(cmd, globals, locals)
  File "<string>", line 1, in <module>
  File "c:\users\ibm_admin\documents\python\test db2 connection.py", line 3, in <module>
    import ibm_db
SystemError: <built-in function connect> returned NULL without setting an error
Uncaught exception. Entering post mortem debugging
Running 'cont' or 'step' will restart the program
> c:\users\ibm_admin\documents\python\test db2 connection.py(3)<module>()
-> import ibm_db
(Pdb)

when 'cont' is used, the control reaches python ibm_db driver that should have happened without having to 'cont'.

c:\users\ibm_admin\documents\python\test db2 connection.py(2)()
-> import ibm_db
(Pdb) cont
Traceback (most recent call last):
File "C:\Users\IBM_ADMIN\AppData\Local\Programs\Python\Python36-32\lib\pdb.py", line 1667, in main
pdb._runscript(mainpyfile)
File "C:\Users\IBM_ADMIN\AppData\Local\Programs\Python\Python36-32\lib\pdb.py", line 1548, in _runscript
self.run(statement)
File "C:\Users\IBM_ADMIN\AppData\Local\Programs\Python\Python36-32\lib\bdb.py", line 431, in run
exec(cmd, globals, locals)
File "", line 1, in
File "c:\users\ibm_admin\documents\python\test db2 connection.py", line 2, in
import ibm_db
SQLCODE=-30082][CLI Driver] SQL30082N Security processing failed with reason "15" ("PROCESSING FAILURE"). SQLSTATE=08001
Uncaught exception. Entering post mortem debugging
Running 'cont' or 'step' will restart the program
c:\users\ibm_admin\documents\python\test db2 connection.py(2)()
-> import ibm_db
(Pdb) cont
Post mortem debugger finished. The test DB2 connection.py will be restarted
c:\users\ibm_admin\documents\python\test db2 connection.py(2)()
-> import ibm_db
(Pdb) cont
Traceback (most recent call last):
File "C:\Users\IBM_ADMIN\AppData\Local\Programs\Python\Python36-32\lib\pdb.py", line 1667, in main
pdb._runscript(mainpyfile)
File "C:\Users\IBM_ADMIN\AppData\Local\Programs\Python\Python36-32\lib\pdb.py", line 1548, in _runscript
self.run(statement)
File "C:\Users\IBM_ADMIN\AppData\Local\Programs\Python\Python36-32\lib\bdb.py", line 431, in run
exec(cmd, globals, locals)
File "", line 1, in
File "c:\users\ibm_admin\documents\python\test db2 connection.py", line 2, in
import ibm_db
SQLCODE=-30082][CLI Driver] SQL30082N Security processing failed with reason "15" ("PROCESSING FAILURE"). SQLSTATE=08001
Uncaught exception. Entering post mortem debugging
Running 'cont' or 'step' will restart the program
c:\users\ibm_admin\documents\python\test db2 connection.py(2)()
-> import ibm_db
(Pdb)


Please note that the script works fine when run as administrator and it fails only when run as non-admin user. non-admin user too was working fine until recently when some update was applied to windows OS and then it stopped working only for non-admin user. Python and ibm_db driver both have be uninstalled and re-installed for non-admin user, but no luck.
kindly help!

----------
components: Windows
messages: 309764
nosy: paul.moore, sabakauser, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: windows 7 python 3.6 : after some security updates, import ibm_db fails
type: security
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32527>
_______________________________________

From report at bugs.python.org  Wed Jan 10 11:31:15 2018
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Wed, 10 Jan 2018 16:31:15 +0000
Subject: [New-bugs-announce] [issue32528] Change base class for
 futures.CancelledError
Message-ID: <1515601875.1.0.467229070634.issue32528@psf.upfronthosting.co.za>


New submission from ???? ????????? <socketpair at gmail.com>:

I have discoverd one very ugly pattern connected with asyncio. Many times I see code like this:


try:
    await something()
except Exception:
    log.error('Opertaion failed -- will retry later.')


Seems, everything is fine, but asyncio.CancelledError unintentionally
also suppressed in that code. So, sometimes coroutines are not cancellable.

In order to mitigate thi, we had to write:



try:
    await something()
except CancelledError:
    raise
except Exception:
    log.error('Opertaion failed. will retry later.')


So, what I propose: Basically is to change base class for asyncio.CancelledError
from Exception (yes, I know concurrent.futures and it's `Error` class) to BaseException.

Just like `SystemExit` and other SPECIAL exceptions.

Yes, I know that it would be incompatible change. But I suspect that impact will be minimal. Documentation for concurrent.futures and asyncio does not say that this exception is derived from Exception.

----------
components: asyncio
messages: 309772
nosy: asvetlov, socketpair, yselivanov
priority: normal
severity: normal
status: open
title: Change base class for futures.CancelledError
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32528>
_______________________________________

From report at bugs.python.org  Wed Jan 10 17:11:02 2018
From: report at bugs.python.org (YoSTEALTH)
Date: Wed, 10 Jan 2018 22:11:02 +0000
Subject: [New-bugs-announce] [issue32529] improved shutil.py function
Message-ID: <1515622262.3.0.467229070634.issue32529@psf.upfronthosting.co.za>


New submission from YoSTEALTH <ritesh at stealthcentral.com>:

improved "copyfileobj" function to use less memory

----------
messages: 309784
nosy: YoSTEALTH
priority: normal
pull_requests: 5004
severity: normal
status: open
title: improved shutil.py function
type: performance
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32529>
_______________________________________

From report at bugs.python.org  Wed Jan 10 23:42:02 2018
From: report at bugs.python.org (Hery)
Date: Thu, 11 Jan 2018 04:42:02 +0000
Subject: [New-bugs-announce] [issue32530] How ro fix the chm encoding in Non
 western european codepage(cp1252) Windows
Message-ID: <1515645722.61.0.467229070634.issue32530@psf.upfronthosting.co.za>


New submission from Hery <weiyong.mao at gmail.com>:

Start from Python 3.6.3, the offical chm document is full of corrputed character.

Example: the first page which is `What?s New In Python 3.6` `?`is `0x92` in cp1252 and will not display correctly in non western european code page.  An another example is `9.1. numbers ? Numeric abstract base classes` `?` is `0x97`.

The Microsoft HTML Help does not recognise `<meta http-equiv="Content-Type" content="text/html; charset=cp1252" />`.

Then, how to solve it?

According to this https://blogs.msdn.microsoft.com/sandcastle/2007/09/29/chm-localization-and-unicode-issues-dbcsfix-exe/

I recommand to use the following command to make the hhc encoding chm as cp1252:

SbAppLocale.exe $(LCID) "%PROGRAMFILES%\HTML Help Workshop\hhc.exe" Path\Project.HHp

I donnot know to how to submit patch and it seems quite easy to fix by offical windows developer.

----------
components: Windows
messages: 309790
nosy: Nim, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: How ro fix the chm encoding in Non western european codepage(cp1252) Windows
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32530>
_______________________________________

From report at bugs.python.org  Thu Jan 11 00:24:06 2018
From: report at bugs.python.org (callmekohei)
Date: Thu, 11 Jan 2018 05:24:06 +0000
Subject: [New-bugs-announce] [issue32531] gdb.execute can not put string
 value.
Message-ID: <1515648246.66.0.467229070634.issue32531@psf.upfronthosting.co.za>


New submission from callmekohei <callmekohei at gmail.com>:

Hello! I'm callmekohei! (^_^)/


------------------------
   Problems summary
------------------------

gdb.execute can not put string value.


------------------------
   Steps to Reproduce
------------------------

// create 
$ gcc -g foo.c

// launch sdb
$ sdb a.out

// set breakpoint
$ b foo.c:5

// run
$ run

// next
$ n


------------------------
   Current Behavior
------------------------

(gdb)  n
6	    n = 2;
False
True


------------------------
   Expected Behavior
------------------------

(gdb)  n
False
False


------------------------
   Code 
------------------------

// .gdbinit

set startup-with-shell off

python

class Foo(gdb.Command):

    def __init__(self):
        gdb.Command.__init__(self                     \
                , name            = 'n'               \
                , command_class   = gdb.COMMAND_USER  \
                , completer_class = gdb.COMPLETE_NONE \
                , prefix          = True)

    def invoke(self, arg, from_tty):
        output = gdb.execute(command='next',from_tty=False, to_string=True)
        print(output is None)
        print(output == '')

Foo()

end


// foo.c

#include <stdio.h>

int main(int argc, char *args[])
{
    int n = 1;
    n = 2;
    n = 3;
    n = 4;
    n = 5;
    n = 6;
    n = 7;
    n = 8;
    n = 9;
    printf("n = %d\n",n);
    return 0;
}


------------------------
   Others 
------------------------

see also:

https://github.com/mono/sdb/issues/45

----------
components: macOS
hgrepos: 377
messages: 309791
nosy: callmekohei, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: gdb.execute can not put string value.
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32531>
_______________________________________

From report at bugs.python.org  Thu Jan 11 01:25:56 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Thu, 11 Jan 2018 06:25:56 +0000
Subject: [New-bugs-announce] [issue32532] improve sys.settrace and
 sys.setprofile documentation
Message-ID: <1515651956.68.0.467229070634.issue32532@psf.upfronthosting.co.za>


New submission from Xiang Zhang <angwerzx at 126.com>:

I propose to mention the behaviour that "if exception raised in tracefunc or profilefunc, the handler will be unset" in the documentation of sys.settrace and sys.setprofile. I encounter this behaviour and surprised by it since I can't get the info from the doc. Only by digging into the source code, I can find out why the profile messages suddenly disappear.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 309793
nosy: docs at python, xiang.zhang
priority: normal
severity: normal
stage: needs patch
status: open
title: improve sys.settrace and sys.setprofile documentation
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32532>
_______________________________________

From report at bugs.python.org  Thu Jan 11 08:41:08 2018
From: report at bugs.python.org (Alexey Baldin)
Date: Thu, 11 Jan 2018 13:41:08 +0000
Subject: [New-bugs-announce] [issue32533] SSLSocket read/write
 thread-unsafety
Message-ID: <1515678068.63.0.467229070634.issue32533@psf.upfronthosting.co.za>


New submission from Alexey Baldin <alexeyb17 at gmail.com>:

_ssl.c has thread-usafe code in implementation of read, write and other methods. E.g. 'write' method:

2099        PySSL_BEGIN_ALLOW_THREADS
2100        len = SSL_write(self->ssl, b->buf, (int)b->len);
2101        _PySSL_UPDATE_ERRNO_IF(len <= 0, self, len);
2102        PySSL_END_ALLOW_THREADS
2103        err = self->ssl_errno;

_PySSL_UPDATE_ERRNO_IF updates self->ssl_errno without lock. Similar code used in 'read' method. Later self->ssl_errno is used for decision on retrying the operation. As result, SSL_write can be incorrectly repeated because ssl_errno was updated by 'read' method to SSL_ERROR_WANT_READ from another thread.

Looks like commit e6eb48c10dc389d1d70657593de6a6cb3087d3d1 is the cause.

----------
assignee: christian.heimes
components: SSL
messages: 309805
nosy: Alexey Baldin, christian.heimes
priority: normal
severity: normal
status: open
title: SSLSocket read/write thread-unsafety
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32533>
_______________________________________

From report at bugs.python.org  Thu Jan 11 08:52:14 2018
From: report at bugs.python.org (Jeethu Rao)
Date: Thu, 11 Jan 2018 13:52:14 +0000
Subject: [New-bugs-announce] [issue32534] Speed-up list.insert
Message-ID: <1515678734.85.0.467229070634.issue32534@psf.upfronthosting.co.za>


New submission from Jeethu Rao <jeethu at jeethurao.com>:

I've noticed that replacing the for loop in the ins1 function in listobject.c with a memmove when the number of pointers to move is greater than 16 seems to speed up list.insert by about 3 to 4x on a contrived benchmark.

# Before
jeethu at dev:cpython  (master)$ ./python -m timeit -s "l = []" "for _ in range(100): l.insert(0, None)"
200 loops, best of 5: 3.07 msec per loop

#After
jeethu at dev:cpython  (3.7_list_insert_memmove)$ ./python -m timeit -s "l = []" "for _ in range(100): l.insert(0, None)"
500 loops, best of 5: 744 usec per loop

Both builds were configured with --enable-optimizations and --with-lto

----------
components: Interpreter Core
messages: 309806
nosy: jeethu
priority: normal
severity: normal
status: open
title: Speed-up list.insert
type: performance
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32534>
_______________________________________

From report at bugs.python.org  Thu Jan 11 11:34:33 2018
From: report at bugs.python.org (Bruno Abreu Calfa)
Date: Thu, 11 Jan 2018 16:34:33 +0000
Subject: [New-bugs-announce] [issue32535] msvcr140.dll has been replaced
 with vcruntime140.dll
Message-ID: <1515688473.22.0.467229070634.issue32535@psf.upfronthosting.co.za>


New submission from Bruno Abreu Calfa <bacalfa at gmail.com>:

File msvcr140.dll does not exist after installing Microsoft Visual C++ 2015 Redistributable or Visual Studio 2015. It has been replaced with vcruntime140.dll. See discussion here: https://groups.google.com/a/continuum.io/forum/#!topic/anaconda/yLH46ilPQeo

In addition, I was only able to build an extension (https://github.com/mattjj/pyhsmm) after copying the vcruntime140.dll from the Python installation folder (Anaconda 3 5.0.1 64-bit, Python 3.6.3) to the libs folder. I also had to change file include/pyconfig.h by removing the definitions of hypot (https://github.com/python/cpython/pull/880).

In sum, I suggest replacing

return ['msvcr140']

with

return ['vcruntime140']

----------
components: Distutils
messages: 309816
nosy: Bruno Abreu Calfa, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: msvcr140.dll has been replaced with vcruntime140.dll
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32535>
_______________________________________

From report at bugs.python.org  Fri Jan 12 07:16:49 2018
From: report at bugs.python.org (Mark Shannon)
Date: Fri, 12 Jan 2018 12:16:49 +0000
Subject: [New-bugs-announce] [issue32536] ast and tokenize disagree about
 line number
Message-ID: <1515759409.32.0.467229070634.issue32536@psf.upfronthosting.co.za>


New submission from Mark Shannon <mark at hotpy.org>:

This occurs (on linux at least) when the the end of line sequence `\r\r\n` occurs in a comment that is indented relative to the following lines.

The attached file demonstrates the problem.

----------
components: Library (Lib)
files: tokenize_fail_test.py
messages: 309852
nosy: Mark.Shannon
priority: normal
severity: normal
status: open
title: ast and tokenize disagree about line number
type: behavior
versions: Python 2.7
Added file: https://bugs.python.org/file47380/tokenize_fail_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32536>
_______________________________________

From report at bugs.python.org  Fri Jan 12 09:37:57 2018
From: report at bugs.python.org (Tilman Beck)
Date: Fri, 12 Jan 2018 14:37:57 +0000
Subject: [New-bugs-announce] [issue32537]
 multiprocessing.pool.Pool.starmap_async - wrong parameter name
Message-ID: <1515767877.08.0.467229070634.issue32537@psf.upfronthosting.co.za>


New submission from Tilman Beck <tilman-beck at gmx.de>:

The optional parameter for the error callback function is named "error_callback" not "error_back"

----------
assignee: docs at python
components: Documentation
files: bug.png
messages: 309857
nosy: devnull, docs at python
priority: normal
severity: normal
status: open
title: multiprocessing.pool.Pool.starmap_async - wrong parameter name
versions: Python 3.5
Added file: https://bugs.python.org/file47381/bug.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32537>
_______________________________________

From report at bugs.python.org  Fri Jan 12 10:05:56 2018
From: report at bugs.python.org (Johannes)
Date: Fri, 12 Jan 2018 15:05:56 +0000
Subject: [New-bugs-announce] [issue32538] Multiprocessing Manager on 3D list
 - no change of the list possible
Message-ID: <1515769556.66.0.467229070634.issue32538@psf.upfronthosting.co.za>


New submission from Johannes <johannes.jaegers at gmx.de>:

I have the following code, which works without multiprocessing:

data=[[['','','','','','','','','','','','']]]
data[0][0][0] = 5
data[0][0][1] = "5" # data in the array is mixed with float and str
print(data)

#=> [[[5, '5', '', '', '', '', '', '', '', '', '', '']]]

Now I want to use Multiprocessing and every process should be able to change the 3D list. This doesn't work and no error message is shown.

from multiprocessing import Process, Manager
manager=Manager()
data=manager.list([[['','','','','','','','','','','','']]])
data[0][0][0] = 5
data[0][0][1] = "5"
print(data)    

#=> [[['', '', '', '', '', '', '', '', '', '', '', '']]]

I found the following text:

list(sequence)
Create a shared list object and return a proxy for it.
Changed in version 3.6: Shared objects are capable of being nested. For     
example, a shared container object such as a shared list can contain 
other shared objects which will all be managed and synchronized by the 
SyncManager.(https://docs.python.org/3/library/multiprocessing.html)

Unfortunately it also doesn't work with 3.6.3, same problem as before! But as it should work, I guess it's a bug?

I use Ubuntu 16.04...

----------
components: Interpreter Core
messages: 309858
nosy: John_81
priority: normal
severity: normal
status: open
title: Multiprocessing Manager on 3D list - no change of the list possible
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32538>
_______________________________________

From report at bugs.python.org  Fri Jan 12 11:56:45 2018
From: report at bugs.python.org (Anthony Sottile)
Date: Fri, 12 Jan 2018 16:56:45 +0000
Subject: [New-bugs-announce] [issue32539] os.listdir(...) on deep path on
 windows in python2.7 fails with errno 123
Message-ID: <1515776205.66.0.467229070634.issue32539@psf.upfronthosting.co.za>


New submission from Anthony Sottile <asottile at umich.edu>:

On windows, a deep path can be accessed by prefixing the path with \\?\

https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx?f=255&MSPPError=-2147217396#maxpath

The call to `listdir()` fails because it uses a posix separator.

A quick patch to fix this is to use `SEP` here: https://github.com/python/cpython/blob/ab95b3074ee43098edf3f23b07fb18ef57ee614d/Modules/posixmodule.c#L2388 (I can submit a patch for this)

Here's a stacktrace

>>> os.listdir(r'\\?\C:\Temp')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
WindowsError: [Error 123] The filename, directory name, or volume label syntax is incorrect: '\\\\?\\C:\\Temp/*.*'


This works fine in python3, as the code has been refactored to use `SEP` already.

>>> os.listdir(r'\\?\C:\Temp')
[]

----------
components: Library (Lib), Windows
messages: 309862
nosy: Anthony Sottile, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: os.listdir(...) on deep path on windows in python2.7 fails with errno 123
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32539>
_______________________________________

From report at bugs.python.org  Fri Jan 12 13:07:13 2018
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 12 Jan 2018 18:07:13 +0000
Subject: [New-bugs-announce] [issue32540] venv docs - doesn't match behavior
Message-ID: <1515780433.02.0.467229070634.issue32540@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

In the docs for the venv command, it states:

> Changed in version 3.4: In earlier versions, if the target directory already existed, an error was raised, unless the --clear or --upgrade option was provided. Now, if an existing directory is specified, its contents are removed and the directory is processed as if it had been newly created.

However, that's not the behavior I observe:

$ python -m venv env
$ env/bin/pip install -q requests
$ python -m venv env          
$ env/bin/python -c "import requests"
$

Plus, I believe the _current_ behavior should be documented not in a 'change' note. I suggest the change note should read:

> Changed in version 3.4: In earlier versions, if the target directory already existed, an error was raised, unless the --clear or --upgrade option was provided.

And the third paragraph, following "It also creates an (initially empty...Lib\site-packages).":

> If an existing directory is specified, it will be re-used.

----------
assignee: docs at python
components: Documentation
messages: 309867
nosy: docs at python, jason.coombs
priority: normal
severity: normal
status: open
title: venv docs - doesn't match behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32540>
_______________________________________

From report at bugs.python.org  Fri Jan 12 13:41:57 2018
From: report at bugs.python.org (Ian Craggs)
Date: Fri, 12 Jan 2018 18:41:57 +0000
Subject: [New-bugs-announce] [issue32541] cgi.FieldStorage constructor
 assumes all lines terminate with \n
Message-ID: <1515782517.92.0.467229070634.issue32541@psf.upfronthosting.co.za>


New submission from Ian Craggs <icraggs at gmail.com>:

Using cgi.FieldStorage in an HTTP server in a subclass of BaseHTTPRequestHandler, parsing the request with:

form = cgi.FieldStorage(fp=self.rfile,
                        headers=self.headers,
                        environ={"REQUEST_METHOD":op.upper(),
                              "CONTENT_TYPE":self.headers['Content-Type'],})

This has been working fine with clients using the Python requests library. Now processing requests from a Java library (org.apache.cxf.jaxrs.client.WebClient), the final line in a multipart request does not include the (\r)\n, which causes the final read to hang until a socket timeout.  The read in question is in cgi.py, read_lines_to_outerboundary:

line = self.fp.readline(1<<16) # bytes

(line 824 in Python 3.6.2).  I changed this read to not assume the termination of the final line with \n:

    def read_line(self, last_boundary):
        line = self.fp.readline(len(last_boundary))
        if line != last_boundary and not line.endswith(b"\n"):
            line += self.fp.readline((1<<16) - len(last_boundary))
        return line


and the request worked.  The Java library is being used in tests against our production web server so I assume that is working correctly.  

Perhaps I am misusing the FieldStorage class, I don't know, I'm not expert on this.

----------
components: Library (Lib), macOS
messages: 309868
nosy: Ian Craggs, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: cgi.FieldStorage constructor assumes all lines terminate with \n
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32541>
_______________________________________

From report at bugs.python.org  Fri Jan 12 13:56:34 2018
From: report at bugs.python.org (Michael Felt)
Date: Fri, 12 Jan 2018 18:56:34 +0000
Subject: [New-bugs-announce] [issue32542] memory not freed,
 aka memory leak continues...
Message-ID: <1515783394.33.0.467229070634.issue32542@psf.upfronthosting.co.za>


New submission from Michael Felt <michael at felt.demon.nl>:

in issue25582 - the issue is not (yet) resolved. Perhaps this one can be closed and issue25582 reopened.

Both from python2-2.7.14 and "git master" I am getting:

michael at x071:[/data/prj/python/git/gcc-python3-3.7]./python -m unittest -v ctypes.test.test_pointers          <
test_abstract (ctypes.test.test_pointers.PointersTestCase) ... ok
test_basic (ctypes.test.test_pointers.PointersTestCase) ... ok
test_basics (ctypes.test.test_pointers.PointersTestCase) ... ok
test_bug_1467852 (ctypes.test.test_pointers.PointersTestCase) ... ok
test_c_void_p (ctypes.test.test_pointers.PointersTestCase) ... ok
test_callbacks_with_pointers (ctypes.test.test_pointers.PointersTestCase) ... ok
test_change_pointers (ctypes.test.test_pointers.PointersTestCase) ... ok
test_charpp (ctypes.test.test_pointers.PointersTestCase)
Test that a character pointer-to-pointer is correctly passed ... ok
test_from_address (ctypes.test.test_pointers.PointersTestCase) ... ok
test_other (ctypes.test.test_pointers.PointersTestCase) ... ok
test_pass_pointers (ctypes.test.test_pointers.PointersTestCase) ... ok
test_pointer_crash (ctypes.test.test_pointers.PointersTestCase) ... ok
test_pointer_type_name (ctypes.test.test_pointers.PointersTestCase) ... ok
test_pointer_type_str_name (ctypes.test.test_pointers.PointersTestCase) ... ERROR
test_pointers_bool (ctypes.test.test_pointers.PointersTestCase) ... ok

======================================================================
ERROR: test_pointer_type_str_name (ctypes.test.test_pointers.PointersTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/data/prj/python/git/gcc-python3-3.7/Lib/ctypes/test/test_pointers.py", line 208, in test_pointer_type_str_name
    large_string = 'T' * 2 ** 25
MemoryError

----------------------------------------------------------------------
Ran 15 tests in 0.319s

FAILED (errors=1)

+++++
Looking at the test source:

  +196      def test_pointer_type_name(self):
  +197          LargeNamedType = type('T' * 2 ** 25, (Structure,), {})
  +198          self.assertTrue(POINTER(LargeNamedType))
  +199
  +200          # to not leak references, we must clean _pointer_type_cache
  +201          from ctypes import _pointer_type_cache
  +202          del _pointer_type_cache[LargeNamedType]
  +203
  +204      def test_pointer_type_str_name(self):
  +205          large_string = 'T' * 2 ** 25
  +206          P = POINTER(large_string)
  +207          self.assertTrue(P)
  +208
  +209          # to not leak references, we must clean _pointer_type_cache
  +210          from ctypes import _pointer_type_cache
  +211          del _pointer_type_cache[id(P)]

****
After changing the exponent (** 25) to "** 23" on either line 197 OR 205 
- ALL test succeed -
After changing the exponent to " ** 24" on BOTH lines 197 and 205, all tests pass.

****
My concern is that the "patch" from issue 25582 the 
"del _pointer_type_cache[]" statement is not freeing memory.

+++++
What can I add to the test to debug!
+++++
p.s. - results are the same on AIX (5.3 and 6.1) Python2-2.7.14 and Pyhton3-3.7.X (git master). Compiler does not seem to matter (both xlc and gcc).
32-bit, default memory model (256 MByte max - aka (2 ** 28) for data and malloc. I could also try changing the memory model - but will do that only if the test, by definition, is not "free()ing" the memory used, when done.

HTH
Michael

----------
components: Tests
messages: 309869
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: memory not freed, aka memory leak continues...
type: behavior
versions: Python 2.7, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32542>
_______________________________________

From report at bugs.python.org  Fri Jan 12 17:32:48 2018
From: report at bugs.python.org (Nathan Goldbaum)
Date: Fri, 12 Jan 2018 22:32:48 +0000
Subject: [New-bugs-announce] [issue32543] odd floor division behavior
Message-ID: <1515796368.52.0.467229070634.issue32543@psf.upfronthosting.co.za>


New submission from Nathan Goldbaum <nathan12343 at gmail.com>:

According to PEP 238:


"floor division will be implemented in all the Python numeric types, and will have the semantics of:

a // b == floor(a/b)

except that the result type will be the common type into which a and b are coerced before the operation."

But consider the following cases in Python 3.6.3:

>>> 0.9//0.1
8.0
>>> 0.8//0.1
8.0
>>> import math
>>> math.floor(0.9/0.1)
9
>>> math.floor(0.8/0.1)
8

Am I missing something?

----------
components: Interpreter Core
messages: 309873
nosy: Nathan.Goldbaum
priority: normal
severity: normal
status: open
title: odd floor division behavior
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32543>
_______________________________________

From report at bugs.python.org  Sat Jan 13 13:29:29 2018
From: report at bugs.python.org (INADA Naoki)
Date: Sat, 13 Jan 2018 18:29:29 +0000
Subject: [New-bugs-announce] [issue32544] Speed up hasattr(o,
 name) and getattr(o, name, default)
Message-ID: <1515868169.96.0.467229070634.issue32544@psf.upfronthosting.co.za>


New submission from INADA Naoki <songofacandy at gmail.com>:

ABCMeta.__new__ calls `getattr(value, "__isabstractmethod__", False)` many times.
https://github.com/python/cpython/blob/0f31c74fcfdec8f9e6157de2c366f2273de81677/Lib/abc.py#L135-L142

Since metaclass is used by subclasses, it checks all members of all subclasses (including concrete class).

But getattr() and hasattr() is inefficient when attribution is not found,
because it raises AttributeError and clear it internally.

I tried to bypass AttributeError when tp_getattro == PyObject_GenericGetAttr.
Here is quick micro benchmark:

$ ./python-patched -m perf timeit --compare-to=`pwd`/python-master -s 'def foo(): pass' 'hasattr(foo, "__isabstractmethod__")'python-master: ..................... 385 ns +- 2 ns
python-patched: ..................... 87.6 ns +- 1.6 ns

Mean +- std dev: [python-master] 385 ns +- 2 ns -> [python-patched] 87.6 ns +- 1.6 ns: 4.40x faster (-77%)

(I added Ivan to nosy list because he may implement C version of ABC.)

----------
messages: 309896
nosy: inada.naoki, levkivskyi
priority: normal
severity: normal
status: open
title: Speed up hasattr(o, name) and getattr(o, name, default)

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32544>
_______________________________________

From report at bugs.python.org  Sat Jan 13 15:34:13 2018
From: report at bugs.python.org (Matt Ripley)
Date: Sat, 13 Jan 2018 20:34:13 +0000
Subject: [New-bugs-announce] [issue32545] Unable to install Python 3.7.0a4
 on Windows 10 - Error 0x80070643: Failed to install MSI package.
Message-ID: <1515875653.34.0.467229070634.issue32545@psf.upfronthosting.co.za>


New submission from Matt Ripley <matt.ripley at yahoo.co.uk>:

When I try to use any of the installers downloaded from the website I get the errors 2203 and 0x80070643:

[2468:1D2C][2018-01-13T20:15:51]e000: Error 0x80070643: Failed to install MSI package.
[2468:1D2C][2018-01-13T20:15:51]e000: Error 0x80070643: Failed to configure per-user MSI package.
[2468:1D2C][2018-01-13T20:15:51]i319: Applied execute package: core_JustForMe, result: 0x80070643, restart: None
[2468:1D2C][2018-01-13T20:15:51]e000: Error 0x80070643: Failed to execute MSI package.

Been looking all over the reported issues but nothing has helped me with this one. Other installers work without issue?

----------
components: Installation
files: Python 3.7.0a4 (64-bit)_20180113201542_000_core_JustForMe.log
messages: 309899
nosy: mwr256
priority: normal
severity: normal
status: open
title: Unable to install Python 3.7.0a4 on Windows 10 - Error 0x80070643: Failed to install MSI package.
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file47382/Python 3.7.0a4 (64-bit)_20180113201542_000_core_JustForMe.log

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32545>
_______________________________________

From report at bugs.python.org  Sat Jan 13 16:26:23 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 13 Jan 2018 21:26:23 +0000
Subject: [New-bugs-announce] [issue32546] Unusual TypeError with dataclass
 decorator
Message-ID: <1515878783.18.0.467229070634.issue32546@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <raymond.hettinger at gmail.com>:

The following code (simplified from a real example) triggers an unexpected TypeError:

    @dataclass
    class PrioritizedItem:
        priority: 'int'
        def __eq__(self, other):
            return self.priority == other.priority

This code gives the following trackback:

    Traceback (most recent call last):
      File "/Users/raymond/Documents/tmp16.py", line 16, in <module>
        @dataclass
      File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/dataclasses.py", line 598, in dataclass
        return wrap(_cls)
      File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/dataclasses.py", line 590, in wrap
        return _process_class(cls, repr, eq, order, hash, init, frozen)
      File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/dataclasses.py", line 539, in _process_class
        _set_attribute(cls, '__hash__', None)
      File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/dataclasses.py", line 444, in _set_attribute
        raise TypeError(f'Cannot overwrite attribute {name} '
    TypeError: Cannot overwrite attribute __hash__ in PrioritizedItem

----------
assignee: eric.smith
components: Library (Lib)
files: data_class_type_error.py
messages: 309901
nosy: eric.smith, rhettinger
priority: normal
severity: normal
status: open
title: Unusual TypeError with dataclass decorator
type: behavior
versions: Python 3.7
Added file: https://bugs.python.org/file47384/data_class_type_error.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32546>
_______________________________________

From report at bugs.python.org  Sat Jan 13 19:41:44 2018
From: report at bugs.python.org (Ben Cummings)
Date: Sun, 14 Jan 2018 00:41:44 +0000
Subject: [New-bugs-announce] [issue32547] csv.DictWriter emits strange
 errors if fieldnames is an iterator
Message-ID: <1515890504.43.0.467229070634.issue32547@psf.upfronthosting.co.za>


New submission from Ben Cummings <ben at benandconner.com>:

If I pass an iterator to csv.DictWriter as the fieldname field, then DictWriter consumes that iterator pretty quickly, emitting strange errors such as the following when trying to write the headers.

>>> import csv
>>> fields = iter(["a", "b", "c", "d"])
>>> f = open('test.csv', 'w')
>>> writer = csv.DictWriter(f, fieldnames=fields)
>>> writer.writeheader()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.4/csv.py", line 142, in writeheader
    self.writerow(header)
  File "/usr/lib/python3.4/csv.py", line 153, in writerow
    return self.writer.writerow(self._dict_to_list(rowdict))
  File "/usr/lib/python3.4/csv.py", line 149, in _dict_to_list
    + ", ".join([repr(x) for x in wrong_fields]))
ValueError: dict contains fields not in fieldnames: 'c', 'a'

This is because writeheader and _dict_to_list repeatedly iterate over self.fieldnames. It seems like this could be solved by making a list of fieldnames in the constructor.

----------
components: Library (Lib)
messages: 309904
nosy: bendotc
priority: normal
severity: normal
status: open
title: csv.DictWriter emits strange errors if fieldnames is an iterator
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32547>
_______________________________________

From report at bugs.python.org  Sat Jan 13 20:08:05 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 14 Jan 2018 01:08:05 +0000
Subject: [New-bugs-announce] [issue32548] IDLE: Add links for email and docs
 to help_about
Message-ID: <1515892085.57.0.467229070634.issue32548@psf.upfronthosting.co.za>


New submission from Cheryl Sabella <chekat2 at gmail.com>:

In the help_about dialog, change the email address and IDLE documentation into hyperlinks as a first step toward rewriting the dialog to use hyperlinks instead of buttons, as proposed in msg296648 and msg294298.

----------
assignee: terry.reedy
components: IDLE
messages: 309906
nosy: csabella, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE: Add links for email and docs to help_about
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32548>
_______________________________________

From report at bugs.python.org  Sun Jan 14 05:39:47 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 14 Jan 2018 10:39:47 +0000
Subject: [New-bugs-announce] [issue32549] Travis: Test with OpenSSL 1.1.0
Message-ID: <1515926387.7.0.467229070634.issue32549@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

For several planned features and security improvements, at least OpenSSL 1.0.2 is required. OpenSSL 1.1.0 is preferred to test all new features. See discussion https://mail.python.org/pipermail/python-dev/2018-January/151718.html . However Travis CI uses Ubuntu 14.04 LTS, which comes with OpenSSL 1.0.1.

To address the problem, CPython has either to compile and install a local copy of OpenSSL, move to container-based testing or use a different CI provider with more recent infrastructure.

I have created a PR that uses an improved version of my multissl test helper to compile and install the latest copy of OpenSSL 1.1.0. The build is cached by Travis. I *think* it is necessary to build OpenSSL in master so PRs can use the cache. A daily Travis cron job on master should do the trick.

----------
messages: 309916
nosy: christian.heimes
priority: normal
severity: normal
stage: patch review
status: open
title: Travis: Test with OpenSSL 1.1.0
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32549>
_______________________________________

From report at bugs.python.org  Sun Jan 14 07:05:38 2018
From: report at bugs.python.org (Mark Shannon)
Date: Sun, 14 Jan 2018 12:05:38 +0000
Subject: [New-bugs-announce] [issue32550] STORE_ANNOTATION bytecode is
 unnecessary and can be removed.
Message-ID: <1515931538.97.0.467229070634.issue32550@psf.upfronthosting.co.za>


New submission from Mark Shannon <mark at hotpy.org>:

The STORE_ANNOTATION bytecode is used to implement annotations.
The code 
     name : ann
is equivalent to 
    __annotations__['name'] = ann        

Consequently,
    STORE_ANNOTATION name

can be trivially replaced with 
    LOAD_NAME  __annotations__
    LOAD_CONST 'name'
    STORE_SUBSCR

----------
components: Interpreter Core
messages: 309918
nosy: Mark.Shannon
priority: normal
severity: normal
stage: needs patch
status: open
title: STORE_ANNOTATION bytecode is unnecessary and can be removed.
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32550>
_______________________________________

From report at bugs.python.org  Sun Jan 14 10:53:57 2018
From: report at bugs.python.org (Ned Batchelder)
Date: Sun, 14 Jan 2018 15:53:57 +0000
Subject: [New-bugs-announce] [issue32551] 3.5.4 has a regression that was
 fixed in 3.6.1rc1
Message-ID: <1515945237.21.0.467229070634.issue32551@psf.upfronthosting.co.za>


New submission from Ned Batchelder <ned at nedbatchelder.com>:

The issue that I reported in https://bugs.python.org/issue29723 is now affecting 3.5.4:


```
$ pwd
/Users/ned/foo
$ tree syspathmain
syspathmain
??? __main__.py

0 directories, 1 file
$ cat syspathmain/__main__.py
import sys
print("-" * 20)
print(sys.version)
print("\n".join(sys.path))
$ for pyth in /usr/local/pythonz/pythons/CPython-*/bin/python; do $pyth syspathmain; done
/usr/local/pythonz/pythons/CPython-2.4.6/bin/python: 'syspathmain' is a directory, cannot continue
--------------------
2.6.9 (unknown, Jun 18 2016, 17:45:44)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-2.6.9/lib/python26.zip
/usr/local/pythonz/pythons/CPython-2.6.9/lib/python2.6
/usr/local/pythonz/pythons/CPython-2.6.9/lib/python2.6/plat-darwin
/usr/local/pythonz/pythons/CPython-2.6.9/lib/python2.6/plat-mac
/usr/local/pythonz/pythons/CPython-2.6.9/lib/python2.6/plat-mac/lib-scriptpackages
/usr/local/pythonz/pythons/CPython-2.6.9/lib/python2.6/lib-tk
/usr/local/pythonz/pythons/CPython-2.6.9/lib/python2.6/lib-old
/usr/local/pythonz/pythons/CPython-2.6.9/lib/python2.6/lib-dynload
/usr/local/pythonz/pythons/CPython-2.6.9/lib/python2.6/site-packages
--------------------
2.7.10 (default, Jun 18 2016, 18:30:12)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-2.7.10/lib/python27.zip
/usr/local/pythonz/pythons/CPython-2.7.10/lib/python2.7
/usr/local/pythonz/pythons/CPython-2.7.10/lib/python2.7/plat-darwin
/usr/local/pythonz/pythons/CPython-2.7.10/lib/python2.7/plat-mac
/usr/local/pythonz/pythons/CPython-2.7.10/lib/python2.7/plat-mac/lib-scriptpackages
/usr/local/pythonz/pythons/CPython-2.7.10/lib/python2.7/lib-tk
/usr/local/pythonz/pythons/CPython-2.7.10/lib/python2.7/lib-old
/usr/local/pythonz/pythons/CPython-2.7.10/lib/python2.7/lib-dynload
/usr/local/pythonz/pythons/CPython-2.7.10/lib/python2.7/site-packages
--------------------
2.7.11 (default, Jun 18 2016, 17:51:44)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-2.7.11/lib/python27.zip
/usr/local/pythonz/pythons/CPython-2.7.11/lib/python2.7
/usr/local/pythonz/pythons/CPython-2.7.11/lib/python2.7/plat-darwin
/usr/local/pythonz/pythons/CPython-2.7.11/lib/python2.7/plat-mac
/usr/local/pythonz/pythons/CPython-2.7.11/lib/python2.7/plat-mac/lib-scriptpackages
/usr/local/pythonz/pythons/CPython-2.7.11/lib/python2.7/lib-tk
/usr/local/pythonz/pythons/CPython-2.7.11/lib/python2.7/lib-old
/usr/local/pythonz/pythons/CPython-2.7.11/lib/python2.7/lib-dynload
/usr/local/pythonz/pythons/CPython-2.7.11/lib/python2.7/site-packages
--------------------
2.7.12 (default, Nov 20 2016, 16:53:49)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-2.7.12/lib/python27.zip
/usr/local/pythonz/pythons/CPython-2.7.12/lib/python2.7
/usr/local/pythonz/pythons/CPython-2.7.12/lib/python2.7/plat-darwin
/usr/local/pythonz/pythons/CPython-2.7.12/lib/python2.7/plat-mac
/usr/local/pythonz/pythons/CPython-2.7.12/lib/python2.7/plat-mac/lib-scriptpackages
/usr/local/pythonz/pythons/CPython-2.7.12/lib/python2.7/lib-tk
/usr/local/pythonz/pythons/CPython-2.7.12/lib/python2.7/lib-old
/usr/local/pythonz/pythons/CPython-2.7.12/lib/python2.7/lib-dynload
/usr/local/pythonz/pythons/CPython-2.7.12/lib/python2.7/site-packages
--------------------
2.7.13 (default, Dec 17 2016, 16:51:07)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-2.7.13/lib/python27.zip
/usr/local/pythonz/pythons/CPython-2.7.13/lib/python2.7
/usr/local/pythonz/pythons/CPython-2.7.13/lib/python2.7/plat-darwin
/usr/local/pythonz/pythons/CPython-2.7.13/lib/python2.7/plat-mac
/usr/local/pythonz/pythons/CPython-2.7.13/lib/python2.7/plat-mac/lib-scriptpackages
/usr/local/pythonz/pythons/CPython-2.7.13/lib/python2.7/lib-tk
/usr/local/pythonz/pythons/CPython-2.7.13/lib/python2.7/lib-old
/usr/local/pythonz/pythons/CPython-2.7.13/lib/python2.7/lib-dynload
/usr/local/pythonz/pythons/CPython-2.7.13/lib/python2.7/site-packages
--------------------
2.7.13rc1 (default, Dec  4 2016, 15:34:21)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-2.7.13rc1/lib/python27.zip
/usr/local/pythonz/pythons/CPython-2.7.13rc1/lib/python2.7
/usr/local/pythonz/pythons/CPython-2.7.13rc1/lib/python2.7/plat-darwin
/usr/local/pythonz/pythons/CPython-2.7.13rc1/lib/python2.7/plat-mac
/usr/local/pythonz/pythons/CPython-2.7.13rc1/lib/python2.7/plat-mac/lib-scriptpackages
/usr/local/pythonz/pythons/CPython-2.7.13rc1/lib/python2.7/lib-tk
/usr/local/pythonz/pythons/CPython-2.7.13rc1/lib/python2.7/lib-old
/usr/local/pythonz/pythons/CPython-2.7.13rc1/lib/python2.7/lib-dynload
/usr/local/pythonz/pythons/CPython-2.7.13rc1/lib/python2.7/site-packages
--------------------
2.7.14 (default, Oct  4 2017, 09:45:53)
[GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.37)]
syspathmain
/usr/local/pythonz/pythons/CPython-2.7.14/lib/python27.zip
/usr/local/pythonz/pythons/CPython-2.7.14/lib/python2.7
/usr/local/pythonz/pythons/CPython-2.7.14/lib/python2.7/plat-darwin
/usr/local/pythonz/pythons/CPython-2.7.14/lib/python2.7/plat-mac
/usr/local/pythonz/pythons/CPython-2.7.14/lib/python2.7/plat-mac/lib-scriptpackages
/usr/local/pythonz/pythons/CPython-2.7.14/lib/python2.7/lib-tk
/usr/local/pythonz/pythons/CPython-2.7.14/lib/python2.7/lib-old
/usr/local/pythonz/pythons/CPython-2.7.14/lib/python2.7/lib-dynload
/usr/local/pythonz/pythons/CPython-2.7.14/lib/python2.7/site-packages
--------------------
2.7.14rc1 (default, Aug 27 2017, 08:01:38)
[GCC 4.2.1 Compatible Apple LLVM 8.1.0 (clang-802.0.42)]
syspathmain
/usr/local/pythonz/pythons/CPython-2.7.14rc1/lib/python27.zip
/usr/local/pythonz/pythons/CPython-2.7.14rc1/lib/python2.7
/usr/local/pythonz/pythons/CPython-2.7.14rc1/lib/python2.7/plat-darwin
/usr/local/pythonz/pythons/CPython-2.7.14rc1/lib/python2.7/plat-mac
/usr/local/pythonz/pythons/CPython-2.7.14rc1/lib/python2.7/plat-mac/lib-scriptpackages
/usr/local/pythonz/pythons/CPython-2.7.14rc1/lib/python2.7/lib-tk
/usr/local/pythonz/pythons/CPython-2.7.14rc1/lib/python2.7/lib-old
/usr/local/pythonz/pythons/CPython-2.7.14rc1/lib/python2.7/lib-dynload
/usr/local/pythonz/pythons/CPython-2.7.14rc1/lib/python2.7/site-packages
--------------------
3.1.5 (default, Jun 18 2016, 17:54:07)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.1.5/lib/python31.zip
/usr/local/pythonz/pythons/CPython-3.1.5/lib/python3.1
/usr/local/pythonz/pythons/CPython-3.1.5/lib/python3.1/plat-darwin
/usr/local/pythonz/pythons/CPython-3.1.5/lib/python3.1/lib-dynload
/usr/local/pythonz/pythons/CPython-3.1.5/lib/python3.1/site-packages
--------------------
3.2.6 (default, Jun 18 2016, 17:56:34)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.2.6/lib/python32.zip
/usr/local/pythonz/pythons/CPython-3.2.6/lib/python3.2
/usr/local/pythonz/pythons/CPython-3.2.6/lib/python3.2/plat-darwin
/usr/local/pythonz/pythons/CPython-3.2.6/lib/python3.2/lib-dynload
/usr/local/pythonz/pythons/CPython-3.2.6/lib/python3.2/site-packages
--------------------
3.3.6 (default, Jun 18 2016, 17:58:30)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.3.6/lib/python33.zip
/usr/local/pythonz/pythons/CPython-3.3.6/lib/python3.3
/usr/local/pythonz/pythons/CPython-3.3.6/lib/python3.3/plat-darwin
/usr/local/pythonz/pythons/CPython-3.3.6/lib/python3.3/lib-dynload
/usr/local/pythonz/pythons/CPython-3.3.6/lib/python3.3/site-packages
--------------------
3.4.3 (default, Jun 18 2016, 22:29:43)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.4.3/lib/python34.zip
/usr/local/pythonz/pythons/CPython-3.4.3/lib/python3.4
/usr/local/pythonz/pythons/CPython-3.4.3/lib/python3.4/plat-darwin
/usr/local/pythonz/pythons/CPython-3.4.3/lib/python3.4/lib-dynload
/usr/local/pythonz/pythons/CPython-3.4.3/lib/python3.4/site-packages
--------------------
3.4.4 (default, Jun 18 2016, 18:00:41)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.4.4/lib/python34.zip
/usr/local/pythonz/pythons/CPython-3.4.4/lib/python3.4
/usr/local/pythonz/pythons/CPython-3.4.4/lib/python3.4/plat-darwin
/usr/local/pythonz/pythons/CPython-3.4.4/lib/python3.4/lib-dynload
/usr/local/pythonz/pythons/CPython-3.4.4/lib/python3.4/site-packages
--------------------
3.4.5 (default, Jun 27 2016, 09:25:27)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.4.5/lib/python34.zip
/usr/local/pythonz/pythons/CPython-3.4.5/lib/python3.4
/usr/local/pythonz/pythons/CPython-3.4.5/lib/python3.4/plat-darwin
/usr/local/pythonz/pythons/CPython-3.4.5/lib/python3.4/lib-dynload
/usr/local/pythonz/pythons/CPython-3.4.5/lib/python3.4/site-packages
--------------------
3.4.6 (default, Jan 17 2017, 05:32:05)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.4.6/lib/python34.zip
/usr/local/pythonz/pythons/CPython-3.4.6/lib/python3.4
/usr/local/pythonz/pythons/CPython-3.4.6/lib/python3.4/plat-darwin
/usr/local/pythonz/pythons/CPython-3.4.6/lib/python3.4/lib-dynload
/usr/local/pythonz/pythons/CPython-3.4.6/lib/python3.4/site-packages
--------------------
3.4.6rc1 (default, Jan  3 2017, 06:13:09)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.4.6rc1/lib/python34.zip
/usr/local/pythonz/pythons/CPython-3.4.6rc1/lib/python3.4
/usr/local/pythonz/pythons/CPython-3.4.6rc1/lib/python3.4/plat-darwin
/usr/local/pythonz/pythons/CPython-3.4.6rc1/lib/python3.4/lib-dynload
/usr/local/pythonz/pythons/CPython-3.4.6rc1/lib/python3.4/site-packages
--------------------
3.5.1 (default, Jun 18 2016, 17:20:31)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.5.1/lib/python35.zip
/usr/local/pythonz/pythons/CPython-3.5.1/lib/python3.5
/usr/local/pythonz/pythons/CPython-3.5.1/lib/python3.5/plat-darwin
/usr/local/pythonz/pythons/CPython-3.5.1/lib/python3.5/lib-dynload
/usr/local/pythonz/pythons/CPython-3.5.1/lib/python3.5/site-packages
--------------------
3.5.2 (default, Jun 27 2016, 13:24:47)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.5.2/lib/python35.zip
/usr/local/pythonz/pythons/CPython-3.5.2/lib/python3.5
/usr/local/pythonz/pythons/CPython-3.5.2/lib/python3.5/plat-darwin
/usr/local/pythonz/pythons/CPython-3.5.2/lib/python3.5/lib-dynload
/usr/local/pythonz/pythons/CPython-3.5.2/lib/python3.5/site-packages
--------------------
3.5.3 (default, Jan 17 2017, 05:34:29)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.5.3/lib/python35.zip
/usr/local/pythonz/pythons/CPython-3.5.3/lib/python3.5
/usr/local/pythonz/pythons/CPython-3.5.3/lib/python3.5/plat-darwin
/usr/local/pythonz/pythons/CPython-3.5.3/lib/python3.5/lib-dynload
/usr/local/pythonz/pythons/CPython-3.5.3/lib/python3.5/site-packages
--------------------
3.5.3rc1 (default, Jan  3 2017, 06:16:13)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.5.3rc1/lib/python35.zip
/usr/local/pythonz/pythons/CPython-3.5.3rc1/lib/python3.5
/usr/local/pythonz/pythons/CPython-3.5.3rc1/lib/python3.5/plat-darwin
/usr/local/pythonz/pythons/CPython-3.5.3rc1/lib/python3.5/lib-dynload
/usr/local/pythonz/pythons/CPython-3.5.3rc1/lib/python3.5/site-packages
--------------------
3.5.4 (default, Jan  7 2018, 17:59:30)
[GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.39.2)]
syspathmain
/Users/ned/foo
/usr/local/pythonz/pythons/CPython-3.5.4/lib/python35.zip
/usr/local/pythonz/pythons/CPython-3.5.4/lib/python3.5
/usr/local/pythonz/pythons/CPython-3.5.4/lib/python3.5/plat-darwin
/usr/local/pythonz/pythons/CPython-3.5.4/lib/python3.5/lib-dynload
/usr/local/pythonz/pythons/CPython-3.5.4/lib/python3.5/site-packages
--------------------
3.6.0 (default, Dec 23 2016, 07:11:25)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python36.zip
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/lib-dynload
/usr/local/pythonz/pythons/CPython-3.6.0/lib/python3.6/site-packages
--------------------
3.6.0a1 (default, Jun 18 2016, 17:17:21)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.6.0a1/lib/python36.zip
/usr/local/pythonz/pythons/CPython-3.6.0a1/lib/python3.6
/usr/local/pythonz/pythons/CPython-3.6.0a1/lib/python3.6/plat-darwin
/usr/local/pythonz/pythons/CPython-3.6.0a1/lib/python3.6/lib-dynload
/usr/local/pythonz/pythons/CPython-3.6.0a1/lib/python3.6/site-packages
--------------------
3.6.0a2 (default, Jun 19 2016, 07:45:01)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.6.0a2/lib/python36.zip
/usr/local/pythonz/pythons/CPython-3.6.0a2/lib/python3.6
/usr/local/pythonz/pythons/CPython-3.6.0a2/lib/python3.6/plat-darwin
/usr/local/pythonz/pythons/CPython-3.6.0a2/lib/python3.6/lib-dynload
/usr/local/pythonz/pythons/CPython-3.6.0a2/lib/python3.6/site-packages
--------------------
3.6.0a3 (default, Jul 12 2016, 08:17:28)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.6.0a3/lib/python36.zip
/usr/local/pythonz/pythons/CPython-3.6.0a3/lib/python3.6
/usr/local/pythonz/pythons/CPython-3.6.0a3/lib/python3.6/plat-darwin
/usr/local/pythonz/pythons/CPython-3.6.0a3/lib/python3.6/lib-dynload
/usr/local/pythonz/pythons/CPython-3.6.0a3/lib/python3.6/site-packages
--------------------
3.6.0b1 (default, Sep 12 2016, 20:38:35)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.6.0b1/lib/python36.zip
/usr/local/pythonz/pythons/CPython-3.6.0b1/lib/python3.6
/usr/local/pythonz/pythons/CPython-3.6.0b1/lib/python3.6/lib-dynload
/usr/local/pythonz/pythons/CPython-3.6.0b1/lib/python3.6/site-packages
--------------------
3.6.0b2 (default, Oct 10 2016, 21:30:05)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.6.0b2/lib/python36.zip
/usr/local/pythonz/pythons/CPython-3.6.0b2/lib/python3.6
/usr/local/pythonz/pythons/CPython-3.6.0b2/lib/python3.6/lib-dynload
/usr/local/pythonz/pythons/CPython-3.6.0b2/lib/python3.6/site-packages
--------------------
3.6.0b3 (default, Nov  1 2016, 05:07:34)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.6.0b3/lib/python36.zip
/usr/local/pythonz/pythons/CPython-3.6.0b3/lib/python3.6
/usr/local/pythonz/pythons/CPython-3.6.0b3/lib/python3.6/lib-dynload
/usr/local/pythonz/pythons/CPython-3.6.0b3/lib/python3.6/site-packages
--------------------
3.6.0b4 (default, Nov 22 2016, 06:27:47)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.6.0b4/lib/python36.zip
/usr/local/pythonz/pythons/CPython-3.6.0b4/lib/python3.6
/usr/local/pythonz/pythons/CPython-3.6.0b4/lib/python3.6/lib-dynload
/usr/local/pythonz/pythons/CPython-3.6.0b4/lib/python3.6/site-packages
--------------------
3.6.0rc1 (default, Dec  7 2016, 06:45:00)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.6.0rc1/lib/python36.zip
/usr/local/pythonz/pythons/CPython-3.6.0rc1/lib/python3.6
/usr/local/pythonz/pythons/CPython-3.6.0rc1/lib/python3.6/lib-dynload
/usr/local/pythonz/pythons/CPython-3.6.0rc1/lib/python3.6/site-packages
--------------------
3.6.0rc2 (default, Dec 17 2016, 07:50:27)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.6.0rc2/lib/python36.zip
/usr/local/pythonz/pythons/CPython-3.6.0rc2/lib/python3.6
/usr/local/pythonz/pythons/CPython-3.6.0rc2/lib/python3.6/lib-dynload
/usr/local/pythonz/pythons/CPython-3.6.0rc2/lib/python3.6/site-packages
--------------------
3.6.1 (default, Mar 22 2017, 05:30:11)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.6.1/lib/python36.zip
/usr/local/pythonz/pythons/CPython-3.6.1/lib/python3.6
/usr/local/pythonz/pythons/CPython-3.6.1/lib/python3.6/lib-dynload
/usr/local/pythonz/pythons/CPython-3.6.1/lib/python3.6/site-packages
--------------------
3.6.1rc1 (default, Mar  5 2017, 08:02:03)
[GCC 4.2.1 Compatible Apple LLVM 7.0.2 (clang-700.1.81)]
syspathmain
/Users/ned/foo
/usr/local/pythonz/pythons/CPython-3.6.1rc1/lib/python36.zip
/usr/local/pythonz/pythons/CPython-3.6.1rc1/lib/python3.6
/usr/local/pythonz/pythons/CPython-3.6.1rc1/lib/python3.6/lib-dynload
/usr/local/pythonz/pythons/CPython-3.6.1rc1/lib/python3.6/site-packages
--------------------
3.6.2 (default, Jul 17 2017, 07:05:09)
[GCC 4.2.1 Compatible Apple LLVM 8.1.0 (clang-802.0.42)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.6.2/lib/python36.zip
/usr/local/pythonz/pythons/CPython-3.6.2/lib/python3.6
/usr/local/pythonz/pythons/CPython-3.6.2/lib/python3.6/lib-dynload
/usr/local/pythonz/pythons/CPython-3.6.2/lib/python3.6/site-packages
--------------------
3.6.2rc1 (default, Jun 18 2017, 16:38:24)
[GCC 4.2.1 Compatible Apple LLVM 8.1.0 (clang-802.0.42)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.6.2rc1/lib/python36.zip
/usr/local/pythonz/pythons/CPython-3.6.2rc1/lib/python3.6
/usr/local/pythonz/pythons/CPython-3.6.2rc1/lib/python3.6/lib-dynload
/usr/local/pythonz/pythons/CPython-3.6.2rc1/lib/python3.6/site-packages
--------------------
3.6.2rc2 (default, Jul  8 2017, 07:07:22)
[GCC 4.2.1 Compatible Apple LLVM 8.1.0 (clang-802.0.42)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.6.2rc2/lib/python36.zip
/usr/local/pythonz/pythons/CPython-3.6.2rc2/lib/python3.6
/usr/local/pythonz/pythons/CPython-3.6.2rc2/lib/python3.6/lib-dynload
/usr/local/pythonz/pythons/CPython-3.6.2rc2/lib/python3.6/site-packages
--------------------
3.6.3 (default, Oct  4 2017, 06:03:25)
[GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.37)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.6.3/lib/python36.zip
/usr/local/pythonz/pythons/CPython-3.6.3/lib/python3.6
/usr/local/pythonz/pythons/CPython-3.6.3/lib/python3.6/lib-dynload
/usr/local/pythonz/pythons/CPython-3.6.3/lib/python3.6/site-packages
--------------------
3.6.4 (default, Dec 19 2017, 08:11:42)
[GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.39.2)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.6.4/lib/python36.zip
/usr/local/pythonz/pythons/CPython-3.6.4/lib/python3.6
/usr/local/pythonz/pythons/CPython-3.6.4/lib/python3.6/lib-dynload
/usr/local/pythonz/pythons/CPython-3.6.4/lib/python3.6/site-packages
--------------------
3.6.4rc1 (default, Dec  6 2017, 06:09:07)
[GCC 4.2.1 Compatible Apple LLVM 9.0.0 (clang-900.0.38)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.6.4rc1/lib/python36.zip
/usr/local/pythonz/pythons/CPython-3.6.4rc1/lib/python3.6
/usr/local/pythonz/pythons/CPython-3.6.4rc1/lib/python3.6/lib-dynload
/usr/local/pythonz/pythons/CPython-3.6.4rc1/lib/python3.6/site-packages
--------------------
3.7.0a1 (default, Sep 20 2017, 06:16:54)
[GCC 4.2.1 Compatible Apple LLVM 8.1.0 (clang-802.0.42)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.7.0a1/lib/python37.zip
/usr/local/pythonz/pythons/CPython-3.7.0a1/lib/python3.7
/usr/local/pythonz/pythons/CPython-3.7.0a1/lib/python3.7/lib-dynload
/usr/local/pythonz/pythons/CPython-3.7.0a1/lib/python3.7/site-packages
--------------------
3.7.0a2 (default, Oct 17 2017, 15:40:05)
[Clang 9.0.0 (clang-900.0.38)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.7.0a2/lib/python37.zip
/usr/local/pythonz/pythons/CPython-3.7.0a2/lib/python3.7
/usr/local/pythonz/pythons/CPython-3.7.0a2/lib/python3.7/lib-dynload
/usr/local/pythonz/pythons/CPython-3.7.0a2/lib/python3.7/site-packages
--------------------
3.7.0a3 (default, Jan 13 2018, 20:06:18)
[Clang 9.0.0 (clang-900.0.39.2)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.7.0a3/lib/python37.zip
/usr/local/pythonz/pythons/CPython-3.7.0a3/lib/python3.7
/usr/local/pythonz/pythons/CPython-3.7.0a3/lib/python3.7/lib-dynload
/usr/local/pythonz/pythons/CPython-3.7.0a3/lib/python3.7/site-packages
--------------------
3.7.0a4 (default, Jan 10 2018, 19:19:56)
[Clang 9.0.0 (clang-900.0.39.2)]
syspathmain
/usr/local/pythonz/pythons/CPython-3.7.0a4/lib/python37.zip
/usr/local/pythonz/pythons/CPython-3.7.0a4/lib/python3.7
/usr/local/pythonz/pythons/CPython-3.7.0a4/lib/python3.7/lib-dynload
/usr/local/pythonz/pythons/CPython-3.7.0a4/lib/python3.7/site-packages
$
```

----------
keywords: 3.5regression
messages: 309925
nosy: nedbat
priority: normal
severity: normal
status: open
title: 3.5.4 has a regression that was fixed in 3.6.1rc1
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32551>
_______________________________________

From report at bugs.python.org  Sun Jan 14 19:35:36 2018
From: report at bugs.python.org (elypter)
Date: Mon, 15 Jan 2018 00:35:36 +0000
Subject: [New-bugs-announce] [issue32552] Improve text for file arguments in
 argparse.ArgumentDefaultsHelpFormatter class
Message-ID: <1515976536.21.0.467229070634.issue32552@psf.upfronthosting.co.za>


New submission from elypter <elypter at yahoo.de>:

If you use formatter_class=argparse.ArgumentDefaultsHelpFormatter in the constructor then the defaults that you include in arguments get automatically added to the help text. this looks great for int and Strings but not for files.

example:
  -suffixes [SUFFIXES]
                        suffixes file which contains keywords that are often
                        the last part of a class or style name of a sticky bar
                        (default: <open file 'sources/suffixes.txt', mode 'r'
                        at 0xb71385f8>)

it should rather look like

  -suffixes [SUFFIXES]
                        suffixes file which contains keywords that are often
                        the last part of a class or style name of a sticky bar
                        (default:'sources/suffixes.txt')


the same holds probably true for more exotic datatypes. so an alternative or an addition could be to add an option to arguments to not add the default to the help text

----------
components: Library (Lib)
messages: 309940
nosy: elypter
priority: normal
severity: normal
status: open
title: Improve text for file arguments in argparse.ArgumentDefaultsHelpFormatter class
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32552>
_______________________________________

From report at bugs.python.org  Sun Jan 14 21:08:16 2018
From: report at bugs.python.org (Paul Watson)
Date: Mon, 15 Jan 2018 02:08:16 +0000
Subject: [New-bugs-announce] [issue32553] venv says to use python3 which
 does not exist in 3.6.4
Message-ID: <1515982096.25.0.467229070634.issue32553@psf.upfronthosting.co.za>


New submission from Paul Watson <paul.hermeneutic at gmail.com>:

The 3.6.4 documentation on venv specifies using 'python3', but no python3 executable is in the 3.6.4 kit.

https://docs.python.org/3/library/venv.html?highlight=venv#module-venv

----------
assignee: docs at python
components: Documentation
messages: 309943
nosy: Paul Watson, docs at python
priority: normal
severity: normal
status: open
title: venv says to use python3 which does not exist in 3.6.4
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32553>
_______________________________________

From report at bugs.python.org  Mon Jan 15 04:08:22 2018
From: report at bugs.python.org (Johnny Dude)
Date: Mon, 15 Jan 2018 09:08:22 +0000
Subject: [New-bugs-announce] [issue32554] random seed is not consistent when
 using tuples with a str element
Message-ID: <1516007302.18.0.467229070634.issue32554@psf.upfronthosting.co.za>


New submission from Johnny Dude <johnny.dude at gmail.com>:

When using a tuple that include a string the results are not consistent when invoking a new interpreter or process.

For example executing the following on a linux machine will yield different results:
python3.6 -c 'import random; random.seed(("a", 1)); print(random.random())"

Please note that the doc string of random.seed states: "Initialize internal state from hashable object."

Python documentation does not. (https://docs.python.org/3.6/library/random.html#random.seed)

This is very confusing, I hope you can fix the behavior, not the doc string.

----------
components: Extension Modules
messages: 309956
nosy: JohnnyD
priority: normal
severity: normal
status: open
title: random seed is not consistent when using tuples with a str element
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32554>
_______________________________________

From report at bugs.python.org  Mon Jan 15 06:20:42 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 15 Jan 2018 11:20:42 +0000
Subject: [New-bugs-announce] [issue32555] Encoding issues with the locale
 encoding
Message-ID: <1516015242.77.0.467229070634.issue32555@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

Python 3.6 doesn't use the right encoding in os.strerror(), time.stftime(), locale.localeconv(), time.tzname, etc. on macOS, FreeBSD and other platforms.

See my fix locale encodings in bpo-29240: commit 7ed7aead9503102d2ed316175f198104e0cd674c, and test_all_locales.py attached to bpo-29240.

See also the bpo-31900 for locale.localeconv() encoding issue when LC_NUMERIC encoding is different than the LC_CTYPE encoding.

----------
components: Unicode
messages: 309963
nosy: ezio.melotti, vstinner
priority: normal
severity: normal
status: open
title: Encoding issues with the locale encoding
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32555>
_______________________________________

From report at bugs.python.org  Mon Jan 15 10:22:10 2018
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 15 Jan 2018 15:22:10 +0000
Subject: [New-bugs-announce] [issue32556] support bytes paths in nt
 _getdiskusage, _getvolumepathname, and _getfinalpathname
Message-ID: <1516029730.24.0.467229070634.issue32556@psf.upfronthosting.co.za>


New submission from Eryk Sun <eryksun at gmail.com>:

In issue 26330 it was noted that nt._getdiskusage doesn't accept bytes paths. The same applies to nt._getvolumepathname and nt._getfinalpathname. Callers of these functions shouldn't have to manually implement PEP 529 UTF-8 support to handle input and output bytes paths. 

On the other hand, nt._getfullpathname works with a bytes path since it takes a `path_t` argument instead of `unicode` or `Py_UNICODE`. The above 3 functions could be rewritten to use `path_t` for the input path, and then encode the output path via PyUnicode_EncodeFSDefault if path->narrow is set.

----------
components: Library (Lib), Unicode, Windows
messages: 309990
nosy: eryksun, ezio.melotti, paul.moore, steve.dower, tim.golden, vstinner, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: support bytes paths in nt _getdiskusage, _getvolumepathname, and _getfinalpathname
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32556>
_______________________________________

From report at bugs.python.org  Mon Jan 15 10:26:52 2018
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 15 Jan 2018 15:26:52 +0000
Subject: [New-bugs-announce] [issue32557] allow shutil.disk_usage to take a
 file path
Message-ID: <1516030012.51.0.467229070634.issue32557@psf.upfronthosting.co.za>


New submission from Eryk Sun <eryksun at gmail.com>:

Issue 26330 was resolved by documenting that shutil.disk_usage requires a directory. However, the shutil module is in a position to harmonize cross-platform behavior in ways that aren't normally possible or recommended in the low-level os module. To that end, the Windows implementation could retry calling nt._getdiskusage on the resolved parent directory in case of NotADirectoryError. For example:

    def disk_usage(path):
        try:
            total, free = nt._getdiskusage(path)
        except NotADirectoryError:
            path = os.path.dirname(nt._getfinalpathname(path))
            total, free = nt._getdiskusage(path)
        used = total - free
        return _ntuple_diskusage(total, used, free)

Alternatively, this could be addressed in the implementation of nt._getdiskusage itself.

----------
components: Library (Lib), Windows
messages: 309992
nosy: eryksun, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: allow shutil.disk_usage to take a file path
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32557>
_______________________________________

From report at bugs.python.org  Mon Jan 15 11:40:20 2018
From: report at bugs.python.org (Tristan Colombo)
Date: Mon, 15 Jan 2018 16:40:20 +0000
Subject: [New-bugs-announce] [issue32558] Socketserver documentation : error
 in server example
Message-ID: <1516034420.52.0.467229070634.issue32558@psf.upfronthosting.co.za>


New submission from Tristan Colombo <tristan.colombo at gmail.com>:

In the documentation, at page :
- https://docs.python.org/3.6/library/socketserver.html
- Section 21.21.4.1

In the server side code :
if __name__ == "__main__":
    HOST, PORT = "localhost", 9999

    # Create the server, binding to localhost on port 9999
    with socketserver.TCPServer((HOST, PORT), MyTCPHandler) as server:
    ...

We got an error line 24 :     
with socketserver.TCPServer((HOST, PORT), MyTCPHandler) as server:
AttributeError: __exit__

socketserver.TCPServer object has no __exit__() method and can not be used in 'with' statement.

Proposed correction :
server = socketserver.TCPServer((HOST, PORT), MyTCPHandler)
with server:
    ...

----------
assignee: docs at python
components: Documentation
messages: 309995
nosy: docs at python, tcolombo
priority: normal
severity: normal
status: open
title: Socketserver documentation : error in server example
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32558>
_______________________________________

From report at bugs.python.org  Mon Jan 15 13:01:51 2018
From: report at bugs.python.org (Varun Agrawal)
Date: Mon, 15 Jan 2018 18:01:51 +0000
Subject: [New-bugs-announce] [issue32559] logging - public function to get
 level from name
Message-ID: <1516039311.82.0.467229070634.issue32559@psf.upfronthosting.co.za>


New submission from Varun Agrawal <varagrawal at gmail.com>:

Currently, the logging module has a function `getLevelName` and directly accessing the `_nameToLevel` dict is poor practice bordering on non-pythonic.

It would be nice to have a simple method like `getNameLevel` in the module to retrieve the logger level given the name. This can then be used in things such as argument parsers so someone can pass in the logging level name and the logging level can be appropriately set.

----------
components: Library (Lib)
messages: 310005
nosy: varunagrawal
priority: normal
severity: normal
status: open
title: logging - public function to get level from name
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32559>
_______________________________________

From report at bugs.python.org  Mon Jan 15 16:25:15 2018
From: report at bugs.python.org (Eryk Sun)
Date: Mon, 15 Jan 2018 21:25:15 +0000
Subject: [New-bugs-announce] [issue32560] inherit the py launcher's
 STARTUPINFO
Message-ID: <1516051515.58.0.467229070634.issue32560@psf.upfronthosting.co.za>


New submission from Eryk Sun <eryksun at gmail.com>:

I've occasionally seen requests to find the path of the LNK shortcut that was used to run a script -- for whatever reason. This can be reliably supported in most cases by calling WinAPI GetStartupInfo. If the flag STARTF_TITLEISLINKNAME is set, then the lpTitle field is the path to the LNK file. (This is how the console host process knows to use the shortcut file for its properties instead of the registry.)

However, if .py scripts are associated with the py launcher, the STARTUPINFO that has the required information is in the launcher process instead of the python.exe process. Since to some extent the launcher is acting as a proxy for python.exe, I think it should initialize Python's STARTUPINFO from a copy of its own values as returned by GetStartupInfo. This solves the dwFlags and lpTitle problem.

Additionally, the C runtime spawn family of functions supports inheriting file descriptors by passing them in the lpReserved2 field of STARTUPINFO. Currently this doesn't work when spawning Python via the launcher, since it calls CreateProcess instead of a spawn function. By inheriting the launcher's STARTUPINFO, this feature is restored as well. 

For example, in `run_child` in PC/launcher.c, I replaced `si.cb = sizeof(si)` with GetStartupInfoW(&si). Then I tested passing inherited file descriptors through the launcher as follows:

grandparent:

    >>> import os
    >>> os.pipe()
    (3, 4)
    >>> os.set_inheritable(4, True)
    >>> os.spawnl(os.P_WAIT, 'amd64/py_d.exe', 'py_d')

grandchild (py_d.exe => python.exe):

    Python 3.7.0a4 (v3.7.0a4:07c9d85, Jan  9 2018, 07:07:02)
    [MSC v.1900 64 bit (AMD64)] on win32
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import os
    >>> os.write(4, b'spam')
    4
    >>> ^Z

grandparent:

    0
    >>> os.read(3, 4)
    b'spam'

----------
components: Windows
keywords: easy (C)
messages: 310016
nosy: eryksun, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: inherit the py launcher's STARTUPINFO
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32560>
_______________________________________

From report at bugs.python.org  Mon Jan 15 21:07:22 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Tue, 16 Jan 2018 02:07:22 +0000
Subject: [New-bugs-announce] [issue32561] Add API to io objects for
 non-blocking reads/writes
Message-ID: <1516068442.29.0.467229070634.issue32561@psf.upfronthosting.co.za>


New submission from Nathaniel Smith <njs at pobox.com>:

Background: Doing I/O to files on disk has a hugely bimodal latency. If the I/O happens to be in or going to cache (either user-space cache, like in io.BufferedIOBase, or the OS's page cache), then the operation returns instantly (~1 ?s) without blocking. OTOH if the I/O isn't cached (for reads) or cacheable (for writes), then the operation may block for 10 ms or more.

This creates a problem for async programs that want to do disk I/O. You have to use a thread pool for reads/writes, because sometimes they block for a long time, and you want to let your event loop keep doing other useful work while it's waiting. But dispatching to a thread pool adds a lot of overhead (~100 ?s), so you'd really rather not do it for operations that can be serviced directly through cache. For uncached operations a thread gives a 100x speedup, but for cached operations it's a 100x slowdown, and -- this is the kicker -- there's no way to predict which ahead of time.

But, io.BufferedIOBase at least knows when it can satisfy a request directly from its buffer without issuing any syscalls. And in Linux 4.14, it's even possible to issue a non-blocking read to the kernel that will only succeed if the data is immediately available in page cache (bpo-31368).

So, it would be very nice if there were some way to ask a Python file object to do a "nonblocking read/write", which either succeeds immediately or else raises an error. The intended usage pattern would be:

async def read(self, *args):
    try:
        self._fileobj.read(*args, nonblock=True)
    except BlockingIOError: # maybe?
        return await run_in_worker_thread(self._fileobj.read, *args)

It would *really* help for this to be in the Python core, because right now the convenient way to do non-blocking disk I/O is to re-use the existing Python I/O stack, with worker threads. (This is how both aiofiles and trio's async file support work. I think maybe curio's too.) But to implement this feature ourselves, we'd have to first reimplement the whole I/O stack, because the important caching information, and choice of what syscall to use, are hidden inside.

----------
components: IO
messages: 310032
nosy: benjamin.peterson, njs, stutzbach
priority: normal
severity: normal
status: open
title: Add API to io objects for non-blocking reads/writes
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32561>
_______________________________________

From report at bugs.python.org  Mon Jan 15 21:23:17 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Tue, 16 Jan 2018 02:23:17 +0000
Subject: [New-bugs-announce] [issue32562] Support fspath protocol in AF_UNIX
 sockaddr resolution
Message-ID: <1516069397.77.0.467229070634.issue32562@psf.upfronthosting.co.za>


New submission from Nathaniel Smith <njs at pobox.com>:

In 3.6, trying to connect to a AF_UNIX socket using a pathlib.Path object doesn't work:

Python 3.6.4 (default, Dec 27 2017, 13:02:49) 
[GCC 7.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket, pathlib
>>> s = socket.socket(family=socket.AF_UNIX)
>>> s.connect(pathlib.Path("asdf"))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: a bytes-like object is required, not 'PosixPath'

It would be good to fix this to use the fspath protocol.

----------
messages: 310034
nosy: brett.cannon, njs
priority: normal
severity: normal
status: open
title: Support fspath protocol in AF_UNIX sockaddr resolution
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32562>
_______________________________________

From report at bugs.python.org  Tue Jan 16 00:14:41 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 16 Jan 2018 05:14:41 +0000
Subject: [New-bugs-announce] [issue32563]
 -Werror=declaration-after-statement expat build failure on Python 3.5
Message-ID: <1516079681.55.0.467229070634.issue32563@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

A fresh Python 3.5 checkout failed to build the embedded expat XML library for me, due to the configure check that adds "-Werror=declaration-after-statement" to the compiler flags.

I'm guessing this was introduced via the expat code changes brought in for https://github.com/python/cpython/commit/f2492bb6aae061aea47e21fc7e56b7ab9bfdf543

That configure check is gone in 3.6 and 3.7, but it's still there in 3.5.

Locally, I've worked around the problem by removing the configure check, but I'm not sure that's the right answer, as I believe we still promise that 3.5 will build under C89.

----------
messages: 310037
nosy: larry, ncoghlan, vstinner
priority: low
severity: normal
stage: needs patch
status: open
title: -Werror=declaration-after-statement expat build failure on Python 3.5
type: compile error

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32563>
_______________________________________

From report at bugs.python.org  Tue Jan 16 03:35:47 2018
From: report at bugs.python.org (Andrew Olefira)
Date: Tue, 16 Jan 2018 08:35:47 +0000
Subject: [New-bugs-announce] [issue32564] Syntax error on using variable
 async
Message-ID: <1516091747.29.0.467229070634.issue32564@psf.upfronthosting.co.za>


New submission from Andrew Olefira <andrew.olefira at gmail.com>:

In python 3.6 you can use name "async" for variable:
>>> class A:
...     async = True
... 
>>> 

but in python 3.7a4 you catch syntax error:
>>> class A:
...     async = True
  File "<stdin>", line 2
    async = True
          ^
SyntaxError: invalid syntax
>>>

----------
messages: 310045
nosy: Andrew Olefira
priority: normal
severity: normal
status: open
title: Syntax error on using variable async
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32564>
_______________________________________

From report at bugs.python.org  Tue Jan 16 04:28:50 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 16 Jan 2018 09:28:50 +0000
Subject: [New-bugs-announce] [issue32565] Document the version of adding
 opcodes
Message-ID: <1516094930.57.0.467229070634.issue32565@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

The version of adding a new opcode is not specified for some opcodes. The proposed PR adds missed 'versionadded' directives (as usually, only when added after 3.0).

----------
assignee: docs at python
components: Documentation
messages: 310061
nosy: docs at python, ncoghlan, pitrou, serhiy.storchaka, yselivanov
priority: normal
severity: normal
status: open
title: Document the version of adding opcodes
type: enhancement
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32565>
_______________________________________

From report at bugs.python.org  Tue Jan 16 04:30:28 2018
From: report at bugs.python.org (Kiran)
Date: Tue, 16 Jan 2018 09:30:28 +0000
Subject: [New-bugs-announce] [issue32566] Not able to open Python IDLE
Message-ID: <1516095028.12.0.467229070634.issue32566@psf.upfronthosting.co.za>


New submission from Kiran <kiranreddy.p.s at gmail.com>:

Hello,

I am new to Python and installed python3 recently and when I try to open IDLE, Iam getting the error attached.

Please let me know how to resolve it.

Thanks.

----------
components: Windows
files: Python.jpg
messages: 310062
nosy: Kiran, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Not able to open Python IDLE
type: crash
versions: Python 3.6
Added file: https://bugs.python.org/file47387/Python.jpg

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32566>
_______________________________________

From report at bugs.python.org  Tue Jan 16 05:44:16 2018
From: report at bugs.python.org (Tzu-ping Chung)
Date: Tue, 16 Jan 2018 10:44:16 +0000
Subject: [New-bugs-announce] =?utf-8?b?W2lzc3VlMzI1NjddIFZlbnbigJlzIGNv?=
 =?utf-8?q?nfig_file_=28pyvenv=2Ecfg=29_should_be_compatible_with_ConfigPa?=
 =?utf-8?q?rser?=
Message-ID: <1516099456.9.0.467229070634.issue32567@psf.upfronthosting.co.za>


New submission from Tzu-ping Chung <uranusjr at gmail.com>:

I?m not sure if it is intended, but it seems wrong to me that pyvenv.cfg is using a format that ConfigParser does not recognise. ConfigParser requires all values be placed under a section, but pyvenv.cfg does not do that.

Maybe related:

* ConfigParser?s format requirement: https://docs.python.org/3/library/configparser.html#supported-ini-file-structure
* How venv creates the configuration file: https://github.com/python/cpython/blob/master/Lib/venv/__init__.py#L141
* Abandoned discussion on whether ConfigParser should support section-less format #22253

----------
components: Library (Lib)
messages: 310071
nosy: uranusjr
priority: normal
severity: normal
status: open
title: Venv?s config file (pyvenv.cfg) should be compatible with ConfigParser
type: enhancement
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32567>
_______________________________________

From report at bugs.python.org  Tue Jan 16 05:48:25 2018
From: report at bugs.python.org (Tal Einat)
Date: Tue, 16 Jan 2018 10:48:25 +0000
Subject: [New-bugs-announce] [issue32568] Fix handling of sizehint=-1 in
 select.epoll()
Message-ID: <1516099705.58.0.467229070634.issue32568@psf.upfronthosting.co.za>


New submission from Tal Einat <taleinat at gmail.com>:

In 2fb9ae9dfc5a6830d902332ba93b13387e292ddb, select.epoll() was changed to reject sizehint=-1, despite that still being documented as the default value. Would it be possible to reverse this change, making -1 a special value signaling select.epoll() to use sizehint=FD_SETSIZE-1, as was before this change?

Additionally, in the same commit the docs were changed to say that the sizehint parameter is deprecated and has no effect, but later changes have restored use of sizehint in certain cases without updating the documentation. This inconsistency should be fixed.

For reference, this came up as part of #31938.

----------
messages: 310072
nosy: benjamin.peterson, serhiy.storchaka, taleinat
priority: normal
severity: normal
status: open
title: Fix handling of sizehint=-1 in select.epoll()

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32568>
_______________________________________

From report at bugs.python.org  Tue Jan 16 06:12:26 2018
From: report at bugs.python.org (David Carlier)
Date: Tue, 16 Jan 2018 11:12:26 +0000
Subject: [New-bugs-announce] [issue32569] Blake2 module,
 memory clearance update
Message-ID: <1516101146.75.0.467229070634.issue32569@psf.upfronthosting.co.za>


Change by David Carlier <dcarlier at afilias.info>:


----------
components: Library (Lib)
nosy: David Carlier
priority: normal
pull_requests: 5056
severity: normal
status: open
title: Blake2 module, memory clearance update
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32569>
_______________________________________

From report at bugs.python.org  Tue Jan 16 12:09:05 2018
From: report at bugs.python.org (=?utf-8?b?0JLQsNGB0LjQu9GMINCa0L7Qu9C+0LzRltGU0YbRjA==?=)
Date: Tue, 16 Jan 2018 17:09:05 +0000
Subject: [New-bugs-announce] [issue32570] Python crash 0xc00000fd Windows10
 x64 - "fail without words"
Message-ID: <1516122545.09.0.467229070634.issue32570@psf.upfronthosting.co.za>


New submission from ?????? ????????? <vasilij.kolomiets at gmail.com>:

The code https://ideone.com/ctx92s works for 1 000 000. 
But on my PC it works only for 1024.
Wen i am trting give him 1 000 000 - the Python crashes without any words:
https://i.stack.imgur.com/1do06.png
and in windows we can found this crash report: https://i.stack.imgur.com/nruoa.png
---
so it works for low values and crashes on higher values. Buy its no bug...
Than - What is it?

----------
components: Windows
messages: 310095
nosy: Vasyl Kolomiets, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Python crash  0xc00000fd Windows10 x64  -  "fail without words"
type: crash
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32570>
_______________________________________

From report at bugs.python.org  Tue Jan 16 13:18:05 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 16 Jan 2018 18:18:05 +0000
Subject: [New-bugs-announce] [issue32571] Speed up and clean up getting
 optional attributes in C code
Message-ID: <1516126685.82.0.467229070634.issue32571@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

In issue32544 there was introduced a new private C API function _PyObject_GetAttrWithoutError() which never raises an AttributeError, but returns NULL without error set if an attribute is absent. This allowed to speed up Python builtins hasattr() and getattr() with the default argument.

But C code also could gain a benefit from this. It is common to look up an attribute and silence an AttributeError. Actually it is more common than the opposite case.

The proposed patch adds yet one function, _PyObject_GetAttrIdWithoutError(), and uses these two functions if it is possible to avoid checking an AttributeError after PyObject_GetAttr() and _PyObject_GetAttrId(). This could speed up some code, and also makes it cleaner.

----------
components: Extension Modules, Interpreter Core
messages: 310101
nosy: inada.naoki, serhiy.storchaka, vstinner
priority: normal
severity: normal
status: open
title: Speed up and clean up getting optional attributes in C code
type: performance
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32571>
_______________________________________

From report at bugs.python.org  Tue Jan 16 13:46:18 2018
From: report at bugs.python.org (Hideyuki)
Date: Tue, 16 Jan 2018 18:46:18 +0000
Subject: [New-bugs-announce] [issue32572] Add the ftplib option,
 overrides the IP address.
Message-ID: <1516128378.06.0.467229070634.issue32572@psf.upfronthosting.co.za>


New submission from Hideyuki <studioes at go64.jp>:

Add the ftplib's option, overrides the IP address to be used with the PORT command.
Currently, the PORT command is sending its self IP address.
If the host is connected with NAT, it will not work.
If that command has a NAT external IP address, it is working.
So add an option to overrides the IP address sending with the PORT command.
This is useful when active FTP transfer needed on a 1:1 NAT connected host so like AWS VPC.

----------
components: Library (Lib)
messages: 310102
nosy: hideyuki
priority: normal
severity: normal
status: open
title: Add the ftplib option, overrides the IP address.
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32572>
_______________________________________

From report at bugs.python.org  Tue Jan 16 14:46:28 2018
From: report at bugs.python.org (Pedro)
Date: Tue, 16 Jan 2018 19:46:28 +0000
Subject: [New-bugs-announce] [issue32573] sys.argv documentation should
 include caveat for embedded environments
Message-ID: <1516131988.33.0.467229070634.issue32573@psf.upfronthosting.co.za>


New submission from Pedro <pgacv2+pythonbugs at gmail.com>:

Embedded Python interpreters, such as Boost.Python, do not have sys.argv available. (sys itself works fine.) This causes the interpreter to crash with the following exception when you try to access argv:

    AttributeError: 'module' object has no attribute 'argv'

I'm not sure how closely related this is to #15577 or PEP 432. A simple workaround is to manually assign a list with an empty string to argv, as suggested by https://github.com/google/oauth2client/issues/642. However, the documentation for the sys module makes no mention of this special case for argv, and the line at the top that says "It is always available" can easily be interpreted to mean that *all* of sys's attributes will always be available. I suggest adding the following to the documentation for sys.argv:

========

Since `argv` contains the list of **command line** arguments passed to the Python interpreter, `argv` is not available within embedded interpreters, and scripts that run in embedded environments will raise an `AttributeError` when they attempt to access `argv`. As a workaround, assign a list with an empty string manually:
```
import sys

if not hasattr(sys, 'argv'):
    sys.argv  = ['']
```

----------
assignee: docs at python
components: Documentation
messages: 310105
nosy: docs at python, pgacv2
priority: normal
severity: normal
status: open
title: sys.argv documentation should include caveat for embedded environments
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32573>
_______________________________________

From report at bugs.python.org  Tue Jan 16 14:53:39 2018
From: report at bugs.python.org (=?utf-8?q?Jos=C3=A9_Melero_Fern=C3=A1ndez?=)
Date: Tue, 16 Jan 2018 19:53:39 +0000
Subject: [New-bugs-announce] [issue32574] asyncio.Queue,
 put() leaks memory if the queue is full
Message-ID: <1516132419.05.0.467229070634.issue32574@psf.upfronthosting.co.za>


New submission from Jos? Melero Fern?ndez <jmelerofernandez at gmail.com>:

Repro: asyncio queue with limited size and the queue full, call asyncio.wait_for(some_queue.put(1), some_timeout). Every canceled put produces a new item in queue._putters that is never deleted (memory leak). 

Uploaded to the issue a file with an example.

The get method had a very similar bug which was fixed in 2016-11. The related issue:
https://bugs.python.org/issue31620

I already have the code for the PR prepared, so I want to publish the link of the MR in a few of minutes.

----------
components: asyncio
files: asyncio_put_memory_leak.py
messages: 310107
nosy: Mordis, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.Queue, put() leaks memory if the queue is full
type: resource usage
versions: Python 3.6, Python 3.7
Added file: https://bugs.python.org/file47388/asyncio_put_memory_leak.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32574>
_______________________________________

From report at bugs.python.org  Tue Jan 16 17:16:02 2018
From: report at bugs.python.org (Dan Snider)
Date: Tue, 16 Jan 2018 22:16:02 +0000
Subject: [New-bugs-announce] [issue32575] IDLE cannot locate certain
 SyntaxErrors raised by f-string expressions
Message-ID: <1516140962.04.0.467229070634.issue32575@psf.upfronthosting.co.za>


New submission from Dan Snider <mr.assume.away at gmail.com>:

For example the following f-string

f'{1):.1%}'

IDLE will scroll to the top of the file and highlight a random and irrelevant line (not sure what it's doing tbh).

running the expression with `exec` makes it look like implicit parenthesis are added to the ends of files..

>>> exec("f'{1):.1f}'")
Traceback (most recent call last):
  File "<pyshell#2860>", line 1, in <module>
    exec("f'{1):.1f}'")
  File "<fstring>", line 1
    (1))
       ^
SyntaxError: unexpected EOF while parsing

IDLE can correctly find a `(1))` in a file but appears to fail only in f-string expressions.

----------
assignee: terry.reedy
components: IDLE
messages: 310117
nosy: bup, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE cannot locate certain SyntaxErrors raised by f-string expressions
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32575>
_______________________________________

From report at bugs.python.org  Tue Jan 16 20:04:08 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 17 Jan 2018 01:04:08 +0000
Subject: [New-bugs-announce] [issue32576] concurrent.futures.thread
 potential deadlock due to Queue in weakref callback
Message-ID: <1516151048.85.0.467229070634.issue32576@psf.upfronthosting.co.za>


New submission from Gregory P. Smith <greg at krypto.org>:

As a follow up to https://bugs.python.org/issue14976 which just introduced queue.SimpleQueue:

concurrent.futures.thread currently uses a queue.Queue() from weakref callbacks which could in theory lead to a deadlock when periodic gc triggers a cleanup invalidating some weakrefed objects at an inopportune time while Python code has the queue's lock held.

I don't have a test case proving this (deadlocks are hard).

Switching it to use a SimpleQueue should avoid the problem?

...

This and the C extension module based SimpleQueue would be good to backport to https://pypi.python.org/pypi/futures as well.

----------
messages: 310124
nosy: gregory.p.smith, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: concurrent.futures.thread potential deadlock due to Queue in weakref callback
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32576>
_______________________________________

From report at bugs.python.org  Wed Jan 17 01:14:29 2018
From: report at bugs.python.org (Tzu-ping Chung)
Date: Wed, 17 Jan 2018 06:14:29 +0000
Subject: [New-bugs-announce] [issue32577] Pip creates entry point commands
 in the wrong place when invoked in a venv nested in a virtualenv
Message-ID: <1516169669.76.0.467229070634.issue32577@psf.upfronthosting.co.za>


New submission from Tzu-ping Chung <uranusjr at gmail.com>:

(I?m not sure whether this is a venv or virtualenv problem. Asking here first.)

To reproduce:

    $ python3.6 -m virtualenv outer
    $ ./outer/bin/python -m venv inner
    $ ls inner/bin
    activate  activate.csh  activate.fish  python  python3

In comparison:

    $ python3.6 -m venv another
    $ ls another/bin
    activate         easy_install     pip3             python3
    activate.csh     easy_install-3.6 pip3.6           python3.6
    activate.fish    pip              python

All commands that pip is supposed to populate are missing

Pip can install packages correctly, but the entry points are populated not inside the inner venv, but the outer virtualenv:

    $ ./inner/bin/python -m pip install django
    ....
    $ ls inner/bin
    activate  activate.csh  activate.fish  python  python3
    $ ls outer/bin
    ... django-admin django-admin.py

The entry points correctly point to the inner environment. They are just in the wrong directory.

----------
components: Library (Lib)
messages: 310140
nosy: uranusjr
priority: normal
severity: normal
status: open
title: Pip creates entry point commands in the wrong place when invoked in a venv nested in a virtualenv
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32577>
_______________________________________

From report at bugs.python.org  Wed Jan 17 05:32:06 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 17 Jan 2018 10:32:06 +0000
Subject: [New-bugs-announce] [issue32578] x86-64 Sierra 3.6: test_asyncio
 fails with timeout after 15 minutes
Message-ID: <1516185126.6.0.467229070634.issue32578@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

test_asyncio started to fail at build 163:

http://buildbot.python.org/all/#/builders/20/builds/163
(...)
test_legacy_create_ssl_connection (test.test_asyncio.test_events.KqueueEventLoopTests) ... ok
test_legacy_create_ssl_unix_connection (test.test_asyncio.test_events.KqueueEventLoopTests) ... ok
test_legacy_create_unix_server_ssl (test.test_asyncio.test_events.KqueueEventLoopTests) ... ok
test_legacy_create_unix_server_ssl_verified (test.test_asyncio.test_events.KqueueEventLoopTests) ... ok
test_legacy_create_unix_server_ssl_verify_failed (test.test_asyncio.test_events.KqueueEventLoopTests) ... ok
test_prompt_cancellation (test.test_asyncio.test_events.KqueueEventLoopTests) ... ok
test_read_pipe (test.test_asyncio.test_events.KqueueEventLoopTests) ... ok
Timeout (0:15:00)!
Thread 0x00007fffb5eee340 (most recent call first):
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/selectors.py", line 577 in select
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/asyncio/base_events.py", line 1396 in _run_once
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/asyncio/base_events.py", line 422 in run_forever
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/asyncio/base_events.py", line 455 in run_until_complete
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/test_asyncio/test_events.py", line 1536 in test_read_pty_output
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/support/__init__.py", line 555 in wrapper
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/support/__init__.py", line 600 in wrapper
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/test_asyncio/test_events.py", line 2232 in test_read_pty_output
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/support/__init__.py", line 600 in wrapper
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/unittest/case.py", line 605 in run
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/unittest/case.py", line 653 in __call__
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/unittest/suite.py", line 122 in run
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/unittest/suite.py", line 84 in __call__
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/unittest/suite.py", line 122 in run
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/unittest/suite.py", line 84 in __call__
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/unittest/suite.py", line 122 in run
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/unittest/suite.py", line 84 in __call__
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/unittest/suite.py", line 122 in run
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/unittest/suite.py", line 84 in __call__
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/unittest/suite.py", line 122 in run
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/unittest/suite.py", line 84 in __call__
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/unittest/runner.py", line 176 in run
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/support/__init__.py", line 1887 in _run_suite
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/support/__init__.py", line 1977 in run_unittest
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/libregrtest/runtest.py", line 172 in test_runner
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/libregrtest/runtest.py", line 173 in runtest_inner
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/libregrtest/runtest.py", line 137 in runtest
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/libregrtest/main.py", line 290 in rerun_failed_tests
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/libregrtest/main.py", line 539 in _main
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/libregrtest/main.py", line 509 in main
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/libregrtest/main.py", line 584 in main
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/test/__main__.py", line 2 in <module>
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/runpy.py", line 85 in _run_code
  File "/Users/buildbot/buildarea/3.6.billenstein-sierra/build/Lib/runpy.py", line 193 in _run_module_as_main
make: *** [buildbottest] Error 1
program finished with exit code 2
elapsedTime=2527.463349
test_read_pty_output (test.test_asyncio.test_events.KqueueEventLoopTests) ...

----------
messages: 310151
nosy: vstinner
priority: normal
severity: normal
status: open
title: x86-64 Sierra 3.6: test_asyncio fails with timeout after 15 minutes

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32578>
_______________________________________

From report at bugs.python.org  Wed Jan 17 06:34:05 2018
From: report at bugs.python.org (David CARLIER)
Date: Wed, 17 Jan 2018 11:34:05 +0000
Subject: [New-bugs-announce] [issue32579] UUID module fix,
 uuid1 python module function
Message-ID: <1516188845.07.0.467229070634.issue32579@psf.upfronthosting.co.za>


New submission from David CARLIER <devnexen at gmail.com>:

Spotted to UUID unit tests https://bugs.python.org/issue32493

----------
components: Library (Lib)
messages: 310154
nosy: David CARLIER2
priority: normal
pull_requests: 5068
severity: normal
status: open
title: UUID module fix, uuid1 python module function
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32579>
_______________________________________

From report at bugs.python.org  Wed Jan 17 08:11:08 2018
From: report at bugs.python.org (=?utf-8?b?SmVybmVqIFNpbW9uxI1pxI0=?=)
Date: Wed, 17 Jan 2018 13:11:08 +0000
Subject: [New-bugs-announce] [issue32580] Fallback to dev_urandom doesn't
 work when py_getrandom returns -1
Message-ID: <1516194668.11.0.467229070634.issue32580@psf.upfronthosting.co.za>


New submission from Jernej Simon?i? <jernej+s-python at eternallybored.org>:

I'm playing with Gentoo in LXC running on ARM-based QNAP NAS, and when trying to compile Python 3.5.4, the build failed with "Fatal Python error: failed to get random numbers to initialize Python" (full details at https://forums.gentoo.org/viewtopic-p-8172124.html ).

glibc in the environment is 2.25 (supports getrandom), while kernel is 3.10 (doesn't support getrandom).

Looking at random.c, pyurandom returns -1 instead of falling back to dev_urandom when py_getrandom returns -1, so the attached fix is simple.

----------
components: Build
files: random_fallback.patch
keywords: patch
messages: 310158
nosy: jernejs
priority: normal
severity: normal
status: open
title: Fallback to dev_urandom doesn't work when py_getrandom returns -1
versions: Python 3.5, Python 3.6
Added file: https://bugs.python.org/file47389/random_fallback.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32580>
_______________________________________

From report at bugs.python.org  Wed Jan 17 09:11:48 2018
From: report at bugs.python.org (jiangjinhu)
Date: Wed, 17 Jan 2018 14:11:48 +0000
Subject: [New-bugs-announce] [issue32581] A bug of the write funtion of
 ConfigParser.py
Message-ID: <1516198308.88.0.467229070634.issue32581@psf.upfronthosting.co.za>


New submission from jiangjinhu <jiangjinhu000 at 126.com>:

By the write funtion of ConfigParser.py,the partial content of the configue will change.

----------
components: Library (Lib)
messages: 310168
nosy: jiangjinhu666
priority: normal
severity: normal
status: open
title: A bug of the write funtion of ConfigParser.py
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32581>
_______________________________________

From report at bugs.python.org  Wed Jan 17 09:32:06 2018
From: report at bugs.python.org (=?utf-8?q?Uwe_Kleine-K=C3=B6nig?=)
Date: Wed, 17 Jan 2018 14:32:06 +0000
Subject: [New-bugs-announce] [issue32582] chr raises OverflowError
Message-ID: <1516199526.4.0.467229070634.issue32582@psf.upfronthosting.co.za>


New submission from Uwe Kleine-K?nig <uwe+python at kleine-koenig.org>:

Hello,

the description for chr (from https://docs.python.org/3/library/functions.html#chr) reads as:

        Return the string representing a character whose Unicode code
        point is the integer i. [...] The valid range for the argument
        is from 0 through 1,114,111 (0x10FFFF in base 16). ValueError
        will be raised if i is outside that range.

If however a value > 0x7fffffff (or < -0x80000000) is provided, the function raises an Overflow error:

        $ python3 -c 'print(chr(0x80000000))'
        Traceback (most recent call last):
          File "<string>", line 1, in <module>
        OverflowError: signed integer is greater than maximum

This is either a documentation problem or (more like) an implementation issue. I attached a patch that fixes the issue for me. (I'm not sure however if I should call PyErr_Clear() before raising ValueError.)

----------
components: Interpreter Core
files: chr-OverflowError.patch
keywords: patch
messages: 310178
nosy: ukl
priority: normal
severity: normal
status: open
title: chr raises OverflowError
versions: Python 3.6
Added file: https://bugs.python.org/file47390/chr-OverflowError.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32582>
_______________________________________

From report at bugs.python.org  Wed Jan 17 10:12:30 2018
From: report at bugs.python.org (Alexander Sibiryakov)
Date: Wed, 17 Jan 2018 15:12:30 +0000
Subject: [New-bugs-announce] [issue32583] Crash during decoding using
 UTF-16/32 and custom error handler
Message-ID: <1516201950.63.0.467229070634.issue32583@psf.upfronthosting.co.za>


Change by Alexander Sibiryakov <sixty-one at yandex.ru>:


----------
files: decode_crash.py
nosy: sibiryakov
priority: normal
severity: normal
status: open
title: Crash during decoding using UTF-16/32 and custom error handler
type: crash
versions: Python 3.5, Python 3.7
Added file: https://bugs.python.org/file47391/decode_crash.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32583>
_______________________________________

From report at bugs.python.org  Wed Jan 17 10:35:04 2018
From: report at bugs.python.org (Jeethu Rao)
Date: Wed, 17 Jan 2018 15:35:04 +0000
Subject: [New-bugs-announce] [issue32584] Uninitialized free_extra in
 code_dealloc
Message-ID: <1516203304.77.0.467229070634.issue32584@psf.upfronthosting.co.za>


New submission from Jeethu Rao <jeethu at jeethurao.com>:

In one of patches I'm building, (yet another attempt at caching LOAD_GLOBALS)[1], I'm using the private APIs from PEP 523 to store an array with every code object. I'm calling _PyEval_RequestCodeExtraIndex with PyMem_Free for the freefunc argument. While running  the cpython testsuite, I found that test_embed case crashes with a segfault. The gdb backtrace[2] seems to indicate that PyInterpreterState::co_extra_freefuncs is uninitialized, while it should be a pointer to the PyMem_Free function. 

One way to work around this is to set the array as a member on the PyCodeObject struct and use it directly. And I've verified that it works. Am I using the PEP 523 private api correctly? Also, on Linux, this consistently crashes while on OSX, it occasionally doesn't crash which makes me wonder if it's some kind of a race condition involving Sub-interpreters. The attached gist[2] has steps for repro.

[1]: https://github.com/python/cpython/compare/master...jeethu:py3.7_load_global_cache
[2]: https://gist.github.com/jeethu/6d92185ca97dd692e7fadcd105e0ef70

----------
components: Interpreter Core
messages: 310191
nosy: jeethu
priority: normal
severity: normal
status: open
title: Uninitialized free_extra in code_dealloc
type: crash
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32584>
_______________________________________

From report at bugs.python.org  Wed Jan 17 12:17:11 2018
From: report at bugs.python.org (Alan Moore)
Date: Wed, 17 Jan 2018 17:17:11 +0000
Subject: [New-bugs-announce] [issue32585] Add ttk::spinbox to tkinter.ttk
Message-ID: <1516209431.55.0.467229070634.issue32585@psf.upfronthosting.co.za>


New submission from Alan Moore <me at alandmoore.com>:

Ttk has a spinbox widget, which is a themed version of Tkinter spinbox, but this is missing from Python's ttk implementation.

----------
components: Tkinter
messages: 310198
nosy: Alan Moore
priority: normal
severity: normal
status: open
title: Add ttk::spinbox to tkinter.ttk
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32585>
_______________________________________

From report at bugs.python.org  Wed Jan 17 13:00:55 2018
From: report at bugs.python.org (Tim Morris)
Date: Wed, 17 Jan 2018 18:00:55 +0000
Subject: [New-bugs-announce] [issue32586] urllib2 HOWTO URLError example
 minor error
Message-ID: <1516212055.1.0.467229070634.issue32586@psf.upfronthosting.co.za>


New submission from Tim Morris <timothy at morrises.org.uk>:

In the HOWTO for urllib2 for Python 2, in the Handling Exceptions section, it discusses the URLError exception being raised by urlopen() (https://docs.python.org/2/howto/urllib2.html#urlerror). The code snippet example for this has (I think) a minor error:
the 3rd line reads:
"except URLError as e:"
which I think should be:
"except urllib2.URLError as e:"

The code as given only works if urllib2 had been imported via:
"from urllib2 import *"
The snippet doesn't list the import statements but all the other examples just use "import urllib2" (and obviously "from x import *" is bad practice anyway and wouldn't be encouraged or expected).

I am relatively new to Python, so it's possible it *is* correct and I just implemented it incorrectly. But if not, it would be helpful to correct it (even though it's a very minor error) so that other newbies like me don't come unstuck when using the tutorial.

----------
assignee: docs at python
components: Documentation
messages: 310201
nosy: MarmiteFox, docs at python
priority: normal
severity: normal
status: open
title: urllib2 HOWTO URLError example minor error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32586>
_______________________________________

From report at bugs.python.org  Wed Jan 17 13:09:12 2018
From: report at bugs.python.org (Seppo Yli-Olli)
Date: Wed, 17 Jan 2018 18:09:12 +0000
Subject: [New-bugs-announce] [issue32587] Make REG_MULTI_SZ support
 PendingFileRenameOperations
Message-ID: <1516212552.32.0.467229070634.issue32587@psf.upfronthosting.co.za>


New submission from Seppo Yli-Olli <seppo.yli-olli at iki.fi>:

MSDN documents that REG_MULTI_SZ is not supposed to have \0\0 anywhere else than in the end. The comment in  
https://github.com/python/cpython/blob/a5293b4ff2c1b5446947b4986f98ecf5d52432d4/PC/winreg.c#L504
clearly shows that Python has the assumption that this specification is actually correct. However, Microsoft is violating it eg in https://technet.microsoft.com/en-us/library/cc960241.aspx which prevents you from reading that registry key in Python at all. This is a list which is treated as pairs:
"""
foo

meep
bar
"""
so you can have empty items which in Windows semantics means "remove this file". This results in a string like "foo\0\0meep\0\bar\0\0". I'm proposing relaxing Python registry handling semantics because it's clearly Microsoft isn't following this either

----------
messages: 310202
nosy: nanonyme
priority: normal
severity: normal
status: open
title: Make REG_MULTI_SZ support PendingFileRenameOperations

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32587>
_______________________________________

From report at bugs.python.org  Wed Jan 17 17:09:56 2018
From: report at bugs.python.org (Steve Dower)
Date: Wed, 17 Jan 2018 22:09:56 +0000
Subject: [New-bugs-announce] [issue32588] Move _findvs into its own
 extension module
Message-ID: <1516226996.51.0.467229070634.issue32588@psf.upfronthosting.co.za>


New submission from Steve Dower <steve.dower at python.org>:

The _findvs module I added for distutils has added load-time dependencies on the ole32 and oleaut32 DLLs.

To reduce startup time, we should move _findvs into its own .pyd (unless I hear a better suggestion, I like "distutils._findvs.pyd").

----------
components: Distutils, Windows
messages: 310209
nosy: dstufft, eric.araujo, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Move _findvs into its own extension module
type: performance
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32588>
_______________________________________

From report at bugs.python.org  Wed Jan 17 23:54:22 2018
From: report at bugs.python.org (Matthias Gilch)
Date: Thu, 18 Jan 2018 04:54:22 +0000
Subject: [New-bugs-announce] [issue32589] Statistics as a result from timeit
Message-ID: <1516251262.25.0.467229070634.issue32589@psf.upfronthosting.co.za>


New submission from Matthias Gilch <matthias.gilch.mg+py at gmail.com>:

I propose to add a function parameter for timeit to get some statistics back from it. I think it's inconvenient to write those stubs every time when we have a method for this in the standard library that could be easily used with a few changes in it.

----------
components: Library (Lib)
messages: 310218
nosy: MGilch
priority: normal
severity: normal
status: open
title: Statistics as a result from timeit
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32589>
_______________________________________

From report at bugs.python.org  Thu Jan 18 00:32:11 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 18 Jan 2018 05:32:11 +0000
Subject: [New-bugs-announce] [issue32590] Proposal: add an "ensure(arg)"
 builtin for parameter validation
Message-ID: <1516253531.71.0.467229070634.issue32590@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

This proposal is an outcome of repeated requests on python-ideas that assert statements be made unconditional, so they can be legitimately used for parameter validation, rather than solely as a form of inline self-test.

Rather than changing the assert statement, an alternative option would be to provide a new builtin (suggested name: "ensure") that raises ValidationError (a new subclass of AssertionError) if the first argument is false.

As a function, the new builtin could accept parameters for:

- the message to be reported on failure
- the exception type to be raised on failure

And since it would only be a new builtin rather than a new keyword, existing uses of the name "ensure" would be unaffected (except to the extent that linters may start warning about shadowing a builtin).

(Since it's a suggestion for a new builtin, actually doing this would require a PEP, which I'm not planning to write, I just wanted to get the suggestion explicitly on the record rather than leaving it buried in mailing list archives)

----------
messages: 310219
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Proposal: add an "ensure(arg)" builtin for parameter validation
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32590>
_______________________________________

From report at bugs.python.org  Thu Jan 18 02:09:05 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Thu, 18 Jan 2018 07:09:05 +0000
Subject: [New-bugs-announce] [issue32591] Deprecate
 sys.set_coroutine_wrapper and replace it with more focused API(s)
Message-ID: <1516259345.01.0.467229070634.issue32591@psf.upfronthosting.co.za>


New submission from Nathaniel Smith <njs at pobox.com>:

sys.set_coroutine_wrapper is a problematic API. It was added to solve a specific problem: asyncio debug mode wanting to track where coroutine objects are created, so that when unawaited coroutines are GC'ed, the warning they print can include a traceback. But to do this, it adds a *very* generic hook that lets you hook into the coroutine creation code to replace all instances of a built-in type with an arbitrary new type, which is highly unusual. It's hard to use correctly (see bpo-30578, and bpo-24342 before it). It's hard to use without creating performance problems, since anything you do here tends to add overhead to every async function call, and in many cases also every async function frame suspend/resume cycle.

Fortunately, it's explicitly documented as provisional. (I think Yury intentionally excluded it from the stabilization of the rest of asyncio and async/await, because of the reasons above.) And the things we *actually* want to do here are very simple. The only known use cases are the one mentioned above (see asyncio.coroutines.CoroWrapper), and the one in bpo-30491. So after discussions with Yury, I'm proposing to migrate those both into the interpreter as directly usable, fast, built-in features that can be used individually or together, and deprecate sys.set_coroutine_wrapper.

See bpo-30491 for details on that use case; here I'll discuss my plan for replacing the "coroutine origin tracking" that asyncio debug mode does.

We add a new function sys.set_coroutine_origin_tracking(depth), and I guess sys.get_coroutine_origin_tracking() because why not. The depth is thread-local, and defaults to 0, which means that newly created coroutines don't capture any origin info.

When a coroutine is created, it will check the current origin_tracking depth, and capture that many frames of traceback information. Like the current asyncio debug code and unlike real tracebacks, we won't capture actual frame objects -- we'll just capture (filename, lineno, function) information, to avoid pinning objects in memory. This is a debug helper, so it should avoid changing semantics whenever possible.

Later, we can retrieve the captured information by accessing the new attribute coro.origin.

In addition, the code in CoroutineType.__del__ that currently emits a warning for unawaited coroutines, will be modified to check for whether 'self' has origin information, and print it if so, similar to the current asyncio debug wrapper.

Some particular points where I'd appreciate feedback:

Should we add an envvar to configure coroutine source tracking? What about an -X switch?

Should it be coro.origin or coro.cr_origin? On the one hand the cr_ prefixing is super annoying and I think we should probably get rid of it; on the other maybe we should keep it here so things stay consistent and then have a separate the debate about removing it in general.

Most important: what format should we use for storing the origin information? I can see three plausible approaches:

1. Call traceback.StackSummary.extract. This means re-entering the Python interpreter from inside the coroutine setup code, which makes me a little nervous. I guess there can't be any real re-entrancy issues here because if there were, set_coroutine_wrapper would already be hitting them. Can it cause problems during shutdown when the traceback module might have disappeared? (Not that anyone's likely to be instantiating coroutines at that point.) It also might be a bit slower than the other options below, but this isn't clear. OTOH, it has the benefit that coro.origin could be a full-fledged StackSummary with all its features, like traceback printing. Which honestly feels a little weird to me, because I know coroutine objects are built-in and StackSummary objects aren't, but it would certainly be convenient.

2. Capture (filename, lineno, function) directly in a packed struct, similar to how tracemalloc works. Then coro.origin can unpack this into a list of tuples or whatever. This is definitely very fast, and avoids re-entering Python. In practice we'd probably still end up needing to re-enter Python and using the traceback module when it came time to print a warning, though, because traceback printing is complicated and we don't want to reimplement it. Also, if the origin comes from a custom importer like zipimport, then we may not be able to look up the line information later, because that requires access to frame.f_globals["__loader__"].

3. Like (2), but insert a call to linecache.lazycache for each origin frame we capture. This would fix option (2)'s issue with printing source lines, but it means re-entering Python as well, so at this point maybe it'd just be simpler to go with option (1).

Given this analysis I guess I'm leaning towards just calling StackSummary.extract, but I don't feel like I fully understand the consequences of calling into a Python module like that so want to hear what others think.

----------
components: Interpreter Core, asyncio
messages: 310226
nosy: asvetlov, giampaolo.rodola, njs, yselivanov
priority: normal
severity: normal
status: open
title: Deprecate sys.set_coroutine_wrapper and replace it with more focused API(s)
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32591>
_______________________________________

From report at bugs.python.org  Thu Jan 18 04:37:18 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Jan 2018 09:37:18 +0000
Subject: [New-bugs-announce] [issue32592] Drop support of Windows Vista in
 Python 3.7
Message-ID: <1516268238.05.0.467229070634.issue32592@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

https://docs.python.org/dev/using/windows.html#supported-versions

"As specified in PEP 11, a Python release only supports a Windows platform while Microsoft considers the platform under extended support. This means that Python 3.7 supports Windows Vista and newer. If you require Windows XP support then please install Python 3.4."

But Windows Vista extended supported already ended last year, in April 2017.

Attached PR removes code to support Windows Vista.

----------
components: Windows
messages: 310227
nosy: paul.moore, steve.dower, tim.golden, vstinner, zach.ware
priority: normal
severity: normal
status: open
title: Drop support of Windows Vista in Python 3.7
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32592>
_______________________________________

From report at bugs.python.org  Thu Jan 18 05:08:47 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 18 Jan 2018 10:08:47 +0000
Subject: [New-bugs-announce] [issue32593] Drop support of FreeBSD 9 and
 older in Python 3.7
Message-ID: <1516270127.28.0.467229070634.issue32593@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

FreeBSD 9.3 support ended at December 31, 2016. It's time to drop code for compatibility with FreeBSD 9 and older.
https://www.freebsd.org/security/unsupported.html

Attached PR removes this code.

----------
components: Build
messages: 310229
nosy: vstinner
priority: normal
severity: normal
status: open
title: Drop support of FreeBSD 9 and older in Python 3.7
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32593>
_______________________________________

From report at bugs.python.org  Thu Jan 18 08:51:34 2018
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 18 Jan 2018 13:51:34 +0000
Subject: [New-bugs-announce] [issue32594] File object 'name' attribute
 inconsistent type and not obviously documented
Message-ID: <1516283494.43.0.467229070634.issue32594@psf.upfronthosting.co.za>


New submission from Skip Montanaro <skip.montanaro at gmail.com>:

I stumbled on what I think is an inconsistency in the "name" attribute of file objects. When a file is opened with an existing file descriptor, the "name" attribute is of type int (this from a 3.6.4 session, but it also exists in 2.7):

>>> import sys
>>> sys.stderr.name
'<stderr>'
>>> f = open(sys.stderr.fileno())
>>> f.name
2
>>> type(f.name)
<class 'int'>

I thought it odd that the standard I/O objects would be blessed with string filenames (despite not representing real filesystem paths), but that files opened by file descriptor would have that file descriptor as their name.

I looked in the documentation for open():

https://docs.python.org/3/library/functions.html#open

but saw no mention of the "name" attribute at all. In fact, the first argument to open() is called "file", so it's not obvious that the "name" attribute needs to be a copy of that parameter.

It seems to me that "name" attributes of open file objects should be of a consistent type, even if they might not represent an actual path in the filesystem. Even if this dual-type behavior is retained, it should be documented.

----------
assignee: docs at python
components: Documentation, IO, Interpreter Core
messages: 310237
nosy: docs at python, skip.montanaro
priority: normal
severity: normal
status: open
title: File object 'name' attribute inconsistent type and not obviously documented
type: behavior
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32594>
_______________________________________

From report at bugs.python.org  Thu Jan 18 14:53:57 2018
From: report at bugs.python.org (Jonathan)
Date: Thu, 18 Jan 2018 19:53:57 +0000
Subject: [New-bugs-announce] [issue32595] Deque with iterable object as one
 object
Message-ID: <1516305237.13.0.467229070634.issue32595@psf.upfronthosting.co.za>


New submission from Jonathan <qjonathandaniel at gmail.com>:

Creating a deque with an iterable object creates extra overhead if you want to insert it as one element.

e.g:
import timeit

test1 = '''
str = "x" * 100000
lst = [str]
'''

test2 = '''
str = "x" * 100000
'''

print(timeit.timeit(test1, number=100000))
print(timeit.timeit(test2, number=100000))

If I want to add a string to a deque i will have to put it in a list first, this causes 23% slower performance in my case.

There should be a deque where this overhead is not needed because in most cases this will be used in performance demanding cases.

----------
components: Library (Lib)
messages: 310256
nosy: jonathandaniel
priority: normal
severity: normal
status: open
title: Deque with iterable object as one object
type: performance
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32595>
_______________________________________

From report at bugs.python.org  Fri Jan 19 05:54:10 2018
From: report at bugs.python.org (INADA Naoki)
Date: Fri, 19 Jan 2018 10:54:10 +0000
Subject: [New-bugs-announce] [issue32596] Lazy import
 concurrent.futures.process and thread
Message-ID: <1516359250.47.0.467229070634.issue32596@psf.upfronthosting.co.za>


New submission from INADA Naoki <songofacandy at gmail.com>:

Since PEP 562 is implemented, we can use lazy imports easily.

Asyncio uses concurrent.futures.Future and concurrent.futures.ThreadPoolExecutor,
but not concurrent.futures.ProcessPoolExecutor by default.

Since importing concurrent.futures.process is slow, I want to import it lazily.
And it make sense to import concurrent.futures.thread too, because it's very
easy when we start to use __getattr__ once.

Here is quick benchmark:


$ ./python -m perf command ./python -c 'import asyncio'  # patched
.....................
command: Mean +- std dev: 60.5 ms +- 0.1 ms
$ git stash
$ ./python -m perf command ./python -c 'import asyncio'  # original
.....................
command: Mean +- std dev: 74.3 ms +- 0.2 ms

----------
components: Library (Lib)
messages: 310272
nosy: inada.naoki, levkivskyi, yselivanov
priority: normal
severity: normal
status: open
title: Lazy import concurrent.futures.process and thread
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32596>
_______________________________________

From report at bugs.python.org  Fri Jan 19 08:15:32 2018
From: report at bugs.python.org (bapt)
Date: Fri, 19 Jan 2018 13:15:32 +0000
Subject: [New-bugs-announce] [issue32597] Bad detection of clang
Message-ID: <1516367732.86.0.467229070634.issue32597@psf.upfronthosting.co.za>


New submission from bapt <bapt at FreeBSD.org>:

When building modules and trying to set the proper linker flags for the library runtime path, the detection of the compiler is wrong. the issue: 
https://bugs.python.org/issue20767 was showing the issue and imho badly fixed.

Clang behave like gcc regarding how it passes flags to the linker: -Wl,... so clang and gcc should be treated exactly the same way and no specific code should be added for FreeBSD

Here https://github.com/python/cpython/blob/master/Lib/distutils/unixccompiler.py#L237, it should accept both clang and gcc,

This block https://github.com/python/cpython/blob/master/Lib/distutils/unixccompiler.py#L230 should be removed

The issue is not only on FreeBSD but on any system which compiler is clang. side note, the detection of gcc looks at first glance wrong, as on many system gcc is installed as cc sometime.

----------
components: Distutils
messages: 310275
nosy: bapt, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: Bad detection of clang
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32597>
_______________________________________

From report at bugs.python.org  Fri Jan 19 08:48:26 2018
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 19 Jan 2018 13:48:26 +0000
Subject: [New-bugs-announce] [issue32598] Use autoconf to detect OpenSSL and
 libssl features
Message-ID: <1516369706.4.0.467229070634.issue32598@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

Starting with #31399 Python will require some OpenSSL 1.0.2 features. The features are not available in LibreSSL yet. There is no easy way to detect the feature from setup.py. The inc_dir variable in setup.py does not reflect CPPFLAG. I tried "self.compiler.preprocess()" but run into more issues. For example prints to stderr in error cases.

https://www.gnu.org/software/autoconf-archive/ax_check_openssl.html makes it easy to check for working OpenSSL. It uses either pkg-config or falls back to manual detection in common locations.

Based on the M4 macro it is easy to check for features like working X509_VERIFY_PARAM_set1_host() function.

----------
components: Extension Modules, Installation
messages: 310277
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: Use autoconf to detect OpenSSL and libssl features
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32598>
_______________________________________

From report at bugs.python.org  Fri Jan 19 12:39:36 2018
From: report at bugs.python.org (Frank Ch. Eigler)
Date: Fri, 19 Jan 2018 17:39:36 +0000
Subject: [New-bugs-announce] [issue32599] Add dtrace hook for
 PyCFunction_Call
Message-ID: <1516383576.04.0.467229070634.issue32599@psf.upfronthosting.co.za>


New submission from Frank Ch. Eigler <fche at elastic.org>:

Similar to https://bugs.python.org/issue31574, it would be useful the the interpreter allowed a tracing tool to hook the PyCFunction_Call() site, maybe via the C_TRACE() macro, kind of how it already does in  _PyEval_EvalFrameDefault().  This would help diagnose problems in the C upcalls.

----------
components: Interpreter Core
messages: 310278
nosy: fche
priority: normal
severity: normal
status: open
title: Add dtrace hook for PyCFunction_Call
type: performance

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32599>
_______________________________________

From report at bugs.python.org  Fri Jan 19 13:31:53 2018
From: report at bugs.python.org (Greg Matous)
Date: Fri, 19 Jan 2018 18:31:53 +0000
Subject: [New-bugs-announce] [issue32600] SpooledTemporaryFile should
 implement IOBase
Message-ID: <1516386713.77.0.467229070634.issue32600@psf.upfronthosting.co.za>


New submission from Greg Matous <gregory.matous at gmail.com>:

SpooledTemporaryFile returns alternately a buffer or a TemporaryFile().

In either case it should behave like a file-thing.
However it doesn't implement certain properties in IOBase like readable, seekable which seems like should be available.

for example, on Ubuntu Linux with Python 3.6.2, 

reader = csv.reader(TextIOWrapper(csvfile), *args, **kwargs)

gives error AttributeError: 'SpooledTemporaryFile' object has no attribute 'readable'
when csvfile is a werkzeug.datastructures.FileStorage object

see also:
https://stackoverflow.com/questions/47160211/why-doesnt-tempfile-spooledtemporaryfile-implement-readable-writable-seekable

----------
components: Library (Lib)
messages: 310281
nosy: dutchmo
priority: normal
severity: normal
status: open
title: SpooledTemporaryFile should implement IOBase
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32600>
_______________________________________

From report at bugs.python.org  Fri Jan 19 14:31:36 2018
From: report at bugs.python.org (Anders Kaseorg)
Date: Fri, 19 Jan 2018 19:31:36 +0000
Subject: [New-bugs-announce] [issue32601] PosixPathTest.test_expanduser
 fails in NixOS build sandbox
Message-ID: <1516390296.8.0.467229070634.issue32601@psf.upfronthosting.co.za>


New submission from Anders Kaseorg <andersk at mit.edu>:

PosixPathTest.test_expanduser fails in the NixOS build sandbox, where every user has home directory /, so it falls off the end of the for pwdent in pwd.getpwall() loop.

nixbld:x:30001:30000:Nix build user:/:/noshell
nobody:x:65534:65534:Nobody:/:/noshell

======================================================================
FAIL: test_expanduser (__main__.PosixPathTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/nix/store/mdak9gcy16dc536ws08rshyakd1l7srj-test_pathlib.py", line 2162, in test_expanduser
    self.assertEqual(p3.expanduser(), P(otherhome) / 'Documents')
AssertionError: PosixPath('/Documents') != PosixPath('Documents')

----------
components: Tests
messages: 310282
nosy: andersk
priority: normal
pull_requests: 5091
severity: normal
status: open
title: PosixPathTest.test_expanduser fails in NixOS build sandbox
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32601>
_______________________________________

From report at bugs.python.org  Fri Jan 19 14:46:32 2018
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 19 Jan 2018 19:46:32 +0000
Subject: [New-bugs-announce] [issue32602] Test ECDSA and dual mode context
Message-ID: <1516391192.37.0.467229070634.issue32602@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

OpenSSL supports ECDSA certs and dual EC/RSA mode context, e.g. a context a RSA and an ECDSA key/cert pair loaded at the same time. Python shoulkd verify that ECDSA certs are working properly.

----------
assignee: christian.heimes
components: SSL, Tests
messages: 310284
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: Test ECDSA and dual mode context
type: enhancement

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32602>
_______________________________________

From report at bugs.python.org  Fri Jan 19 18:20:51 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Fri, 19 Jan 2018 23:20:51 +0000
Subject: [New-bugs-announce] [issue32603] Deprecation warning on strings
 used in re module
Message-ID: <1516404051.77.0.467229070634.issue32603@psf.upfronthosting.co.za>


New submission from Cheryl Sabella <chekat2 at gmail.com>:

I apologize if this is a duplicate question, but I couldn't find another issue about this.  It's hard to search on 're'.

In 3.7, I get a deprecation warning when using a regular string with re escape characters:
>>> s = '123abcd'
>>> re.findall('\d', s)
<stdin>:1: DeprecationWarning: invalid escape sequence \d
['1', '2', '3']

Of course, this works:
>>> s = '123abcd'
>>> re.findall(r'\d', s)
['1', '2', '3']


I know that the documentation strongly suggests using raw strings with re, but I didn't see anywhere mentioning that it would be a requirement.  I would think this would break a lot of 're' code.

----------
assignee: docs at python
components: Documentation
messages: 310300
nosy: csabella, docs at python
priority: normal
severity: normal
status: open
title: Deprecation warning on strings used in re module
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32603>
_______________________________________

From report at bugs.python.org  Fri Jan 19 20:58:02 2018
From: report at bugs.python.org (Eric Snow)
Date: Sat, 20 Jan 2018 01:58:02 +0000
Subject: [New-bugs-announce] [issue32604] Expose the subinterpreters C-API
 in Python for testing use.
Message-ID: <1516413482.13.0.467229070634.issue32604@psf.upfronthosting.co.za>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

In the interest of getting something landed for 3.7, so we can start using it in tests, I'm putting up a patch for a low-level interpreters module.  In some ways this is a precursor for issue #30439, which will add a proper public stdlib module in 3.8.

The module I'm adding draws from the ideas in PEP 554 (particularly for channels).  Consequently, this will also give us an opportunity to try out some of the semantics from the PEP to give us better ideas for 3.8.

I expect to have some follow-on patches to facilitate simpler use in tests.  This patch is big enough already. :)

----------
assignee: eric.snow
components: Interpreter Core
messages: 310314
nosy: eric.snow, ncoghlan, yselivanov
priority: normal
severity: normal
stage: needs patch
status: open
title: Expose the subinterpreters C-API in Python for testing use.
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32604>
_______________________________________

From report at bugs.python.org  Sat Jan 20 00:30:50 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Sat, 20 Jan 2018 05:30:50 +0000
Subject: [New-bugs-announce] [issue32605] Should we really hide unawaited
 coroutine warnings when an exception is pending?
Message-ID: <1516426250.01.0.467229070634.issue32605@psf.upfronthosting.co.za>


New submission from Nathaniel Smith <njs at pobox.com>:

There's a curious bit of code in genobject.c:_PyGen_Finalize:

        if (!error_value) {
            PyErr_WarnFormat(PyExc_RuntimeWarning, 1,
                             "coroutine '%.50S' was never awaited",
                             gen->gi_qualname);
        }

Obviously this is the code that issues "coroutine ... was never awaited" warnings. That's not so curious. What's curious is the 'if' statement: what it does is suppress this warning if -- at the moment the coroutine object was GCed -- there is an active exception propagating.

This was added by bpo-27968, apparently as a way to hide some warnings in test_coroutine.py. This justification seems dubious to me, though, and there doesn't seem to have been much/any scrutiny of this at the time. We can certainly write those tests more carefully, so that they don't issue warnings -- e.g. by using 'with closing(corofn()) as coro: ...'. And this has a much broader effect than on just those tests. For example, say we accidentally write:

   def foo():
       len(corofn())  # should be len(await corofn())

we'll get an error that was caused by the coroutine not being awaited -- and we *won't* get the usual warning message explaining this, because the coroutine object is GCed while the exception propagates. Or, if an unawaited coroutine happens to get stuck in a reference cycle, then it's a matter of luck whether the message gets printed, depending on when exactly the cycle collector happens to trigger.

I guess in most cases where someone forgets an await and it causes errors, the coroutine happens to get stashed into a local variable, so it can't be GCed until after the exception is no longer active. And if another exception becomes active in the mean time, probably it will capture the first one as __context__, so that also keeps the coroutine alive past the time when the warning would be suppressed. So maybe this isn't a huge issue in practice? But this all feels very finicky and accidental, so I wanted to raise the issue for discussion.

----------
components: asyncio
messages: 310325
nosy: asvetlov, benjamin.peterson, giampaolo.rodola, njs, yselivanov
priority: normal
severity: normal
status: open
title: Should we really hide unawaited coroutine warnings when an exception is pending?
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32605>
_______________________________________

From report at bugs.python.org  Sun Jan 21 00:40:52 2018
From: report at bugs.python.org (Dalton Campbell)
Date: Sun, 21 Jan 2018 05:40:52 +0000
Subject: [New-bugs-announce] [issue32606] Email Header Injection Protection
 Bypass
Message-ID: <1516513252.62.0.467229070634.issue32606@psf.upfronthosting.co.za>


New submission from Dalton Campbell <drcampbell13 at gmail.com>:

The protection's implemented in https://github.com/python/cpython/blob/master/Lib/email/header.py to prevent Email Header injection can be bypassed by specifying an injected additional header in the following format:
example at python.org\ncc :injected at python.org

The white space bypasses the current regex protection (_embedded_header = re.compile(r'\n[^ \t]+:')) and is still accepted by the smtp server. 

Attached is a proof of concept script

----------
components: Library (Lib)
files: PythonEmailHeaderInjectionPOC.py
messages: 310367
nosy: r.david.murray, thedoctorsoup
priority: normal
severity: normal
status: open
title: Email Header Injection Protection Bypass
type: security
Added file: https://bugs.python.org/file47396/PythonEmailHeaderInjectionPOC.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32606>
_______________________________________

From report at bugs.python.org  Sun Jan 21 05:08:13 2018
From: report at bugs.python.org (Shrivatsa Hosabettu)
Date: Sun, 21 Jan 2018 10:08:13 +0000
Subject: [New-bugs-announce] [issue32607] After Python Installation Error
Message-ID: <1516529293.34.0.467229070634.issue32607@psf.upfronthosting.co.za>


New submission from Shrivatsa Hosabettu <shrivatsa555 at gmail.com>:

Please let me know the below error is ok to have or how to resolve it?

3.6.4 (v3.6.4:d48eceb, Dec 19 2017, 06:04:45) [MSC v.1900 32 bit (Intel)]
Traceback (most recent call last):
  Python Shell, prompt 0, line 21
  File "<string>", line 1, in <module>
  File "C:\Users\adm\AppData\Local\Programs\Python\Python36-32\Lib\site-packages\django\__init__.py", line 19, in setup
    configure_logging(settings.LOGGING_CONFIG, settings.LOGGING)
  File "C:\Users\adm\AppData\Local\Programs\Python\Python36-32\Lib\site-packages\django\conf\__init__.py", line 56, in __getattr__
    self._setup(name)
  File "C:\Users\adm\AppData\Local\Programs\Python\Python36-32\Lib\site-packages\django\conf\__init__.py", line 43, in _setup
    self._wrapped = Settings(settings_module)
  File "C:\Users\adm\AppData\Local\Programs\Python\Python36-32\Lib\site-packages\django\conf\__init__.py", line 106, in __init__
    mod = importlib.import_module(self.SETTINGS_MODULE)
  File "C:\Users\adm\AppData\Local\Programs\Python\Python36-32\Lib\importlib\__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "C:\Users\adm\AppData\Local\Programs\Python\Python36-32\Lib\importlib\_bootstrap.py", line 994, in _gcd_import
    return _find_and_load(name, _gcd_import)
  File "C:\Users\adm\AppData\Local\Programs\Python\Python36-32\Lib\importlib\_bootstrap.py", line 971, in _find_and_load
    return _find_and_load_unlocked(name, import_)
  File "C:\Users\adm\AppData\Local\Programs\Python\Python36-32\Lib\importlib\_bootstrap.py", line 941, in _find_and_load_unlocked
    _call_with_frames_removed(import_, parent)
  File "C:\Users\adm\AppData\Local\Programs\Python\Python36-32\Lib\importlib\_bootstrap.py", line 219, in _call_with_frames_removed
    return f(*args, **kwds)
  File "C:\Users\adm\AppData\Local\Programs\Python\Python36-32\Lib\importlib\_bootstrap.py", line 994, in _gcd_import
    return _find_and_load(name, _gcd_import)
  File "C:\Users\adm\AppData\Local\Programs\Python\Python36-32\Lib\importlib\_bootstrap.py", line 971, in _find_and_load
    return _find_and_load_unlocked(name, import_)
  File "C:\Users\adm\AppData\Local\Programs\Python\Python36-32\Lib\importlib\_bootstrap.py", line 953, in _find_and_load_unlocked
    raise ModuleNotFoundError(_ERR_MSG.format(name), name=name)
builtins.ModuleNotFoundError: No module named 'simplesocial'

----------
messages: 310368
nosy: shri_vatsa
priority: normal
severity: normal
status: open
title: After Python Installation Error
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32607>
_______________________________________

From report at bugs.python.org  Sun Jan 21 07:55:27 2018
From: report at bugs.python.org (Michael Durso)
Date: Sun, 21 Jan 2018 12:55:27 +0000
Subject: [New-bugs-announce] [issue32608] Incompatibilities with the
 socketserver and multiprocessing packages
Message-ID: <1516539327.3.0.467229070634.issue32608@psf.upfronthosting.co.za>


New submission from Michael Durso <rbprogrammer at gmail.com>:

This is more of an issue with socketserver rather than multiprocessing.  I could not find socketserver experts to add to the nosy list, but I've included the multiprocessing experts for completeness.

Under specific conditions, multiprocessing queues cease to work when modules like socketserver is used, more specifically when fork() is used.  This makes sense that things can break when fork() is used since a simple forked process has things like file descriptors and threads invalidated.  The socketserver.ForkingMixIn class, which has very reasonable use-cases, causes multiprocessing queues and threads to break.  A script that replicates and simulates the issue is attached.

The attached script sets up a multiprocessing queue used for logging across all sub-processes, then uses a socketserver.ForkingTCPServer to handle new client connection.  What's happening is the fork() is invalidating the thread in the QueueHandler in each new sub-process (for each new client conncetion).  It turns the QueueHandler into a dead object.

In this scenario, the only indication the problem exists is the fact that log messages are not actually logged.  But I think it's plausible that more than just log data could be lost.

When a non-modified version of CPython, the script should run and produce a log file.  However, logs from the client connection handler (MyClientHandler) will be lost and never sent to the logging handler that performs the actual file writing.  To exercise the proposed fix to CPython, build the changes to socketserver.py and then change the script's "USE_FIX" flag to "True" and run the script.

----------
components: Library (Lib)
files: multiprocessing_socketserver.py
messages: 310371
nosy: davin, pitrou, rbprogrammer
priority: normal
severity: normal
status: open
title: Incompatibilities with the socketserver and multiprocessing packages
type: behavior
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8
Added file: https://bugs.python.org/file47398/multiprocessing_socketserver.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32608>
_______________________________________

From report at bugs.python.org  Sun Jan 21 09:00:24 2018
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 21 Jan 2018 14:00:24 +0000
Subject: [New-bugs-announce] [issue32609] Add setter and getter for min/max
 protocol ersion
Message-ID: <1516543224.12.0.467229070634.issue32609@psf.upfronthosting.co.za>


New submission from Christian Heimes <lists at cheimes.de>:

OpenSSL 1.1 has introduced a new API to set the minimum and maximum supported protocol version. The API is easier to use than the old OP_NO_TLSv1 option flags, too

https://www.openssl.org/docs/man1.1.0/ssl/SSL_CTX_set_min_proto_version.html

Debian used the new setters to disable TLS 1.0 and 1.1 in testing, #31453. The old TLS versions have been enabled again for now. Python must expose the new API in case Debian decides to disable them again.

I also like to deprecate the old OP_NO_TLSv1 et al. flags in favor of the new API. The option flags are awkward to use and easy to get wrong. For example applications must not leave holes in the OP_NO range (e.g. allow TLS 1.0 and 1.2 but disable 1.1).

----------
assignee: christian.heimes
components: SSL
messages: 310374
nosy: christian.heimes
priority: normal
severity: normal
stage: needs patch
status: open
title: Add setter and getter for min/max protocol ersion
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32609>
_______________________________________

From report at bugs.python.org  Sun Jan 21 11:45:25 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 21 Jan 2018 16:45:25 +0000
Subject: [New-bugs-announce] [issue32610] asyncio.all_tasks() should return
 only non-finished tasks.
Message-ID: <1516553125.63.0.467229070634.issue32610@psf.upfronthosting.co.za>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

Current behavior has a subtle pitfall.
The function returns a list of *existing* tasks (not removed by decref or explicit call).
If user's code has a strong reference to some task the task will be in return list for unpredictable amount of time, even if the task was done.

Returning only *alive* tasks can make a function result more predictable (`not task.done()`).

Opinions?

----------
components: asyncio
messages: 310378
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.all_tasks() should return only non-finished tasks.
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32610>
_______________________________________

From report at bugs.python.org  Sun Jan 21 15:11:32 2018
From: report at bugs.python.org (Minion Jim)
Date: Sun, 21 Jan 2018 20:11:32 +0000
Subject: [New-bugs-announce] [issue32611] Tkinter taskbar icon (Windows)
Message-ID: <1516565492.0.0.467229070634.issue32611@psf.upfronthosting.co.za>


New submission from Minion Jim <epaine13 at ranelagh.bracknell-forest.sch.uk>:

When using Python version 3.6.4, Tkinter shows a blank icon on the taskbar. This means any Tkinter window including IDLE and a blank one. Unfortunately, I don't have a screenshot to show this as I reinstalled version 3.6.3 which works perfectly.

----------
components: Windows
messages: 310382
nosy: Minion Jim, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Tkinter taskbar icon (Windows)
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32611>
_______________________________________

From report at bugs.python.org  Sun Jan 21 16:04:41 2018
From: report at bugs.python.org (benrg)
Date: Sun, 21 Jan 2018 21:04:41 +0000
Subject: [New-bugs-announce] [issue32612] pathlib.(Pure)WindowsPaths can
 compare equal but refer to different files
Message-ID: <1516568681.86.0.467229070634.issue32612@psf.upfronthosting.co.za>


New submission from benrg <benrudiak at gmail.com>:

(Pure)WindowsPath uses str.lower to fold paths for comparison and hashing. This doesn't match the case folding of actual Windows file systems. There exist WindowsPath objects that compare and hash equal, but refer to different files. For example, the strings

  '\xdf' (sharp S) and '\u1e9e' (capital sharp S)
  '\u01c7' (LJ) and '\u01c8' (Lj)
  '\u0130' (I with dot) and 'i\u0307' (i followed by combining dot)
  'K' and '\u212a' (Kelvin sign)

are equal under str.lower folding but are distinct file names on NTFS volumes on my Windows 7 machine. There are hundreds of other such pairs.

I think this is very bad. The reverse (paths that compare unequal but refer to the same file) is probably unavoidable and is expected by programmers. But paths that compare equal should never be unequal to the OS.

How to fix this:

Unfortunately, there is no correct way to case fold Windows paths. The FAT, NTFS, and exFAT drivers on my machine all have different behavior. (The examples above work on all three, except for 'K' and '\u212a', which are equivalent on FAT volumes.) NTFS stores its case-folding map on each volume in the hidden $UpCase file, so even different NTFS volumes on the same machine can have different behavior. The contents of $UpCase have changed over time as Windows is updated to support new Unicode versions. NTFS and NFS (and possibly WebDAV) also support full case sensitivity when used with Interix/SUA and Cygwin, though this requires disabling system-wide case insensitivity via the registry.

I think that pathlib should either give up on case folding entirely, or should fold very conservatively, treating WCHARs as equivalent only if they're equivalent on all standard file systems on all supported Windows versions.

If pathlib folds case at all, there should be a solution for people who need to interoperate with Cygwin or SUA tools on a case-sensitive machine, but I suppose they can just use PosixPath.

----------
components: Library (Lib), Windows
messages: 310384
nosy: benrg, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: pathlib.(Pure)WindowsPaths can compare equal but refer to different files
type: security
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32612>
_______________________________________

From report at bugs.python.org  Sun Jan 21 17:07:09 2018
From: report at bugs.python.org (Julien Palard)
Date: Sun, 21 Jan 2018 22:07:09 +0000
Subject: [New-bugs-announce] [issue32613] Use PEP 397 py launcher in windows
 faq
Message-ID: <1516572429.98.0.467229070634.issue32613@psf.upfronthosting.co.za>


New submission from Julien Palard <julien+python at palard.fr>:

The windows FAQ (https://docs.python.org/3.6/faq/windows.html) uses `python` to launch python, I think it should use the `py` python launcher from pep 397.

----------
assignee: mdk
components: Documentation
keywords: easy
messages: 310385
nosy: mdk
priority: low
severity: normal
stage: needs patch
status: open
title: Use PEP 397 py launcher in windows faq
type: enhancement
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32613>
_______________________________________

From report at bugs.python.org  Sun Jan 21 17:47:38 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sun, 21 Jan 2018 22:47:38 +0000
Subject: [New-bugs-announce] [issue32614] Fix documentation examples of
 using re with escape sequences
Message-ID: <1516574858.82.0.467229070634.issue32614@psf.upfronthosting.co.za>


New submission from Cheryl Sabella <chekat2 at gmail.com>:

If a documentation example would produce a DeprecationWarning for an invalid escape sequence, change the example to use a raw string.

----------
assignee: docs at python
components: Documentation
messages: 310386
nosy: csabella, docs at python
priority: normal
severity: normal
status: open
title: Fix documentation examples of using re with escape sequences
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32614>
_______________________________________

From report at bugs.python.org  Sun Jan 21 18:46:26 2018
From: report at bugs.python.org (ppperry)
Date: Sun, 21 Jan 2018 23:46:26 +0000
Subject: [New-bugs-announce] [issue32615] Inconsistent behavior if globals
 is a dict subclass
Message-ID: <1516578386.14.0.467229070634.issue32615@psf.upfronthosting.co.za>


New submission from ppperry <mapreader at olum.org>:

Take the following code:

    import builtins
    class K(dict):
	def __getitem__(self, k):
		if k not in builtins.__dict__:
			print("get %s" % k)
		return dict.__getitem__(self, k)
	def __setitem__(self, k, v):
		print("set %s" % k)
		dict.__setitem__(self, k, v)
    exec("""
        foo = "bar"
        foo
        try:
            qyz
        except NameError:
	    pass
        class K:
	    baz = foo
	    def f(ggg=foo): pass
        def g(ggg=foo):
	    global f
	    f = 87
            f
        g()
    """,K())

This should consitently either call or not call the overridden methods on the dictionary, producing either no output or:

    set foo
    get foo
    get qyz
    get foo
    get foo
    set K
    get foo
    set g
    get g
    set f
    get f
    
Instead, only sometime the override gets called, producing

    set foo
    get foo
    get qyz
    set K
    get foo
    set g
    get g
    get f

meaning that 
    (a) modifications of global variables via global statements
    (b) code at class-level

ignore overridden methods, whereas everything else follows them

----------
components: Interpreter Core
messages: 310388
nosy: ppperry
priority: normal
severity: normal
status: open
title: Inconsistent behavior if globals is a dict subclass
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32615>
_______________________________________

From report at bugs.python.org  Sun Jan 21 23:34:14 2018
From: report at bugs.python.org (Zhiming Wang)
Date: Mon, 22 Jan 2018 04:34:14 +0000
Subject: [New-bugs-announce] [issue32616] Significant performance problems
 with Python 2.7 built with clang 3.x or 4.x
Message-ID: <1516595654.84.0.467229070634.issue32616@psf.upfronthosting.co.za>


New submission from Zhiming Wang <zmwangx at gmail.com>:

Python 2.7 could be significantly slower (5x in some cases) when compiled with clang 3.x or 4.x, compared to clang 5.x. This is quite a problem on macOS, since the latest clang from Apple (which comes with Xcode 9.2) is based on LLVM 4.x. This issue was first noticed by Bart Skowron and reported to the Homebrew project.[1]

I ran some preliminary benchmarks (here[2] are the exact setup scripts) with just a simple loop:

    import time

    def f(n):
        while n > 0:
            n -= 1

    start = time.time()
    f(50000000)
    stop = time.time()
    print('%.6f' % (stop - start))

and here are my results:

- macOS 10.13.2 on a MacBook Pro:

    2.082144	/usr/bin/python2.7
    7.964049	/usr/local/bin/python2.7
    8.750652	dist/python27-apple-clang-900/bin/python2.7
    8.476405	dist/python27-clang-3.9/bin/python2.7
    8.625660	dist/python27-clang-4.0/bin/python2.7
    1.760096	dist/python27-clang-5.0/bin/python2.7
    3.254814	/usr/local/bin/python3.6
    2.864716	dist/python-master-apple-clang-900/bin/python3
    3.071757	dist/python-master-clang-3.9/bin/python3
    2.925192	dist/python-master-clang-4.0/bin/python3
    2.908782	dist/python-master-clang-5.0/bin/python3

- Ubuntu 17.10 in VirtualBox:

    1.475095	/usr/bin/python2.7
    8.576817	dist/python27-clang-3.9/bin/python2.7
    8.165588	dist/python27-clang-4.0/bin/python2.7
    1.779193	dist/python27-clang-5.0/bin/python2.7
    1.728321	dist/python27-gcc-5/bin/python2.7
    1.570040	dist/python27-gcc-6/bin/python2.7
    1.604617	dist/python27-gcc-7/bin/python2.7
    2.323037	/usr/bin/python3.6
    2.964338	dist/python-master-clang-3.9/bin/python3
    3.054277	dist/python-master-clang-4.0/bin/python3
    2.734908	dist/python-master-clang-5.0/bin/python3
    2.490278	dist/python-master-gcc-5/bin/python3
    2.494691	dist/python-master-gcc-6/bin/python3
    2.642277	dist/python-master-gcc-7/bin/python3

I haven't got time to run more rigorous benchmark suites (e.g., the performance[3] package). I did try the floating point benchmark from performance, and again saw a 2x difference in performance.

[1] https://github.com/Homebrew/homebrew-core/issues/22743
[2] https://gist.github.com/zmwangx/f8151ba8907ba8159a07fdd1528fc2b5
[3] https://pypi.python.org/pypi/performance

----------
messages: 310395
nosy: zmwangx
priority: normal
severity: normal
status: open
title: Significant performance problems with Python 2.7 built with clang 3.x or 4.x
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32616>
_______________________________________

From report at bugs.python.org  Mon Jan 22 01:22:13 2018
From: report at bugs.python.org (Avnish Midha)
Date: Mon, 22 Jan 2018 06:22:13 +0000
Subject: [New-bugs-announce] [issue32617] dict.update does not
 concat/replace if same key
Message-ID: <1516602133.05.0.467229070634.issue32617@psf.upfronthosting.co.za>


New submission from Avnish Midha <avnishbm10 at gmail.com>:

The dict does not seem to work as one would expect a dictionary or a hashtable to work. 

dict.update(otherdict) just replaces the entries as per otherdict, removing items which were extra in dict too and just keeping items as per new data in otherdict only. Shouldn't this be actually about updating the dict with new/updated entries and not touching those entries which pre-existed?

Sample program below:
import pandas as pd

x = {'name': ['A', 'B', 'C'], 'col2': [3, 4,6]}
y = {'name': ['B', 'C', 'D', 'E'], 'col2': [1,2, 9, 10]}


print ("X = \n" + str(x))

print ("Y = \n" + str(y))

x.update(y)

print ("updated dict = \n"  + str(x) + "\n")

#####

Output:

X = 
{'name': ['A', 'B', 'C'], 'col2': [3, 4, 6]}
Y = 
{'name': ['B', 'C', 'D', 'E'], 'col2': [1, 2, 9, 10]}
updated dict = 
{'name': ['B', 'C', 'D', 'E'], 'col2': [1, 2, 9, 10]}


Expected value:
updated dict = 
{'name': ['A','B', 'C', 'D', 'E'], 'col2': [3, 1, 2, 9, 10]}


Somehow to do this basic hashtable or dictionary update kind of operation is too complex in python and update() should have actually functioned as expected above IMO.

----------
components: Interpreter Core
files: dict_try.py
messages: 310397
nosy: Avnish Midha
priority: normal
severity: normal
status: open
title: dict.update does not concat/replace if same key
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file47400/dict_try.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32617>
_______________________________________

From report at bugs.python.org  Mon Jan 22 01:28:29 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Mon, 22 Jan 2018 06:28:29 +0000
Subject: [New-bugs-announce] [issue32618] fix
 test_codeccallbacks.test_mutatingdecodehandler
Message-ID: <1516602509.19.0.467229070634.issue32618@psf.upfronthosting.co.za>


New submission from Xiang Zhang <angwerzx at 126.com>:

test_codeccallbacks.test_mutatingdecodehandler is introduced in e78178e2c05ec2bb628b70a8b5422bb4dae63343. Obviously it should test against both test.replacing and test.mutating but it tests test.replacing twice.

----------
components: Tests
keywords: easy
messages: 310398
nosy: xiang.zhang
priority: normal
severity: normal
status: open
title: fix test_codeccallbacks.test_mutatingdecodehandler
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32618>
_______________________________________

From report at bugs.python.org  Mon Jan 22 04:29:42 2018
From: report at bugs.python.org (Mukhit)
Date: Mon, 22 Jan 2018 09:29:42 +0000
Subject: [New-bugs-announce] [issue32619] multiplication error
Message-ID: <1516613382.08.0.467229070634.issue32619@psf.upfronthosting.co.za>


New submission from Mukhit <mukhit at mail.ru>:

print (10*3.14)

31.400000000000002

----------
components: ctypes
messages: 310406
nosy: mukhit
priority: normal
severity: normal
status: open
title: multiplication error
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32619>
_______________________________________

From report at bugs.python.org  Mon Jan 22 05:56:53 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Jan 2018 10:56:53 +0000
Subject: [New-bugs-announce] [issue32620] [3.5] Travis CI fails on Python
 3.5 with "pyenv: version `3.5' not installed"
Message-ID: <1516618613.48.0.467229070634.issue32620@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

My workaround for bpo-31568 is causing new issues on Python 3.5.

Output:
---
0.03s$ pyenv global system 3.5
pyenv: version `3.5' not installed
---

Extract of Python 3.5 .travis.yml:
---
      before_install:
        # work around https://github.com/travis-ci/travis-ci/issues/8363
        - pyenv global system 3.5
---

=> https://github.com/travis-ci/travis-ci/issues/8363

This workaround was added by me:
---
commit 70c630a7316f9f6063557786442e3c56502fe8ea
Author: Victor Stinner <victor.stinner at gmail.com>
Date:   Sun Sep 24 15:45:00 2017 -0700

    bpo-31568, Travis CI: Fix python3.5 (#3737)
    
    Works around Travis CI bug about the python3.5 binary:
    https://github.com/travis-ci/travis-ci/issues/8363
---

Without the workaround, running "python3.5" on Travis CI failed with "pyenv: python3.5: command not found".

Extract of Larry Hastings's email:
---

I have three PRs for Python 3.5.5rc1:

    https://github.com/python/cpython/pull/4656
    https://github.com/python/cpython/pull/5197
    https://github.com/python/cpython/pull/5201

I can't merge them because Travis CI is unhappy.  All three CI tests fail in the same way, reporting this error:

    The command "pyenv global system 3.5" failed and exited with 1 during .
---
https://mail.python.org/pipermail/python-committers/2018-January/005135.html

----------
components: Tests
messages: 310416
nosy: vstinner
priority: normal
severity: normal
status: open
title: [3.5] Travis CI fails on Python 3.5 with "pyenv: version `3.5' not installed"
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32620>
_______________________________________

From report at bugs.python.org  Mon Jan 22 09:28:36 2018
From: report at bugs.python.org (Yahya Abou Imran)
Date: Mon, 22 Jan 2018 14:28:36 +0000
Subject: [New-bugs-announce] [issue32621] Problem of consistence in
 collection.abc documentation
Message-ID: <1516631316.64.0.467229070634.issue32621@psf.upfronthosting.co.za>


New submission from Yahya Abou Imran <yahya-abou-imran at protonmail.com>:

Opened after https://github.com/python/cpython/pull/5270 was closed.

Here:

https://docs.python.org/3/library/collections.abc.html

Some abstract methods are inherited from a superclass.
Most of the time the name of the method is mentioned in the subclass.

For example:

Collection inherit from Sized, Iterable and Contains.
But __len__, __iter__ and __contains__ are mentioned, even if they are inherited.

Mapping inherits from Collection, but __len__ and __iter__ appears in the table

There is one exception: Coroutine.
It inherits from Awaitable but we don't see __await__.

What would we do? Let all appear or not?

----------
messages: 310422
nosy: yahya-abou-imran
priority: normal
severity: normal
status: open
title: Problem of consistence in collection.abc documentation
type: enhancement
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32621>
_______________________________________

From report at bugs.python.org  Mon Jan 22 10:21:57 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 22 Jan 2018 15:21:57 +0000
Subject: [New-bugs-announce] [issue32622] Implement loop.sendfile
Message-ID: <1516634517.98.0.467229070634.issue32622@psf.upfronthosting.co.za>


Change by Andrew Svetlov <andrew.svetlov at gmail.com>:


----------
components: asyncio
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Implement loop.sendfile
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32622>
_______________________________________

From report at bugs.python.org  Mon Jan 22 11:37:38 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 22 Jan 2018 16:37:38 +0000
Subject: [New-bugs-announce] [issue32623] Resize dict on del/pop
Message-ID: <1516639058.13.0.467229070634.issue32623@psf.upfronthosting.co.za>


New submission from Yury Selivanov <yselivanov at gmail.com>:

We should investigate whether we want dicts to compact themselves on del/pop operations.  Currently we have to rely on workarounds to have compactable dict.copy (see issue 31179) etc.

----------
components: Interpreter Core
messages: 310427
nosy: inada.naoki, serhiy.storchaka, vstinner, yselivanov
priority: normal
severity: normal
status: open
title: Resize dict on del/pop
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32623>
_______________________________________

From report at bugs.python.org  Mon Jan 22 12:39:55 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 22 Jan 2018 17:39:55 +0000
Subject: [New-bugs-announce] [issue32624] Implement
 WriteTransport.is_protocol_paused()
Message-ID: <1516642795.12.0.467229070634.issue32624@psf.upfronthosting.co.za>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

The method should return True is write is suspended

----------
components: asyncio
messages: 310439
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Implement WriteTransport.is_protocol_paused()
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32624>
_______________________________________

From report at bugs.python.org  Mon Jan 22 12:41:42 2018
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 22 Jan 2018 17:41:42 +0000
Subject: [New-bugs-announce] [issue32625] Update the dis module
 documentation to reflect switch to wordcode
Message-ID: <1516642902.05.0.467229070634.issue32625@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <alexander.belopolsky at gmail.com>:

A switch to wordcode is implemented in Python 3.6, but the documentation in the dis module was mostly left unchanged.  See issue 26647, msg266388 and issue 27095, msg268389.

----------
assignee: docs at python
components: Documentation
messages: 310440
nosy: belopolsky, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: Update the dis module documentation to reflect switch to wordcode
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32625>
_______________________________________

From report at bugs.python.org  Mon Jan 22 17:39:59 2018
From: report at bugs.python.org (Ben Burrill)
Date: Mon, 22 Jan 2018 22:39:59 +0000
Subject: [New-bugs-announce] [issue32626] Subscript unpacking raises
 SyntaxError
Message-ID: <1516660799.03.0.467229070634.issue32626@psf.upfronthosting.co.za>


New submission from Ben Burrill <bburrill98 at gmail.com>:

PEP 448 defines unpacking generalizations for tuples.  However, this does not currently work for subscripted tuples that are not delimited by parentheses.

Current behavior (Tested on 3.6/3.7a4):
>>> class Subscriptable:
...     def __getitem__(self, item):
...         return item
...
>>> ss = Subscriptable()
>>> 
>>> 1, 2, 3
(1, 2, 3)
>>> ss[1, 2, 3]
(1, 2, 3)
>>> *range(5), 42
(0, 1, 2, 3, 4, 42)
>>> ss[*range(5), 42]  # This should be the same as above
  File "<stdin>", line 1
    ss[*range(5), 42]
       ^
SyntaxError: invalid syntax
>>> ss[(*range(5), 42)]  # Workaround
(0, 1, 2, 3, 4, 42)

----------
components: Interpreter Core
messages: 310447
nosy: Ben Burrill
priority: normal
severity: normal
status: open
title: Subscript unpacking raises SyntaxError
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32626>
_______________________________________

From report at bugs.python.org  Mon Jan 22 20:54:03 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 23 Jan 2018 01:54:03 +0000
Subject: [New-bugs-announce] [issue32627] Header dependent _uuid build
 failure on Fedora 27
Message-ID: <1516672443.95.0.467229070634.issue32627@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

I'm hitting a build failure relating to the new _uuid module on Fedora 27:

==============
building '_uuid' extension
gcc -pthread -fPIC -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration -I./Include -I. -I/usr/local/include -I/home/ncoghlan/devel/cpython/Include -I/home/ncoghlan/devel/cpython -c /home/ncoghlan/devel/cpython/Modules/_uuidmodule.c -o build/temp.linux-x86_64-3.7/home/ncoghlan/devel/cpython/Modules/_uuidmodule.o
In file included from /home/ncoghlan/devel/cpython/Modules/_uuidmodule.c:8:0:
/usr/include/uuid.h:94:24: error: conflicting types for ?uuid_t?
 typedef struct uuid_st uuid_t;
                        ^~~~~~
In file included from /home/ncoghlan/devel/cpython/Modules/_uuidmodule.c:5:0:
/usr/include/uuid/uuid.h:44:23: note: previous declaration of ?uuid_t? was here
 typedef unsigned char uuid_t[16];
                       ^~~~~~
In file included from /home/ncoghlan/devel/cpython/Modules/_uuidmodule.c:8:0:
/usr/include/uuid.h:107:22: error: conflicting types for ?uuid_compare?
 extern uuid_rc_t     uuid_compare  (const uuid_t  *_uuid, const uuid_t *_uuid2, int *_result);
                      ^~~~~~~~~~~~
In file included from /home/ncoghlan/devel/cpython/Modules/_uuidmodule.c:5:0:
/usr/include/uuid/uuid.h:73:12: note: previous declaration of ?uuid_compare? was here
 extern int uuid_compare(const uuid_t uu1, const uuid_t uu2);
            ^~~~~~~~~~~~
/home/ncoghlan/devel/cpython/Modules/_uuidmodule.c: In function ?py_uuid_generate_time_safe?:
/home/ncoghlan/devel/cpython/Modules/_uuidmodule.c:15:12: error: storage size of ?uuid? isn?t known
     uuid_t uuid;
            ^~~~
/home/ncoghlan/devel/cpython/Modules/_uuidmodule.c:15:12: warning: unused variable ?uuid? [-Wunused-variable]
/home/ncoghlan/devel/cpython/Modules/_uuidmodule.c:29:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^
==============

>From my initial investigation, I think the issue may be related to my previous attempt to fix this in https://github.com/python/cpython/commit/53efbf3977a44e382397e7994a2524b4f8c9d053#diff-2eeaed663bd0d25b7e608891384b7298 and the fact that there are *two* "uuid.h" headers available in the Fedora repos:

* /usr/include/uuid.h (provided by uuid-devel)
* /usr/include/uuid/uuid.h (provided by libuuid-devel)

Right now, the build works if you have "libuuid-devel" installed, but do *not* have "uuid-devel" installed.

With both installed, neither installed, or only uuid-devel installed, the build will fail, but the exact errors reported will vary. (There's also a distinct set of compile errors you can get if you forget to rerun configure after installing the additional headers)

Reverting my previous commit (and replacing it with a comment saying we're specifically looking for "uuid/uuid.h", not "uuid.h") may be enough to handle the case where both are installed.

----------
messages: 310459
nosy: christian.heimes, ncoghlan, vstinner
priority: normal
severity: normal
stage: needs patch
status: open
title: Header dependent _uuid build failure on Fedora 27
type: compile error
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32627>
_______________________________________

From report at bugs.python.org  Mon Jan 22 23:16:45 2018
From: report at bugs.python.org (Erik Paulson)
Date: Tue, 23 Jan 2018 04:16:45 +0000
Subject: [New-bugs-announce] [issue32628] Add configurable DirectoryIndex to
 http.server
Message-ID: <1516681005.05.0.467229070634.issue32628@psf.upfronthosting.co.za>


New submission from Erik Paulson <epaulson at unit1127.com>:

In http.server and SimpleHTTPRequestHandler - the send_head function is hard-coded to treat index.html and index.htm as files to return in a directory - if neither of those files are present, it lists the directory. 

It would be very nice to be able to specify other files to use as a directory index, similar to the DirectoryIndex directive from Apache.

I think it'd be straight forward to add some kind of list you could set, just like you can modify extensions_map to include other types of MIME types. 

Would it be OK to just add a directory_index list with index.html and index.htm on by default that people could do like
Handler.directory_index.append("index.htmlx") in their setup? Or would such an API be better with some kind of helper?

----------
components: Library (Lib)
messages: 310468
nosy: epaulson
priority: normal
severity: normal
status: open
title: Add configurable DirectoryIndex to http.server
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32628>
_______________________________________

From report at bugs.python.org  Tue Jan 23 01:36:29 2018
From: report at bugs.python.org (Jack Branson)
Date: Tue, 23 Jan 2018 06:36:29 +0000
Subject: [New-bugs-announce] [issue32629] PyImport_ImportModule occasionally
 cause access violation
Message-ID: <1516689389.11.0.467229070634.issue32629@psf.upfronthosting.co.za>


New submission from Jack Branson <a1q123456 at gmail.com>:

I found that calling PyImport_ImportModule frequently may cause access violation error.

here is call stack:

00 0354f610 67d01605 00000001 00000020 0000007f python36!_PyObject_Alloc+0x5e [c:\build\cpython36\objects\obmalloc.c @ 1258]
01 (Inline) -------- -------- -------- -------- python36!PyObject_Malloc+0x18 [c:\build\cpython36\objects\obmalloc.c @ 479]
02 0354f638 67d18070 00000008 0000007f 67e541e0 python36!PyUnicode_New+0xf5 [c:\build\cpython36\objects\unicodeobject.c @ 1281]
03 0354f654 67d0963a 0354f69c 00000008 0000007f python36!_PyUnicodeWriter_PrepareInternal+0x60 [c:\build\cpython36\objects\unicodeobject.c @ 13534]
04 0354f6c0 67d02a66 67e541e0 00000008 00000000 python36!PyUnicode_DecodeUTF8Stateful+0xca [c:\build\cpython36\objects\unicodeobject.c @ 5034]
05 0354f6e4 67d59183 67e541e0 02a09db8 02a09de0 python36!PyUnicode_FromString+0x46 [c:\build\cpython36\objects\unicodeobject.c @ 2077]
06 (Inline) -------- -------- -------- -------- python36!PyImport_ImportModuleLevel+0xa [c:\build\cpython36\python\import.c @ 1652]
07 0354f704 67d5878f 02a09de0 02a09db8 02a09dd0 python36!PyImport_Import+0xe3 [c:\build\cpython36\python\import.c @ 1732]
08 0354f718 00478639 02a09dd0 7651129a 00000000 python36!PyImport_ImportModule+0x1f [c:\build\cpython36\python\import.c @ 1257]

pointer bp's value is 0x00000001, which is NULL + 1. In this case, `assert(bp != NULL)` will not let application crash for assert failure, and application will continue run until the line `pool->freeblock = *(block **)bp` which is defrencing bp, causes access violation.

0:009> .frame 0
00 0354f610 67d01605 python36!_PyObject_Alloc+0x5e [c:\build\cpython36\objects\obmalloc.c @ 1258]
0:009> r
eax=67ecfeb8 ebx=00000021 ecx=02a09000 edx=00000000 esi=00000001 edi=00000001
eip=67cdda4e esp=0354f5f8 ebp=0354f610 iopl=0         nv up ei pl nz na pe cy
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010207
python36!_PyObject_Alloc+0x5e:
67cdda4e 8b06            mov     eax,dword ptr [esi]  ds:002b:00000001=????????
0:009> dv
     use_calloc = 0n0
          nelem = 1
         elsize = <value unavailable>
         nbytes = 0x21
           pool = 0x02a09000
           size = 4
           next = 0x67ecfeb8
             bp = 0x00000001 "--- memory read error at address 0x00000001 ---"
         result = <value unavailable>
  usable_arenas = <value unavailable>


/*
             * There is a used pool for this size class.
             * Pick up the head block of its free list.
             */
            ++pool->ref.count;
            bp = pool->freeblock;
            assert(bp != NULL);
            if ((pool->freeblock = *(block **)bp) != NULL) {
                UNLOCK();
                if (use_calloc)
                    memset(bp, 0, nbytes);
                return (void *)bp;
            }
            /*

----------
components: ctypes
messages: 310471
nosy: Jack Branson
priority: normal
severity: normal
status: open
title: PyImport_ImportModule occasionally cause access violation
type: crash
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32629>
_______________________________________

From report at bugs.python.org  Tue Jan 23 01:56:55 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 23 Jan 2018 06:56:55 +0000
Subject: [New-bugs-announce] [issue32630] Migrate decimal to use PEP 567
 context variables
Message-ID: <1516690615.68.0.467229070634.issue32630@psf.upfronthosting.co.za>


New submission from Yury Selivanov <yselivanov at gmail.com>:

PEP 567 allows decimal to be safely used in async/await code.

I couldn't observe any performance impact by the proposed PR.  The PR doesn't modify decimal context behaviour: instead of using a thread-local storage it now uses a context variable.

----------
components: Library (Lib)
messages: 310472
nosy: gvanrossum, inada.naoki, skrah, vstinner, yselivanov
priority: normal
severity: normal
stage: patch review
status: open
title: Migrate decimal to use PEP 567 context variables
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32630>
_______________________________________

From report at bugs.python.org  Tue Jan 23 01:57:24 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 23 Jan 2018 06:57:24 +0000
Subject: [New-bugs-announce] [issue32631] IDLE: revise zzdummy.py
Message-ID: <1516690644.63.0.467229070634.issue32631@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

zzdummy.py is needed for properly testing the extension mechanism.  It is intended to provide an example extension for users to follow.  When completed, enabled, and invoked, it will prefix every line of a window with some text, or remove the prefix from every line.  It would be even better to make it respect selections, as other format options do.

Needed: more comments, including what it does when enabled; docstring for z_in_event; uncomment z_in_event; code for z_out_event.

Should the extension have a different name? ZzTestExample? ZzIgnoreThis?  Changing an extension name would normally be a bad idea, as it would disable any customizations.  But I think we could do it for this one if desired.

The default insertion text could be more informative: for instance, 'ignore this' or 'see-doc' or #ignore#.  The last would make it a configurable comment/uncomment.  Normally, changing a default is a no-no, as it can mess up user configurations.  But since the current text is inoperative, this should not matter here.

The menu defs are commented out because enabling the extension currently has no effect, so the menu entries would be useless.

***There should be help text for the extension tab explaining the presence and operation of the extension.  (This should have  been done already.)

Extension tests, last revised in #31480, will likely need more changes.

----------
assignee: terry.reedy
components: IDLE
messages: 310473
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: IDLE: revise zzdummy.py
type: behavior
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32631>
_______________________________________

From report at bugs.python.org  Tue Jan 23 02:24:45 2018
From: report at bugs.python.org (Sergey)
Date: Tue, 23 Jan 2018 07:24:45 +0000
Subject: [New-bugs-announce] [issue32632] Mock does not create deepcopy of
 mutable args
Message-ID: <1516692285.74.0.467229070634.issue32632@psf.upfronthosting.co.za>


New submission from Sergey <sergejyit at gmail.com>:

MagicMock allows to check parameters of calls by using "assert_has_calls". However it fails if argument has a mutable type and was changed in-place before the second call.

The example is provided in attached file.

In "func1" value in "data" changes for each iteration and as result:
call_args_list contains two same calls.
In "func2" variable "data" generates by function "get_dict" and in this case call_args_list contains correct values.

Obviously it happens because class _Call (https://github.com/python/cpython/blob/3.5/Lib/unittest/mock.py#L1929) does not create a deepcopy of call args/kwargs.

Will it be correct to add deep_copy logic in mock.py ? or may be it's wrong to use logic like in "func1"? 
I see only one disadvantage of using deepcopy: it will become slower.

----------
components: Tests
files: test.py
messages: 310476
nosy: michael.foord, skraynev
priority: normal
severity: normal
status: open
title: Mock does not create deepcopy of mutable args
versions: Python 3.5
Added file: https://bugs.python.org/file47401/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32632>
_______________________________________

From report at bugs.python.org  Tue Jan 23 02:43:08 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Tue, 23 Jan 2018 07:43:08 +0000
Subject: [New-bugs-announce] [issue32633] Warnings from
 test_asyncio.test_tasks.SetMethodsTest
Message-ID: <1516693388.97.0.467229070634.issue32633@psf.upfronthosting.co.za>


New submission from Nathaniel Smith <njs at pobox.com>:

The test_asyncio tests are generating some warnings:

0:00:00 load avg: 2.14 [1/1] test_asyncio.test_tasks
/home/njs/src/cpython/Lib/test/test_asyncio/test_tasks.py:100: RuntimeWarning: coroutine 'SetMethodsTest.test_set_exception_causes_invalid_state.<locals>.foo' was never awaited
  gc.collect()
/home/njs/src/cpython/Lib/test/test_asyncio/test_tasks.py:100: RuntimeWarning: coroutine 'SetMethodsTest.test_set_result_causes_invalid_state.<locals>.foo' was never awaited
  gc.collect()
/home/njs/src/cpython/Lib/test/test_asyncio/test_tasks.py:100: RuntimeWarning: coroutine 'SetMethodsTest.test_set_exception_causes_invalid_state.<locals>.foo' was never awaited
  gc.collect()
/home/njs/src/cpython/Lib/test/test_asyncio/test_tasks.py:100: RuntimeWarning: coroutine 'SetMethodsTest.test_set_result_causes_invalid_state.<locals>.foo' was never awaited
  gc.collect()
1 test OK.

It looks like these have been here for a while. Easy to fix though.

----------
components: Tests, asyncio
messages: 310478
nosy: asvetlov, giampaolo.rodola, njs, yselivanov
priority: normal
severity: normal
status: open
title: Warnings from test_asyncio.test_tasks.SetMethodsTest
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32633>
_______________________________________

From report at bugs.python.org  Tue Jan 23 03:31:16 2018
From: report at bugs.python.org (Maxim Barabanov)
Date: Tue, 23 Jan 2018 08:31:16 +0000
Subject: [New-bugs-announce] [issue32634] Message parsing fails where it has
 incompele headers
Message-ID: <1516696276.33.0.467229070634.issue32634@psf.upfronthosting.co.za>


New submission from Maxim Barabanov <maxim.barabanov at gmail.com>:

If email message dont have a content-transfer-encoding or content-type header, function write in generator.py crashes

----------
components: email
messages: 310485
nosy: barry, r.david.murray, reb00ter
priority: normal
severity: normal
status: open
title: Message parsing fails where it has incompele headers
type: crash
versions: Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32634>
_______________________________________

From report at bugs.python.org  Tue Jan 23 05:22:07 2018
From: report at bugs.python.org (Charalampos Stratakis)
Date: Tue, 23 Jan 2018 10:22:07 +0000
Subject: [New-bugs-announce] [issue32635] test_crypt segfaults when using
 libxcrypt instead of libcrypt
Message-ID: <1516702927.0.0.467229070634.issue32635@psf.upfronthosting.co.za>


New submission from Charalampos Stratakis <cstratak at redhat.com>:

Currently in Fedora glibc stopped providing libcrypt[0] a change which is slowly being upstreamed as well[1] in favor of the libxcrypt project[2].

This causes a segfault when importing the crypt module as python assumes that crypt.h is always available.

Providing a working patch from the libxcrypt maintainer. I'll convert the patch into a PR.

[0] https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt
[1] https://sourceware.org/ml/libc-alpha/2017-08/msg01257.html
[2] https://github.com/besser82/libxcrypt

----------
files: 00290-cryptmodule-Include-crypt.h-for-declaration-of-crypt.patch
keywords: patch
messages: 310490
nosy: cstratak
priority: normal
severity: normal
status: open
title: test_crypt segfaults when using libxcrypt instead of libcrypt
Added file: https://bugs.python.org/file47402/00290-cryptmodule-Include-crypt.h-for-declaration-of-crypt.patch

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32635>
_______________________________________

From report at bugs.python.org  Tue Jan 23 06:21:12 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Jan 2018 11:21:12 +0000
Subject: [New-bugs-announce] [issue32636] test_asyncio fails with
 PYTHONASYNCIODEBUG=1
Message-ID: <1516706472.98.0.467229070634.issue32636@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

(1) test.test_asyncio.test_tasks.CTaskSubclass_PyFuture_Tests.test_wait_with_exception() hangs:

vstinner at apu$ PYTHONASYNCIODEBUG=1 ./python -m test test_asyncio -m test_wait_with_exception -v
== CPython 3.7.0a4+ (heads/freebsd_configure:27218edef7, Jan 23 2018, 11:52:08) [GCC 7.2.1 20170915 (Red Hat 7.2.1-2)]
== Linux-4.14.13-300.fc27.x86_64-x86_64-with-fedora-27-Twenty_Seven little-endian
== cwd: /home/vstinner/prog/python/master/build/test_python_24675
== CPU count: 8
== encodings: locale=UTF-8, FS=utf-8
Run tests sequentially
0:00:00 load avg: 1.37 [1/1] test_asyncio
test_wait_with_exception (test.test_asyncio.test_tasks.CTaskSubclass_PyFuture_Tests) ... /home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py:1009: RuntimeWarning: coroutine 'sleep' was never awaited
Coroutine created at (most recent call last)
  File "/home/vstinner/prog/python/master/Lib/unittest/case.py", line 615, in run
    testMethod()
  File "/home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py", line 1021, in test_wait_with_exception
    loop.run_until_complete(self.new_task(loop, foo()))
  File "/home/vstinner/prog/python/master/Lib/asyncio/base_events.py", line 423, in run_until_complete
    self.run_forever()
  File "/home/vstinner/prog/python/master/Lib/asyncio/base_events.py", line 391, in run_forever
    self._run_once()
  File "/home/vstinner/prog/python/master/Lib/test/test_asyncio/utils.py", line 454, in _run_once
    super()._run_once()
  File "/home/vstinner/prog/python/master/Lib/asyncio/base_events.py", line 1521, in _run_once
    handle._run()
  File "/home/vstinner/prog/python/master/Lib/asyncio/events.py", line 88, in _run
    self._context.run(self._callback, *self._args)
  File "/home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py", line 2289, in _step
    return super()._step(*args)
  File "/home/vstinner/prog/python/master/Lib/asyncio/coroutines.py", line 61, in send
    return self.gen.send(value)
  File "/home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py", line 1009, in sleeper
    yield from asyncio.sleep(0.15, loop=loop)
  yield from asyncio.sleep(0.15, loop=loop)


(2) 43 failures and 55 errors:

ERROR: test_context_manager (test.test_asyncio.test_locks.ConditionTests)
ERROR: test_context_manager (test.test_asyncio.test_locks.LockTests)
ERROR: test_context_manager_cant_reuse (test.test_asyncio.test_locks.LockTests)
ERROR: test_lock (test.test_asyncio.test_locks.LockTests)
ERROR: test_lock_by_with_statement (test.test_asyncio.test_locks.LockTests)
ERROR: test_repr (test.test_asyncio.test_locks.LockTests)
ERROR: test_context_manager (test.test_asyncio.test_locks.SemaphoreTests)
ERROR: test_semaphore (test.test_asyncio.test_locks.SemaphoreTests)
ERROR: test_as_completed (test.test_asyncio.test_tasks.CTaskSubclass_PyFuture_Tests)
ERROR: test_as_completed_duplicate_coroutines (test.test_asyncio.test_tasks.CTaskSubclass_PyFuture_Tests)
ERROR: test_sleep (test.test_asyncio.test_tasks.CTaskSubclass_PyFuture_Tests)
ERROR: test_task_cancel_sleeping_task (test.test_asyncio.test_tasks.CTaskSubclass_PyFuture_Tests)
ERROR: test_tb_logger_not_called_after_cancel (test.test_asyncio.test_tasks.CTaskSubclass_PyFuture_Tests)
ERROR: test_as_completed (test.test_asyncio.test_tasks.CTask_CFuture_SubclassTests)
ERROR: test_as_completed_duplicate_coroutines (test.test_asyncio.test_tasks.CTask_CFuture_SubclassTests)
ERROR: test_sleep (test.test_asyncio.test_tasks.CTask_CFuture_SubclassTests)
ERROR: test_task_cancel_sleeping_task (test.test_asyncio.test_tasks.CTask_CFuture_SubclassTests)
ERROR: test_tb_logger_not_called_after_cancel (test.test_asyncio.test_tasks.CTask_CFuture_SubclassTests)
ERROR: test_as_completed (test.test_asyncio.test_tasks.CTask_CFuture_Tests)
ERROR: test_as_completed_duplicate_coroutines (test.test_asyncio.test_tasks.CTask_CFuture_Tests)
ERROR: test_sleep (test.test_asyncio.test_tasks.CTask_CFuture_Tests)
ERROR: test_task_cancel_sleeping_task (test.test_asyncio.test_tasks.CTask_CFuture_Tests)
ERROR: test_tb_logger_not_called_after_cancel (test.test_asyncio.test_tasks.CTask_CFuture_Tests)
ERROR: test_foobar (test.test_asyncio.test_tasks.CTask_Future_Tests)
ERROR: test_as_completed (test.test_asyncio.test_tasks.CTask_PyFuture_Tests)
ERROR: test_as_completed_duplicate_coroutines (test.test_asyncio.test_tasks.CTask_PyFuture_Tests)
ERROR: test_sleep (test.test_asyncio.test_tasks.CTask_PyFuture_Tests)
ERROR: test_task_cancel_sleeping_task (test.test_asyncio.test_tasks.CTask_PyFuture_Tests)
ERROR: test_tb_logger_not_called_after_cancel (test.test_asyncio.test_tasks.CTask_PyFuture_Tests)
ERROR: test_await_old_style_coro (test.test_asyncio.test_tasks.CompatibilityTests)
ERROR: test_yield_from_awaitable (test.test_asyncio.test_tasks.CompatibilityTests)
ERROR: test_as_completed (test.test_asyncio.test_tasks.PyTask_CFutureSubclass_Tests)
ERROR: test_as_completed_duplicate_coroutines (test.test_asyncio.test_tasks.PyTask_CFutureSubclass_Tests)
ERROR: test_sleep (test.test_asyncio.test_tasks.PyTask_CFutureSubclass_Tests)
ERROR: test_task_cancel_sleeping_task (test.test_asyncio.test_tasks.PyTask_CFutureSubclass_Tests)
ERROR: test_tb_logger_not_called_after_cancel (test.test_asyncio.test_tasks.PyTask_CFutureSubclass_Tests)
ERROR: test_as_completed (test.test_asyncio.test_tasks.PyTask_CFuture_Tests)
ERROR: test_as_completed_duplicate_coroutines (test.test_asyncio.test_tasks.PyTask_CFuture_Tests)
ERROR: test_sleep (test.test_asyncio.test_tasks.PyTask_CFuture_Tests)
ERROR: test_task_cancel_sleeping_task (test.test_asyncio.test_tasks.PyTask_CFuture_Tests)
ERROR: test_tb_logger_not_called_after_cancel (test.test_asyncio.test_tasks.PyTask_CFuture_Tests)
ERROR: test_as_completed (test.test_asyncio.test_tasks.PyTask_PyFuture_SubclassTests)
ERROR: test_as_completed_duplicate_coroutines (test.test_asyncio.test_tasks.PyTask_PyFuture_SubclassTests)
ERROR: test_sleep (test.test_asyncio.test_tasks.PyTask_PyFuture_SubclassTests)
ERROR: test_task_cancel_sleeping_task (test.test_asyncio.test_tasks.PyTask_PyFuture_SubclassTests)
ERROR: test_tb_logger_not_called_after_cancel (test.test_asyncio.test_tasks.PyTask_PyFuture_SubclassTests)
ERROR: test_as_completed (test.test_asyncio.test_tasks.PyTask_PyFuture_Tests)
ERROR: test_as_completed_duplicate_coroutines (test.test_asyncio.test_tasks.PyTask_PyFuture_Tests)
ERROR: test_sleep (test.test_asyncio.test_tasks.PyTask_PyFuture_Tests)
ERROR: test_task_cancel_sleeping_task (test.test_asyncio.test_tasks.PyTask_PyFuture_Tests)
ERROR: test_tb_logger_not_called_after_cancel (test.test_asyncio.test_tasks.PyTask_PyFuture_Tests)
ERROR: test_run_coroutine_threadsafe (test.test_asyncio.test_tasks.RunCoroutineThreadsafeTests)
ERROR: test_run_coroutine_threadsafe_task_cancelled (test.test_asyncio.test_tasks.RunCoroutineThreadsafeTests)
ERROR: test_run_coroutine_threadsafe_with_exception (test.test_asyncio.test_tasks.RunCoroutineThreadsafeTests)
ERROR: test_sleep_zero (test.test_asyncio.test_tasks.SleepTests)
FAIL: test_default_exc_handler_coro (test.test_asyncio.test_base_events.BaseEventLoopTests)
FAIL: test_nonstream_socket (test.test_asyncio.test_base_events.BaseLoopSendfileTests)
FAIL: test_as_completed (test.test_asyncio.test_tasks.CTaskSubclass_PyFuture_Tests)
FAIL: test_baseexception_during_cancel (test.test_asyncio.test_tasks.CTaskSubclass_PyFuture_Tests)
FAIL: test_baseexception_during_cancel (test.test_asyncio.test_tasks.CTaskSubclass_PyFuture_Tests)
FAIL: test_sleep (test.test_asyncio.test_tasks.CTaskSubclass_PyFuture_Tests)
FAIL: test_task_cancel_sleeping_task (test.test_asyncio.test_tasks.CTaskSubclass_PyFuture_Tests)
FAIL: test_as_completed (test.test_asyncio.test_tasks.CTask_CFuture_SubclassTests)
FAIL: test_baseexception_during_cancel (test.test_asyncio.test_tasks.CTask_CFuture_SubclassTests)
FAIL: test_baseexception_during_cancel (test.test_asyncio.test_tasks.CTask_CFuture_SubclassTests)
FAIL: test_sleep (test.test_asyncio.test_tasks.CTask_CFuture_SubclassTests)
FAIL: test_task_cancel_sleeping_task (test.test_asyncio.test_tasks.CTask_CFuture_SubclassTests)
FAIL: test_as_completed (test.test_asyncio.test_tasks.CTask_CFuture_Tests)
FAIL: test_baseexception_during_cancel (test.test_asyncio.test_tasks.CTask_CFuture_Tests)
FAIL: test_baseexception_during_cancel (test.test_asyncio.test_tasks.CTask_CFuture_Tests)
FAIL: test_sleep (test.test_asyncio.test_tasks.CTask_CFuture_Tests)
FAIL: test_task_cancel_sleeping_task (test.test_asyncio.test_tasks.CTask_CFuture_Tests)
FAIL: test_as_completed (test.test_asyncio.test_tasks.CTask_PyFuture_Tests)
FAIL: test_baseexception_during_cancel (test.test_asyncio.test_tasks.CTask_PyFuture_Tests)
FAIL: test_baseexception_during_cancel (test.test_asyncio.test_tasks.CTask_PyFuture_Tests)
FAIL: test_sleep (test.test_asyncio.test_tasks.CTask_PyFuture_Tests)
FAIL: test_task_cancel_sleeping_task (test.test_asyncio.test_tasks.CTask_PyFuture_Tests)
FAIL: test_as_completed (test.test_asyncio.test_tasks.PyTask_CFutureSubclass_Tests)
FAIL: test_baseexception_during_cancel (test.test_asyncio.test_tasks.PyTask_CFutureSubclass_Tests)
FAIL: test_baseexception_during_cancel (test.test_asyncio.test_tasks.PyTask_CFutureSubclass_Tests)
FAIL: test_sleep (test.test_asyncio.test_tasks.PyTask_CFutureSubclass_Tests)
FAIL: test_task_cancel_sleeping_task (test.test_asyncio.test_tasks.PyTask_CFutureSubclass_Tests)
FAIL: test_as_completed (test.test_asyncio.test_tasks.PyTask_CFuture_Tests)
FAIL: test_baseexception_during_cancel (test.test_asyncio.test_tasks.PyTask_CFuture_Tests)
FAIL: test_baseexception_during_cancel (test.test_asyncio.test_tasks.PyTask_CFuture_Tests)
FAIL: test_sleep (test.test_asyncio.test_tasks.PyTask_CFuture_Tests)
FAIL: test_task_cancel_sleeping_task (test.test_asyncio.test_tasks.PyTask_CFuture_Tests)
FAIL: test_as_completed (test.test_asyncio.test_tasks.PyTask_PyFuture_SubclassTests)
FAIL: test_baseexception_during_cancel (test.test_asyncio.test_tasks.PyTask_PyFuture_SubclassTests)
FAIL: test_baseexception_during_cancel (test.test_asyncio.test_tasks.PyTask_PyFuture_SubclassTests)
FAIL: test_sleep (test.test_asyncio.test_tasks.PyTask_PyFuture_SubclassTests)
FAIL: test_task_cancel_sleeping_task (test.test_asyncio.test_tasks.PyTask_PyFuture_SubclassTests)
FAIL: test_as_completed (test.test_asyncio.test_tasks.PyTask_PyFuture_Tests)
FAIL: test_baseexception_during_cancel (test.test_asyncio.test_tasks.PyTask_PyFuture_Tests)
FAIL: test_baseexception_during_cancel (test.test_asyncio.test_tasks.PyTask_PyFuture_Tests)
FAIL: test_sleep (test.test_asyncio.test_tasks.PyTask_PyFuture_Tests)
FAIL: test_task_cancel_sleeping_task (test.test_asyncio.test_tasks.PyTask_PyFuture_Tests)
FAIL: test_run_coroutine_threadsafe_task_factory_exception (test.test_asyncio.test_tasks.RunCoroutineThreadsafeTests)
FAILED (failures=43, errors=55, skipped=5)

These errors can be reproduced using attached fails file:

PYTHONASYNCIODEBUG=1 ./python -m test -v test_asyncio --matchfile=fails


Note: I found these issue when trying to run the full Python test suite using -X dev.

----------
components: Tests, asyncio
files: fails
messages: 310496
nosy: asvetlov, vstinner, yselivanov
priority: normal
severity: normal
status: open
title: test_asyncio fails with PYTHONASYNCIODEBUG=1
versions: Python 3.7
Added file: https://bugs.python.org/file47403/fails

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32636>
_______________________________________

From report at bugs.python.org  Tue Jan 23 12:16:49 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Jan 2018 17:16:49 +0000
Subject: [New-bugs-announce] [issue32637] Android: set sys.platform and
 os.name to android
Message-ID: <1516727809.08.0.467229070634.issue32637@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

Currently, sys.platform and os.name are equal to 'linux' on Android. While Android uses the Linux kernel, the operating system is not a regular Linux. The libc (bionic) is very different than the regular glibc, the filesystem is organized very differently, etc.

I propose to change sys.platform and os.name to 'android' when running on Android.

----------
components: Library (Lib)
messages: 310511
nosy: vstinner, xdegaye
priority: normal
severity: normal
status: open
title: Android: set sys.platform and os.name to android
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32637>
_______________________________________

From report at bugs.python.org  Tue Jan 23 15:06:25 2018
From: report at bugs.python.org (Michael Felt)
Date: Tue, 23 Jan 2018 20:06:25 +0000
Subject: [New-bugs-announce] [issue32638] distutils test errors with AIX and
 xlc
Message-ID: <1516737985.98.0.467229070634.issue32638@psf.upfronthosting.co.za>


New submission from Michael Felt <michael at felt.demon.nl>:

While working in issue11191 I found a fix for Python3-3.6 and later for the following tests, and later - but not for Python3-3.5

I suppose "we" could ignore the error on Python3-3.5 (as I then have a quick - simple - fix for Python3-3.6 and later.

Suggestions, rather - how important are the tests on Python3-3.5?

++++++++++++++++

root at x066:[/data/prj/python/git/x066-python3-3.7]nohup ./python Lib/test/test_distutils.py | egrep "^(ERROR|FAIL):"
ERROR: test_run (distutils.tests.test_build_clib.BuildCLibTestCase)
ERROR: test_build_ext (distutils.tests.test_build_ext.BuildExtTestCase)
ERROR: test_get_outputs (distutils.tests.test_build_ext.BuildExtTestCase)
ERROR: test_build_ext (distutils.tests.test_build_ext.ParallelBuildExtTestCase)
ERROR: test_get_outputs (distutils.tests.test_build_ext.ParallelBuildExtTestCase)
ERROR: test_record_extensions (distutils.tests.test_install.InstallTestCase)

root at x066:[/data/prj/python/python3-3.6.4]nohup ./python ../src/python3-3.6.4/Lib/test/test_distutils.py | egrep "^(ERROR|FAIL):"
ERROR: test_build_ext (distutils.tests.test_build_ext.BuildExtTestCase)
ERROR: test_get_outputs (distutils.tests.test_build_ext.BuildExtTestCase)
ERROR: test_build_ext (distutils.tests.test_build_ext.ParallelBuildExtTestCase)
ERROR: test_get_outputs (distutils.tests.test_build_ext.ParallelBuildExtTestCase)
ERROR: test_run (distutils.tests.test_build_clib.BuildCLibTestCase)
ERROR: test_search_cpp (distutils.tests.test_config_cmd.ConfigTestCase)
ERROR: test_record_extensions (distutils.tests.test_install.InstallTestCase)

root at x066:[/data/prj/python/python3-3.5.4]nohup ./python Lib/test/test_distutils.py | egrep "^(ERROR|FAIL):"
ERROR: test_record_extensions (distutils.tests.test_install.InstallTestCase)
ERROR: test_build_ext (distutils.tests.test_build_ext.BuildExtTestCase)
ERROR: test_get_outputs (distutils.tests.test_build_ext.BuildExtTestCase)
ERROR: test_build_ext (distutils.tests.test_build_ext.ParallelBuildExtTestCase)
ERROR: test_get_outputs (distutils.tests.test_build_ext.ParallelBuildExtTestCase)
FAIL: test_sysconfig_compiler_vars (distutils.tests.test_sysconfig.SysconfigTestCase)
FAIL: test_sysconfig_module (distutils.tests.test_sysconfig.SysconfigTestCase)

----------
components: Distutils
messages: 310519
nosy: Michael.Felt, dstufft, eric.araujo
priority: normal
severity: normal
status: open
title: distutils test errors with AIX and xlc
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32638>
_______________________________________

From report at bugs.python.org  Tue Jan 23 15:58:35 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Jan 2018 20:58:35 +0000
Subject: [New-bugs-announce] [issue32639] Coverity: CID 1428443: Null
 pointer dereferences (NULL_RETURNS) /Python/hamt.c: 1058 in
 hamt_node_bitmap_without()
Message-ID: <1516741115.79.0.467229070634.issue32639@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

Coverity found a bug in hamt.c:

** CID 1428443:  Null pointer dereferences  (NULL_RETURNS)
/Python/hamt.c: 1058 in hamt_node_bitmap_without()


________________________________________________________________________________________________________
*** CID 1428443:  Null pointer dereferences  (NULL_RETURNS)
/Python/hamt.c: 1058 in hamt_node_bitmap_without()
1052                         assert(hamt_node_collision_count(
1053                                 (PyHamtNode_Collision*)sub_node) > 1);
1054                     }
1055     #endif
1056
1057                     PyHamtNode_Bitmap *clone = hamt_node_bitmap_clone(self);
>>>     CID 1428443:  Null pointer dereferences  (NULL_RETURNS)
>>>     Dereferencing a null pointer "clone".
1058                     Py_SETREF(clone->b_array[val_idx],
1059                               (PyObject *)sub_node);  /* borrow */
1060
1061                     *new_node = (PyHamtNode *)clone;
1062                     return W_NEWNODE;
1063                 }

----------
components: Interpreter Core
messages: 310522
nosy: vstinner, yselivanov
priority: normal
severity: normal
status: open
title: Coverity: CID 1428443:  Null pointer dereferences  (NULL_RETURNS) /Python/hamt.c: 1058 in hamt_node_bitmap_without()
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32639>
_______________________________________

From report at bugs.python.org  Tue Jan 23 16:32:21 2018
From: report at bugs.python.org (Malcolm Smith)
Date: Tue, 23 Jan 2018 21:32:21 +0000
Subject: [New-bugs-announce] [issue32640] Python 2.7 str.join documentation
 is incorrect
Message-ID: <1516743141.31.0.467229070634.issue32640@psf.upfronthosting.co.za>


New submission from Malcolm Smith <malcolm.smith at gmail.com>:

At some point the Python 3 documentation of str.join has been copied to Python 2. This includes the sentence "A TypeError will be raised if there are any non-string values in iterable, including bytes objects." 

The second half of this sentence is wrong for Python 2. Not only is there no "bytes" type in Python 2, but join() in this version will happily join any mixture of unicode and (byte-)str objects, producing unicode output if any of the items (or separator) were unicode.

https://docs.python.org/2/library/stdtypes.html#str.join

----------
assignee: docs at python
components: Documentation
messages: 310525
nosy: Malcolm Smith, docs at python
priority: normal
severity: normal
status: open
title: Python 2.7 str.join documentation is incorrect
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32640>
_______________________________________

From report at bugs.python.org  Tue Jan 23 17:07:58 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 23 Jan 2018 22:07:58 +0000
Subject: [New-bugs-announce] [issue32641] test_context and test_asyncio
 crash on Windows 7
Message-ID: <1516745278.18.0.467229070634.issue32641@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

http://buildbot.python.org/all/#/builders/58/builds/498

0:36:25 [252/414/1] test_context crashed (Exit code 3) -- running: test_largefile (239 sec)
Windows fatal exception: code 0xc000001d

Current thread 0x00000944 (most recent call first):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_context.py", line 321 in ctx1_fun
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_context.py", line 339 in test_context_copy_1
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\case.py", line 615 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\case.py", line 663 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\runner.py", line 176 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\support\__init__.py", line 1861 in _run_suite
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\support\__init__.py", line 1951 in run_unittest
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 175 in test_runner
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 176 in runtest_inner
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 130 in runtest
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest_mp.py", line 67 in run_tests_slave
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 517 in _main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 510 in main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 585 in main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\regrtest.py", line 46 in _main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\regrtest.py", line 50 in <module>
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\runpy.py", line 85 in _run_code
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\runpy.py", line 193 in _run_module_as_main
Fatal Python error: Illegal instruction

Current thread 0x00000944 (most recent call first):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_context.py", line 321 in ctx1_fun
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_context.py", line 339 in test_context_copy_1
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\case.py", line 615 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\case.py", line 663 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\runner.py", line 176 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\support\__init__.py", line 1861 in _run_suite
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\support\__init__.py", line 1951 in run_unittest
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 175 in test_runner
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 176 in runtest_inner
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 130 in runtest
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest_mp.py", line 67 in run_tests_slave
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 517 in _main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 510 in main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 585 in main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\regrtest.py", line 46 in _main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\regrtest.py", line 50 in <module>
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\runpy.py", line 85 in _run_code
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\runpy.py", line 193 in _run_module_as_main


0:46:50 [306/414/2] test_asyncio crashed (Exit code 3) -- running: test_io (487 sec)
Windows fatal exception: code 0xc000001d

Current thread 0x00000d24 (most recent call first):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_asyncio\test_tasks.py", line 2191 in main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_asyncio\test_tasks.py", line 2289 in _step
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\asyncio\events.py", line 88 in _run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\asyncio\base_events.py", line 1529 in _run_once
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\asyncio\base_events.py", line 391 in run_forever
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\asyncio\base_events.py", line 423 in run_until_complete
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_asyncio\test_tasks.py", line 2199 in test_context_1
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\case.py", line 615 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\case.py", line 663 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\runner.py", line 176 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\support\__init__.py", line 1861 in _run_suite
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\support\__init__.py", line 1951 in run_unittest
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 175 in test_runner
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 176 in runtest_inner
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 130 in runtest
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest_mp.py", line 67 in run_tests_slave
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 517 in _main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 510 in main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 585 in main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\regrtest.py", line 46 in _main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\regrtest.py", line 50 in <module>
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\runpy.py", line 85 in _run_code
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\runpy.py", line 193 in _run_module_as_main
Fatal Python error: Illegal instruction

Current thread 0x00000d24 (most recent call first):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_asyncio\test_tasks.py", line 2191 in main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_asyncio\test_tasks.py", line 2289 in _step
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\asyncio\events.py", line 88 in _run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\asyncio\base_events.py", line 1529 in _run_once
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\asyncio\base_events.py", line 391 in run_forever
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\asyncio\base_events.py", line 423 in run_until_complete
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_asyncio\test_tasks.py", line 2199 in test_context_1
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\case.py", line 615 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\case.py", line 663 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 122 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\suite.py", line 84 in __call__
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\runner.py", line 176 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\support\__init__.py", line 1861 in _run_suite
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\support\__init__.py", line 1951 in run_unittest
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 175 in test_runner
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 176 in runtest_inner
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 130 in runtest
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest_mp.py", line 67 in run_tests_slave
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 517 in _main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 510 in main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 585 in main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\regrtest.py", line 46 in _main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\regrtest.py", line 50 in <module>
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\runpy.py", line 85 in _run_code
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\runpy.py", line 193 in _run_module_as_main

Note: the commit 0bad4d63c654d93e1f32ff35026405a3987db5ca doesn't fix these crashes. (The running build 399 hash this fix, and test_context does still crash.)

----------
components: asyncio
messages: 310528
nosy: asvetlov, vstinner, yselivanov
priority: normal
severity: normal
status: open
title: test_context and test_asyncio crash on Windows 7
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32641>
_______________________________________

From report at bugs.python.org  Wed Jan 24 00:27:12 2018
From: report at bugs.python.org (Chris Jerdonek)
Date: Wed, 24 Jan 2018 05:27:12 +0000
Subject: [New-bugs-announce] [issue32642] add support for path-like objects
 in sys.path
Message-ID: <1516771632.94.0.467229070634.issue32642@psf.upfronthosting.co.za>


New submission from Chris Jerdonek <chris.jerdonek at gmail.com>:

This issue is to suggest enhancing sys.path to recognize path-like objects, per PEP 519.

I recently ran into an issue where a path was getting added to sys.path, but the corresponding imports weren't working as they should, even though sys.path showed the path as being present. Eventually I tracked this down to the path being a pathlib.Path object rather than a string. This wasn't obvious because Path objects appear as strings in normal debug output, etc.

The sys.path docs currently say this:

> Only strings and bytes should be added to sys.path; all other data types are ignored during import.

----------
components: Library (Lib)
messages: 310560
nosy: brett.cannon, chris.jerdonek
priority: normal
severity: normal
status: open
title: add support for path-like objects in sys.path
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32642>
_______________________________________

From report at bugs.python.org  Wed Jan 24 00:32:19 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Wed, 24 Jan 2018 05:32:19 +0000
Subject: [New-bugs-announce] [issue32643] Make Task._step,
 Task._wakeup and Future._schedule_callback methods private
Message-ID: <1516771939.71.0.467229070634.issue32643@psf.upfronthosting.co.za>


New submission from Yury Selivanov <yselivanov at gmail.com>:

I propose to drop support for overloading Task._step, Task._wakeup, and Future._schedule_callbacks.

This makes the implementation easier for us to maintain and optimize. It also makes it easier for alternative asyncio event loops and interops with other async frameworks.

----------
components: asyncio
messages: 310561
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Make Task._step, Task._wakeup and Future._schedule_callback methods private
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32643>
_______________________________________

From report at bugs.python.org  Wed Jan 24 01:52:38 2018
From: report at bugs.python.org (Snakevil)
Date: Wed, 24 Jan 2018 06:52:38 +0000
Subject: [New-bugs-announce] [issue32644] unittest.mock.call len() error
Message-ID: <1516776758.4.0.467229070634.issue32644@psf.upfronthosting.co.za>


New submission from Snakevil <zsnakevil at gmail.com>:

In some testcase, an instance of unittest.mock.call was generated as:

call('solution', 'foo', {'__spots__': {}, '__event__': None, '__solution__': None})

The third argument is an instance of a derived component from dict.

In this issue, result of len() is 2 but not 3 as expected.

----------
components: Tests
messages: 310565
nosy: snakevil
priority: normal
severity: normal
status: open
title: unittest.mock.call len() error
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32644>
_______________________________________

From report at bugs.python.org  Wed Jan 24 04:49:28 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Jan 2018 09:49:28 +0000
Subject: [New-bugs-announce] [issue32645] test_asyncio: TLS tests fail on
 "x86 Windows7" buildbot
Message-ID: <1516787368.83.0.467229070634.issue32645@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

test_asyncio started to fail after the implementation of STARTTLS in asyncio, bpo-23749: commit f111b3dcb414093a4efb9d74b69925e535ddc470.

http://buildbot.python.org/all/#/builders/58/builds/502

Extract of test.pythoninfo:
----
ssl.HAS_SNI: True
ssl.OPENSSL_VERSION: OpenSSL 1.1.0f  25 May 2017
ssl.OPENSSL_VERSION_INFO: (1, 1, 0, 6, 15)
ssl.OP_ALL: -0x7fffffac
ssl.OP_NO_TLSv1_1: 0x10000000

sys.version: 3.7.0a4+ (heads/master:018e1b7, Jan 24 2018, 02:53:43) [MSC v.1900 32 bit (Intel)]
sys.version_info: sys.version_info(major=3, minor=7, micro=0, releaselevel='alpha', serial=4)
sys.windowsversion: sys.getwindowsversion(major=6, minor=1, build=7601, platform=2, service_pack='Service Pack 1')
sys.winver: 3.7-32
---

Extract of compile step:
---
Fetching external libraries...
(...)
openssl-bin-1.1.0f already exists, skipping.
---

Test failures:

======================================================================
ERROR: test_start_tls_client_1 (test.test_asyncio.test_sslproto.ProactorStartTLSTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_asyncio\test_sslproto.py", line 225, in test_start_tls_client_1
    asyncio.wait_for(client(srv.addr), loop=self.loop, timeout=10))
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\asyncio\base_events.py", line 436, in run_until_complete
    return future.result()
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\asyncio\tasks.py", line 406, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError

======================================================================
ERROR: test_start_tls_server_1 (test.test_asyncio.test_sslproto.ProactorStartTLSTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_asyncio\test_sslproto.py", line 285, in test_start_tls_server_1
    asyncio.wait_for(main(), loop=self.loop, timeout=10))
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\asyncio\base_events.py", line 436, in run_until_complete
    return future.result()
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\asyncio\tasks.py", line 406, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError

======================================================================
ERROR: test_start_tls_client_1 (test.test_asyncio.test_sslproto.SelectorStartTLSTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_asyncio\test_sslproto.py", line 225, in test_start_tls_client_1
    asyncio.wait_for(client(srv.addr), loop=self.loop, timeout=10))
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\asyncio\base_events.py", line 436, in run_until_complete
    return future.result()
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\asyncio\tasks.py", line 406, in wait_for
    raise futures.TimeoutError()
concurrent.futures._base.TimeoutError

======================================================================
FAIL: test_start_tls_server_1 (test.test_asyncio.test_sslproto.ProactorStartTLSTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_asyncio\functional.py", line 42, in tearDown
    self.fail('unexpected calls to loop.call_exception_handler()')
AssertionError: unexpected calls to loop.call_exception_handler()

----------------------------------------------------------------------
Ran 1651 tests in 117.209s

FAILED (failures=1, errors=3, skipped=56)

----------
components: Tests, Windows, asyncio
messages: 310576
nosy: asvetlov, paul.moore, steve.dower, tim.golden, vstinner, yselivanov, zach.ware
priority: normal
severity: normal
status: open
title: test_asyncio: TLS tests fail on "x86 Windows7" buildbot
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32645>
_______________________________________

From report at bugs.python.org  Wed Jan 24 05:10:20 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Jan 2018 10:10:20 +0000
Subject: [New-bugs-announce] [issue32646] test_asyncgen: race condition on
 test_async_gen_asyncio_gc_aclose_09(), random failure
Message-ID: <1516788620.43.0.467229070634.issue32646@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

test_asyncgen.test_async_gen_asyncio_gc_aclose_09() fails randomly. It looks like a race condition, likely related to the system load.

https://ci.appveyor.com/project/python/cpython/build/3.6build10993/job/l89045et4rmey72q

(...)
Run tests in parallel using 4 child processes
(...)
test_async_gen_asyncio_gc_aclose_09 (test.test_asyncgen.AsyncGenAsyncioTest) ... Task was destroyed but it is pending!
task: <Task pending coro=<async_generator_athrow()> wait_for=<Future finished result=None>>
FAIL

======================================================================
FAIL: test_async_gen_asyncio_gc_aclose_09 (test.test_asyncgen.AsyncGenAsyncioTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\projects\cpython\lib\test\test_asyncgen.py", line 630, in test_async_gen_asyncio_gc_aclose_09
    self.assertEqual(DONE, 1)
AssertionError: 0 != 1
----------------------------------------------------------------------

(...)

Re-running test 'test_asyncgen' in verbose mode
(...)
test_async_gen_asyncio_gc_aclose_09 (test.test_asyncgen.AsyncGenAsyncioTest) ... ok
(...)
Ran 40 tests in 1.125s

----------
components: asyncio
messages: 310580
nosy: asvetlov, vstinner, yselivanov
priority: normal
severity: normal
status: open
title: test_asyncgen: race condition on test_async_gen_asyncio_gc_aclose_09(), random failure
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32646>
_______________________________________

From report at bugs.python.org  Wed Jan 24 05:27:29 2018
From: report at bugs.python.org (Charalampos Stratakis)
Date: Wed, 24 Jan 2018 10:27:29 +0000
Subject: [New-bugs-announce] [issue32647] Undefined references when
 compiling ctypes
Message-ID: <1516789649.91.0.467229070634.issue32647@psf.upfronthosting.co.za>


New submission from Charalampos Stratakis <cstratak at redhat.com>:

Original bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1537489

As soon as strict symbol checking was enabled on the development branch of Fedora, our build of CPython started failing due to undefined symbols when compiling ctypes.

Build log is attached.

That seems to be because ctypes are not explicitly linked against -ldl.

This can be fixed by adding the -ldl flag at https://github.com/python/cpython/blob/master/setup.py#L1935 , not sure though how portable that is.

----------
files: build.log
messages: 310583
nosy: cstratak
priority: normal
severity: normal
status: open
title: Undefined references when compiling ctypes
versions: Python 3.6, Python 3.7, Python 3.8
Added file: https://bugs.python.org/file47407/build.log

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32647>
_______________________________________

From report at bugs.python.org  Wed Jan 24 05:52:36 2018
From: report at bugs.python.org (=?utf-8?q?R=C3=B3bert_Lexmann?=)
Date: Wed, 24 Jan 2018 10:52:36 +0000
Subject: [New-bugs-announce] [issue32648] Wrong byte count with struct
Message-ID: <1516791156.25.0.467229070634.issue32648@psf.upfronthosting.co.za>


New submission from R?bert Lexmann <robo.lexmann at gmail.com>:

struct.pack('id',a,b) returns 16 bytes, should return 4+8=12 bytes. struct.calcsize('id') also returns 16.

----------
messages: 310584
nosy: R?bert Lexmann
priority: normal
severity: normal
status: open
title: Wrong byte count with struct
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32648>
_______________________________________

From report at bugs.python.org  Wed Jan 24 08:02:30 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Wed, 24 Jan 2018 13:02:30 +0000
Subject: [New-bugs-announce] [issue32649] complete C API doc debug and
 profile part with new PyTrace_OPCODE
Message-ID: <1516798950.57.0.467229070634.issue32649@psf.upfronthosting.co.za>


New submission from Xiang Zhang <angwerzx at 126.com>:

As the title, the new PyTrace_OPCODE event is not documented in C API doc yet.

----------
assignee: docs at python
components: Documentation
messages: 310588
nosy: docs at python, ncoghlan, pablogsal, xiang.zhang
priority: normal
severity: normal
status: open
title: complete C API doc debug and profile part with new PyTrace_OPCODE
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32649>
_______________________________________

From report at bugs.python.org  Wed Jan 24 10:08:43 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 24 Jan 2018 15:08:43 +0000
Subject: [New-bugs-announce] [issue32650] Debug support for native
 coroutines is broken
Message-ID: <1516806523.55.0.467229070634.issue32650@psf.upfronthosting.co.za>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

pdb (and other Python debuggers) are built on top of bdb.py module.

The module has a support for stepping to next line in function (next command).

The command checks frame flags and do extra steps if the flags contains CO_GENERATOR.

But CO_COROUTINE is not supported, it leads to stepping into a native coroutine instead of expecting stepping over.

The patch should be relative simple: just add a check for CO_COROUTINE along with CO_GENERATOR everywhere.

----------
messages: 310600
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Debug support for native coroutines is broken
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32650>
_______________________________________

From report at bugs.python.org  Wed Jan 24 10:37:19 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 24 Jan 2018 15:37:19 +0000
Subject: [New-bugs-announce] [issue32651] os.getlogin() should recommend
 getpass.getuser()
Message-ID: <1516808239.87.0.467229070634.issue32651@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

The documentation for os.getlogin() says:

"Return the name of the user logged in on the controlling terminal of the process. For most purposes, it is more useful to use the environment variables LOGNAME or USERNAME to find out who the user is, or pwd.getpwuid(os.getuid())[0] to get the login name of the current real user id.

Availability: Unix, Windows."

Well, why not suggestion getpass.getuser() since that's exactly how the latter works? :)

----------
assignee: barry
components: Documentation
messages: 310601
nosy: barry
priority: normal
severity: normal
status: open
title: os.getlogin() should recommend getpass.getuser()
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32651>
_______________________________________

From report at bugs.python.org  Wed Jan 24 11:35:34 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Jan 2018 16:35:34 +0000
Subject: [New-bugs-announce] [issue32652] test_distutils: BuildRpmTestCase
 tests fail on RHEL buildbots
Message-ID: <1516811734.58.0.467229070634.issue32652@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

It may be a regression introduced by commit 8ded5b803705328749622256701b3f08a9d6c5ab, bpo-32030: "Add _PyCoreConfig.module_search_paths", since it's the only change of the failing build 577.

s390x RHEL 3.x5:

http://buildbot.python.org/all/#/builders/21/builds/577

======================================================================
ERROR: test_no_optimize_flag (distutils.tests.test_bdist_rpm.BuildRpmTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z/build/Lib/distutils/tests/test_bdist_rpm.py", line 120, in test_no_optimize_flag
    cmd.run()
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z/build/Lib/distutils/command/bdist_rpm.py", line 366, in run
    self.spawn(rpm_cmd)
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z/build/Lib/distutils/cmd.py", line 365, in spawn
    spawn(cmd, search_path, dry_run=self.dry_run)
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z/build/Lib/distutils/spawn.py", line 36, in spawn
    _spawn_posix(cmd, search_path, dry_run=dry_run)
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z/build/Lib/distutils/spawn.py", line 159, in _spawn_posix
    % (cmd, exit_status))
distutils.errors.DistutilsExecError: command 'rpmbuild' failed with exit status 1

======================================================================
ERROR: test_quiet (distutils.tests.test_bdist_rpm.BuildRpmTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z/build/Lib/distutils/tests/test_bdist_rpm.py", line 77, in test_quiet
    cmd.run()
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z/build/Lib/distutils/command/bdist_rpm.py", line 366, in run
    self.spawn(rpm_cmd)
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z/build/Lib/distutils/cmd.py", line 365, in spawn
    spawn(cmd, search_path, dry_run=self.dry_run)
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z/build/Lib/distutils/spawn.py", line 36, in spawn
    _spawn_posix(cmd, search_path, dry_run=dry_run)
  File "/home/dje/cpython-buildarea/3.x.edelsohn-rhel-z/build/Lib/distutils/spawn.py", line 159, in _spawn_posix
    % (cmd, exit_status))
distutils.errors.DistutilsExecError: command 'rpmbuild' failed with exit status 1

----------
components: Tests
messages: 310614
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_distutils: BuildRpmTestCase tests fail on RHEL buildbots
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32652>
_______________________________________

From report at bugs.python.org  Wed Jan 24 11:44:23 2018
From: report at bugs.python.org (Timur Irmatov)
Date: Wed, 24 Jan 2018 16:44:23 +0000
Subject: [New-bugs-announce] [issue32653] AttributeError: 'Task' object has
 no attribute '_callbacks'
Message-ID: <1516812263.42.0.467229070634.issue32653@psf.upfronthosting.co.za>


New submission from Timur Irmatov <irmatov at gmail.com>:

Sometimes during shutdown of our simple http server based on asyncio/ aiohttp we get following stack trace:

ERROR    [2018-01-24 08:28:33,398]: Exception in default exception handler while handling an unexpected error in custom exception handler
Traceback (most recent call last):
  File "/opt/alt/python35/lib64/python3.5/asyncio/base_events.py", line 1293, in call_exception_handler
    self._exception_handler(self, context)
  File "/opt/alt/python35/bin/imunify360-captchaserver", line 640, in _error_handler
    loop.default_exception_handler(context)
  File "/opt/alt/python35/lib64/python3.5/asyncio/base_events.py", line 1256, in default_exception_handler
    value = repr(value)
  File "/opt/alt/python35/lib64/python3.5/asyncio/futures.py", line 213, in __repr__
    info = self._repr_info()
  File "/opt/alt/python35/lib64/python3.5/asyncio/tasks.py", line 96, in _repr_info
    info = super()._repr_info()
  File "/opt/alt/python35/lib64/python3.5/asyncio/futures.py", line 205, in _repr_info
    if self._callbacks:
AttributeError: 'Task' object has no attribute '_callbacks'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/opt/alt/python35/lib64/python3.5/asyncio/base_events.py", line 1301, in call_exception_handler
    'context': context,
  File "/opt/alt/python35/lib64/python3.5/asyncio/base_events.py", line 1256, in default_exception_handler
    value = repr(value)
  File "/opt/alt/python35/lib64/python3.5/asyncio/futures.py", line 213, in __repr__
    info = self._repr_info()
  File "/opt/alt/python35/lib64/python3.5/asyncio/tasks.py", line 96, in _repr_info
    info = super()._repr_info()
  File "/opt/alt/python35/lib64/python3.5/asyncio/futures.py", line 205, in _repr_info
    if self._callbacks:
AttributeError: 'Task' object has no attribute '_callbacks'

Is this some bug or consequence of our code not cancelling/ waiting for all coroutines?

----------
components: asyncio
messages: 310616
nosy: Timur Irmatov, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: AttributeError: 'Task' object has no attribute '_callbacks'
type: behavior
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32653>
_______________________________________

From report at bugs.python.org  Wed Jan 24 12:31:20 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 24 Jan 2018 17:31:20 +0000
Subject: [New-bugs-announce] [issue32654] Fixes Python for Android API 19
Message-ID: <1516815080.83.0.467229070634.issue32654@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

I'm working on a pull request to make https://github.com/pmp-p/droid-pydk/tree/master/sources.32/cpython-bpo-30386.patchset changes upstream.

----------
messages: 310619
nosy: vstinner
priority: normal
severity: normal
status: open
title: Fixes Python for Android API 19
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32654>
_______________________________________

From report at bugs.python.org  Wed Jan 24 12:31:36 2018
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0LDRgiDQndCw0LPQsNC10LI=?=)
Date: Wed, 24 Jan 2018 17:31:36 +0000
Subject: [New-bugs-announce] [issue32655] File mode shou
Message-ID: <1516815096.3.0.467229070634.issue32655@psf.upfronthosting.co.za>


Change by ????? ?????? <sidorovmarat1995 at gmail.com>:


----------
components: IO
nosy: nagayev
priority: normal
severity: normal
status: open
title: File mode shou
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32655>
_______________________________________

From report at bugs.python.org  Wed Jan 24 15:54:41 2018
From: report at bugs.python.org (David Albert Torpey)
Date: Wed, 24 Jan 2018 20:54:41 +0000
Subject: [New-bugs-announce] [issue32656] writing to stdout prints
 extraneous size character
Message-ID: <1516827281.38.0.467229070634.issue32656@psf.upfronthosting.co.za>


New submission from David Albert Torpey <dtorp at users.sourceforge.net>:

$ python3.5
Python 3.5.3 (v3.5.3:1880cb95a742, Jan 16 2017, 08:49:46)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.stdout.write('python')
python6

----------
messages: 310631
nosy: dtorp
priority: normal
severity: normal
status: open
title: writing to stdout prints extraneous size character
versions: Python 3.5

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32656>
_______________________________________

From report at bugs.python.org  Wed Jan 24 17:44:57 2018
From: report at bugs.python.org (Kenny Trytek)
Date: Wed, 24 Jan 2018 22:44:57 +0000
Subject: [New-bugs-announce] [issue32657] Mutable Objects in SMTP
 send_message Signature
Message-ID: <1516833897.61.0.467229070634.issue32657@psf.upfronthosting.co.za>


New submission from Kenny Trytek <kenny.trytek at workiva.com>:

Mutable arguments in signature of send_message:
https://github.com/python/cpython/blob/master/Lib/smtplib.py#L892-L893

More Information:
http://docs.python-guide.org/en/latest/writing/gotchas/#mutable-default-arguments

----------
components: Library (Lib)
messages: 310641
nosy: Kenny Trytek
priority: normal
severity: normal
status: open
title: Mutable Objects in SMTP send_message Signature
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32657>
_______________________________________

From report at bugs.python.org  Wed Jan 24 19:01:01 2018
From: report at bugs.python.org (Kevin Raeder)
Date: Thu, 25 Jan 2018 00:01:01 +0000
Subject: [New-bugs-announce] [issue32658] Metacharacter (\) documentation
 suggestion
Message-ID: <1516838461.29.0.467229070634.issue32658@psf.upfronthosting.co.za>


New submission from Kevin Raeder <raeder at ucar.edu>:

I've found the Regular Expression HOWTO to be very helpful
(https://docs.python.org/3/howto/regex.html?highlight=regular%20expressions). 
One inconsistency I noticed is that the intro to metacharacters says
"Metacharacters are not active inside classes. "
But farther down we learn that a class can be constructed using \s: [\s,.],
which is "all white space characters , and ."
It's not the 4 characters "\ s , and ."
So I think the first statement would be clearer as
"Metacharacters (except \) are not active inside classes. "

----------
assignee: docs at python
components: Documentation
messages: 310647
nosy: docs at python, kdraeder
priority: normal
severity: normal
status: open
title: Metacharacter (\) documentation suggestion

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32658>
_______________________________________

From report at bugs.python.org  Wed Jan 24 19:46:54 2018
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 25 Jan 2018 00:46:54 +0000
Subject: [New-bugs-announce] [issue32659] Solaris "stat" should support
 "st_fstype"
Message-ID: <1516841214.25.0.467229070634.issue32659@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n <jcea at jcea.es>:

Solaris has an extra "st_fstype" in the "stat" structure:

"""
       st_fstype
                     A null-teminated string that uniquely identifies the type
                     of the filesystem that contains the file.
"""

Supporting this should be trivial and 3.7RC1 is still a week away. I can take care of the patch for Python 3.7, if you agree that this must be fixed.

----------
assignee: jcea
messages: 310650
nosy: jcea
priority: normal
severity: normal
stage: needs patch
status: open
title: Solaris "stat" should support "st_fstype"
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32659>
_______________________________________

From report at bugs.python.org  Wed Jan 24 19:56:59 2018
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 25 Jan 2018 00:56:59 +0000
Subject: [New-bugs-announce] [issue32660] Solaris should support constants
 like termios' FIONREAD
Message-ID: <1516841819.51.0.467229070634.issue32660@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n <jcea at jcea.es>:

Solaris supports termios constants like FIONREAD with an appropiate "#include" in the C code. The main issue is that some names conflicts between System V and BSD personalities.

I could evaluate the situation and do a patch proposal for Python 3.7. We are still a week away of 3.7RC1 and this patch would affect only Solaris/derivatives.

----------
assignee: jcea
messages: 310651
nosy: jcea
priority: normal
severity: normal
stage: needs patch
status: open
title: Solaris should support constants like termios' FIONREAD
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32660>
_______________________________________

From report at bugs.python.org  Wed Jan 24 22:24:15 2018
From: report at bugs.python.org (Roger Taylor)
Date: Thu, 25 Jan 2018 03:24:15 +0000
Subject: [New-bugs-announce] [issue32661] ProactorEventLoop locks up on
 close call
Message-ID: <1516850655.32.0.467229070634.issue32661@psf.upfronthosting.co.za>


New submission from Roger Taylor <roger.taylor.email at gmail.com>:

The following problem only occurs when I use ProactorEventLoop.  If I use 'asyncio.get_event_loop()' it exits normally, rather than infinite looping in IOCP land.

1. I run the attached 'bug.py' script in a DOS window.  It is a slightly modified version of the asyncio echo server example.
2. It reaches 'loop.run_forever()' and blocks.  I can make connections here and use it as an echo server.  Or make no connections.
3. I press Ctrl-C in the DOS window.  Nothing happens.
4. I do a raw connection with Putty and try some input.
5. 'run_forever()' exits and the script proceeds to the 'loop.close()' call.  Before this is invoked and the infinite loop entered, I see the script output '<ProactorEventLoop running=False closed=False debug=False>'.

At this point, the script locks up and never reaches the next line.  It can be interrupted with another Ctrl-C, and the following stack track is seen:

	Traceback (most recent call last):
	  File "bug.py", line 39, in <module>
		loop.close()
	  File "C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python36_64\lib\asyncio\proactor_events.py", line 437, in close
		self._proactor.close()
	  File "C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python36_64\lib\asyncio\windows_events.py", line 745, in close
		if not self._poll(1):
	  File "C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python36_64\lib\asyncio\windows_events.py", line 673, in _poll
		status = _overlapped.GetQueuedCompletionStatus(self._iocp, ms)
	KeyboardInterrupt

The following code in 'windows_events.py:IocpProactor.close' is looping infinitely.

        while self._cache:
            if not self._poll(1):
                logger.debug('taking long time to close proactor')

Note that '_poll' does not actually return anything.

----------
components: asyncio
files: bug.py
messages: 310655
nosy: asvetlov, rt121212121, yselivanov
priority: normal
severity: normal
status: open
title: ProactorEventLoop locks up on close call
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file47408/bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32661>
_______________________________________

From report at bugs.python.org  Thu Jan 25 01:44:24 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 25 Jan 2018 06:44:24 +0000
Subject: [New-bugs-announce] [issue32662] Implement Server.serve_forever and
 corresponding APIs
Message-ID: <1516862664.59.0.467229070634.issue32662@psf.upfronthosting.co.za>


New submission from Yury Selivanov <yselivanov at gmail.com>:

As discussed, we want to make Server objects more usable in async/await code and more compatible with asyncio.run.

This is also needed to handle a use case when two or more servers are created and need to start listening at the same time.

We propose to:

1. Add a new bool flag defaulting to True to loop.create_server and loop.create_unix_server: start_serving.  By default, loop will return a server that is already accepting connections.  When start_serving is set to False, create_server and create_unix_server will return a server that will not listen on its sockets.

2. A new idempotent Server.start_serving() method can be used to make server listen on its sockets (useful when a server object was created with start_serving=False).

3. A new Server.serve_forever() method that calls start_serving() and blocks forever, until cancelled.  When cancelled, it closes its server object.

4. A new Server.is_serving() method.  This is useful to introspect a server object in unittests.

5. Server objects should be async context managers.  Server.__aexit__ should close the server and await on Server.wait_closed().

With these new APIs, the following pattern becomes possible:

    async def main():
        srv = await asyncio.start_server(...)
        async with srv:
            await srv.serve_forever()

    asyncio.run(main())

----------
components: asyncio
messages: 310657
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Implement Server.serve_forever and corresponding APIs
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32662>
_______________________________________

From report at bugs.python.org  Thu Jan 25 03:41:56 2018
From: report at bugs.python.org (Chason Chaffin)
Date: Thu, 25 Jan 2018 08:41:56 +0000
Subject: [New-bugs-announce] [issue32663] SMTPUTF8SimTests are not actually
 being run
Message-ID: <1516869716.21.0.467229070634.issue32663@psf.upfronthosting.co.za>


New submission from Chason Chaffin <chason at gmail.com>:

In the tests for smtplib, the suite of tests for SMTPUTF8SimTests (added by issue 24218)  are not actually being run. This is troublesome in particular, because the test test_send_message_error_on_non_ascii_addrs_if_no_smtputf8 calls assertRaises incorrectly and thus fails.

----------
components: Tests
messages: 310664
nosy: chason
priority: normal
severity: normal
status: open
title: SMTPUTF8SimTests are not actually being run
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32663>
_______________________________________

From report at bugs.python.org  Thu Jan 25 03:54:10 2018
From: report at bugs.python.org (Richard Neumann)
Date: Thu, 25 Jan 2018 08:54:10 +0000
Subject: [New-bugs-announce] [issue32664] Connector "|" missing between
 ImportError and LookupError
Message-ID: <1516870450.69.0.467229070634.issue32664@psf.upfronthosting.co.za>


New submission from Richard Neumann <r.neumann at homeinfo.de>:

In the documentation of the built-in exceptions hierarchy, there is a "|" missing connecting ImportError and LookupError.

https://docs.python.org/3/library/exceptions.html#exception-hierarchy

>From LookupError.__mro__ we can tell, that it is actually derived from Exception, thus there should be a "|" connecting it to the hierarchy under Exception to emphasize that (like between ArithmeticError and AssertionError).

----------
assignee: docs at python
components: Documentation
messages: 310666
nosy: Richard Neumann, docs at python
priority: normal
severity: normal
status: open
title: Connector "|"  missing between ImportError and LookupError
type: enhancement
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32664>
_______________________________________

From report at bugs.python.org  Thu Jan 25 07:27:25 2018
From: report at bugs.python.org (qb-cea)
Date: Thu, 25 Jan 2018 12:27:25 +0000
Subject: [New-bugs-announce] [issue32665] pathlib.Path._from_parsed_parts
 should call cls.__new__(cls)
Message-ID: <1516883245.2.0.467229070634.issue32665@psf.upfronthosting.co.za>


New submission from qb-cea <quentin.bouget at cea.fr>:

Hi,

I tried subclassing pathlib.Path and provide it with a new attribute (basically an accessor to an extended attribute). I am rather new to the concept of __slots__ and __new__() but here is how I pictured it should look:

from errno import ENODATA
from os import getxattr, setxattr
from pathlib import Path

class Path_(type(Path())):

    __slots__ = ("new_attr",)

    def __new__(cls, *args, new_attr=None, **kwargs):
        self = super().__new__(cls, *args, **kwargs)
        self._new_attr = new_attr
        return self

    @property
    def new_attr(self):
        if self._new_attr:
            return self._new_attr

        try:
            new_attr = getxattr(self, "user.new_attr")
        except OSError as exc:
            if exc.errno != ENODATA:
                raise exc
        else:
            self._new_attr = new_attr
            return new_attr

        new_attr = b"something_dynamic" # for example uuid4().bytes
        setxattr(self, "user.new_attr", new_attr)
        self._new_attr = new_attr
        return new_attr

The issue I have is that although my class defines its own __new__() method, it is not always called by the methods of pathlib.Path. For example:

>>> Path_("/etc").parent.new_attr
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/path/to/reproducer.py", line 19, in new_attr
    if self._new_attr:
AttributeError: _new_attr

The current workaround I use consists in redefining pathlib.Path's _from_parsed_parts() method in my class: instead of creating a new object using:
    object.__new__(cls)
my implementation uses:
    cls.__new__(cls)

This is the first time I play with the __new__() special method, so it is possible I missed something, if so, sorry for the noise.

----------
components: Library (Lib)
files: reproducer.py
messages: 310671
nosy: pitrou, qb-cea
priority: normal
severity: normal
status: open
title: pathlib.Path._from_parsed_parts should call cls.__new__(cls)
versions: Python 3.6
Added file: https://bugs.python.org/file47409/reproducer.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32665>
_______________________________________

From report at bugs.python.org  Thu Jan 25 08:29:45 2018
From: report at bugs.python.org (Reuben Thomas)
Date: Thu, 25 Jan 2018 13:29:45 +0000
Subject: [New-bugs-announce] [issue32666] Valgrind documentation seems to
 need updating
Message-ID: <1516886985.24.0.467229070634.issue32666@psf.upfronthosting.co.za>


New submission from Reuben Thomas <rrt at sc3d.org>:

I have just been trying to use Valgrind (in my case, to debug code in a library being tested via a Cython module).

It is working fine, but there seem to be some discrepancies between the documentation in README.valgrind and valgrind-python.supp on the one hand, and the actual code on the other.

README.Valgrind says (current git master):

Second, you must do one of the following:

  * Uncomment Py_USING_MEMORY_DEBUGGER in Objects/obmalloc.c,
    then rebuild Python
  * Uncomment the lines in Misc/valgrind-python.supp that
    suppress the warnings for PyObject_Free and PyObject_Realloc

However, Objects/objmalloc.c no longer contain this symbol (though Python/dtoa.c does).

Further, in https://bugs.python.org/issue31494 I find the following comment:

Also, I don't think --with-pydebug works well with valgrind.

It's either:
   1) --with-pydebug
   2) CFLAGS="-O0 -g" --with-valgrind
   3) CFLAGS="-O0 -g" --without-pymalloc

Combining 2) and 3) probably does not hurt, but is not necessary.

It would be useful to have this information in README.valgrind.

Also, the provided suppressions do not currently work with a normal build of Python, at least with Python 2.7 (with the PyObject_{Free,Realloc} suppressions uncommented). There seem to be at least two problems:

1. Extra symbols from LTO. This can be fixed by adding "*" to PyObject_Realloc in all its suppressions.

2. After fixing that, I still get one more "Invalid read of size 4":

==3227== Invalid read of size 4
==3227==    at 0x4FCEE2: long_dealloc.lto_priv.323 (abstract.c:2000)
==3227==    by 0x4BA22B: frame_dealloc (frameobject.c:458)
==3227==    by 0x4BA22B: PyEval_EvalCodeEx (ceval.c:3593)
==3227==    by 0x4C16E6: fast_function (ceval.c:4445)
==3227==    by 0x4C16E6: call_function (ceval.c:4370)

I can't see how this is related to any existing suppression.

I am using the stock Python 2.7 on Ubuntu 16.04. I find that I can work around both the above problems (that is, use the suppressions file as-is, just uncommenting the extra suppressions for PyObject_{Free,Realloc}) by using Ubuntu's debug build of Python (installed as /usr/bin/python-dbg). It is built with --with-pydebug.

Finally, README.valgrind says: "Valgrind is used periodically by Python developers to try to ensure there are no memory leaks or invalid memory reads/writes." Another reason to use Valgrind is, as in my case, to debug unrelated C code that is being run via Python (this is often a convenient way to write tests). I suggest deleting this sentence and making it more obvious how to simply make Python "transparent to Valgrind" for those trying to debug C libraries.

To summarise:

i. It seems that for current Python 3, this text:

  * Uncomment Py_USING_MEMORY_DEBUGGER in Objects/obmalloc.c,
    then rebuild Python

needs to be updated.

ii. For Python 2.7 at least, and possibly Python 3, extra suppressions are needed to use a standard build.

iii. It would be good to have the specific build advice from https://bugs.python.org/issue31494 in README.valgrind.

iv. It would be nice to clarify how to use a normal build of Python (e.g. by splitting the advice into "For Python developers" and "For Python users").

Given some guidance on what is correct, and what is desired/acceptable, I'd be happy to work up a patch to README.valgrind and valgrind-python.supp.

----------
assignee: docs at python
components: Documentation
messages: 310673
nosy: docs at python, rrt
priority: normal
severity: normal
status: open
title: Valgrind documentation seems to need updating
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32666>
_______________________________________

From report at bugs.python.org  Thu Jan 25 10:12:46 2018
From: report at bugs.python.org (Jay Yin)
Date: Thu, 25 Jan 2018 15:12:46 +0000
Subject: [New-bugs-announce] [issue32667] Failing test_dtrace and
 test_subprocess on Ubuntu 16.04 on master
Message-ID: <1516893166.92.0.467229070634.issue32667@psf.upfronthosting.co.za>


New submission from Jay Yin <jayyin11043 at gmail.com>:

Hello everyone,


I've been trying to build the master branch on Ubuntu 16.04 and it currently fails 2 test, I was wondering if this was normal or if I'm missing dependencies, I also tried apt-get build-dev python3.6 and python3.7 to no avail, the build requirements install worked for python3.5 but I suspect 3.7 has different dependencies but I can't find where the documentation for the requirements are. 
2 tests failed:
    test_dtrace test_subprocess


running test_dtrace as verbose gave https://pastebin.com/ZGzzxwjk
	
[Bash] FAILED (errors=4) test test_dtrace failed 1 test failed: test_dtrace R - Pastebin.com
pastebin.com


and running test_subprocess gives


https://pastebin.com/DNjPzpgp

----------
messages: 310678
nosy: jayyin11043
priority: normal
severity: normal
status: open
title: Failing test_dtrace and test_subprocess on Ubuntu 16.04 on master
type: compile error
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32667>
_______________________________________

From report at bugs.python.org  Thu Jan 25 11:39:40 2018
From: report at bugs.python.org (Martin Kolman)
Date: Thu, 25 Jan 2018 16:39:40 +0000
Subject: [New-bugs-announce] [issue32668] deepcopy() fails on ArgumentParser
 instances
Message-ID: <1516898380.94.0.467229070634.issue32668@psf.upfronthosting.co.za>


New submission from Martin Kolman <mkolman at redhat.com>:

We (the Anaconda OS intaller team) are in the process of switching to a new version of a library (Pykickstart), which among other things switched from using optparse to argparse. And during this endeavour we found that it's apparently not possible to deepcopy ArgumentParser instances:


$ ipython3
Python 3.6.3 (default, Oct  9 2017, 12:07:10) 
Type 'copyright', 'credits' or 'license' for more information
IPython 6.2.1 -- An enhanced Interactive Python. Type '?' for help.

In [1]: import argparse

In [2]: from copy import deepcopy

In [3]: parser = argparse.ArgumentParser()

In [4]: deepcopy(parser)
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-4-53dc517e3ecc> in <module>()
----> 1 deepcopy(parser)

/usr/lib64/python3.6/copy.py in deepcopy(x, memo, _nil)
    178                     y = x
    179                 else:
--> 180                     y = _reconstruct(x, memo, *rv)
    181 
    182     # If is its own copy, don't memoize.

/usr/lib64/python3.6/copy.py in _reconstruct(x, memo, func, args, state, listiter, dictiter, deepcopy)
    278     if state is not None:
    279         if deep:
--> 280             state = deepcopy(state, memo)
    281         if hasattr(y, '__setstate__'):
    282             y.__setstate__(state)

/usr/lib64/python3.6/copy.py in deepcopy(x, memo, _nil)
    148     copier = _deepcopy_dispatch.get(cls)
    149     if copier:
--> 150         y = copier(x, memo)
    151     else:
    152         try:

/usr/lib64/python3.6/copy.py in _deepcopy_dict(x, memo, deepcopy)
    238     memo[id(x)] = y
    239     for key, value in x.items():
--> 240         y[deepcopy(key, memo)] = deepcopy(value, memo)
    241     return y
    242 d[dict] = _deepcopy_dict

/usr/lib64/python3.6/copy.py in deepcopy(x, memo, _nil)
    148     copier = _deepcopy_dispatch.get(cls)
    149     if copier:
--> 150         y = copier(x, memo)
    151     else:
    152         try:

/usr/lib64/python3.6/copy.py in _deepcopy_list(x, memo, deepcopy)
    213     append = y.append
    214     for a in x:
--> 215         append(deepcopy(a, memo))
    216     return y
    217 d[list] = _deepcopy_list

/usr/lib64/python3.6/copy.py in deepcopy(x, memo, _nil)
    178                     y = x
    179                 else:
--> 180                     y = _reconstruct(x, memo, *rv)
    181 
    182     # If is its own copy, don't memoize.

/usr/lib64/python3.6/copy.py in _reconstruct(x, memo, func, args, state, listiter, dictiter, deepcopy)
    278     if state is not None:
    279         if deep:
--> 280             state = deepcopy(state, memo)
    281         if hasattr(y, '__setstate__'):
    282             y.__setstate__(state)

/usr/lib64/python3.6/copy.py in deepcopy(x, memo, _nil)
    148     copier = _deepcopy_dispatch.get(cls)
    149     if copier:
--> 150         y = copier(x, memo)
    151     else:
    152         try:

/usr/lib64/python3.6/copy.py in _deepcopy_dict(x, memo, deepcopy)
    238     memo[id(x)] = y
    239     for key, value in x.items():
--> 240         y[deepcopy(key, memo)] = deepcopy(value, memo)
    241     return y
    242 d[dict] = _deepcopy_dict

/usr/lib64/python3.6/copy.py in deepcopy(x, memo, _nil)
    178                     y = x
    179                 else:
--> 180                     y = _reconstruct(x, memo, *rv)
    181 
    182     # If is its own copy, don't memoize.

/usr/lib64/python3.6/copy.py in _reconstruct(x, memo, func, args, state, listiter, dictiter, deepcopy)
    278     if state is not None:
    279         if deep:
--> 280             state = deepcopy(state, memo)
    281         if hasattr(y, '__setstate__'):
    282             y.__setstate__(state)

/usr/lib64/python3.6/copy.py in deepcopy(x, memo, _nil)
    148     copier = _deepcopy_dispatch.get(cls)
    149     if copier:
--> 150         y = copier(x, memo)
    151     else:
    152         try:

/usr/lib64/python3.6/copy.py in _deepcopy_dict(x, memo, deepcopy)
    238     memo[id(x)] = y
    239     for key, value in x.items():
--> 240         y[deepcopy(key, memo)] = deepcopy(value, memo)
    241     return y
    242 d[dict] = _deepcopy_dict

/usr/lib64/python3.6/copy.py in deepcopy(x, memo, _nil)
    159             copier = getattr(x, "__deepcopy__", None)
    160             if copier:
--> 161                 y = copier(memo)
    162             else:
    163                 reductor = dispatch_table.get(cls)

TypeError: cannot deepcopy this pattern object


This should either be fixed or documented in proper places (the argparse documentation does not mention any pottential deepcopy issues as far as we can tell).

----------
components: Library (Lib)
messages: 310686
nosy: mkolman
priority: normal
severity: normal
status: open
title: deepcopy() fails on ArgumentParser instances
type: crash
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32668>
_______________________________________

From report at bugs.python.org  Thu Jan 25 14:03:08 2018
From: report at bugs.python.org (steven Michalske)
Date: Thu, 25 Jan 2018 19:03:08 +0000
Subject: [New-bugs-announce] [issue32669] cgitb file to print OSError
 exceptions
Message-ID: <1516906988.26.0.467229070634.issue32669@psf.upfronthosting.co.za>


New submission from steven Michalske <smichalske at gmail.com>:

With the source

```
import cgitb
import sys

try:
    f = open('non_exitant_file_path.foo')
except Exception as e:
    cgitb.text(sys.exc_info())
```

we get the output

```
Traceback (most recent call last):
  File "foo.py", line 22, in <module>
    f = open('non_exitant_file_path.foo')
FileNotFoundError: [Errno 2] No such file or directory: 'non_exitant_file_path.foo'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "foo.py", line 24, in <module>
    cgitb.text(sys.exc_info())
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/cgitb.py", line 245, in text
    value = pydoc.text.repr(getattr(evalue, name))
AttributeError: characters_written
```

In bug #30554 it was brought up that there are attributes designed as invariant os some other as designed behavior.  Unfortunately it was closed "as designed" 

So this means that cgitb has a bug when text formatting a sys_exc traceback of an OSError.

This is hidden in the by the hook with this code form cgitb.py
by falling back to the standard formatter...

line 277
```
        try:
            doc = formatter(info, self.context)
        except:                         # just in case something goes wrong
            doc = ''.join(traceback.format_exception(*info))
            plain = True
```

----------
messages: 310702
nosy: hardkrash
priority: normal
severity: normal
status: open
title: cgitb file to print OSError exceptions
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32669>
_______________________________________

From report at bugs.python.org  Thu Jan 25 16:50:49 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Thu, 25 Jan 2018 21:50:49 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue32670=5D_Enforce_PEP_479?=
 =?utf-8?q?=E2=80=94StopIteration_and_generators=E2=80=94in_Python_3=2E7_b?=
 =?utf-8?q?y_default?=
Message-ID: <1516917049.09.0.467229070634.issue32670@psf.upfronthosting.co.za>


New submission from Yury Selivanov <yselivanov at gmail.com>:

As per PEP 479, in Python 3.7 it should be a RuntimeError when a StopIteration exception is raised manually in a generator, a coroutine, or an async generator.

----------
assignee: yselivanov
components: Interpreter Core
messages: 310712
nosy: gvanrossum, ncoghlan, ned.deily, yselivanov
priority: release blocker
severity: normal
status: open
title: Enforce PEP 479?StopIteration and generators?in Python 3.7 by default
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32670>
_______________________________________

From report at bugs.python.org  Thu Jan 25 20:17:24 2018
From: report at bugs.python.org (Eryk Sun)
Date: Fri, 26 Jan 2018 01:17:24 +0000
Subject: [New-bugs-announce] [issue32671] redesign Windows  os.getlogin,
 and add os.getuser
Message-ID: <1516929444.23.0.467229070634.issue32671@psf.upfronthosting.co.za>


New submission from Eryk Sun <eryksun at gmail.com>:

os.getlogin() is supposed to return the name of the user logged in on the "controlling terminal" of the process. Windows doesn't have POSIX terminals; however, every process does belong to a terminal/desktop session that can be connected either to the physical console or a remote desktop. A standard user can call WTSQuerySessionInformation (an RPC to the Local Session Manager) to get the user name (i.e. WTSUserName) for the current session. ISTM that this is the closest analog to POSIX getlogin() that exists in Windows.

A caveat is that session 0 ("services") is never connected to the physical console. Thus there's no associated user account name.

os.getlogin() currently calls GetUserName (an RPC to the Local Security Authority), which returns the user name from the caller's effective token. If os.getlogin() is changed to return the session user, posixmodule.c could still wrap GetUserName privately as nt._getusername(). 

If the calling thread is impersonating, nt._getusername should temporarily revert to the process token (i.e. the real user), since this will usually be consistent with USERNAME. That said, getting the effective user can be useful for logging, so there should also be an option to return the effective user instead of the real user.

Note that the user name of the SYSTEM logon (and thus the USERNAME environment variable in a SYSTEM process) is actually "%COMPUTERNAME%$". It's noteworthy that GetUserName instead returns "SYSTEM" for this case. The "NETWORK SERVICE" logon also uses "%COMPUTERNAME%$", but in this case GetUserName returns "%COMPUTERNAME%$" instead of "NETWORK SERVICE".

A pair of high-level Python functions named getuser() and geteuser() could be added in os.py. These functions would return the real and effective user name of the caller, respectively. In Windows, os.getuser() would return the USERNAME environment variable and otherwise fall back on nt._getusername(). In POSIX, it would return the value of the first defined variable among LOGNAME, USER, and LNAME, and otherwise fall back on pwd.getpwuid(os.getuid()).pw_name. In Windows, os.geteuser() would return nt_getusername(effective=True). In POSIX it would return pwd.getpwuid(os.geteuid()).pw_name.

Currently getpass.getuser() always looks for environment variables named LOGNAME, USER, LNAME, and finally USERNAME. This is an odd choice on Windows. I wouldn't expect Windows users to know about and respect the special status of the first 3 variable names. getpass.getuser() also falls back on using the pwd module, which is another odd choice on Windows. It isn't worth removing or modifying this function, but the docs could encourage using the proposed os.getuser() and os.geteuser() functions on Windows and new code.

----------
components: Library (Lib), Windows
messages: 310724
nosy: eryksun, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
stage: test needed
status: open
title: redesign Windows  os.getlogin, and add os.getuser
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32671>
_______________________________________

From report at bugs.python.org  Thu Jan 25 23:04:25 2018
From: report at bugs.python.org (dancollins34)
Date: Fri, 26 Jan 2018 04:04:25 +0000
Subject: [New-bugs-announce] [issue32672] .then execution of actions
 following a future's completion
Message-ID: <1516939465.12.0.467229070634.issue32672@psf.upfronthosting.co.za>


New submission from dancollins34 <dancollins34 at gmail.com>:

To my knowledge, python currently has no capability to chain future execution, requiring another future to begin executing with the result from the first.

I have submitted a pr to enable this functionality with a .then(self, fn) method on the concurrent.futures.Future object.

-dancollins34

----------
components: Interpreter Core
messages: 310730
nosy: dancollins34
priority: normal
pull_requests: 5181
severity: normal
status: open
title: .then execution of actions following a future's completion
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32672>
_______________________________________

From report at bugs.python.org  Fri Jan 26 01:10:52 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Fri, 26 Jan 2018 06:10:52 +0000
Subject: [New-bugs-announce] [issue32673] update tutorial dict part to
 reflect dict is ordered
Message-ID: <1516947052.29.0.467229070634.issue32673@psf.upfronthosting.co.za>


New submission from Xiang Zhang <angwerzx at 126.com>:

Ordered builtin dict is the rule in 3.7, the tutorial part about dict[1] needs updating.

[1] https://docs.python.org/3.7/tutorial/datastructures.html#dictionaries

----------
assignee: docs at python
components: Documentation
messages: 310737
nosy: docs at python, xiang.zhang
priority: normal
severity: normal
stage: needs patch
status: open
title: update tutorial dict part to reflect dict is ordered
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32673>
_______________________________________

From report at bugs.python.org  Fri Jan 26 01:41:42 2018
From: report at bugs.python.org (Qian Yun)
Date: Fri, 26 Jan 2018 06:41:42 +0000
Subject: [New-bugs-announce] [issue32674] minor documentation fix for
 '__import__'
Message-ID: <1516948902.25.0.467229070634.issue32674@psf.upfronthosting.co.za>


New submission from Qian Yun <oldk1331 at gmail.com>:

This is a minor documentation for builtin function '__import__'.

----------
assignee: docs at python
components: Documentation
messages: 310741
nosy: Qian Yun, docs at python
priority: normal
severity: normal
status: open
title: minor documentation fix for '__import__'
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32674>
_______________________________________

From report at bugs.python.org  Fri Jan 26 05:43:55 2018
From: report at bugs.python.org (xitop)
Date: Fri, 26 Jan 2018 10:43:55 +0000
Subject: [New-bugs-announce] [issue32675] dict.__contains__(unhashable)
 raises TypeError where False was expected
Message-ID: <1516963435.48.0.467229070634.issue32675@psf.upfronthosting.co.za>


New submission from xitop <reg.bugs at poti.sk>:

The `dict.__contains()` function does not fully comply with the description in the "Data Model" section of the official documentation, which states:
  "__contains__(self, item) ... Should return true if item is in self, false otherwise."

Basically the same is written in "Mapping Types - dict": "key in d - Return True if d has a key key, else False."

According to that, testing a presence of an unhashable object in a dict should return False. But it raises a TypeError instead.

Example:
  >>> () in {}
  False
but:
  >>> [] in {}
  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  TypeError: unhashable type: 'list'

There is a related SO question:
  https://stackoverflow.com/questions/48444079/unexpected-behaviour-of-dictionary-membership-check
currently without a clear answer whether it is a bug or desired behaviour supposed to expose programming errors. In the latter case, it seems to be not documented.

----------
components: Interpreter Core
messages: 310751
nosy: xitop
priority: normal
severity: normal
status: open
title: dict.__contains__(unhashable) raises TypeError where False was expected
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32675>
_______________________________________

From report at bugs.python.org  Fri Jan 26 06:07:29 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 26 Jan 2018 11:07:29 +0000
Subject: [New-bugs-announce] [issue32676] test_asyncio emits many warnings
 when run in debug mode
Message-ID: <1516964849.79.0.467229070634.issue32676@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

vstinner at apu$ ./python -u -X dev -m test -v test_asyncio 2>&1|tee log

Tests which emit warnings:

test__sock_sendfile_native_failure (test.test_asyncio.test_base_events.BaseLoopSendfileTests) ...
/home/vstinner/prog/python/master/Lib/asyncio/selector_events.py:648: ResourceWarning: unclosed transport <_SelectorSocketTransport fd=11>
  source=self)
ok

test_start_tls_client_1 (test.test_asyncio.test_sslproto.SelectorStartTLSTests) ...
Executing <Handle <TaskWakeupMethWrapper object at 0x7f85fab75838>(<Future finis...events.py:304>) created at /home/vstinner/prog/python/master/Lib/test/test_asyncio/test_sslproto.py:202> took 0.205 seconds
ok

test_error_in_call_soon (test.test_asyncio.test_tasks.CTaskSubclass_PyFuture_Tests) ...
<CoroWrapper BaseTaskTests.test_error_in_call_soon.<locals>.coro() running, defined at /home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py:2089, created at /home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py:2096> was never yielded from
Coroutine object created at (most recent call last, truncated to 10 last lines):
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 84, in __call__
    return self.run(*args, **kwds)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 84, in __call__
    return self.run(*args, **kwds)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/vstinner/prog/python/master/Lib/unittest/case.py", line 663, in __call__
    return self.run(*args, **kwds)
  File "/home/vstinner/prog/python/master/Lib/unittest/case.py", line 615, in run
    testMethod()
  File "/home/vstinner/prog/python/master/Lib/unittest/mock.py", line 1191, in patched
    return func(*args, **keywargs)
  File "/home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py", line 2096, in test_error_in_call_soon
    self.new_task(self.loop, coro())
ok

test_error_in_call_soon (test.test_asyncio.test_tasks.CTask_CFuture_SubclassTests) ...
<CoroWrapper BaseTaskTests.test_error_in_call_soon.<locals>.coro() running, defined at /home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py:2089, created at /home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py:2096> was never yielded from
Coroutine object created at (most recent call last, truncated to 10 last lines):
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 84, in __call__
    return self.run(*args, **kwds)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 84, in __call__
    return self.run(*args, **kwds)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/vstinner/prog/python/master/Lib/unittest/case.py", line 663, in __call__
    return self.run(*args, **kwds)
  File "/home/vstinner/prog/python/master/Lib/unittest/case.py", line 615, in run
    testMethod()
  File "/home/vstinner/prog/python/master/Lib/unittest/mock.py", line 1191, in patched
    return func(*args, **keywargs)
  File "/home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py", line 2096, in test_error_in_call_soon
    self.new_task(self.loop, coro())
ok

test_error_in_call_soon (test.test_asyncio.test_tasks.CTask_CFuture_Tests) ...
<CoroWrapper BaseTaskTests.test_error_in_call_soon.<locals>.coro() running, defined at /home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py:2089, created at /home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py:2096> was never yielded from
Coroutine object created at (most recent call last, truncated to 10 last lines):
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 84, in __call__
    return self.run(*args, **kwds)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 84, in __call__
    return self.run(*args, **kwds)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/vstinner/prog/python/master/Lib/unittest/case.py", line 663, in __call__
    return self.run(*args, **kwds)
  File "/home/vstinner/prog/python/master/Lib/unittest/case.py", line 615, in run
    testMethod()
  File "/home/vstinner/prog/python/master/Lib/unittest/mock.py", line 1191, in patched
    return func(*args, **keywargs)
  File "/home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py", line 2096, in test_error_in_call_soon
    self.new_task(self.loop, coro())
ok

test_context_3 (test.test_asyncio.test_tasks.CTask_PyFuture_Tests) ...
Executing <Handle <TaskWakeupMethWrapper object at 0x7f860261ce98>(<Future finis...events.py:304>) created at /home/vstinner/prog/python/master/Lib/asyncio/futures.py:288> took 5.753 seconds
ok

test_error_in_call_soon (test.test_asyncio.test_tasks.CTask_PyFuture_Tests) ...
<CoroWrapper BaseTaskTests.test_error_in_call_soon.<locals>.coro() running, defined at /home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py:2089, created at /home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py:2096> was never yielded from
Coroutine object created at (most recent call last, truncated to 10 last lines):
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 84, in __call__
    return self.run(*args, **kwds)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 84, in __call__
    return self.run(*args, **kwds)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/vstinner/prog/python/master/Lib/unittest/case.py", line 663, in __call__
    return self.run(*args, **kwds)
  File "/home/vstinner/prog/python/master/Lib/unittest/case.py", line 615, in run
    testMethod()
  File "/home/vstinner/prog/python/master/Lib/unittest/mock.py", line 1191, in patched
    return func(*args, **keywargs)
  File "/home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py", line 2096, in test_error_in_call_soon
    self.new_task(self.loop, coro())
ok

test_error_in_call_soon (test.test_asyncio.test_tasks.PyTask_CFutureSubclass_Tests) ...
<CoroWrapper BaseTaskTests.test_error_in_call_soon.<locals>.coro() running, defined at /home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py:2089, created at /home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py:2096> was never yielded from
Coroutine object created at (most recent call last, truncated to 10 last lines):
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 84, in __call__
    return self.run(*args, **kwds)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 84, in __call__
    return self.run(*args, **kwds)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/vstinner/prog/python/master/Lib/unittest/case.py", line 663, in __call__
    return self.run(*args, **kwds)
  File "/home/vstinner/prog/python/master/Lib/unittest/case.py", line 615, in run
    testMethod()
  File "/home/vstinner/prog/python/master/Lib/unittest/mock.py", line 1191, in patched
    return func(*args, **keywargs)
  File "/home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py", line 2096, in test_error_in_call_soon
    self.new_task(self.loop, coro())
ok

test_error_in_call_soon (test.test_asyncio.test_tasks.PyTask_CFuture_Tests) ...
<CoroWrapper BaseTaskTests.test_error_in_call_soon.<locals>.coro() running, defined at /home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py:2089, created at /home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py:2096> was never yielded from
Coroutine object created at (most recent call last, truncated to 10 last lines):
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 84, in __call__
    return self.run(*args, **kwds)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 84, in __call__
    return self.run(*args, **kwds)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/vstinner/prog/python/master/Lib/unittest/case.py", line 663, in __call__
    return self.run(*args, **kwds)
  File "/home/vstinner/prog/python/master/Lib/unittest/case.py", line 615, in run
    testMethod()
  File "/home/vstinner/prog/python/master/Lib/unittest/mock.py", line 1191, in patched
    return func(*args, **keywargs)
  File "/home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py", line 2096, in test_error_in_call_soon
    self.new_task(self.loop, coro())
ok

test_error_in_call_soon (test.test_asyncio.test_tasks.PyTask_PyFuture_SubclassTests) ...
<CoroWrapper BaseTaskTests.test_error_in_call_soon.<locals>.coro() running, defined at /home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py:2089, created at /home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py:2096> was never yielded from
Coroutine object created at (most recent call last, truncated to 10 last lines):
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 84, in __call__
    return self.run(*args, **kwds)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 84, in __call__
    return self.run(*args, **kwds)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/vstinner/prog/python/master/Lib/unittest/case.py", line 663, in __call__
    return self.run(*args, **kwds)
  File "/home/vstinner/prog/python/master/Lib/unittest/case.py", line 615, in run
    testMethod()
  File "/home/vstinner/prog/python/master/Lib/unittest/mock.py", line 1191, in patched
    return func(*args, **keywargs)
  File "/home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py", line 2096, in test_error_in_call_soon
    self.new_task(self.loop, coro())
ok

test_error_in_call_soon (test.test_asyncio.test_tasks.PyTask_PyFuture_Tests) ...
<CoroWrapper BaseTaskTests.test_error_in_call_soon.<locals>.coro() running, defined at /home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py:2089, created at /home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py:2096> was never yielded from
Coroutine object created at (most recent call last, truncated to 10 last lines):
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 84, in __call__
    return self.run(*args, **kwds)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 84, in __call__
    return self.run(*args, **kwds)
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122, in run
    test(result)
  File "/home/vstinner/prog/python/master/Lib/unittest/case.py", line 663, in __call__
    return self.run(*args, **kwds)
  File "/home/vstinner/prog/python/master/Lib/unittest/case.py", line 615, in run
    testMethod()
  File "/home/vstinner/prog/python/master/Lib/unittest/mock.py", line 1191, in patched
    return func(*args, **keywargs)
  File "/home/vstinner/prog/python/master/Lib/test/test_asyncio/test_tasks.py", line 2096, in test_error_in_call_soon
    self.new_task(self.loop, coro())
ok

----------
components: Tests, asyncio
messages: 310753
nosy: asvetlov, vstinner, yselivanov
priority: normal
severity: normal
status: open
title: test_asyncio emits many warnings when run in debug mode
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32676>
_______________________________________

From report at bugs.python.org  Fri Jan 26 06:09:08 2018
From: report at bugs.python.org (INADA Naoki)
Date: Fri, 26 Jan 2018 11:09:08 +0000
Subject: [New-bugs-announce] [issue32677] Add str.isascii()
Message-ID: <1516964948.19.0.467229070634.issue32677@psf.upfronthosting.co.za>


New submission from INADA Naoki <songofacandy at gmail.com>:

int() and str.is*** functions accepts other than ASCII.
But we want to accept only ASCII in some cases.  (e.g. ipaddress module)

We can use try-except to check ASCII, but it's inefficient.

try:
    s.encode('ascii')
except UnicodeEncodeError:
    ascii = False
else:
    ascii = True

CPython can check string is ASCII efficiently.

(Voting on python-ideas ML now)

----------
components: Interpreter Core
messages: 310754
nosy: inada.naoki
priority: normal
severity: normal
status: open
title: Add str.isascii()
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32677>
_______________________________________

From report at bugs.python.org  Fri Jan 26 07:30:50 2018
From: report at bugs.python.org (INADA Naoki)
Date: Fri, 26 Jan 2018 12:30:50 +0000
Subject: [New-bugs-announce] [issue32678] Lazy import ast in inspect
Message-ID: <1516969850.22.0.467229070634.issue32678@psf.upfronthosting.co.za>


New submission from INADA Naoki <songofacandy at gmail.com>:

inspect imports ast but it's used only for creating signature.

But asyncio uses inspect module for unwrap(), isgenerator(), etc...
And ast module is relatively heavy for import.

This is output of python -Ximporttime -c 'import asyncio':

import time:       147 |        147 |     asyncio.constants
import time:      1456 |       1456 |           _ast
import time:       363 |       1818 |         ast
...
import time:      1890 |       5152 |       inspect
...
import time:       303 |       5984 |     asyncio.coroutines
...
import time:       731 |      37941 |   asyncio.base_events
...
import time:       375 |      41383 | asyncio

----------
components: Library (Lib)
messages: 310759
nosy: inada.naoki
priority: normal
severity: normal
status: open
title: Lazy import ast in inspect
type: resource usage
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32678>
_______________________________________

From report at bugs.python.org  Fri Jan 26 09:23:30 2018
From: report at bugs.python.org (Jonas H.)
Date: Fri, 26 Jan 2018 14:23:30 +0000
Subject: [New-bugs-announce] [issue32679] concurrent.futures should store
 full sys.exc_info()
Message-ID: <1516976610.0.0.467229070634.issue32679@psf.upfronthosting.co.za>


New submission from Jonas H. <jonas at lophus.org>:

Use case: Try to get a future's result using concurrent.futures.Future.result(), and log the full exception if there was any.

Currently, only "excinst" (sys.exc_info()[1]) is provided with the Future.exception() method.

Proposal: Add new Future.exc_info() method that returns the full sys.exc_info() at the time of the exception.

----------
components: Library (Lib)
messages: 310762
nosy: jonash
priority: normal
severity: normal
status: open
title: concurrent.futures should store full sys.exc_info()
type: enhancement
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32679>
_______________________________________

From report at bugs.python.org  Fri Jan 26 10:26:15 2018
From: report at bugs.python.org (Romuald Brunet)
Date: Fri, 26 Jan 2018 15:26:15 +0000
Subject: [New-bugs-announce] [issue32680] smtplib SMTP instances missing a
 default sock attribute
Message-ID: <1516980375.64.0.467229070634.issue32680@psf.upfronthosting.co.za>


New submission from Romuald Brunet <romuald.brunet at gmail.com>:

SMTP instances from the smtplib module are not creating their sock attribute consistently after __init__

When host is sent as parameter a sock object is created (and hopefully, connected)

When the host is not sent, the sock attribute doesn't exist at all

----------
messages: 310764
nosy: Romuald
priority: normal
severity: normal
status: open
title: smtplib SMTP instances missing a default sock attribute

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32680>
_______________________________________

From report at bugs.python.org  Fri Jan 26 10:34:17 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Fri, 26 Jan 2018 15:34:17 +0000
Subject: [New-bugs-announce] [issue32681] Fix uninitialized variable in
 os_dup2_impl
Message-ID: <20180126153414.GA604@xps>


New submission from St?phane Wirtel <stephane at wirtel.be>:

With the last revision, I get this warning from the compiler.

gcc -pthread -Wno-unused-result -Wsign-compare -g -Og -Wall -Wstrict-prototypes    -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter -Wno-missing-field-initializers -Werror=implicit-function-declaration   -I. -I./Include    -DPy_BUILD_CORE  -c ./Modules/_collectionsmodule.c -o Modules/_collectionsmodule.o
./Modules/posixmodule.c: In function ?os_dup2_impl?:
./Modules/posixmodule.c:7785:9: warning: ?res? may be used uninitialized in this function [-Wmaybe-uninitialized]
     int res;
         ^~~

----------
messages: 310767
nosy: matrixise
priority: normal
severity: normal
status: open
title: Fix uninitialized variable in os_dup2_impl

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32681>
_______________________________________

From report at bugs.python.org  Fri Jan 26 10:55:24 2018
From: report at bugs.python.org (pmpp)
Date: Fri, 26 Jan 2018 15:55:24 +0000
Subject: [New-bugs-announce] [issue32682] test_zlib improve version parsing
Message-ID: <1516982124.56.0.467229070634.issue32682@psf.upfronthosting.co.za>


New submission from pmpp <pmpp.pub at gmail.com>:

On some OS like android 4.0+, system libz.so gives funny versions number that prevent test_zlib from correctly parse it from zlib.ZLIB_RUNTIME_VERSION

https://patch-diff.githubusercontent.com/raw/vstinner/cpython/pull/1.patch

seems to fix "1.2.8-linuxfoundation-mods-v1" and "1.2.8.f-linuxfoundation-mods-v1" cases as already encountered on an popular operating system and maybe others yet unknown.

----------
components: Tests
messages: 310773
nosy: pmpp
priority: normal
severity: normal
status: open
title: test_zlib improve version parsing
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32682>
_______________________________________

From report at bugs.python.org  Fri Jan 26 16:10:40 2018
From: report at bugs.python.org (Dan Snider)
Date: Fri, 26 Jan 2018 21:10:40 +0000
Subject: [New-bugs-announce] [issue32683] isinstance is calling
 ob.__getattribute__ as a fallback instead of object.__class__.__get__
Message-ID: <1517001040.56.0.467229070634.issue32683@psf.upfronthosting.co.za>


New submission from Dan Snider <mr.assume.away at gmail.com>:

It doesn't even care if the result it gets from ob.__getattribute__("__class__") isn't a type.

Surely `isinstance` is intended to do what it is named and be guaranteed to return True if an object `ob` is an instance of class `cls`. There are already ways to trick `isinstance` into thinking objects are instances of types not present in its __mro__, ie with abstract base classes. All this does is introduce the possibility of bugs.

`inspect.isclass` in particular is affected. If there's some obscure use case for breaking `isinstance` in this manner, surely it shouldn't apply to `inspect.isclass` which according to its documentation, "Return true if the object is a class."

from inspect import isclass
class Liar:
    def __getattribute__(self, attr):
        if attr == '__class__':
            return type
        return object.__getattribute__(self, attr)

>>> islcass(Liar())
True

----------
components: Interpreter Core, Library (Lib)
messages: 310793
nosy: bup
priority: normal
severity: normal
status: open
title: isinstance is calling ob.__getattribute__ as a fallback instead of object.__class__.__get__
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32683>
_______________________________________

From report at bugs.python.org  Sat Jan 27 00:38:11 2018
From: report at bugs.python.org (=?utf-8?b?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Sat, 27 Jan 2018 05:38:11 +0000
Subject: [New-bugs-announce] [issue32684] asyncio.gather(...,
 return_exceptions=True) swallows cancellation
Message-ID: <1517031491.22.0.467229070634.issue32684@psf.upfronthosting.co.za>


New submission from ???? ????????? <socketpair at gmail.com>:

Proof:

================
import asyncio

async def test():
    while True:
        print('sleeping 1')
        await asyncio.gather(asyncio.sleep(1), return_exceptions=True)

async def amain():
    print('creating task')
    qwe = asyncio.Task(test())
    print('sleeping 2')
    await asyncio.sleep(2)
    print('cancelling task')
    qwe.cancel()
    print('waiting task for completion')
    try:
        await qwe
    except Exception as e:
        print('task complete: %r', e)

loop = asyncio.get_event_loop()
loop.run_until_complete(amain())

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

This program will never complete.

This case should be either fixed, or documented.

----------
components: asyncio
messages: 310843
nosy: asvetlov, socketpair, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.gather(..., return_exceptions=True) swallows cancellation
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32684>
_______________________________________

From report at bugs.python.org  Sat Jan 27 05:31:56 2018
From: report at bugs.python.org (Mayank Singhal)
Date: Sat, 27 Jan 2018 10:31:56 +0000
Subject: [New-bugs-announce] [issue32685] Erroneous suggestion in print
 statement
Message-ID: <1517049116.26.0.467229070634.issue32685@psf.upfronthosting.co.za>


New submission from Mayank Singhal <17mayanksinghal at gmail.com>:

The suggestion given when a for and print with the syntax for python 2.x are used together seems erroneous.

Steps to reproduce:
Just type following in the python interpreter (3.x):


for p in some_list: print p


The error produced is:

SyntaxError: Missing parentheses in call to 'print'. Did you mean print(in some_list: print p)?

I am also attaching a small file, that produces the error when run with:

python3 printBug.py

----------
components: Interpreter Core
files: printBug.py
messages: 310852
nosy: storymode7
priority: normal
severity: normal
status: open
title: Erroneous suggestion in print statement
type: behavior
versions: Python 3.6, Python 3.7
Added file: https://bugs.python.org/file47412/printBug.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32685>
_______________________________________

From report at bugs.python.org  Sat Jan 27 08:46:56 2018
From: report at bugs.python.org (7stud)
Date: Sat, 27 Jan 2018 13:46:56 +0000
Subject: [New-bugs-announce] [issue32686] python3.6.4 install hangs
Message-ID: <1517060816.16.0.467229070634.issue32686@psf.upfronthosting.co.za>


New submission from 7stud <7stud at excite.com>:

I tried to install python3.6.4 on OSX 10.13.2.  I followed the Build Instructions in the README.rst:

    ./configure
    make
    make test
    sudo make install

After ./configure step, the end of the output said:

---
If you want a release build with all stable optimizations active (PGO, etc),
please run ./configure --enable-optimizations
---

So I did:

~/Downloads/Python-3.6.4$ ./configure --enable-optimizations

Next, I did:

~/Downloads/Python-3.6.4$ make

But the make step always hangs on the line:
       
      ...
      ...
      0:00:18 load avg: 2.10 [ 23/406] test_asyncgen
      0:00:19 load avg: 2.10 [ 24/406] test_asynchat
      0:00:21 load avg: 2.01 [ 25/406] test_asyncio


During the make step, OSX prompts me whether to allow incoming connections.  I've tried it both ways: Deny and Allow, but the install allows hangs on the test_asyncio line.  I hit Ctrl+C to quit the install.  One time, I waited over an hour and the install was still hanging.

----------
components: asyncio
messages: 310858
nosy: 7stud, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: python3.6.4 install hangs
type: compile error
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32686>
_______________________________________

From report at bugs.python.org  Sat Jan 27 10:58:19 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 27 Jan 2018 15:58:19 +0000
Subject: [New-bugs-announce] [issue32687] wrong meaning of arg in
 Py_tracefunc doc
Message-ID: <1517068699.74.0.467229070634.issue32687@psf.upfronthosting.co.za>


New submission from Xiang Zhang <angwerzx at 126.com>:

The meaning of arg for PyTrace_Line and PyTrace_CALL is wrong, it is not always NULL but always Py_None.

----------
assignee: docs at python
components: Documentation
messages: 310865
nosy: docs at python, xiang.zhang
priority: normal
severity: normal
status: open
title: wrong meaning of arg in Py_tracefunc doc
versions: Python 2.7, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32687>
_______________________________________

From report at bugs.python.org  Sat Jan 27 11:03:53 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sat, 27 Jan 2018 16:03:53 +0000
Subject: [New-bugs-announce] [issue32688] weird comment out line of code
Message-ID: <1517069033.48.0.467229070634.issue32688@psf.upfronthosting.co.za>


New submission from Xiang Zhang <angwerzx at 126.com>:

I find one line[1] is weirdly commented out. But I don't think profile here is any different with trace. In 2.7, this line is not commented out and the change happens in b94767ff, fixing clang warnings.

----------
messages: 310866
nosy: brett.cannon, xiang.zhang
priority: normal
severity: normal
status: open
title: weird comment out line of code
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32688>
_______________________________________

From report at bugs.python.org  Sat Jan 27 19:01:24 2018
From: report at bugs.python.org (Craig Holmquist)
Date: Sun, 28 Jan 2018 00:01:24 +0000
Subject: [New-bugs-announce] [issue32689] shutil.move raises AttributeError
 if first argument is a pathlib.Path object and destination is a directory
Message-ID: <1517097684.51.0.467229070634.issue32689@psf.upfronthosting.co.za>


New submission from Craig Holmquist <craigholm at gmail.com>:

>>> import os, pathlib, shutil
>>> os.mkdir('test1')
>>> os.mkdir('test2')
>>> path = pathlib.Path('test1')
>>> shutil.move(path, 'test2')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.6/shutil.py", line 540, in move
    real_dst = os.path.join(dst, _basename(src))
  File "/usr/lib/python3.6/shutil.py", line 504, in _basename
    return os.path.basename(path.rstrip(sep))
AttributeError: 'PosixPath' object has no attribute 'rstrip'

----------
components: Library (Lib)
messages: 310900
nosy: craigh
priority: normal
severity: normal
status: open
title: shutil.move raises AttributeError if first argument is a pathlib.Path object and destination is a directory
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32689>
_______________________________________

From report at bugs.python.org  Sat Jan 27 22:16:31 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 28 Jan 2018 03:16:31 +0000
Subject: [New-bugs-announce] [issue32690] Return function locals() in order
 of creation?
Message-ID: <1517109391.6.0.467229070634.issue32690@psf.upfronthosting.co.za>


New submission from Guido van Rossum <guido at python.org>:

Found in this thread: https://twitter.com/dabeaz/status/956264950430912512

Note that at the global level locals() indeed returns variables in order of definition. Ditto at class scope. Because those calls just return the actual dict. But in a function, a dict is constructed. I agree with Dave that it would be nice if the order there was reversed.

----------
components: Interpreter Core
messages: 310905
nosy: gvanrossum
priority: low
severity: normal
stage: needs patch
status: open
title: Return function locals() in order of creation?
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32690>
_______________________________________

From report at bugs.python.org  Sun Jan 28 00:04:51 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 28 Jan 2018 05:04:51 +0000
Subject: [New-bugs-announce] [issue32691] "pdb -m <module>" sets
 __main__.__package__ incorrectly
Message-ID: <1517115891.43.0.467229070634.issue32691@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

For regular modules, the initial implementation of bpo-32206 sets __package__ to "module_name" instead of "module_name.rpartition('.')[0]".

This is not correct, and will cause problems for relative imports.

(From https://bugs.python.org/issue32206#msg310882)

----------
messages: 310917
nosy: jason.coombs, mariocj89, ncoghlan
priority: normal
severity: normal
stage: test needed
status: open
title: "pdb -m <module>" sets __main__.__package__ incorrectly
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32691>
_______________________________________

From report at bugs.python.org  Sun Jan 28 03:54:10 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Sun, 28 Jan 2018 08:54:10 +0000
Subject: [New-bugs-announce] [issue32692] test_threading.test_set_and_clear
 fails in AppVeyor CI
Message-ID: <1517129650.59.0.467229070634.issue32692@psf.upfronthosting.co.za>


New submission from Xiang Zhang <angwerzx at 126.com>:

test_threading.test_set_and_clear fails in AppVeyor CI. But seems it not stable since rerun succeeds. See https://ci.appveyor.com/project/python/cpython/build/3.6build11314/job/ussor83yaglx5whb.

FAIL: test_set_and_clear (test.test_threading.EventTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\projects\cpython\lib\test\lock_tests.py", line 407, in test_set_and_clear
    self.assertEqual(results, [True] * N)
AssertionError: Lists differ: [False, False, False, True, True] != [True, True, True, True, True]
First differing element 0:
False
True
- [False, False, False, True, True]
+ [True, True, True, True, True]

----------
components: Tests
messages: 310930
nosy: xiang.zhang
priority: normal
severity: normal
status: open
title: test_threading.test_set_and_clear fails in AppVeyor CI
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32692>
_______________________________________

From report at bugs.python.org  Sun Jan 28 06:16:16 2018
From: report at bugs.python.org (Nikolay Aleksandrovich Pavlov)
Date: Sun, 28 Jan 2018 11:16:16 +0000
Subject: [New-bugs-announce] [issue32693] os.path.ismount does not accept
 bytes objects
Message-ID: <1517138176.06.0.467229070634.issue32693@psf.upfronthosting.co.za>


New submission from Nikolay Aleksandrovich Pavlov <zyx.vim at gmail.com>:

According to the documentation it ought to accept any path-like object, but actually throws for bytes ones. The trace of logic is the following:

1. ismount() from Lib/ntpath.py is using `os.fpath` which may return either bytes or str: https://github.com/python/cpython/blob/255f7a26da47ca6b7bd1d375b8a04920f68c119c/Lib/ntpath.py#L263.
2. The output is passed to _getvolumepathname unchanged.
3. The clinic defines that function?s only argument as [unicode](https://github.com/python/cpython/blob/255f7a26da47ca6b7bd1d375b8a04920f68c119c/Modules/posixmodule.c#L3793).
4. If clinic was not there it would still require to change how path_wchar is defined below, PyUnicode? functions will not accept bytes object: https://github.com/python/cpython/blob/255f7a26da47ca6b7bd1d375b8a04920f68c119c/Modules/posixmodule.c#L3808.

Suggestion: change `Lib/ntpath.py` to use `os.fsdecode` in place of `os.fspath`.

This is a relay of issue https://github.com/powerline/powerline/issues/1876. Initial reporter observed bug on Python 3.6 (patch unknown), I could see an issue in current master (all links above point to that).

----------
components: Windows
messages: 310936
nosy: Nikolay Aleksandrovich Pavlov, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: os.path.ismount does not accept bytes objects
type: behavior
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32693>
_______________________________________

From report at bugs.python.org  Sun Jan 28 10:11:23 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Sun, 28 Jan 2018 15:11:23 +0000
Subject: [New-bugs-announce] [issue32694] macos/configure: Discover OpenSSL
 when installed with MacPorts
Message-ID: <1517152283.77.0.467229070634.issue32694@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
components: Cross-Build
nosy: Alex.Willmer, christian.heimes, ned.deily, yselivanov
priority: normal
severity: normal
status: open
title: macos/configure: Discover OpenSSL when installed with MacPorts
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32694>
_______________________________________

From report at bugs.python.org  Sun Jan 28 10:22:05 2018
From: report at bugs.python.org (bbayles)
Date: Sun, 28 Jan 2018 15:22:05 +0000
Subject: [New-bugs-announce] [issue32695] tarfile.open() raises TypeError
 when using compresslevel parameter with LZMA
Message-ID: <1517152925.99.0.467229070634.issue32695@psf.upfronthosting.co.za>


New submission from bbayles <bbayles at gmail.com>:

tarfile.open() allows for specifying both a compression type and a compression level. However, the compresslevel parameter doesn't work when using the xz modes.

    import tarfile
    good_archive = tarfile.open('/tmp/dummy.tar.gz', 'w:gz', compresslevel=9)
    bad_archive = tarfile.open('/tmp/dummy.tar.gz', 'w:xz', compresslevel=9)

This gives an error in the tarfile.TarFile constructor:

    TypeError: __init__() got an unexpected keyword argument 'compresslevel'

This appears to be due to tarfile.xzopen() specifying a preset keyword instead of a compresslevel keyword. This matches the LZMAFile compressor, but it means that it doesn't get passed in and is then carried along in the kwargs - see [1].

Changing to lzma.LZMAFile(fileobj or name, mode, preset=compresslevel) seems to fix the issue. Assuming that's the right fix, I'll submit a PR.

[1] https://github.com/python/cpython/blob/374c6e178a7599aae46c857b17c6c8bc19dfe4c2/Lib/tarfile.py#L1684-L1699

----------
components: Library (Lib)
messages: 310954
nosy: bbayles
priority: normal
severity: normal
status: open
title: tarfile.open() raises TypeError when using compresslevel parameter with LZMA
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32695>
_______________________________________

From report at bugs.python.org  Sun Jan 28 11:15:55 2018
From: report at bugs.python.org (Ofer)
Date: Sun, 28 Jan 2018 16:15:55 +0000
Subject: [New-bugs-announce] [issue32696] Fix pickling exceptions with
 multiple arguments
Message-ID: <1517156155.35.0.467229070634.issue32696@psf.upfronthosting.co.za>


New submission from Ofer <horowitz.ofer at gmail.com>:

Pickling exceptions fails when a custom exception class requires multiple arguments.

import pickle
class MultipleArgumentsError(Exception):
    def __init__(self, a, b):
        self.a = a
        self.b = b

pickle.loads(pickle.dumps(MultipleArgumentsError('a', 'b')))

this code produces the following error:

Traceback (most recent call last):
  File "/tmp/multiple_arguments_exception.py", line 8, in <module>
    pickle.loads(pickle.dumps(MultipleArgumentsError('a', 'b')))
  File "/usr/local/Cellar/python/2.7.13/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pickle.py", line 1388, in loads
    return Unpickler(file).load()
  File "/usr/local/Cellar/python/2.7.13/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pickle.py", line 864, in load
    dispatch[key](self)
  File "/usr/local/Cellar/python/2.7.13/Frameworks/Python.framework/Versions/2.7/lib/python2.7/pickle.py", line 1139, in load_reduce
    value = func(*args)
TypeError: __init__() takes exactly 3 arguments (2 given)


The same error occurs when using a built-in module like subprocess:
>>> import subprocess, pickle
>>> try:
...   subprocess.check_call(['python', '-c', 'raise SystemExit(1)'])
... except Exception as e:
...   pickle.loads(pickle.dumps(e))
... 


Related issue: https://bugs.python.org/issue1692335

----------
components: Interpreter Core
messages: 310963
nosy: alexandre.vassalotti, georg.brandl, jason.coombs, sbt, slallum, zseil
priority: normal
severity: normal
status: open
title: Fix pickling exceptions with multiple arguments
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32696>
_______________________________________

From report at bugs.python.org  Sun Jan 28 12:48:42 2018
From: report at bugs.python.org (Larry Hastings)
Date: Sun, 28 Jan 2018 17:48:42 +0000
Subject: [New-bugs-announce] [issue32697] Guarantee that Python preserves
 the order of kwonly parameters
Message-ID: <1517161722.52.0.467229070634.issue32697@psf.upfronthosting.co.za>


New submission from Larry Hastings <larry at hastings.org>:

Following on from the "Can Python guarantee the order of keyword-only parameters?", here's a patch to enforce that guarantee.  It adds documentation that makes the guarantee, and adds tests that make at least a passable attempt at testing that it's true.

I nosied everybody who +1'd my original proposal in python-dev, because I'm looking for someone to review the patch.  Beta 1 gets tagged on Sunday, so can someone rubber-stamp this today?

----------
assignee: larry
components: Interpreter Core
messages: 310975
nosy: eric.snow, gregory.p.smith, larry, yselivanov
priority: normal
severity: normal
stage: patch review
status: open
title: Guarantee that Python preserves the order of kwonly parameters
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32697>
_______________________________________

From report at bugs.python.org  Sun Jan 28 13:37:33 2018
From: report at bugs.python.org (Adrien)
Date: Sun, 28 Jan 2018 18:37:33 +0000
Subject: [New-bugs-announce] [issue32698] Improper gzip compression if
 output file extension is not "gz"
Message-ID: <1517164653.32.0.467229070634.issue32698@psf.upfronthosting.co.za>


New submission from Adrien <delgan.py at gmail.com>:

Hello.

The following code produces a improper compressed "test.txt.gzip" file:

    import gzip
    import shutil
    
    input_path = "test.txt"
    output_path = input_path + ".gzip"
    
    with open(input_path, 'w') as file:
        file.write("abc" * 10)
    
    with gzip.open(output_path, 'wb') as f_out:
        with open(input_path, 'rb') as f_in:
            shutil.copyfileobj(f_in, f_out)

Although the content can be read correctly using `gzip.open(outputh_path, 'rb')`, it cannot be correctly opened using software like 7-Zip or WinRar.
If I open the "test.txt.gzip" file, it contains another "test.txt.gzip" file. If I change the code to use ".gz" extension and then open "test.txt.gz", it contains the expected "test.txt" file.
The contained "test.txt.gzip" is actually the same (at bytes level) that "test.txt", just the filename differs which causes tools like 7-Zip to mess up.

The bug is not present using compressions functions from "bz2" and "lzma" modules. I can use custom extension, it still can be (un)compressed without issue.

As to why I need to use an extension differents from ".gz": I would like to compress arbitrary ".tar" file given in input to ".tgz". I wish the user could open the file in his favorite software archiver and see that it contains a ".tar" file, rather than he does not understand why it contains the same ".tgz" file.

----------
components: Library (Lib)
files: test.py
messages: 310978
nosy: Delgan
priority: normal
severity: normal
status: open
title: Improper gzip compression if output file extension is not "gz"
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file47414/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32698>
_______________________________________

From report at bugs.python.org  Sun Jan 28 13:51:50 2018
From: report at bugs.python.org (Thomas Kluyver)
Date: Sun, 28 Jan 2018 18:51:50 +0000
Subject: [New-bugs-announce] [issue32699] pythonXY._pth : unclear how .pth
 files are handled
Message-ID: <1517165510.64.0.467229070634.issue32699@psf.upfronthosting.co.za>


New submission from Thomas Kluyver <thomas at kluyver.me.uk>:

Nicholas Tollervey has been getting Pynsist to use the new pythonXY._pth file to assemble sys.path. However, I'm not clear on how this behaves with .pth files. The docs on this (https://docs.python.org/3/using/windows.html#finding-modules ) appear to contradict themselves:

> site is not imported unless one line in the file specifies import site
> ...
> Note that .pth files (without leading underscore) will be processed normally by the site module.

I can see two possibilities:

1. .pth files are processed normally if and only if the ._pth file specifies 'import site'. If it doesn't, they are ignored.
2. If a .pth file is encountered, site is imported to process it, but with sys.flags.nosite set, so that site doesn't do the normal stuff on import.

Some packages unfortunately seem to depend on .pth files getting processed, so if 1. is the case, Pynsist needs to ensure site is loaded.

Thanks :-)

----------
messages: 310980
nosy: steve.dower, takluyver
priority: normal
severity: normal
status: open
title: pythonXY._pth : unclear how .pth files are handled

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32699>
_______________________________________

From report at bugs.python.org  Sun Jan 28 16:10:15 2018
From: report at bugs.python.org (Allen)
Date: Sun, 28 Jan 2018 21:10:15 +0000
Subject: [New-bugs-announce] [issue32700] The replys additional (Re.) is ok.
Message-ID: <CAG3QrKuF2qDP8Lezwh9XhpiLpT-dTv0m8ZTWKvft2cswGoonmQ@mail.gmail.com>


New submission from Allen <Londonowl1973 at gmail.com>:

..

----------
messages: 310995
nosy: BIGAL
priority: normal
severity: normal
status: open
title: The replys additional (Re.) is ok.

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32700>
_______________________________________

From report at bugs.python.org  Sun Jan 28 18:34:50 2018
From: report at bugs.python.org (Julien Palard)
Date: Sun, 28 Jan 2018 23:34:50 +0000
Subject: [New-bugs-announce] [issue32701] Typo in quopri documentation
Message-ID: <1517182490.19.0.467229070634.issue32701@psf.upfronthosting.co.za>


New submission from Julien Palard <julien+python at palard.fr>:

Spotted a typo in https://docs.python.org/3/library/quopri.html: "must be provideda"

But I also can't extract the meaning of the sentence:

> quotetabs, a flag which controls whether to encode embedded spaces and tabs must be provideda and when true it encodes such embedded whitespace, and when false it leaves them unencoded.

So here's the diff from 99597c4d12e358174275945d97e504c0318a3783:

+ *quotetabs*, a flag which controls whether to encode embedded spaces and tabs must be provideda and when true it encodes such embedded whitespace, and when false it leaves them unencoded.
- *quotetabs* is a flag which controls whether to encode embedded spaces and tabs; when true it encodes such embedded whitespace, and when false it leaves them unencoded.

So the "must be provided" has been added, I propose:

*quotetabs*, a non-optional flag which controls whether to encode embedded spaces and tabs; when true it encodes such embedded whitespace, and when false it leaves them unencoded.

----------
assignee: docs at python
components: Documentation
messages: 311033
nosy: docs at python, mdk, orsenthil
priority: low
severity: normal
status: open
title: Typo in quopri documentation
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32701>
_______________________________________

From report at bugs.python.org  Sun Jan 28 22:44:32 2018
From: report at bugs.python.org (KINEBUCHI Tomohiko)
Date: Mon, 29 Jan 2018 03:44:32 +0000
Subject: [New-bugs-announce] [issue32702] Minor markup typo
Message-ID: <1517197472.5.0.467229070634.issue32702@psf.upfronthosting.co.za>


New submission from KINEBUCHI Tomohiko <cocoatomo77 at gmail.com>:

In the staticmethod document [1], code snippet should be a literal block, but actually be a block quote.
See the attached image file.

[1] https://docs.python.org/3.6/library/functions.html#staticmethod

----------
assignee: docs at python
components: Documentation
files: Screen Shot 2018-01-29 at 12.37.37.png
messages: 311048
nosy: cocoatomo, docs at python
priority: normal
severity: normal
status: open
title: Minor markup typo
versions: Python 3.6, Python 3.7, Python 3.8
Added file: https://bugs.python.org/file47415/Screen Shot 2018-01-29 at 12.37.37.png

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32702>
_______________________________________

From report at bugs.python.org  Sun Jan 28 23:06:16 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Mon, 29 Jan 2018 04:06:16 +0000
Subject: [New-bugs-announce] [issue32703] 'async with' somehow suppresses
 unawaited coroutine warnings
Message-ID: <1517198776.9.0.467229070634.issue32703@psf.upfronthosting.co.za>


New submission from Nathaniel Smith <njs at pobox.com>:

Example (minimal version of https://github.com/python-trio/trio/issues/425):

-----

async def open_file():
    pass

async def main():
    async with open_file():  # Should be 'async with await open_file()'
        pass

coro = main()
coro.send(None)

-----

Here we accidentally left out an 'await' on the call to 'open_file', so the 'async with' tries to look up 'CoroutineType.__aexit__', which obviously doesn't exist, and the program crashes with an AttributeError("__aexit__"). Yet weirdly, this doesn't trigger a warning about 'open_file' being unawaited. It should!

Yury's theory: maybe BEFORE_ASYNC_WITH's error-handling path is forgetting to DECREF the object.

----------
components: asyncio
messages: 311052
nosy: asvetlov, giampaolo.rodola, njs, yselivanov
priority: normal
severity: normal
status: open
title: 'async with' somehow suppresses unawaited coroutine warnings
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32703>
_______________________________________

From report at bugs.python.org  Mon Jan 29 00:49:48 2018
From: report at bugs.python.org (Allen)
Date: Mon, 29 Jan 2018 05:49:48 +0000
Subject: [New-bugs-announce] [issue32704] Tracking
Message-ID: <CAG3QrKsc3mRMLR7rfJr9SDoeKGtZ+OfbFFi_9jDWcogP608vRQ@mail.gmail.com>


New submission from Allen <Londonowl1973 at gmail.com>:

Could someone help me use python to track the tArget phones location and i
would like to intercepts all text and emaIl.

..

----------
messages: 311059
nosy: BIGAL
priority: normal
severity: normal
status: open
title: Tracking

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32704>
_______________________________________

From report at bugs.python.org  Mon Jan 29 02:42:18 2018
From: report at bugs.python.org (Chih-Hsuan Yen)
Date: Mon, 29 Jan 2018 07:42:18 +0000
Subject: [New-bugs-announce] [issue32705] Current Android does not have
 posix_spawn
Message-ID: <1517211738.51.0.467229070634.issue32705@psf.upfronthosting.co.za>


New submission from Chih-Hsuan Yen <yan12125 at gmail.com>:

Currently Android does not have posix_spawn, thus posixmodule.c does not build. Build log attached. I'll create a patch for this.

Testing environment: my building scripts [1] + Android NDK r16b
Building target: ARM64, android-21

/cc Primary reviewer of issue 20104 and Android enthusiasts in CPython

PS. Looks like posix_spawn will be available in Android P (API 28) [2]. For now I propose to disable it in CPython.

[1] https://github.com/yan12125/python3-android/
[2] https://android-review.googlesource.com/c/platform/bionic/+/504842

----------
components: Cross-Build
files: build.log
messages: 311078
nosy: Alex.Willmer, gregory.p.smith, vstinner, yan12125
priority: normal
severity: normal
status: open
title: Current Android does not have posix_spawn
type: compile error
versions: Python 3.7
Added file: https://bugs.python.org/file47416/build.log

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32705>
_______________________________________

From report at bugs.python.org  Mon Jan 29 06:27:36 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jan 2018 11:27:36 +0000
Subject: [New-bugs-announce] [issue32706] test_check_hostname() of
 test_ftplib started to fail randomly
Message-ID: <1517225256.94.0.467229070634.issue32706@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

It may be a regression caused by this recent change:
---
commit 61d478c71c5341cdc54e6bfb4ace4252852fd972
Author: Christian Heimes <christian at python.org>
Date:   Sat Jan 27 15:51:38 2018 +0100

    bpo-31399: Let OpenSSL verify hostname and IP address (#3462)
    
    bpo-31399: Let OpenSSL verify hostname and IP
    
    The ssl module now uses OpenSSL's X509_VERIFY_PARAM_set1_host() and
    X509_VERIFY_PARAM_set1_ip() API to verify hostname and IP addresses.
    
    * Remove match_hostname calls
    * Check for libssl with set1_host, libssl must provide X509_VERIFY_PARAM_set1_host()
    * Add documentation for OpenSSL 1.0.2 requirement
    * Don't support OpenSSL special mode with a leading dot, e.g. ".example.org" matches "www.example.org". It's not standard conform.
    * Add hostname_checks_common_name
    
    Signed-off-by: Christian Heimes <christian at python.org>
---

Travis CI output, reformatted to make it more readable:

https://travis-ci.org/python/cpython/jobs/334652437

test_check_hostname (test.test_ftplib.TestTLS_FTPClass) ...

Exception in thread Thread-83:
Traceback (most recent call last):
  File "/home/travis/build/python/cpython/Lib/asynchat.py", line 251, in initiate_send
    num_sent = self.send(data)
  File "/home/travis/build/python/cpython/Lib/test/test_ftplib.py", line 381, in send
    return super(SSLConnection, self).send(data)
  File "/home/travis/build/python/cpython/Lib/asyncore.py", line 360, in send
    result = self.socket.send(data)
  File "/home/travis/build/python/cpython/Lib/ssl.py", line 963, in send
    return self._sslobj.write(data)
  File "/home/travis/build/python/cpython/Lib/ssl.py", line 670, in write
    return self._sslobj.write(data)
ssl.SSLError: [SSL: SSLV3_ALERT_BAD_CERTIFICATE] sslv3 alert bad certificate (_ssl.c:2206)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/travis/build/python/cpython/Lib/asyncore.py", line 83, in read
    obj.handle_read_event()
  File "/home/travis/build/python/cpython/Lib/test/test_ftplib.py", line 369, in handle_read_event
    super(SSLConnection, self).handle_read_event()
  File "/home/travis/build/python/cpython/Lib/asyncore.py", line 422, in handle_read_event
    self.handle_read()
  File "/home/travis/build/python/cpython/Lib/asynchat.py", line 171, in handle_read
    self.found_terminator()
  File "/home/travis/build/python/cpython/Lib/test/test_ftplib.py", line 116, in found_terminator
    method(arg)
  File "/home/travis/build/python/cpython/Lib/test/test_ftplib.py", line 231, in cmd_list
    self.dtp.push(LIST_DATA)
  File "/home/travis/build/python/cpython/Lib/test/test_ftplib.py", line 73, in push
    super(DummyDTPHandler, self).push(what.encode('ascii'))
  File "/home/travis/build/python/cpython/Lib/asynchat.py", line 202, in push
    self.initiate_send()
  File "/home/travis/build/python/cpython/Lib/asynchat.py", line 253, in initiate_send
    self.handle_error()
  File "/home/travis/build/python/cpython/Lib/test/test_ftplib.py", line 402, in handle_error
    raise Exception
Exception

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/travis/build/python/cpython/Lib/threading.py", line 917, in _bootstrap_inner
    self.run()
  File "/home/travis/build/python/cpython/Lib/test/test_ftplib.py", line 279, in run
    asyncore.loop(timeout=0.1, count=1)
  File "/home/travis/build/python/cpython/Lib/asyncore.py", line 207, in loop
    poll_fun(timeout, map)
  File "/home/travis/build/python/cpython/Lib/asyncore.py", line 150, in poll
    read(obj)
  File "/home/travis/build/python/cpython/Lib/asyncore.py", line 87, in read
    obj.handle_error()
  File "/home/travis/build/python/cpython/Lib/test/test_ftplib.py", line 402, in handle_error
    raise Exception
Exception

ERROR

======================================================================
ERROR: test_check_hostname (test.test_ftplib.TestTLS_FTPClass)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/travis/build/python/cpython/Lib/test/test_ftplib.py", line 958, in test_check_hostname
    self.client.quit()
  File "/home/travis/build/python/cpython/Lib/ftplib.py", line 665, in quit
    resp = self.voidcmd('QUIT')
  File "/home/travis/build/python/cpython/Lib/ftplib.py", line 278, in voidcmd
    return self.voidresp()
  File "/home/travis/build/python/cpython/Lib/ftplib.py", line 251, in voidresp
    resp = self.getresp()
  File "/home/travis/build/python/cpython/Lib/ftplib.py", line 236, in getresp
    resp = self.getmultiline()
  File "/home/travis/build/python/cpython/Lib/ftplib.py", line 222, in getmultiline
    line = self.getline()
  File "/home/travis/build/python/cpython/Lib/ftplib.py", line 204, in getline
    line = self.file.readline(self.maxline + 1)
  File "/home/travis/build/python/cpython/Lib/socket.py", line 582, in readinto
    return self._sock.recv_into(b)
socket.timeout: timed out

----------
assignee: christian.heimes
components: SSL, Tests
messages: 311096
nosy: christian.heimes, vstinner
priority: normal
severity: normal
status: open
title: test_check_hostname() of test_ftplib started to fail randomly
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32706>
_______________________________________

From report at bugs.python.org  Mon Jan 29 07:31:06 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jan 2018 12:31:06 +0000
Subject: [New-bugs-announce] [issue32707] Python/hamt.c warnings
Message-ID: <1517229066.54.0.467229070634.issue32707@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

https://ci.appveyor.com/project/python/cpython/build/3.7build11469

..\Python\hamt.c(623): warning C4018: '<': signed/unsigned mismatch [C:\projects\cpython\PCbuild\pythoncore.vcxproj]
..\Python\hamt.c(937): warning C4018: '<': signed/unsigned mismatch [C:\projects\cpython\PCbuild\pythoncore.vcxproj]

IMHO it's a real bug, the warning must not be made quiet. HAMT doesn't support sizes larger than UINT32_MAX. HAMT must either fail to create if size is larger than UINT32_MAX, or the code should be fixed to use wider C types (larger than uint32_t, like uint64_t).

----------
components: Interpreter Core, asyncio
messages: 311112
nosy: asvetlov, vstinner, yselivanov
priority: normal
severity: normal
status: open
title: Python/hamt.c warnings
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32707>
_______________________________________

From report at bugs.python.org  Mon Jan 29 07:35:22 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jan 2018 12:35:22 +0000
Subject: [New-bugs-announce] [issue32708] test_sendfile() hangs on AMD64
 FreeBSD 10.x Shared 3.x buildbot
Message-ID: <1517229322.87.0.467229070634.issue32708@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

loop.sendfile() was added to asyncio in bpo-32622.

The test hangs on AMD64 FreeBSD 10.x Shared 3.x buildbot:

http://buildbot.python.org/all/#/builders/87/builds/598

Timeout (0:15:00)!
Thread 0x0000000802006400 (most recent call first):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/selectors.py", line 415 in select
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/asyncio/base_events.py", line 1702 in _run_once
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/asyncio/base_events.py", line 521 in run_forever
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/asyncio/base_events.py", line 553 in run_until_complete
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/test_asyncio/test_events.py", line 2131 in run_loop
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/test_asyncio/test_events.py", line 2194 in test_sendfile
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/case.py", line 615 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/case.py", line 663 in __call__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 122 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 84 in __call__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 122 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 84 in __call__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 122 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 84 in __call__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 122 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 84 in __call__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 122 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/suite.py", line 84 in __call__
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/unittest/runner.py", line 176 in run
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/support/__init__.py", line 1861 in _run_suite
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/support/__init__.py", line 1951 in run_unittest
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/runtest.py", line 175 in test_runner
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/runtest.py", line 176 in runtest_inner
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/runtest.py", line 140 in runtest
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/main.py", line 291 in rerun_failed_tests
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/main.py", line 540 in _main
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/main.py", line 510 in main
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/libregrtest/main.py", line 585 in main
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/__main__.py", line 2 in <module>
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/runpy.py", line 85 in _run_code
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/runpy.py", line 193 in _run_module_as_main
test_sendfile (test.test_asyncio.test_events.PollEventLoopTests) ... *** Error code 1

----------
components: Tests, asyncio
messages: 311113
nosy: asvetlov, vstinner, yselivanov
priority: normal
severity: normal
status: open
title: test_sendfile() hangs on AMD64 FreeBSD 10.x Shared 3.x buildbot
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32708>
_______________________________________

From report at bugs.python.org  Mon Jan 29 07:40:46 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 29 Jan 2018 12:40:46 +0000
Subject: [New-bugs-announce] [issue32709] the iterable for itertools.groupby
 must be sorted
Message-ID: <1517229646.32.0.467229070634.issue32709@psf.upfronthosting.co.za>


New submission from St?phane Wirtel <stephane at wirtel.be>:

The documentation of itertools.groupby indicates that generally, the iterable needs to be sorted. In fact, this iterable MUST be sorted.

----------
assignee: docs at python
components: Documentation
messages: 311115
nosy: docs at python, matrixise
priority: normal
severity: normal
status: open
title: the iterable for itertools.groupby must be sorted
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32709>
_______________________________________

From report at bugs.python.org  Mon Jan 29 07:43:38 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 29 Jan 2018 12:43:38 +0000
Subject: [New-bugs-announce] [issue32710] test_asyncio leaked [4, 4,
 3] memory blocks, sum=11 on AMD64 Windows8.1 Refleaks 3.x
Message-ID: <1517229818.86.0.467229070634.issue32710@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at gmail.com>:

AMD64 Windows8.1 Refleaks 3.x:
http://buildbot.python.org/all/#/builders/80/builds/118

test_asyncio leaked [4, 4, 3] memory blocks, sum=11

I reproduced the issue. I'm running test.bisect to try to isolate this bug.

----------
components: asyncio
messages: 311116
nosy: asvetlov, vstinner, yselivanov
priority: normal
severity: normal
status: open
title: test_asyncio leaked [4, 4, 3] memory blocks, sum=11 on AMD64 Windows8.1 Refleaks 3.x
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32710>
_______________________________________

From report at bugs.python.org  Mon Jan 29 08:35:09 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Mon, 29 Jan 2018 13:35:09 +0000
Subject: [New-bugs-announce] [issue32711] Fix warnings for
 Python/ast_unparse.c
Message-ID: <1517232909.04.0.467229070634.issue32711@psf.upfronthosting.co.za>


New submission from St?phane Wirtel <stephane at wirtel.be>:

Python/ast_unparse.c: At top level:
Python/ast_unparse.c:1122:1: warning: function declaration isn?t a prototype [-Wstrict-prototypes]
 maybe_init_static_strings()
 ^~~~~~~~~~~~~~~~~~~~~~~~~
Python/ast_unparse.c: In function ?append_ast_binop?:
Python/ast_unparse.c:105:15: warning: ?op? may be used uninitialized in this function [-Wmaybe-uninitialized]
     if (-1 == append_charp(writer, op)) {
               ^~~~~~~~~~~~~~~~~~~~~~~~
Python/ast_unparse.c: In function ?append_ast_unaryop?:
Python/ast_unparse.c:132:15: warning: ?op? may be used uninitialized in this function [-Wmaybe-uninitialized]
     if (-1 == append_charp(writer, op)) {
               ^~~~~~~~~~~~~~~~~~~~~~~~

----------
components: Interpreter Core
messages: 311131
nosy: matrixise
priority: normal
severity: normal
status: open
title: Fix warnings for Python/ast_unparse.c
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32711>
_______________________________________

From report at bugs.python.org  Mon Jan 29 08:57:45 2018
From: report at bugs.python.org (64andy)
Date: Mon, 29 Jan 2018 13:57:45 +0000
Subject: [New-bugs-announce] [issue32712] Modifying a list/dict effects all
 variables sharing that address
Message-ID: <1517234265.82.0.467229070634.issue32712@psf.upfronthosting.co.za>


New submission from 64andy <64andy2000 at gmail.com>:

If multiple lists/dictionaries are in the same memory address (usually caused by var1 = var2), then altering one will effect every variable in that address.
The ways I've found to achieve this are:
>>> my_list[2] = "Spam"
>>> my_list += "9"
>>> my_list.insert(4, "Hello")
>>> dictvar.update({"Three": "Four"})

This was achieved using Python 3.6.4 32-bit and 3.6.3 64-bit (CPython), and happened in both IDLE and python.exe

List Example code:
x = ['a','b','c']
y = x #Now y and x share a memory address, because CPython does that
print(f"Sanity test - x and y share the same address = {x is y}")

y[1] = '123'
y += ["Foo"]
y.insert(-1, "Eleven")

#x's Expected Value: ['a','b','c']
print(x) #Actual Value

----------
messages: 311135
nosy: 64andy
priority: normal
severity: normal
status: open
title: Modifying a list/dict effects all variables sharing that address
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32712>
_______________________________________

From report at bugs.python.org  Mon Jan 29 16:15:56 2018
From: report at bugs.python.org (Joffrey F)
Date: Mon, 29 Jan 2018 21:15:56 +0000
Subject: [New-bugs-announce] [issue32713] tarfile.itn breaks if n is a
 negative float
Message-ID: <1517260556.9.0.467229070634.issue32713@psf.upfronthosting.co.za>


New submission from Joffrey F <f.joffrey at gmail.com>:

Originally reported @ github.com/docker/compose/issues/5618

It seems that tarfile.itn() attempts to execute bitwise operations on a float if the n argument is a negative float, raising a TypeError.

As pointed out in the original report, this is an issue when converting some mtime values in TarInfo._create_header

This also happens for positive floats > 8**11 - 1, but that one is less of an issue for the next two hundred years or so.

----------
components: Library (Lib)
messages: 311173
nosy: j0ffrey
priority: normal
severity: normal
status: open
title: tarfile.itn breaks if n is a negative float
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32713>
_______________________________________

From report at bugs.python.org  Mon Jan 29 17:00:44 2018
From: report at bugs.python.org (Jay Yin)
Date: Mon, 29 Jan 2018 22:00:44 +0000
Subject: [New-bugs-announce] [issue32714] remove resourceLoader related code
 since it's deprecated
Message-ID: <1517263244.89.0.467229070634.issue32714@psf.upfronthosting.co.za>


New submission from Jay Yin <jayyin11043 at gmail.com>:

I recently discovered in the documentation within the code and recent discussions with Barry, that ResourceLoader is deprecated and was wondering if we wanted to remove the code exclusively pertaining to ResourceLoader for clarity and to remove unused code. (PS if this is will be done I'll gladly contribute to doing so)

----------
messages: 311177
nosy: jayyin11043
priority: normal
severity: normal
status: open
title: remove resourceLoader related code since it's deprecated
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32714>
_______________________________________

From report at bugs.python.org  Mon Jan 29 17:29:50 2018
From: report at bugs.python.org (holger)
Date: Mon, 29 Jan 2018 22:29:50 +0000
Subject: [New-bugs-announce] [issue32715] Make create_unix_server for
 SOCK_DGRAM work
Message-ID: <1517264990.0.0.467229070634.issue32715@psf.upfronthosting.co.za>


New submission from holger <holger+lp at freyther.de>:

The current implementation verifies that the sock passed is a stream socket. This limitation appears to be arbitrary and is limiting.

* An AF_UNIX SOCK_DGRAM server socket becomes readable when one can accept(2) it. Just like SOCK_STREAM.
* One could provide a different factory to create a reader/writer to use a SOCK_DGRAM socket (but most likely nothing special is needed)
* A connected AF_UNIX SOCK_DGRAM socket will work with normal read/write messages just like SOCK_STREAM.

AF_UNIX, SOCK_DGRAM is interesting because it provides a reliable transport for messages. This avoids having to write message segmentation or packing messages in any kind of envelope.

----------
components: asyncio
messages: 311188
nosy: asvetlov, holger+lp, yselivanov
priority: normal
severity: normal
status: open
title: Make create_unix_server for SOCK_DGRAM work
type: behavior
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32715>
_______________________________________

From report at bugs.python.org  Mon Jan 29 17:58:48 2018
From: report at bugs.python.org (Takayuki SHIMIZUKAWA)
Date: Mon, 29 Jan 2018 22:58:48 +0000
Subject: [New-bugs-announce] [issue32716] setup.py register --repository is
 broken
Message-ID: <1517266728.23.0.467229070634.issue32716@psf.upfronthosting.co.za>


New submission from Takayuki SHIMIZUKAWA <shimizukawa at gmail.com>:

Although document https://docs.python.org/3.6/distutils/packageindex.html#package-cmdoptions says "The --repository or -r option lets you specify a PyPI server different from the default", if there is no URL specified in ``.pypirc`` it will display "ValueError: <URL> not found in .pypirc".


::

  $ python3 setup.py register -r https://test.pypi.org/legacy/
  running register
  running egg_info
  writing dependency_links to test.egg-info/dependency_links.txt
  writing top-level names to test.egg-info/top_level.txt
  writing test.egg-info/PKG-INFO
  reading manifest file 'test.egg-info/SOURCES.txt'
  writing manifest file 'test.egg-info/SOURCES.txt'
  Traceback (most recent call last):
    File "setup.py", line 4, in <module>
      setup(name='test')
    File "/usr/lib/python3.5/distutils/core.py", line 148, in setup
      dist.run_commands()
    File "/usr/lib/python3.5/distutils/dist.py", line 955, in run_commands
      self.run_command(cmd)
    File "/usr/lib/python3.5/distutils/dist.py", line 974, in run_command
      cmd_obj.run()
    File "/usr/lib/python3/dist-packages/setuptools/command/register.py", line 10, in run
      orig.register.run(self)
    File "/usr/lib/python3.5/distutils/command/register.py", line 45, in run
      self._set_config()
    File "/usr/lib/python3.5/distutils/command/register.py", line 80, in _set_config
      raise ValueError('%s not found in .pypirc' % self.repository)
  ValueError: https://test.pypi.org/legacy/ not found in .pypirc

  $ python3 -V
  Python 3.5.2

  $ lsb_release -a
  No LSB modules are available.
  Distributor ID: Ubuntu
  Description:    Ubuntu 16.04.3 LTS
  Release:        16.04
  Codename:       xenial

This behavior could be confirmed on Windows.

I think there are two correction methods.
One is to fix it so that we can specify any URL regardless of the setting of .pypirc.
The other is to write in the document that "-r option can specify server name or URL in .pypirc".

----------
components: Distutils
messages: 311195
nosy: dstufft, eric.araujo, shimizukawa
priority: normal
severity: normal
status: open
title: setup.py register --repository is broken
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32716>
_______________________________________

From report at bugs.python.org  Mon Jan 29 18:39:36 2018
From: report at bugs.python.org (Ivan Levkivskyi)
Date: Mon, 29 Jan 2018 23:39:36 +0000
Subject: [New-bugs-announce] [issue32717] Document PEP 560
Message-ID: <1517269176.0.0.467229070634.issue32717@psf.upfronthosting.co.za>


New submission from Ivan Levkivskyi <levkivskyi at gmail.com>:

This should include:
* Short documentation PR for `__mro_entry__` and `__base_subclass__` methods.
* The `__class_getitem__` C API calling convention (with motivation, many classes are implemented in C but are generic in nature, like numpy.ndarray) in PEP 560.

----------
assignee: levkivskyi
components: Documentation
messages: 311200
nosy: gvanrossum, levkivskyi, serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Document PEP 560
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32717>
_______________________________________

From report at bugs.python.org  Mon Jan 29 19:54:56 2018
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 30 Jan 2018 00:54:56 +0000
Subject: [New-bugs-announce] [issue32718] Install PowerShell activation
 scripts for venv for all platforms
Message-ID: <1517273696.22.0.467229070634.issue32718@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

Thanks to https://github.com/PowerShell/PowerShell, PowerShell Core is cross-platform. That suggests that the Activate.ps1 file for venv should be moved to the common/ directory instead of existing only in the nt/ directory.

----------
components: Library (Lib)
messages: 311206
nosy: brett.cannon, vinay.sajip
priority: low
severity: normal
status: open
title: Install PowerShell activation scripts for venv for all platforms
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32718>
_______________________________________

From report at bugs.python.org  Mon Jan 29 22:00:56 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 30 Jan 2018 03:00:56 +0000
Subject: [New-bugs-announce] [issue32719] fatal error raised when Ctrl-C
 print loop
Message-ID: <1517281256.8.0.467229070634.issue32719@psf.upfronthosting.co.za>


New submission from Xiang Zhang <angwerzx at 126.com>:

A simple snippet:

import threading

def func():
	while True:
		print(1,2,3,4,5,6,7,8,9,10) 

t1 = threading.Thread(target=func)
t2 = threading.Thread(target=func)
t1.start()
t2.start()

Running this snippet and Ctrl-C raises FatalError:

^CException ignored in: <module 'threading' from '/root/Python-2.8.1/Lib/threading.py'>
Traceback (most recent call last):
1 2 3 4 5 6 7 8 9 10
  File "/root/Python-2.8.1/Lib/threading.py", line 1294, in _shutdown
1 2 3 4 5 6 7 8 9 10
1 2 3 4 5 6 7 8 9 10
    t.join()
  File "/root/Python-2.8.1/Lib/threading.py", line 1056, in join
1 2 3 4 5 6 7 8 9 10
1 2 3 4 5 6 7 8 9 10
    self._wait_for_tstate_lock()
  File "/root/Python-2.8.1/Lib/threading.py", line 1072, in _wait_for_tstate_lock
1 2 3 4 5 6 7 8 9 10
1 2 3 4 5 6 7 8 9 10
    elif lock.acquire(block, timeout):
KeyboardInterrupt
Fatal Python error: could not acquire lock for <_io.BufferedWriter name='<stdout>'> at interpreter shutdown, possibly due to daemon threads

Thread 0x00007f7f6b22e700 (most recent call first):
  File "/tmp/test.py", line 5 in func
  File "/root/Python-2.8.1/Lib/threading.py", line 864 in run
  File "/root/Python-2.8.1/Lib/threading.py", line 916 in _bootstrap_inner
  File "/root/Python-2.8.1/Lib/threading.py", line 884 in _bootstrap

Thread 0x00007f7f6ba2f700 (most recent call first):
  File "/tmp/test.py", line 5 in func
  File "/root/Python-2.8.1/Lib/threading.py", line 864 in run
  File "/root/Python-2.8.1/Lib/threading.py", line 916 in _bootstrap_inner
  File "/root/Python-2.8.1/Lib/threading.py", line 884 in _bootstrap

Current thread 0x00007f7f73761740 (most recent call first):
???(??) /* segfault(core dump) */

----------
components: IO
messages: 311215
nosy: xiang.zhang
priority: normal
severity: normal
status: open
title: fatal error raised when Ctrl-C print loop
type: behavior
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32719>
_______________________________________

From report at bugs.python.org  Mon Jan 29 23:45:29 2018
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 30 Jan 2018 04:45:29 +0000
Subject: [New-bugs-announce] [issue32720] Format mini-language integer
 definition is incorrect
Message-ID: <1517287529.39.0.467229070634.issue32720@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

I just noticed that https://docs.python.org/3/library/string.html#formatspec links to the "integer" definition in the main Python grammar for the permitted format of numeric fields.

This isn't accurate:

```
>>> format(10e4, ",.2f")
'100,000.00'
>>> format(10e4, ",.0x2f")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Invalid format specifier
>>> format(10e4, ",.2_2f")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Invalid format specifier
```

Instead, the `width` and `precision` subfields should be defined as "digit+"

----------
assignee: docs at python
components: Documentation
messages: 311229
nosy: docs at python, ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Format mini-language integer definition is incorrect
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32720>
_______________________________________

From report at bugs.python.org  Tue Jan 30 00:29:15 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 30 Jan 2018 05:29:15 +0000
Subject: [New-bugs-announce] [issue32721] test_hashlib fails if _md5 is not
 built
Message-ID: <1517290155.28.0.467229070634.issue32721@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

$ make
$ rm build/lib.linux-x86_64-3.7/_md5.cpython-37m-x86_64-linux-gnu.so 
$ ./python -m test test_hashlib
Run tests sequentially
0:00:00 load avg: 1.11 [1/1] test_hashlib
ERROR:root:code for hash md5 was not found.
Traceback (most recent call last):
  File "/home/benjamin/dev/python/cpython/Lib/hashlib.py", line 243, in <module>
    globals()[__func_name] = __get_hash(__func_name)
  File "/home/benjamin/dev/python/cpython/Lib/hashlib.py", line 113, in __get_builtin_constructor
    raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type md5
/home/benjamin/dev/python/cpython/Lib/test/test_hashlib.py:90: UserWarning: Did a C extension fail to compile? No module named '_md5'
  warnings.warn('Did a C extension fail to compile? %s' % error)
Warning -- logging._handlerList was modified by test_hashlib
  Before: (139817255081928, [<weakref at 0x7f29bdc02868; to '_StderrHandler' at 0x7f29bdbfeb70>, <weakref at 0x7f29ba4f71d8; to 'StreamHandler' at 0x7f29ba4ee8d0>], [<weakref at 0x7f29bdc02868; to '_StderrHandler' at 0x7f29bdbfeb70>])
  After:  (139817255081928, [<weakref at 0x7f29bdc02868; to '_StderrHandler' at 0x7f29bdbfeb70>, <weakref at 0x7f29ba4f71d8; to 'StreamHandler' at 0x7f29ba4ee8d0>], [<weakref at 0x7f29bdc02868; to '_StderrHandler' at 0x7f29bdbfeb70>, <weakref at 0x7f29ba4f71d8; to 'StreamHandler' at 0x7f29ba4ee8d0>]) 
test test_hashlib failed -- Traceback (most recent call last):
  File "/home/benjamin/dev/python/cpython/Lib/test/test_hashlib.py", line 209, in test_get_builtin_constructor
    constructor = get_builtin_constructor('md5')
  File "/home/benjamin/dev/python/cpython/Lib/hashlib.py", line 113, in __get_builtin_constructor
    raise ValueError('unsupported hash type ' + name)
ValueError: unsupported hash type md5

test_hashlib failed

1 test failed:
    test_hashlib

Total duration: 397 ms
Tests result: FAILURE

----------
components: Build
messages: 311233
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: test_hashlib fails if _md5 is not built
versions: Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32721>
_______________________________________

From report at bugs.python.org  Tue Jan 30 00:41:01 2018
From: report at bugs.python.org (Soothsayer)
Date: Tue, 30 Jan 2018 05:41:01 +0000
Subject: [New-bugs-announce] [issue32722] Classes
Message-ID: <1517290861.72.0.467229070634.issue32722@psf.upfronthosting.co.za>


New submission from Soothsayer <qd57h9m4q2 at snkmail.com>:

In the Python tutorial, in "9. Classes", in "9.10 Generator expression", a list of sample generator expressions used as arguments to functions is given. However, one of the examples isn't a generator expression, it's a set comprehension.

sine_table = {x: sin(x*pi/180) for x in range(0, 91)}

Perhaps this used to be a call to set() and was mistakenly converted?

----------
assignee: docs at python
components: Documentation
messages: 311235
nosy: Soothsayer, docs at python
priority: normal
severity: normal
status: open
title: Classes
type: enhancement
versions: Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32722>
_______________________________________

From report at bugs.python.org  Tue Jan 30 01:13:32 2018
From: report at bugs.python.org (Xiang Zhang)
Date: Tue, 30 Jan 2018 06:13:32 +0000
Subject: [New-bugs-announce] [issue32723] codecs.open
Message-ID: <1517292812.79.0.467229070634.issue32723@psf.upfronthosting.co.za>


New submission from Xiang Zhang <angwerzx at 126.com>:

>>> import codecs
>>> f = codecs.open('/tmp/a', 'w', errors='replace')
>>> f.errors
'strict'

Passing errors to codecs.open without encoding doesn't work. Can't get this from doc and I don't think it should silently ignore the passing argument.

----------
components: Library (Lib)
messages: 311240
nosy: lemburg, vstinner, xiang.zhang
priority: normal
severity: normal
status: open
title: codecs.open
versions: Python 2.7, Python 3.6, Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32723>
_______________________________________

From report at bugs.python.org  Tue Jan 30 02:59:33 2018
From: report at bugs.python.org (=?utf-8?q?St=C3=A9phane_Wirtel?=)
Date: Tue, 30 Jan 2018 07:59:33 +0000
Subject: [New-bugs-announce] [issue32724] Fix references to commands in
 Doc/pdb.rst
Message-ID: <1517299173.52.0.467229070634.issue32724@psf.upfronthosting.co.za>


New submission from St?phane Wirtel <stephane at wirtel.be>:

In the documentation of pdb.rst, we explain that we have to use some commands, but there is no link to these commands.

----------
assignee: docs at python
components: Documentation
messages: 311253
nosy: Mariatta, docs at python, matrixise
priority: normal
severity: normal
status: open
title: Fix references to commands in Doc/pdb.rst
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32724>
_______________________________________

From report at bugs.python.org  Tue Jan 30 05:13:55 2018
From: report at bugs.python.org (Clement Rouault)
Date: Tue, 30 Jan 2018 10:13:55 +0000
Subject: [New-bugs-announce] [issue32725] Instance of
 _multiprocessing.PipeConnection-subtype crash on deletion
Message-ID: <1517307235.22.0.467229070634.issue32725@psf.upfronthosting.co.za>


New submission from Clement Rouault <python at hakril.net>:

While playing with '_multiprocessing.PipeConnection' I found out that instancing an object with a subtype of '_multiprocessing.PipeConnection' will crash the interpreter when the object is deleted.

My guess is that some connection methods does not check/handle the fact that the object is a subtype and not a 'pure' PipeConnection.

I don't know if the exploitability aspect of this crash is important but it allows to rewrite an arbitrary address easily with some heap-pointer (leading to CPython trying to execute the heap).

I attached a simple program that crash CPython using this bug.

----------
components: Library (Lib)
files: poc.py
messages: 311260
nosy: hakril
priority: normal
severity: normal
status: open
title: Instance of _multiprocessing.PipeConnection-subtype crash on deletion
type: crash
versions: Python 2.7
Added file: https://bugs.python.org/file47417/poc.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32725>
_______________________________________

From report at bugs.python.org  Tue Jan 30 06:58:51 2018
From: report at bugs.python.org (Ned Deily)
Date: Tue, 30 Jan 2018 11:58:51 +0000
Subject: [New-bugs-announce] [issue32726] 3.7.0 macOS installer and
 framework enhancements and changes
Message-ID: <1517313531.59.0.467229070634.issue32726@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at python.org>:

This issue covers various changes for the macOS installers provided via python.org for 3.7.0.

----------
components: Build, macOS
messages: 311268
nosy: ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: 3.7.0 macOS installer and framework enhancements and changes
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32726>
_______________________________________

From report at bugs.python.org  Tue Jan 30 10:10:32 2018
From: report at bugs.python.org (=?utf-8?q?Micha=C3=ABl_Lemaire?=)
Date: Tue, 30 Jan 2018 15:10:32 +0000
Subject: [New-bugs-announce] [issue32727] smtplib's SMTP.send_message
 behaves differently with from_addr and to_addrs
Message-ID: <1517325032.97.0.467229070634.issue32727@psf.upfronthosting.co.za>


New submission from Micha?l Lemaire <m.lemaire at rodacom.fr>:

Hi,

I noticed that SMTP.send_message, when getting the sender and recipients from the Message object, strips the name from recipients (to keep only the address), but not from the sender.

        if from_addr is None:
            # Prefer the sender field per RFC 2822:3.6.2.
            from_addr = (msg[header_prefix + 'Sender']
                           if (header_prefix + 'Sender') in msg
                           else msg[header_prefix + 'From'])
        if to_addrs is None:
            addr_fields = [f for f in (msg[header_prefix + 'To'],
                                       msg[header_prefix + 'Bcc'],
                                       msg[header_prefix + 'Cc'])
                           if f is not None]
            to_addrs = [a[1] for a in email.utils.getaddresses(addr_fields)]

There is an ugly side-effect to that (starting with Python 3.5) : if the sender name contains a non-ascii character, send_message will then require the SMTPUTF8 option from the SMTP server, and raise a SMTPNotSupportedError if unavailable. This is not wanted because the sender name is not actually sent to the SMTP server in the "MAIL FROM:" command (it is only sent in the MIME payload), so the SMTPUTF8 option should not be required based on it (it should only depend on the addresses).

----------
components: Library (Lib)
messages: 311275
nosy: Micha?l Lemaire
priority: normal
severity: normal
status: open
title: smtplib's SMTP.send_message behaves differently with from_addr and to_addrs
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32727>
_______________________________________

From report at bugs.python.org  Tue Jan 30 11:47:20 2018
From: report at bugs.python.org (bbayles)
Date: Tue, 30 Jan 2018 16:47:20 +0000
Subject: [New-bugs-announce] [issue32728] Extend zipfile's compression level
 support to LZMA
Message-ID: <1517330840.6.0.467229070634.issue32728@psf.upfronthosting.co.za>


New submission from bbayles <bbayles at gmail.com>:

In [1] (issue 21417), support for setting an archive (or its files) compression level was added to the zipfile module.

That currently works for the ZIP_DEFLATED and ZIP_BZIP2 compression methods, but not for ZIP_LZMA. This is because zipfile includes its own implementation of LZMACompressor that hard-codes the default preset's parameters (see also [2]).

It should be possible to extend compression level settings to ZIP_LZMA by making zipfile.LZMACompressor more flexible, i.e. able to accept an LZMA preset. I think this would involve porting the function that translates presets to options (lzma_lzma_preset, see [3]) and passing in those options to lzma.LZMACompressor .

[1] https://bugs.python.org/issue21417
[2] https://github.com/python/cpython/pull/5385
[3] https://git.tukaani.org/?p=xz.git;a=blob;f=src/liblzma/lzma/lzma_encoder_presets.c;hb=HEAD

----------
components: Library (Lib)
messages: 311283
nosy: bbayles
priority: normal
severity: normal
status: open
title: Extend zipfile's compression level support  to LZMA
type: enhancement
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32728>
_______________________________________

From report at bugs.python.org  Wed Jan 31 01:37:29 2018
From: report at bugs.python.org (=?utf-8?b?7JaR7JiB7J28?=)
Date: Wed, 31 Jan 2018 06:37:29 +0000
Subject: [New-bugs-announce] [issue32729] socket error handling needed
Message-ID: <1517380649.99.0.467229070634.issue32729@psf.upfronthosting.co.za>


New submission from ??? <sun0202id at gmail.com>:

socket error handling needed

----------
components: IO
messages: 311313
nosy: ???
priority: normal
severity: normal
status: open
title: socket error handling needed
type: crash
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32729>
_______________________________________

From report at bugs.python.org  Wed Jan 31 10:57:13 2018
From: report at bugs.python.org (Peter Suter)
Date: Wed, 31 Jan 2018 15:57:13 +0000
Subject: [New-bugs-announce] [issue32730] Allow py launcher to launch other
 registered Pythons
Message-ID: <1517414233.69.0.467229070634.issue32730@psf.upfronthosting.co.za>


New submission from Peter Suter <petsuter at gmail.com>:

For example Anaconda Python is registered under HKEY_LOCAL_MACHINE\Software\Python\ContinuumAnalytics\Anaconda36-64\ as described in PEP 514 "Python registration in the Windows registry" .

The py launcher from PEP 397 however ignores that and only considers HKEY_LOCAL_MACHINE\Software\Python\PythonCore\ registrations.

There seems to be no mechanism to register Anaconda Python with the py launcher. Anaconda considers this a bug in the Python launcher. https://github.com/ContinuumIO/anaconda-issues/issues/149#issuecomment-361922640

Shouldn't this be possible? Maybe via py.ini [defaults]?

----------
components: Windows
messages: 311338
nosy: paul.moore, petsuter at gmail.com, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Allow py launcher to launch other registered Pythons
type: enhancement
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32730>
_______________________________________

From report at bugs.python.org  Wed Jan 31 13:02:32 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 31 Jan 2018 18:02:32 +0000
Subject: [New-bugs-announce] [issue32731] getpass.getuser() raises an
 unspecified exceptions (ImportError, OSError, etc)
Message-ID: <1517421752.06.0.467229070634.issue32731@psf.upfronthosting.co.za>


New submission from Gregory P. Smith <greg at krypto.org>:

This has been true since Python 1.x.  getpass.getuser() is documented as "raising an exception" but doesn't specify what exception.

On Windows when the environment variables it looks at are not set, an ImportError (!) escapes due to "import pwd" failing.  It could just a easily allow an exception from the following pwd.getpwuid(os.getuid())[0] call to escape on systems when pwd exists.

None of these are actually helpful to the caller as they are left having to catch a bare Exception around a getpass.getuser() call to take another course of action.  I filed this as I just saw someone suggesting code that specifically catches ImportError on getpass.getuser().

It is too late to change the exception type coming out in 2.7 or 3.6, but cleaning up this underspecified behavior to be a meaningful exception for 3.7 seems reasonable.

----------
components: Library (Lib)
messages: 311349
nosy: gregory.p.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: getpass.getuser() raises an unspecified exceptions (ImportError, OSError, etc)
type: behavior
versions: Python 2.7, Python 3.7, Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32731>
_______________________________________

From report at bugs.python.org  Wed Jan 31 13:26:15 2018
From: report at bugs.python.org (Cyril Martin)
Date: Wed, 31 Jan 2018 18:26:15 +0000
Subject: [New-bugs-announce] [issue32732] LoggingAdapter ignores extra
 kwargs of Logger#log()
Message-ID: <1517423175.51.0.467229070634.issue32732@psf.upfronthosting.co.za>


New submission from Cyril Martin <mcoolive at gmail.com>:

- LoggerAdapter processes only extra kwargs given during its __init__
So extra kwargs, given to Logger#log are ignored when we configure a LoggerAdapter (same for: debug, info, warning etc).
- I expect extras are merged. More precisely, I expect local extra override the ones given in __init__

----------
components: Library (Lib)
messages: 311353
nosy: mcoolive
priority: normal
pull_requests: 5289
severity: normal
status: open
title: LoggingAdapter ignores extra kwargs of Logger#log()
versions: Python 3.8

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32732>
_______________________________________

From report at bugs.python.org  Wed Jan 31 13:29:07 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 31 Jan 2018 18:29:07 +0000
Subject: [New-bugs-announce] [issue32733] test_coroutines is failed when run
 with -We
Message-ID: <1517423347.93.0.467229070634.issue32733@psf.upfronthosting.co.za>


New submission from Serhiy Storchaka <storchaka+cpython at gmail.com>:

$ ./python -We -m test test_coroutines
Run tests sequentially
0:00:00 load avg: 0.29 [1/1] test_coroutines
Exception ignored in: <coroutine object OriginTrackingTest.test_origin_tracking_warning.<locals>.corofn at 0x7fc5fc692cb8>
Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/warnings.py", line 511, in _warn_unawaited_coroutine
    warn(msg, category=RuntimeWarning, stacklevel=2, source=coro)
RuntimeWarning: coroutine 'OriginTrackingTest.test_origin_tracking_warning.<locals>.corofn' was never awaited
test test_coroutines failed -- Traceback (most recent call last):
  File "/home/serhiy/py/cpython/Lib/test/test_coroutines.py", line 2167, in test_origin_tracking_warning
    msg = check(0, f"coroutine '{corofn.__qualname__}' was never awaited")
  File "/home/serhiy/py/cpython/Lib/test/test_coroutines.py", line 2161, in check
    self.assertTrue(len(wlist) == 1)
AssertionError: False is not true

test_coroutines failed

1 test failed:
    test_coroutines

Total duration: 371 ms
Tests result: FAILURE

This isn't release blocker, because the test is failed, not crashed, and seems this is just a test issue.

----------
components: Tests
messages: 311354
nosy: serhiy.storchaka, yselivanov
priority: normal
severity: normal
status: open
title: test_coroutines is failed when run with -We
type: behavior
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32733>
_______________________________________

From report at bugs.python.org  Wed Jan 31 13:55:45 2018
From: report at bugs.python.org (Bar Harel)
Date: Wed, 31 Jan 2018 18:55:45 +0000
Subject: [New-bugs-announce] [issue32734] Asyncio Lock safety issue
 (unlimited acquire)
Message-ID: <1517424945.58.0.467229070634.issue32734@psf.upfronthosting.co.za>


New submission from Bar Harel <bzvi7919 at gmail.com>:

Hey guys,

I found a pretty dangerous bug that allows acquiring locks in asyncio without them being free.

This happens due to double release (calling _wake_up_first) from both release and acquire in case of cancellation.

The example I've uploaded exploits it by acquiring 4 times, which grooms the loop's _ready queue, cancelling the second acquire to add the cancellation to the _ready queue, and releasing once to add the next waiter (number 3) to the _ready queue. Next event loop step causes the cancellation to run first, skipping the queued waiter (due to .done check being true) and waking the next waiter in line (number 4). Then both number 3 and number 4 run together on the same Lock.

I'm not at home so it's hard for me to code but the simple way of fixing it is by adding this line - "if self._locked: yield from self.acquire()" after the "yield from fut" (quite minimal overhead and only if bug happens, so no harm) or by slightly restructuring the code and the checks regarding cancelled futures.

I can later on post the restructured code but I think the simple if statement is a pretty fine and efficient fix.

----------
components: asyncio
files: bug.py
messages: 311361
nosy: asvetlov, bar.harel, yselivanov
priority: normal
severity: normal
status: open
title: Asyncio Lock safety issue (unlimited acquire)
type: security
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8
Added file: https://bugs.python.org/file47419/bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32734>
_______________________________________

From report at bugs.python.org  Wed Jan 31 15:56:00 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Wed, 31 Jan 2018 20:56:00 +0000
Subject: [New-bugs-announce] [issue32735] Typo in f-string example in docs
Message-ID: <1517432160.79.0.467229070634.issue32735@psf.upfronthosting.co.za>


New submission from Cheryl Sabella <chekat2 at gmail.com>:

On the lexical analysis doc page, in f-strings example, the following example isn't quite right:

>>> f"{today:%b %d, %Y}"  # using date format specifier
'January 27, 2017'

Submitting a patch shortly to use %B instead of %b.

----------
assignee: docs at python
components: Documentation
messages: 311371
nosy: csabella, docs at python
priority: normal
severity: normal
status: open
title: Typo in f-string example in docs
type: enhancement
versions: Python 3.7

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32735>
_______________________________________

From report at bugs.python.org  Wed Jan 31 16:39:14 2018
From: report at bugs.python.org (Edward Preble)
Date: Wed, 31 Jan 2018 21:39:14 +0000
Subject: [New-bugs-announce] [issue32736] random.triangular yields
 unexpected distribution when args mixed
Message-ID: <1517434754.22.0.467229070634.issue32736@psf.upfronthosting.co.za>


New submission from Edward Preble <preble.edward at gmail.com>:

The random.triangular function produces an unexpected distribution result (instead of an error or warning message) when the order of the 3 arguments are mixed up.

Python notebook with demo of issue here:
https://github.com/epreble/random_triangular_distribution_issue

Cases 1-4 are OK
1. random.triangular(low, high, mode) (Docs specified usage)
2. random.triangular(high, low, mode)
3. random.triangular(low, high)
4. random.triangular(high, low)

Incorrect argument input (e.g. numpy style) yields distributions that are NOT 3-value-triangular and the output is also from different ranges than expected:

Incorrect arguments (first one is numpy.random.triangular style)
6. random.triangular(low, mode, high) 
or:
7. random.triangular(high, mode, low)

Raising errors was discouraged in prior discussion (https://bugs.python.org/issue13355) due to back compatibility concerns. However, I would argue that output of an incorrect distribution without a warning is a problem that -should- be broken, even in old code.

A possible solution, that might not break the old code (I haven't looked at all the edge cases):

If 3 arguments provided, need to be sure the mode is arg3:
If arg1 < arg2 < arg3, this is definitely wrong since the mode is definitely in the middle (wrong position).
If arg1 > arg2 > arg3, this is definitely wrong since the mode is definitely in the middle (wrong position).

Those tests would not break the old use cases, since the signs of the tests switch between arg1/arg2/arg3:
  low, high, mode (would be arg1 < arg2 > arg3)
  high, low, mode (would be arg1 > arg2 < arg3)

Not positive how all the <=, >= combos work out with these tests.

----------
components: Library (Lib)
messages: 311377
nosy: eddieprebs
priority: normal
severity: normal
status: open
title: random.triangular yields unexpected distribution when args mixed
type: behavior
versions: Python 2.7, Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32736>
_______________________________________

From report at bugs.python.org  Wed Jan 31 19:08:16 2018
From: report at bugs.python.org (D. Michael Parrish)
Date: Thu, 01 Feb 2018 00:08:16 +0000
Subject: [New-bugs-announce] [issue32737] str.format not producing strings
 for nan argument in accordance with documentation
Message-ID: <1517443696.2.0.467229070634.issue32737@psf.upfronthosting.co.za>


New submission from D. Michael Parrish <will.hill.fx at gmail.com>:

>>> version_info
(3, 0, 1, 'final', 0)
# I know this is an older version---stuck with it at work.
# I did not see this issue in the tracker (380 results for nan).
# Perhaps there is better documentation for how to use the issue
# tracker. Many of the links on the Dealing with Bugs page---
# https://docs.python.org/3/bugs.html#contributing-to-python
# ---are not helpful, e.g., 'contribute' just links back the same
# page.
#
# There are similar problems with inf and -inf
>>> isnan(float('nan'))
True
>>> repr(float('nan'))
'nan'
>>> '{0:f}'.format(float('nan'))
'-1.#IND00'
>>> '{0:F}'.format(float('nan'))
'-1.#IND00'
>>> '{0:g}'.format(float('nan'))
'-1.#IND'
>>> '{0:G}'.format(float('nan'))
'-1.#IND'
>>> '{0:.2f}'.format(float('nan'))
'-1.#J'

# c.f. https://docs.python.org/3/library/string.html#formatspec

----------
assignee: docs at python
components: Documentation
messages: 311393
nosy: ana, docs at python
priority: normal
severity: normal
status: open
title: str.format not producing strings for nan argument in accordance with documentation
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32737>
_______________________________________

From report at bugs.python.org  Wed Jan 31 20:58:06 2018
From: report at bugs.python.org (twinkim2)
Date: Thu, 01 Feb 2018 01:58:06 +0000
Subject: [New-bugs-announce] [issue32738] CDLL : Can't fine module
Message-ID: <1517450286.23.0.467229070634.issue32738@psf.upfronthosting.co.za>


New submission from twinkim2 <twinkim2 at hanmail.net>:

I just try to import ./so created by c language.
However , if some c function library is added in c souce code such as "fopen" and "sscanf" related with stdio , runtime error is happend like as below.
==================================================================
Traceback (most recent call last):  File "D:\python_test\c_library_test.py", line 8, in <module>
    adder = CDLL('./_adder.so')
  File "C:\Users\admin\AppData\Local\Programs\Python\Python36\lib\ctypes\__init__.py", line 348, in __init__
    self._handle = _dlopen(self._name, mode)
OSError: [WinError 126] can't fine Module.
===================================================================
Please give your guide to fix this issue.

----------
components: ctypes
messages: 311398
nosy: twinkim2
priority: normal
severity: normal
status: open
title: CDLL : Can't fine module
type: behavior
versions: Python 3.6

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue32738>
_______________________________________