From report at bugs.python.org  Sat Sep  1 06:05:51 2018
From: report at bugs.python.org (Zyg)
Date: Sat, 01 Sep 2018 10:05:51 +0000
Subject: [New-bugs-announce] [issue34562] cannot install versions 3.6.5+ on
 Windows
Message-ID: <1535796351.86.0.56676864532.issue34562@psf.upfronthosting.co.za>


New submission from Zyg <zclips at gmail.com>:

Hi. 
I tried to unsuccessfully install 3.7.0 and 3.6.5. The error I received was 0x80072f7d unspecified error. Searching the internet and turning off my firewall didn't help. Then I tried installing 3.4.4, it worked.

----------
components: Windows
files: Python 3.7.0 (32-bit)_20180901123914.log
messages: 324461
nosy: Zyg, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: cannot install versions 3.6.5+ on Windows
versions: Python 3.6, Python 3.7
Added file: https://bugs.python.org/file47777/Python 3.7.0 (32-bit)_20180901123914.log

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

From report at bugs.python.org  Sat Sep  1 12:52:43 2018
From: report at bugs.python.org (Oleksandr Buchkovskyi)
Date: Sat, 01 Sep 2018 16:52:43 +0000
Subject: [New-bugs-announce] [issue34563] invalid assert on big output of
 multiprocessing.Process
Message-ID: <1535820763.57.0.56676864532.issue34563@psf.upfronthosting.co.za>


New submission from Oleksandr Buchkovskyi <olex.buchkovsky at gmail.com>:

the bug is reproduced on big multiprocessing.Process output
when the size of the output gets bigger than signed int the value becomes negative, thus
```            
assert left > 0
```
in multiprocessing/connection.py:337 raises an exception like the following

```
Traceback (most recent call last):
  File "D:\GitHub\cpython\lib\threading.py", line 917, in _bootstrap_inner
    self.run()
  File "D:\GitHub\cpython\lib\threading.py", line 865, in run
    self._target(*self._args, **self._kwargs)
  File "D:\GitHub\cpython\lib\multiprocessing\pool.py", line 470, in _handle_results
    task = get()
  File "D:\GitHub\cpython\lib\multiprocessing\connection.py", line 250, in recv
    buf = self._recv_bytes()
  File "D:\GitHub\cpython\lib\multiprocessing\connection.py", line 318, in _recv_bytes
    return self._get_more_data(ov, maxsize)
  File "D:\GitHub\cpython\lib\multiprocessing\connection.py", line 337, in _get_more_data
    assert left > 0
AssertionError
```


this assert looks invalid in this case because in C code the left value is DWORD (unsigned long), which cannot be negative by definition.

----------
components: Library (Lib)
files: invalid_assert_bug_reproduce.py
messages: 324465
nosy: Oleksandr Buchkovskyi
priority: normal
severity: normal
status: open
title: invalid assert on big output of multiprocessing.Process
type: crash
versions: Python 3.6
Added file: https://bugs.python.org/file47778/invalid_assert_bug_reproduce.py

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

From report at bugs.python.org  Sun Sep  2 14:23:40 2018
From: report at bugs.python.org (Tom Berry)
Date: Sun, 02 Sep 2018 18:23:40 +0000
Subject: [New-bugs-announce] [issue34564] Tutorial Section 2.1 Windows
 Installation Path Correction
Message-ID: <1535912620.22.0.56676864532.issue34564@psf.upfronthosting.co.za>


New submission from Tom Berry <tom.berryx at gmail.com>:

The listed installation location is incorrect in the 02 Sep 18 release of the tutorial. It shows the default install path as C:\python36 vice C:\Program Files\python37. 

This may be related to an installer issue, as installing single-user places the program in an entirely different directory. Changing the installer to default back to C:\python37 would remove the need to differentiate Program Files (x86) for a 32-bit installer, as well as Program Files\ for the 64-bit. 

Corrected Tutorial attached reflecting change FROM C:\python36 TO C:\Program Files\Python37.

----------
assignee: docs at python
components: Documentation
files: Tutorial_EDIT.pdf
messages: 324482
nosy: aperture, docs at python
priority: normal
severity: normal
status: open
title: Tutorial Section 2.1 Windows Installation Path Correction
type: enhancement
versions: Python 3.7
Added file: https://bugs.python.org/file47781/Tutorial_EDIT.pdf

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

From report at bugs.python.org  Sun Sep  2 16:03:40 2018
From: report at bugs.python.org (Brendan Gerrity)
Date: Sun, 02 Sep 2018 20:03:40 +0000
Subject: [New-bugs-announce] [issue34565] Launcher does not validate major
 versions
Message-ID: <1535918620.54.0.56676864532.issue34565@psf.upfronthosting.co.za>


New submission from Brendan Gerrity <bgerrity at ucdavis.edu>:

When a version argument is passed to the launcher (e.g. `py -3.4` or `py -7.0`), contrary to the launcher help text, the major version isn't validated as 2 or 3.

----------
components: Windows
messages: 324483
nosy: bgerrity, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Launcher does not validate major versions
type: behavior
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Mon Sep  3 08:06:40 2018
From: report at bugs.python.org (Marcel Plch)
Date: Mon, 03 Sep 2018 12:06:40 +0000
Subject: [New-bugs-announce] [issue34566] pipe read sometimmes returns EOF
 but returncode is still None
Message-ID: <1535976400.44.0.56676864532.issue34566@psf.upfronthosting.co.za>


New submission from Marcel Plch <mplch at redhat.com>:

TL;DR: For reproducer, please see attached file and the end of this description for a runner script.

It seems that when pipe is being read it has a chance of returning EOF and not setting the return code.
This bug affects all (or at least a broad set of) architectures and is present in all versions. (2.7 and 3.8 were tested).
This bug is not reproducible when configured using --with-pydebug flag.
As a result, any code relying on proper setting of the returncode attribute might (and probably is going to) fail.
-----------
$ for i in $(seq 1 1000); do ./python script.py; done | grep poll | sort | uniq -c

Actual output:
630 output: '', return code: 0, pollstatus=0
370 output: '', return code: None, pollstatus=None

Expected output:
1000 output: '', return code: 0, pollstatus=0

----------
components: Library (Lib)
files: script.py
messages: 324508
nosy: Dormouse759
priority: normal
severity: normal
status: open
title: pipe read sometimmes returns EOF but returncode is still None
versions: Python 3.8
Added file: https://bugs.python.org/file47782/script.py

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

From report at bugs.python.org  Mon Sep  3 09:28:24 2018
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 03 Sep 2018 13:28:24 +0000
Subject: [New-bugs-announce] [issue34567] test.pythoninfo: dump interpreter
 _PyCoreConfig
Message-ID: <1535981304.49.0.56676864532.issue34567@psf.upfronthosting.co.za>


New submission from STINNER Victor <vstinner at redhat.com>:

test.pythoninfo should also dump the interpreter _PyCoreConfig. It would help to check if the C locale has been coerced for example.

----------
components: Tests
messages: 324515
nosy: vstinner
priority: normal
severity: normal
status: open
title: test.pythoninfo: dump interpreter _PyCoreConfig
versions: Python 3.8

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

From report at bugs.python.org  Mon Sep  3 09:47:34 2018
From: report at bugs.python.org (=?utf-8?q?Pekka_Kl=C3=A4rck?=)
Date: Mon, 03 Sep 2018 13:47:34 +0000
Subject: [New-bugs-announce] [issue34568] Types in `typing` not anymore
 instances of `type` or subclasses of "real" types
Message-ID: <1535982454.49.0.56676864532.issue34568@psf.upfronthosting.co.za>


New submission from Pekka Kl?rck <pekka.klarck at gmail.com>:

= Introduction =

In Python 3.5 and 3.6 types defined in the typing module are instances of `type` and also subclasses of the "real" type they represent. For example, both `isinstance(typing.List, type)` and `issubclass(typing.List, list)` return true. In Python 3.7 the former returns false and the latter causes a TypeError. I could find anything related to these changes in the Python 3.7 release notes or from the documentation of the typing module.

I explain my use case and the problems these changes have caused below.

= Use case =

I'm implementing automatic argument conversion to Robot Framework, a generic open source test automation framework, based on function annotations. The idea is that if a user has defined a keyword like

    def example(arg: int):
        # ...

we can convert argument passed in plain text test data like

    Example    42

into the correct type automatically. For more details see this issue in our tracker:
https://github.com/robotframework/robotframework/issues/2890


= Problem 1 =

I have implemented converters for different types and use annotations to find out the expected type for each argument. To exclude non-type annotations, my code uses `isinstance(annotation, type)` but in Python 3.7 this excludes also types defined in the typing module.

I could apparently use `isinstance(annoation, (type, typing._GenericAlias))`, but touching private parts like is fragile and feels wrong in general.

= Problem 2 =

Each converter I've implemented is mapped to a certain type (e.g. `list`) and, when applicable, also to an abc (e.g. `collections.abc.MutableSequence`). When finding a correct converter for a certain type, the code uses an equivalent of `issubclass(type_, (converter.type, converter.abc))`. In Python 3.5 and 3.6 this works also if the used type is defined in the typing module but with Python 3.7 it causes a TypeError.

I guess I could handle the types in the typing module by explicitly mapping converters also to these types (e.g. `typing.List`) and then using something like `type_ is converter.typing`. The problem is that although it would work with types like `List`, it wouldn't work if types are used like `List[int]`.

----------
messages: 324518
nosy: pekka.klarck
priority: normal
severity: normal
status: open
title: Types in `typing` not anymore instances of `type` or subclasses of "real" types

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

From report at bugs.python.org  Mon Sep  3 09:47:59 2018
From: report at bugs.python.org (Michael Felt)
Date: Mon, 03 Sep 2018 13:47:59 +0000
Subject: [New-bugs-announce] [issue34569]
 test__xxsubinterpreters.ShareableTypeTests._assert_values fails on AIX -
 32-bit mode
Message-ID: <1535982479.72.0.56676864532.issue34569@psf.upfronthosting.co.za>


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

+364      def _assert_values(self, values):
  +365          for obj in values:
  +366              with self.subTest(obj):
  +367                  interpreters.channel_send(self.cid, obj)
  +368                  got = interpreters.channel_recv(self.cid)
  +369
  +370                  self.assertEqual(got, obj)
  +371                  self.assertIs(type(got), type(obj))
  +372                  # XXX Check the following in the channel tests?
  +373                  #self.assertIsNot(got, obj)
  +374

  +395      def test_int(self):
  +396          self._assert_values(range(-1, 258))
  +397

The assert fails on -1 with:

======================================================================
FAIL: test_int (test.test__xxsubinterpreters.ShareableTypeTests) [-1]
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/data/prj/python/python3-3.8.0/Lib/test/test__xxsubinterpreters.py", line 371, in _assert_values
    self.assertEqual(got, obj)
AssertionError: 4294967295 != -1

Note that this value is the unsigned value for 32-bit int as -1

root at x066:[/data/prj/python/python3-3.8.0]grep 4294967295 /usr/include/sys/*.h
/usr/include/sys/limits.h:#define ULONG_MAX     (4294967295UL)
/usr/include/sys/limits.h:#define UINT_MAX      (4294967295U)
/usr/include/sys/stdint.h:#define UINT32_MAX    (4294967295U)

After quite a lot of "learning", I narrow the issue to:

 +1432  static int
 +1433  _long_shared(PyObject *obj, _PyCrossInterpreterData *data)
 +1434  {
 +1435      int64_t value = PyLong_AsLongLong(obj);
 +1436      if (value == -1 && PyErr_Occurred()) {
 +1437          if (PyErr_ExceptionMatches(PyExc_OverflowError)) {
 +1438              PyErr_SetString(PyExc_OverflowError, "try sending as bytes");
 +1439          }
 +1440          return -1;
 +1441      }
 +1442      data->data = (void *)value;
 +1443      data->obj = NULL;
 +1444      data->new_object = _new_long_object;
 +1445      data->free = NULL;
 +1446      return 0;
 +1447  }
 +1448

 +1426  static PyObject *
 +1427  _new_long_object(_PyCrossInterpreterData *data)
 +1428  {
 +1429      return PyLong_FromLongLong((int64_t)(data->data));
 +1430  }

The "value" is stored as a void data type, and the high-order 64-bits are zero. When it gets returned as a PyLong... it goes positive.

I do not dare touch anything here without some "mentoring".

Or, we change the test so that it knows it is in 32-bit mode, and compares with something else.

In short, "mentoring" requested.

p.s. not had time to test in 64-bit mode. Will post on that later.

----------
messages: 324519
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: test__xxsubinterpreters.ShareableTypeTests._assert_values fails on AIX - 32-bit mode

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

From report at bugs.python.org  Mon Sep  3 10:01:47 2018
From: report at bugs.python.org (Pablosky)
Date: Mon, 03 Sep 2018 14:01:47 +0000
Subject: [New-bugs-announce] [issue34570] Segmentation fault in
 _PyType_Lookup
Message-ID: <1535983307.72.0.56676864532.issue34570@psf.upfronthosting.co.za>


New submission from Pablosky <pawelhrycyk at gmail.com>:

Platform details:
Ubuntu 16.04 LTS (64 bit)
Python 2.7.12

I am using Robot framework environment for testing. It looks segmentation fault appears when there is a lot (like 20) of pybot (Robot Framework component) instances running in the system. When the crash appears single pybot instance is killed. Rest is fine.

It happens sporadically. Like 4% of pybot executions.

----------
components: ctypes
files: segfault.txt
messages: 324521
nosy: Pablosky
priority: normal
severity: normal
status: open
title: Segmentation fault in _PyType_Lookup
type: crash
versions: Python 2.7
Added file: https://bugs.python.org/file47783/segfault.txt

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

From report at bugs.python.org  Mon Sep  3 11:12:37 2018
From: report at bugs.python.org (mcdallas)
Date: Mon, 03 Sep 2018 15:12:37 +0000
Subject: [New-bugs-announce] [issue34571] help(hashlib.blake2b) causes
 RuntimeError in 3.7
Message-ID: <1535987557.8.0.56676864532.issue34571@psf.upfronthosting.co.za>


New submission from mcdallas <mcdallas at protonmail.com>:

$ python3.7                                                                       
Python 3.7.0 (default, Jul 23 2018, 20:22:55)
[Clang 9.1.0 (clang-902.0.39.2)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import hashlib
>>> help(hashlib.blake2b)
Traceback (most recent call last):
  File "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/inspect.py", line 1996, in wrap_value
    value = eval(s, module_dict)
  File "<string>", line 1, in <module>
NameError: name '_blake2b' is not defined

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/inspect.py", line 1999, in wrap_value
    value = eval(s, sys_module_dict)
  File "<string>", line 1, in <module>
NameError: name '_blake2b' is not defined

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/_sitebuiltins.py", line 103, in __call__
    return pydoc.help(*args, **kwds)
  File "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/pydoc.py", line 1895, in __call__
    self.help(request)
  File "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/pydoc.py", line 1954, in help
    else: doc(request, 'Help on %s:', output=self._output)
  File "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/pydoc.py", line 1674, in doc
    pager(render_doc(thing, title, forceload))
  File "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/pydoc.py", line 1667, in render_doc
    return title % desc + '\n\n' + renderer.document(object, name)
  File "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/pydoc.py", line 386, in document
    if inspect.isclass(object): return self.docclass(*args)
  File "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/pydoc.py", line 1237, in docclass
    signature = inspect.signature(object)
  File "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/inspect.py", line 3070, in signature
    return Signature.from_callable(obj, follow_wrapped=follow_wrapped)
  File "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/inspect.py", line 2820, in from_callable
    follow_wrapper_chains=follow_wrapped)
  File "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/inspect.py", line 2343, in _signature_from_callable
    return _signature_fromstr(sigcls, obj, text_sig)
  File "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/inspect.py", line 2067, in _signature_fromstr
    p(name, default)
  File "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/inspect.py", line 2037, in p
    default_node = RewriteSymbolics().visit(default_node)
  File "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/ast.py", line 262, in visit
    return visitor(node)
  File "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/inspect.py", line 2024, in visit_Attribute
    return wrap_value(value)
  File "/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions/3.7/lib/python3.7/inspect.py", line 2001, in wrap_value
    raise RuntimeError()
RuntimeError


same for blake2s

----------
components: Library (Lib)
messages: 324524
nosy: mcdallas
priority: normal
severity: normal
status: open
title: help(hashlib.blake2b) causes RuntimeError in 3.7
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Mon Sep  3 11:53:21 2018
From: report at bugs.python.org (Tim Burgess)
Date: Mon, 03 Sep 2018 15:53:21 +0000
Subject: [New-bugs-announce] [issue34572] C unpickling bypasses import
 thread safety
Message-ID: <1535990001.55.0.56676864532.issue34572@psf.upfronthosting.co.za>


New submission from Tim Burgess <ozburgess at gmail.com>:

Retrieving and using a module directly from sys.modules (from C in this case) leads to a race condition where the module may be importing on another thread but has not yet been initialised.  For slow filesystems or large modules (e.g. numpy) this seems to lead to easily reproducible errors (the attached code fails 100% of the time on my work machine - CentOS 7).

I believe they have to be in sys.modules during this phase due to the possibility of circular references.

importlib handles this carefully with locking, but _pickle.c bypasses all that, leading to issues with threaded codes that use pickling, e.g. dask/distributed.

----------
components: Extension Modules
files: reproducer_submit.py
messages: 324528
nosy: tjb900
priority: normal
severity: normal
status: open
title: C unpickling bypasses import thread safety
type: crash
versions: Python 3.6, Python 3.7, Python 3.8
Added file: https://bugs.python.org/file47784/reproducer_submit.py

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

From report at bugs.python.org  Tue Sep  4 00:13:52 2018
From: report at bugs.python.org (Sergey Fedoseev)
Date: Tue, 04 Sep 2018 04:13:52 +0000
Subject: [New-bugs-announce] [issue34573] Simplify __reduce__() of set and
 dict iterators.
Message-ID: <1536034432.71.0.56676864532.issue34573@psf.upfronthosting.co.za>


New submission from Sergey Fedoseev <fedoseev.sergey at gmail.com>:

Currently __reduce__() implementation of set and dict iterators saves items to list using next/PyList_Append(), it could be simplified by using PySequence_List().

----------
components: Interpreter Core
messages: 324550
nosy: sir-sigurd
priority: normal
severity: normal
status: open
title: Simplify __reduce__() of set and dict iterators.
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Tue Sep  4 00:19:39 2018
From: report at bugs.python.org (Sergey Fedoseev)
Date: Tue, 04 Sep 2018 04:19:39 +0000
Subject: [New-bugs-announce] [issue34574] OrderedDict iterators are
 exhausted during pickling
Message-ID: <1536034779.39.0.56676864532.issue34574@psf.upfronthosting.co.za>


New submission from Sergey Fedoseev <fedoseev.sergey at gmail.com>:

In [1]: from collections import OrderedDict

In [2]: od = OrderedDict.fromkeys(range(10))

In [3]: it = iter(od)

In [4]: it.__reduce__()
Out[4]: (<function iter>, ([0, 1, 2, 3, 4, 5, 6, 7, 8, 9],))

In [5]: list(it)
Out[5]: []

----------
messages: 324551
nosy: sir-sigurd
priority: normal
severity: normal
status: open
title: OrderedDict iterators are exhausted during pickling
type: behavior

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

From report at bugs.python.org  Tue Sep  4 05:31:27 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Sep 2018 09:31:27 +0000
Subject: [New-bugs-announce] [issue34575] Python 3.6 compilation fails on
 AppVeyor: libeay.lib was created with an older compiler
Message-ID: <1536053487.61.0.56676864532.issue34575@psf.upfronthosting.co.za>


New submission from STINNER Victor <vstinner at redhat.com>:

Example on my PR:
https://github.com/python/cpython/pull/9057

https://ci.appveyor.com/project/python/cpython/build/3.6build21480/job/lge7r4qknx0t0tlv

LINK : fatal error C1047: The object or library file 'C:\projects\cpython\PCBuild\win32\libeay.lib' was created with an older compiler than other objects; rebuild old objects and libraries [C:\projects\cpython\PCbuild\_hashlib.vcxproj]
LINK : fatal error LNK1257: code generation failed [C:\projects\cpython\PCbuild\_hashlib.vcxproj]
LINK : fatal error C1047: The object or library file 'C:\projects\cpython\PCBuild\win32\libeay.lib' was created with an older compiler than other objects; rebuild old objects and libraries [C:\projects\cpython\PCbuild\_ssl.vcxproj]
LINK : fatal error LNK1257: code generation failed [C:\projects\cpython\PCbuild\_ssl.vcxproj]
Command exited with code 1

----------
components: Build, Windows
messages: 324576
nosy: paul.moore, steve.dower, tim.golden, vstinner, zach.ware
priority: normal
severity: normal
status: open
title: Python 3.6 compilation fails on AppVeyor: libeay.lib was created with an older compiler
versions: Python 3.6

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

From report at bugs.python.org  Tue Sep  4 05:39:03 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 04 Sep 2018 09:39:03 +0000
Subject: [New-bugs-announce] [issue34576] SimpleHTTPServer: warn users on
 security
Message-ID: <1536053943.84.0.56676864532.issue34576@psf.upfronthosting.co.za>


New submission from STINNER Victor <vstinner at redhat.com>:

Larry Hastings proposed on the PSRT mailing list to add the following note of the SimpleHTTPServer documentation:

    Note: SimpleHTTPServer is, as its name implies, a simple HTTP
    server.  We provide it as a sample implementation of the Python HTTP
    server API.  However, SimpleHTTPServer is neither secure nor
    high-performance, and as such you should not use SimpleHTTPServer in
    security-sensitive or performance-sensitive applications.

For example, if you create a symbolic link outside the directory served by SimpleHTTPServer, SimpleHTTPServer follows symbolic links.

----------
components: Library (Lib)
messages: 324577
nosy: vstinner
priority: normal
severity: normal
status: open
title: SimpleHTTPServer: warn users on security
type: security
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Tue Sep  4 10:11:45 2018
From: report at bugs.python.org (Nikita Velykanov)
Date: Tue, 04 Sep 2018 14:11:45 +0000
Subject: [New-bugs-announce] [issue34577] imaplib Cyrillic password
Message-ID: <1536070305.76.0.56676864532.issue34577@psf.upfronthosting.co.za>


New submission from Nikita Velykanov <nvelykanov at jerasoft.net>:

Let's consider there is an email box with password which contains Cyrillic symbols. When loging in

  imaplib.IMAP4_SSL(host, port).login(login, password)

password field is passed as "?????????" (type is str, not unicode).
Then, I get this traceback:

  File "/usr/lib64/python2.7/imaplib.py", line 518, in login
    typ, dat = self._simple_command('LOGIN', user, self._quote(password))
  File "/usr/lib64/python2.7/imaplib.py", line 1083, in _simple_command
    return self._command_complete(name, self._command(name, *args))
  File "/usr/lib64/python2.7/imaplib.py", line 870, in _command
    self.send('%s%s' % (data, CRLF))
  File "/usr/lib64/python2.7/imaplib.py", line 1191, in send
    sent = self.sslobj.write(data)
  File "/usr/lib64/python2.7/ssl.py", line 669, in write
    return self._sslobj.write(data)

This is because self._sslobj.write method requires unicode string.

In other case, if password field is passed as u"?????????" (type unicode, not str), I get another traceback:

  File "/usr/lib64/python2.7/imaplib.py", line 518, in login
    typ, dat = self._simple_command('LOGIN', user, self._quote(password))
  File "/usr/lib64/python2.7/imaplib.py", line 1083, in _simple_command
    return self._command_complete(name, self._command(name, *args))
  File "/usr/lib64/python2.7/imaplib.py", line 852, in _command
    data = '%s %s' % (data, self._checkquote(arg))

It's because '%s' % u"some unicode string" doesn't work.

I guess the problem was described in details.
The problem is that two different libraries are using different string types but they must be agreed.

----------
components: Library (Lib), Unicode
messages: 324586
nosy: Nikita Velykanov, ezio.melotti, vstinner
priority: normal
severity: normal
status: open
title: imaplib Cyrillic password
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Sep  4 10:50:41 2018
From: report at bugs.python.org (Arselon)
Date: Tue, 04 Sep 2018 14:50:41 +0000
Subject: [New-bugs-announce] [issue34578] Pipenv lock : ModuleNotFoundError:
 No module named '_ctypes'
Message-ID: <1536072641.34.0.56676864532.issue34578@psf.upfronthosting.co.za>


New submission from Arselon <arslanaliev at yahoo.com>:

I migrated from 3.6.6 to 3.7.
Error during command: pipenv lock (environment was created before successfully):
LOG:
PS C:\Program Files (x86)\Microsoft Visual Studio\Shared\Python\repos\DjangoPollsNew> pipenv lock
Locking [dev-packages] dependencies...
Locking [packages] dependencies...
ser\appdata\local\programs\python\python37\lib\site-packages\pipenv\vendor\click\core.py", line 8, in <module>
    from .types import convert_type, IntRange, BOOL
  File "c:\users\user\appdata\local\programs\python\python37\lib\site-packages\pipenv\vendor\click\types.py", line 4, in <module>
    from ._compat import open_stream, text_type, filename_to_ui, \
  File "c:\users\user\appdata\local\programs\python\python37\lib\site-packages\pipenv\vendor\click\_compat.py", line 536, in <module>
    from ._winconsole import _get_windows_console_stream
  File "c:\users\user\appdata\local\programs\python\python37\lib\site-packages\pipenv\vendor\click\_winconsole.py", line 16, in <module>
    import ctypes
  File "C:\Users\User\AppData\Local\Programs\Python\Python37\Lib\ctypes\__init__.py", line 7, in <module>
    from _ctypes import Union, Structure, Array
ModuleNotFoundError: No module named '_ctypes'

What can I do?
I need to create new Pipfile.lock for heroku hosting.
Thanks in advance))

----------
components: Library (Lib)
hgrepos: 378
messages: 324589
nosy: Arselon
priority: normal
severity: normal
status: open
title: Pipenv lock : ModuleNotFoundError: No module named '_ctypes'
type: crash
versions: Python 3.7

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

From report at bugs.python.org  Tue Sep  4 11:06:52 2018
From: report at bugs.python.org (Michael Felt)
Date: Tue, 04 Sep 2018 15:06:52 +0000
Subject: [New-bugs-announce] [issue34579] test_embed.InitConfigTests fail on
 AIX
Message-ID: <1536073612.09.0.56676864532.issue34579@psf.upfronthosting.co.za>


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

test_init_default_config (test.test_embed.InitConfigTests) ... FAIL
test_init_dev_mode (test.test_embed.InitConfigTests) ... FAIL
test_init_env (test.test_embed.InitConfigTests) ... FAIL
test_init_from_config (test.test_embed.InitConfigTests) ... ok
test_init_global_config (test.test_embed.InitConfigTests) ... FAIL
test_init_isolated (test.test_embed.InitConfigTests) ... FAIL

This seems to be caused because the dump_config() output is not
'(null)' for the keys allocator, program, and pycache_prefix.

When these are 'expected' to be '' (rather than '(null)', all tests pass.

See PR

----------
messages: 324590
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: test_embed.InitConfigTests fail on AIX

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

From report at bugs.python.org  Tue Sep  4 11:16:36 2018
From: report at bugs.python.org (Daniel Jakots)
Date: Tue, 04 Sep 2018 15:16:36 +0000
Subject: [New-bugs-announce] [issue34580] sqlite doc: clarify the scope of
 the context manager
Message-ID: <1536074196.75.0.56676864532.issue34580@psf.upfronthosting.co.za>


New submission from Daniel Jakots <lolbuntu at chown.me>:

In my experience, the first encounter for beginners with the context manager is with files. The highlighted feature is that you don't need to close the file, 'with' is going to do it for you.

The sqlite3 documentation talks about the context manager in "12.6.8.3. Using the connection as a context manager". The problem in my opinion is that people may believe that the context manager may manage the open/close which is not the case, reading the Modules/_sqlite/connection.c:pysqlite_connection_exit shows that it only does the commit or the rollback.

I'm not sure about the best fix. It can be either (or both) a sentence in the description and/or adding at then end of the code snippet "con.close()" to show that it still needs to be done.

Thanks!

----------
messages: 324591
nosy: vigdis
priority: normal
severity: normal
status: open
title: sqlite doc: clarify the scope of the context manager
type: enhancement

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

From report at bugs.python.org  Tue Sep  4 17:05:20 2018
From: report at bugs.python.org (Erik Janssens)
Date: Tue, 04 Sep 2018 21:05:20 +0000
Subject: [New-bugs-announce] [issue34581] Windows : use of __pragma msvc
 extension without ifdef
Message-ID: <1536095120.63.0.56676864532.issue34581@psf.upfronthosting.co.za>


New submission from Erik Janssens <erik.janssens at conceptive.be>:

The socketmodule uses the MSVC extension __pragma.

The use of this extension is not enabled/disable by an #ifdef _MSC_VER.

This prevents compilation with other compilers then MSVC on Windows.

----------
components: Extension Modules
messages: 324603
nosy: erikjanss
priority: normal
severity: normal
status: open
title: Windows : use of __pragma msvc extension without ifdef
type: compile error
versions: Python 3.8

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

From report at bugs.python.org  Tue Sep  4 17:37:11 2018
From: report at bugs.python.org (David Staheli)
Date: Tue, 04 Sep 2018 21:37:11 +0000
Subject: [New-bugs-announce] [issue34582] VSTS builds should use new YAML
 syntax and pools
Message-ID: <1536097031.78.0.56676864532.issue34582@psf.upfronthosting.co.za>


Change by David Staheli <david at staheli.org>:


----------
nosy: David Staheli
priority: normal
severity: normal
status: open
title: VSTS builds should use new YAML syntax and pools

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

From report at bugs.python.org  Tue Sep  4 18:09:14 2018
From: report at bugs.python.org (Isaac Shabtay)
Date: Tue, 04 Sep 2018 22:09:14 +0000
Subject: [New-bugs-announce] [issue34583] os.stat() wrongfully returns False
 for symlink on Windows 10 v1803
Message-ID: <1536098954.93.0.56676864532.issue34583@psf.upfronthosting.co.za>


New submission from Isaac Shabtay <isaac at shabtay.com>:

Windows 10 Pro, v1803.
Created a directory: D:\Test
Created a symbolic link to it: C:\Test -> D:\Test

The current user has permissions to access the link, however os.stat() fails:

>>> os.stat('C:\\Test')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
PermissionError: [WinError 5] Access is denied: 'C:\\Test'

The only change in my system since this has last worked, is that I upgraded to v1803 (used to be v1709 up until about a week ago).

----------
components: Library (Lib)
messages: 324605
nosy: Isaac Shabtay
priority: normal
severity: normal
status: open
title: os.stat() wrongfully returns False for symlink on Windows 10 v1803
versions: Python 3.7

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

From report at bugs.python.org  Wed Sep  5 05:10:36 2018
From: report at bugs.python.org (Joseph)
Date: Wed, 05 Sep 2018 09:10:36 +0000
Subject: [New-bugs-announce] [issue34584] subprocess
Message-ID: <1536138636.84.0.56676864532.issue34584@psf.upfronthosting.co.za>


New submission from Joseph <zengjoseph at hotmail.com>:

Every time IDLE is opened this message "IDLE's subprocess didn't make connection.  Either IDLE can't start a subprocess or personal firewall software is blocking the connection" shows up.
When I open IDLE through .py programs the app crashes
crash code:
Process:               Python [5021]
Path:                  /Applications/Python 3.7/IDLE.app/Contents/MacOS/Python
Identifier:            org.python.IDLE
Version:               3.7.0 (3.7.0)
Code Type:             X86-64 (Native)
Parent Process:        ??? [1]
Responsible:           Python [5021]
User ID:               501

Date/Time:             2018-09-05 17:09:24.893 +0800
OS Version:            Mac OS X 10.13.4 (17E199)
Report Version:        12
Anonymous UUID:        01609E2F-27A5-CB5F-4612-5BA977830EA2

Sleep/Wake UUID:       30FAEA7D-EBF8-44D0-AE53-A40B0636777A

Time Awake Since Boot: 87000 seconds
Time Since Wake:       510 seconds

System Integrity Protection: enabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Reason:    Namespace OBJC, Code 0x1

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	0x0000000101922ed6 __abort_with_payload + 10
1   libsystem_kernel.dylib        	0x000000010191d2cf abort_with_payload_wrapper_internal + 89
2   libsystem_kernel.dylib        	0x000000010191d276 abort_with_reason + 22
3   libobjc.A.dylib               	0x0000000100e16962 _objc_fatalv(unsigned long long, unsigned long long, char const*, __va_list_tag*) + 108
4   libobjc.A.dylib               	0x0000000100e16814 _objc_fatal(char const*, ...) + 135
5   libobjc.A.dylib               	0x0000000100e21f63 (anonymous namespace)::AutoreleasePoolPage::busted(bool) + 123
6   libobjc.A.dylib               	0x0000000100e09da5 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 79
7   com.apple.CoreFoundation      	0x0000000100047a56 _CFAutoreleasePoolPop + 22
8   com.apple.Foundation          	0x0000000103ee28ad -[NSAutoreleasePool drain] + 144
9   com.apple.Foundation          	0x0000000103f165a4 _NSAppleEventManagerGenericHandler + 120
10  com.apple.AE                  	0x000000010a9ccdd0 aeDispatchAppleEvent(AEDesc const*, AEDesc*, unsigned int, unsigned char*) + 1788
11  com.apple.AE                  	0x000000010a9cc677 dispatchEventAndSendReply(AEDesc const*, AEDesc*) + 41
12  com.apple.AE                  	0x000000010a9cc565 aeProcessAppleEvent + 383
13  com.apple.HIToolbox           	0x00000001078ad4a0 AEProcessAppleEvent + 55
14  com.apple.AppKit              	0x00000001045e1d32 _DPSNextEvent + 2788
15  com.apple.AppKit              	0x0000000104d77e34 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 3044
16  libtk8.6.dylib                	0x0000000103d4594a -[TKApplication(TKNotify) nextEventMatchingMask:untilDate:inMode:dequeue:] + 44
17  com.apple.AppKit              	0x0000000104813e7b -[NSApplication _doModalLoop:peek:] + 476
18  com.apple.AppKit              	0x00000001049f8c9f __35-[NSApplication runModalForWindow:]_block_invoke_2 + 64
19  com.apple.AppKit              	0x00000001049f8c4c __35-[NSApplication runModalForWindow:]_block_invoke + 75
20  com.apple.AppKit              	0x0000000104ea7219 _NSTryRunModal + 100
21  com.apple.AppKit              	0x0000000104811911 -[NSApplication runModalForWindow:] + 133
22  com.apple.AppKit              	0x00000001049e6eab __19-[NSAlert runModal]_block_invoke_2 + 158
23  com.apple.AppKit              	0x00000001049e6dfa __19-[NSAlert runModal]_block_invoke + 75
24  com.apple.AppKit              	0x0000000104ea7219 _NSTryRunModal + 100
25  com.apple.AppKit              	0x0000000104886609 -[NSAlert runModal] + 124
26  libtk8.6.dylib                	0x0000000103d32f31 Tk_MessageBoxObjCmd + 2098
27  libtcl8.6.dylib               	0x0000000103b12f08 TclNRRunCallbacks + 58
28  _tkinter.cpython-37m-darwin.so	0x0000000101beebf7 Tkapp_Call + 183
29  org.python.python             	0x000000010077aa7b cfunction_call_varargs + 299
30  org.python.python             	0x0000000100856376 _PyEval_EvalFrameDefault + 28614
31  org.python.python             	0x000000010084e740 _PyEval_EvalCodeWithName + 3088
32  org.python.python             	0x000000010077a50a _PyFunction_FastCallKeywords + 218
33  org.python.python             	0x000000010084f04f call_function + 671
34  org.python.python             	0x000000010085243d _PyEval_EvalFrameDefault + 12429
35  org.python.python             	0x000000010084e740 _PyEval_EvalCodeWithName + 3088
36  org.python.python             	0x000000010077a795 _PyFunction_FastCallDict + 469
37  org.python.python             	0x0000000100851eb4 _PyEval_EvalFrameDefault + 11012
38  org.python.python             	0x000000010084e740 _PyEval_EvalCodeWithName + 3088
39  org.python.python             	0x000000010077a50a _PyFunction_FastCallKeywords + 218
40  org.python.python             	0x000000010084f04f call_function + 671
41  org.python.python             	0x0000000100854a78 _PyEval_EvalFrameDefault + 22216
42  org.python.python             	0x000000010077a367 function_code_fastcall + 135
43  org.python.python             	0x000000010084f04f call_function + 671
44  org.python.python             	0x000000010085243d _PyEval_EvalFrameDefault + 12429
45  org.python.python             	0x000000010077a367 function_code_fastcall + 135
46  org.python.python             	0x000000010084f04f call_function + 671
47  org.python.python             	0x000000010085243d _PyEval_EvalFrameDefault + 12429
48  org.python.python             	0x000000010077a367 function_code_fastcall + 135
49  org.python.python             	0x000000010084f04f call_function + 671
50  org.python.python             	0x000000010085243d _PyEval_EvalFrameDefault + 12429
51  org.python.python             	0x000000010084e740 _PyEval_EvalCodeWithName + 3088
52  org.python.python             	0x000000010077a50a _PyFunction_FastCallKeywords + 218
53  org.python.python             	0x000000010084f04f call_function + 671
54  org.python.python             	0x000000010085243d _PyEval_EvalFrameDefault + 12429
55  org.python.python             	0x000000010084e740 _PyEval_EvalCodeWithName + 3088
56  org.python.python             	0x000000010077a50a _PyFunction_FastCallKeywords + 218
57  org.python.python             	0x000000010084f04f call_function + 671
58  org.python.python             	0x0000000100851843 _PyEval_EvalFrameDefault + 9363
59  org.python.python             	0x000000010084e740 _PyEval_EvalCodeWithName + 3088
60  org.python.python             	0x000000010084e904 PyEval_EvalCode + 100
61  org.python.python             	0x0000000100894d8e PyRun_FileExFlags + 206
62  org.python.python             	0x000000010089502f PyRun_SimpleFileExFlags + 447
63  org.python.python             	0x00000001008b376d pymain_main + 2733
64  org.python.python             	0x00000001008b3afa _Py_UnixMain + 218
65  Python                        	0x0000000100000f14 0x100000000 + 3860

Thread 1:
0   libsystem_kernel.dylib        	0x0000000101924292 __workq_kernreturn + 10
1   libsystem_pthread.dylib       	0x000000010195a20e _pthread_wqthread + 1552
2   libsystem_pthread.dylib       	0x0000000101959be9 start_wqthread + 13

Thread 2:
0   libsystem_kernel.dylib        	0x0000000101924292 __workq_kernreturn + 10
1   libsystem_pthread.dylib       	0x000000010195a009 _pthread_wqthread + 1035
2   libsystem_pthread.dylib       	0x0000000101959be9 start_wqthread + 13

Thread 3:
0   libsystem_kernel.dylib        	0x0000000101923cfa __select + 10
1   libtcl8.6.dylib               	0x0000000103c064c7 NotifierThreadProc + 558
2   libsystem_pthread.dylib       	0x000000010195a661 _pthread_body + 340
3   libsystem_pthread.dylib       	0x000000010195a50d _pthread_start + 377
4   libsystem_pthread.dylib       	0x0000000101959bf9 thread_start + 13

Thread 4:
0   libsystem_kernel.dylib        	0x0000000101924292 __workq_kernreturn + 10
1   libsystem_pthread.dylib       	0x000000010195a20e _pthread_wqthread + 1552
2   libsystem_pthread.dylib       	0x0000000101959be9 start_wqthread + 13

Thread 5:: Dispatch queue: NSCGSDisableUpdates
0   libsystem_kernel.dylib        	0x000000010191a20a mach_msg_trap + 10
1   libsystem_kernel.dylib        	0x0000000101919724 mach_msg + 60
2   com.apple.SkyLight            	0x00000001069ab9f5 CGSUpdateManager::enable_updates_common() + 565
3   com.apple.SkyLight            	0x000000010694fb28 CGSUpdateManager::enable_update(unsigned long long) + 320
4   libdispatch.dylib             	0x00000001014a964a _dispatch_call_block_and_release + 12
5   libdispatch.dylib             	0x00000001014a1e08 _dispatch_client_callout + 8
6   libdispatch.dylib             	0x00000001014b6267 _dispatch_queue_serial_drain + 635
7   libdispatch.dylib             	0x00000001014a91b6 _dispatch_queue_invoke + 373
8   libdispatch.dylib             	0x00000001014b6f5d _dispatch_root_queue_drain_deferred_wlh + 332
9   libdispatch.dylib             	0x00000001014bad71 _dispatch_workloop_worker_thread + 880
10  libsystem_pthread.dylib       	0x0000000101959fd2 _pthread_wqthread + 980
11  libsystem_pthread.dylib       	0x0000000101959be9 start_wqthread + 13

Thread 6:
0   libsystem_pthread.dylib       	0x0000000101959bdc start_wqthread + 0
1   ???                           	0x0004000200080003 0 + 1125908497301507

Thread 0 crashed with X86 Thread State (64-bit):
  rax: 0x0000000002000209  rbx: 0x0000000000000001  rcx: 0x00007fff5bffba98  rdx: 0x0000000000000000
  rdi: 0x0000000000000008  rsi: 0x0000000000000001  rbp: 0x00007fff5bffbaf0  rsp: 0x00007fff5bffba98
   r8: 0x000000011583b040   r9: 0x0000000000000080  r10: 0x0000000000000000  r11: 0x0000000000000246
  r12: 0x0000000000000000  r13: 0x0000000000000000  r14: 0x0000000000000008  r15: 0x0000000000000080
  rip: 0x0000000101922ed6  rfl: 0x0000000000000246  cr2: 0x0000000116d88000
  
Logical CPU:     0
Error Code:      0x02000209
Trap Number:     133


Binary Images:
       0x100000000 -        0x100000fff +Python (???) <772D781E-3DF3-3A7E-9620-5A4CAE438B7B> /Applications/Python 3.7/IDLE.app/Contents/MacOS/Python
       0x100003000 -        0x1004a4fef  com.apple.CoreFoundation (6.9 - 1452.23) <945E5C0A-86C5-336E-A64F-5BF06E78985A> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
       0x100757000 -        0x1009a1ff7 +org.python.python (3.7.0, [c] 2001-2018 Python Software Foundation. - 3.7.0) <8D0890E3-4550-11C2-704A-D0571C9442A8> /Library/Frameworks/Python.framework/Versions/3.7/Python
       0x100af8000 -        0x100af9ffb  libSystem.B.dylib (1252.50.4) <C7810EA7-A61F-3817-8E54-E2EC4E26F946> /usr/lib/libSystem.B.dylib
       0x100b00000 -        0x100b01ff3  libDiagnosticMessagesClient.dylib (104) <9712E980-76EE-3A89-AEA6-DF4BAF5C0574> /usr/lib/libDiagnosticMessagesClient.dylib
       0x100b07000 -        0x100d2effb  libicucore.A.dylib (59173.0.1) <CECAD5E5-3EFD-3AAC-AD9B-E355B2DD5E9C> /usr/lib/libicucore.A.dylib
       0x100e00000 -        0x1011ee7e7  libobjc.A.dylib (723) <DD9E5EC5-B507-3249-B700-93433E2D5EDF> /usr/lib/libobjc.A.dylib
       0x10139f000 -        0x1013b1ffb  libz.1.dylib (70) <48C67CFC-940D-3857-8DAD-857774605352> /usr/lib/libz.1.dylib
       0x1013b7000 -        0x1013bbff7  libcache.dylib (80) <092479CB-1008-3A83-BECF-E115F24D13C1> /usr/lib/system/libcache.dylib
       0x1013c1000 -        0x1013cbff3  libcommonCrypto.dylib (60118.50.1) <029F5985-9B6E-3DCB-9B96-FD007678C6A7> /usr/lib/system/libcommonCrypto.dylib
       0x1013d9000 -        0x1013e0fff  libcompiler_rt.dylib (62) <968B8E3F-3681-3230-9D78-BB8732024F6E> /usr/lib/system/libcompiler_rt.dylib
       0x1013ee000 -        0x1013f7ffb  libcopyfile.dylib (146.50.5) <3885083D-50D8-3EEC-B481-B2E605180D7F> /usr/lib/system/libcopyfile.dylib
       0x1013fe000 -        0x101483fff  libcorecrypto.dylib (562.50.17) <67007279-24E1-3F30-802D-A55CD5C27946> /usr/lib/system/libcorecrypto.dylib
       0x1014a0000 -        0x1014d9ff7  libdispatch.dylib (913.50.12) <848EEE57-4235-3A61-9A52-C0097DD2AB5E> /usr/lib/system/libdispatch.dylib
       0x101514000 -        0x101531ff7  libdyld.dylib (551.3) <CF59A5A5-288B-30E6-BD42-9056B4E4139A> /usr/lib/system/libdyld.dylib
       0x10154c000 -        0x10154cffb  libkeymgr.dylib (28) <E34E283E-90FA-3C59-B48E-1277CDB9CDCE> /usr/lib/system/libkeymgr.dylib
       0x101551000 -        0x101551ff7  liblaunch.dylib (1205.50.76) <4D52BB64-C568-3A36-8935-2480427EE2A2> /usr/lib/system/liblaunch.dylib
       0x101558000 -        0x10155cffb  libmacho.dylib (906) <1902A611-081A-3452-B11E-EBD1B166E831> /usr/lib/system/libmacho.dylib
       0x101563000 -        0x101565ff3  libquarantine.dylib (86) <26C0BA22-8F93-3A07-9A4E-C8D53D2CE42E> /usr/lib/system/libquarantine.dylib
       0x10156c000 -        0x10156dff3  libremovefile.dylib (45) <711E18B2-5BBE-3211-A916-56740C27D17A> /usr/lib/system/libremovefile.dylib
       0x101573000 -        0x10158afff  libsystem_asl.dylib (356.50.1) <3B24F2D1-B578-359D-ADB2-0ED19A364C38> /usr/lib/system/libsystem_asl.dylib
       0x101598000 -        0x101598fff  libsystem_blocks.dylib (67) <17303FDF-0D2D-3963-B05E-B4DF63052D47> /usr/lib/system/libsystem_blocks.dylib
       0x10159d000 -        0x101626ff7  libsystem_c.dylib (1244.50.9) <1187BFE8-4576-3247-8177-481554E1F9E7> /usr/lib/system/libsystem_c.dylib
       0x10164f000 -        0x101652ffb  libsystem_configuration.dylib (963.50.8) <DF6B5287-203E-30CB-9947-78DF446C72B8> /usr/lib/system/libsystem_configuration.dylib
       0x101659000 -        0x10165cffb  libsystem_coreservices.dylib (51) <486000D3-D8CB-3BE7-8EE5-8BF380DE6DF7> /usr/lib/system/libsystem_coreservices.dylib
       0x101662000 -        0x101663fff  libsystem_darwin.dylib (1244.50.9) <09C21A4A-9EE0-388B-A9D9-DFF8F6758791> /usr/lib/system/libsystem_darwin.dylib
       0x101669000 -        0x10166fff7  libsystem_dnssd.dylib (878.50.17) <9033B909-BCF7-37EB-A040-ADE8081611D6> /usr/lib/system/libsystem_dnssd.dylib
       0x101676000 -        0x1016bfff7  libsystem_info.dylib (517.30.1) <AB634A98-B8AA-3804-8436-38261FC8EC4D> /usr/lib/system/libsystem_info.dylib
       0x1016d7000 -        0x101722fcb  libsystem_m.dylib (3147.50.1) <FC2E58BA-E6D5-3D2A-89CA-67F212294136> /usr/lib/system/libsystem_m.dylib
       0x101731000 -        0x101750fff  libsystem_malloc.dylib (140.50.6) <7FD43735-9DDD-300E-8C4A-F909A74BDF49> /usr/lib/system/libsystem_malloc.dylib
       0x10175d000 -        0x10188dff3  libsystem_network.dylib (1229.51.2) <F65ED095-8ABA-3355-93F8-B9D0505932F4> /usr/lib/system/libsystem_network.dylib
       0x1018ce000 -        0x1018d8ffb  libsystem_networkextension.dylib (767.50.25) <758F1414-796D-3422-83C9-92D2915A06CE> /usr/lib/system/libsystem_networkextension.dylib
       0x1018e5000 -        0x1018eeff3  libsystem_notify.dylib (172) <08012EC0-2CD2-34BE-BF93-E7F56491299A> /usr/lib/system/libsystem_notify.dylib
       0x1018f6000 -        0x1018f9fff  libsystem_sandbox.dylib (765.50.51) <B48D256E-D7DB-3D4F-BC95-34557170C7AA> /usr/lib/system/libsystem_sandbox.dylib
       0x101900000 -        0x101901ff3  libsystem_secinit.dylib (30) <DE8D14E8-A276-3FF8-AE13-77F7040F33C1> /usr/lib/system/libsystem_secinit.dylib
       0x101907000 -        0x10192dff7  libsystem_kernel.dylib (4570.51.1) <5CAAB092-02CC-3A37-9D5F-C4AD1083AB96> /usr/lib/system/libsystem_kernel.dylib
       0x101947000 -        0x10194eff7  libsystem_platform.dylib (161.50.1) <6355EE2D-5456-3CA8-A227-B96E8F1E2AF8> /usr/lib/system/libsystem_platform.dylib
       0x101957000 -        0x101962fff  libsystem_pthread.dylib (301.50.1) <0E51CCBA-91F2-34E1-BF2A-FEEFD3D321E4> /usr/lib/system/libsystem_pthread.dylib
       0x10196f000 -        0x101976ff7  libsystem_symptoms.dylib (820.50.37) <ED7350E0-B68B-374A-9AB7-DC1F195A8327> /usr/lib/system/libsystem_symptoms.dylib
       0x10197d000 -        0x101990fff  libsystem_trace.dylib (829.50.17) <6568D68B-1D4C-38EE-90A9-54821D6403C0> /usr/lib/system/libsystem_trace.dylib
       0x10199f000 -        0x1019a4ff7  libunwind.dylib (35.3) <BEF3FB49-5604-3B5F-82B5-332B80023AC3> /usr/lib/system/libunwind.dylib
       0x1019ac000 -        0x1019d9fff  libxpc.dylib (1205.50.76) <25DB244E-217D-3CE0-A8F2-0C4255783B42> /usr/lib/system/libxpc.dylib
       0x1019fc000 -        0x101a2fff7  libclosured.dylib (551.3) <DC3DA678-9C40-339C-A9C6-32AB74FCC682> /usr/lib/closure/libclosured.dylib
       0x101a4b000 -        0x101a6fff7  libc++abi.dylib (400.8.2) <EF5E37D7-11D9-3530-BE45-B986612D13E2> /usr/lib/libc++abi.dylib
       0x101a7f000 -        0x101ad5fff  libc++.1.dylib (400.9) <7D3DACCC-3804-393C-ABC1-1A580FD00CB6> /usr/lib/libc++.1.dylib
       0x101be8000 -        0x101bf0ff7 +_tkinter.cpython-37m-darwin.so (???) <DE56789A-8D90-430A-22B2-784218C38568> /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_tkinter.cpython-37m-darwin.so
       0x101bfa000 -        0x101bfafff  com.apple.Cocoa (6.11 - 22) <4CF8E31C-B5C7-367B-B73D-1A8AC8E41B7F> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa
       0x101fe0000 -        0x101fe0fff  com.apple.Carbon (158 - 158) <F8B370D9-2103-3276-821D-ACC756167F86> /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon
       0x101fe4000 -        0x101fe4fff  com.apple.CoreServices (822.31 - 822.31) <615919A2-AE11-3F27-9A37-FB0CFF8D36B6> /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices
       0x101fe9000 -        0x101fe9fff  com.apple.ApplicationServices (48 - 50) <8DA47D38-B07B-3AE2-B343-4579864430C6> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices
       0x101fed000 -        0x101fedfff  libenergytrace.dylib (16) <A92AB8B8-B986-3CE6-980D-D55090FEF387> /usr/lib/libenergytrace.dylib
       0x101ff2000 -        0x101ff6ffb  libScreenReader.dylib (562.18.4) <E239923D-54C9-3BBF-852F-87C09DEF4091> /usr/lib/libScreenReader.dylib
       0x103951000 -        0x103974ffb  com.apple.RemoteViewServices (2.0 - 125) <592323D1-CB44-35F1-9921-4C2AB8D920A0> /System/Library/PrivateFrameworks/RemoteViewServices.framework/Versions/A/RemoteViewServices
       0x10399c000 -        0x1039abff7  com.apple.framework.DFRFoundation (1.0 - 191.7) <3B8ED6F7-5DFF-34C3-BA90-DDB85679684C> /System/Library/PrivateFrameworks/DFRFoundation.framework/Versions/A/DFRFoundation
       0x1039be000 -        0x1039befff  com.apple.Accelerate (1.11 - Accelerate 1.11) <8632A9C5-19EA-3FD7-A44D-80765CC9C540> /System/Library/Frameworks/Accelerate.framework/Versions/A/Accelerate
       0x1039c2000 -        0x1039c9ffb  com.apple.IOSurface (211.12 - 211.12) <392CA7DE-B365-364E-AF4A-33EC2CC48E6F> /System/Library/Frameworks/IOSurface.framework/Versions/A/IOSurface
       0x1039d8000 -        0x1039d8fff  com.apple.audio.units.AudioUnit (1.14 - 1.14) <513C9A4B-4F6D-3A21-921F-2CA101B97830> /System/Library/Frameworks/AudioUnit.framework/Versions/A/AudioUnit
       0x1039e3000 -        0x1039e4ff7  com.apple.performance.SignpostNotification (1.2.4 - 2.4) <9957B2C0-4D48-3337-8A4D-5E457CC7B542> /System/Library/PrivateFrameworks/SignpostNotification.framework/Versions/A/SignpostNotification
       0x1039eb000 -        0x1039f1fff  com.apple.speech.recognition.framework (6.0.3 - 6.0.3) <2ED8643D-B0C3-3F17-82A2-BBF13E6CBABC> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SpeechRecognition.framework/Versions/A/SpeechRecognition
       0x1039fb000 -        0x1039fbfff  libOpenScriptingUtil.dylib (174) <610F0242-7CE5-3C86-951B-B646562694AF> /usr/lib/libOpenScriptingUtil.dylib
       0x103b00000 -        0x103c48fef +libtcl8.6.dylib (8.6.8 - 8.6.8) <59169476-3443-1D5C-BC78-58A1A2DB71AD> /Library/Frameworks/Python.framework/Versions/3.7/lib/libtcl8.6.dylib
       0x103c7a000 -        0x103d95fe7 +libtk8.6.dylib (8.6.8 - 8.6.8) <6EA5315E-A60D-EC83-B930-17671B128CE7> /Library/Frameworks/Python.framework/Versions/3.7/lib/libtk8.6.dylib
       0x103de9000 -        0x103e84ff7  com.apple.framework.IOKit (2.0.2 - 1445.50.26) <A63CAC8D-BF57-34FD-9A88-2F74546F2000> /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit
       0x103ecd000 -        0x104293fff  com.apple.Foundation (6.9 - 1452.23) <E64540AD-1755-3C16-8537-552A00E92541> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
       0x1045a0000 -        0x1053fefff  com.apple.AppKit (6.9 - 1561.40.112) <C839B0C1-F7EE-3056-985C-63CF1A030EC4> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
       0x105e5e000 -        0x1061b4fef  com.apple.CoreData (120 - 851) <A2B59780-FB16-36A3-8EE0-E0EF072454E0> /System/Library/Frameworks/CoreData.framework/Versions/A/CoreData
       0x106364000 -        0x106513fff  com.apple.UIFoundation (1.0 - 547.3) <ACC12DF5-E528-33F3-A358-4E1BEA68239C> /System/Library/PrivateFrameworks/UIFoundation.framework/Versions/A/UIFoundation
       0x1065f3000 -        0x106674ff7  com.apple.Metal (125.25 - 125.25) <B2ECA050-4C13-3EAD-A1C8-AC21EFF122F1> /System/Library/Frameworks/Metal.framework/Versions/A/Metal
       0x10676a000 -        0x106899fff  com.apple.desktopservices (1.12.4 - 1.12.4) <47C3FBF3-5E75-3821-B003-2A4DC3657D8D> /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/Versions/A/DesktopServicesPriv
       0x10693e000 -        0x106bdafff  com.apple.SkyLight (1.600.0 - 312.50) <0CF4C608-8748-32BF-9586-A1601945F82C> /System/Library/PrivateFrameworks/SkyLight.framework/Versions/A/SkyLight
       0x106cbc000 -        0x1072ccfef  com.apple.CoreGraphics (2.0 - 1161.10) <31C36FA0-4026-3347-93FD-71CD7287A6F0> /System/Library/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics
       0x1073e9000 -        0x107676ff7  com.apple.audio.toolbox.AudioToolbox (1.14 - 1.14) <87D81714-F167-39F5-B5E7-A7A432EDAB5B> /System/Library/Frameworks/AudioToolbox.framework/Versions/A/AudioToolbox
       0x1077b5000 -        0x10782bfff  com.apple.datadetectorscore (7.0 - 590.3) <83E85A62-44A8-33F8-AD79-AC4C807184C4> /System/Library/PrivateFrameworks/DataDetectorsCore.framework/Versions/A/DataDetectorsCore
       0x10786e000 -        0x107b73fff  com.apple.HIToolbox (2.1.1 - 911.10) <BF7F9C0E-C732-3FB2-9BBC-362888BDA57B> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
       0x107d00000 -        0x107f4bff7  com.apple.QuartzCore (1.11 - 584.40) <ABC7F8FA-5F5A-31F4-868B-FDC4175BAFAC> /System/Library/Frameworks/QuartzCore.framework/Versions/A/QuartzCore
       0x10803c000 -        0x108364fff  com.apple.security (7.0 - 58286.51.6) <7212D257-5324-3DBA-8C26-504D6B8F632A> /System/Library/Frameworks/Security.framework/Versions/A/Security
       0x10853b000 -        0x10853bff3  libauto.dylib (187) <A05C7900-F8C7-3E75-8D3F-909B40C19717> /usr/lib/libauto.dylib
       0x108541000 -        0x108628fff  libxml2.2.dylib (31.10) <503721DB-0D8D-379E-B743-18CE59304155> /usr/lib/libxml2.2.dylib
       0x108661000 -        0x108795fff  com.apple.coreui (2.1 - 494.1) <19624CAA-74DE-3DD3-9585-E64BE866EBFF> /System/Library/PrivateFrameworks/CoreUI.framework/Versions/A/CoreUI
       0x108969000 -        0x1089fcff7  com.apple.audio.CoreAudio (4.3.0 - 4.3.0) <6E3F958D-79BB-3658-99AD-59F16BF756F1> /System/Library/Frameworks/CoreAudio.framework/Versions/A/CoreAudio
       0x108a2a000 -        0x108a2ffff  com.apple.DiskArbitration (2.7 - 2.7) <A6450227-DD23-3100-ADBF-DB1C21E979F7> /System/Library/Frameworks/DiskArbitration.framework/Versions/A/DiskArbitration
       0x108a3a000 -        0x108a3bfff  liblangid.dylib (128) <39C39393-0D05-301D-93B2-F224FC4949AA> /usr/lib/liblangid.dylib
       0x108a40000 -        0x108a6affb  com.apple.MultitouchSupport.framework (1404.4 - 1404.4) <45374A2A-C0BC-3A70-8183-37295205CDFA> /System/Library/PrivateFrameworks/MultitouchSupport.framework/Versions/A/MultitouchSupport
       0x108a7f000 -        0x108a8fffb  com.apple.PerformanceAnalysis (1.194 - 194) <D0211AD1-72B3-3493-92C9-B4F40ED581D5> /System/Library/PrivateFrameworks/PerformanceAnalysis.framework/Versions/A/PerformanceAnalysis
       0x108aac000 -        0x108abbfff  com.apple.opengl (16.5.10 - 16.5.10) <BC4EEFE3-A09B-3998-B723-1415B995B0EE> /System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL
       0x108ac6000 -        0x108b7ffff  com.apple.ColorSync (4.13.0 - 3325) <D283C285-447D-3258-A7E4-59532123B8FF> /System/Library/Frameworks/ColorSync.framework/Versions/A/ColorSync
       0x108bcc000 -        0x108ebbfff  com.apple.CoreImage (13.0.0 - 579.4.11) <702F8035-26FE-3C78-8587-4C9563E03CC4> /System/Library/Frameworks/CoreImage.framework/Versions/A/CoreImage
       0x10905c000 -        0x1091acfff  com.apple.CoreText (352.0 - 578.18) <B8454115-2A4B-3585-A7A1-B47A638F2EEB> /System/Library/Frameworks/CoreText.framework/Versions/A/CoreText
       0x109276000 -        0x1093effe7  com.apple.ImageIO.framework (3.3.0 - 1739.1) <E5E88083-26A7-3E48-8EB4-A1F04E0737CE> /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO
       0x1094a4000 -        0x10952bff7  com.apple.backup.framework (1.9.5 - 1.9.5) <BC020BDD-7C93-37E5-A762-4FDCBD2056A8> /System/Library/PrivateFrameworks/Backup.framework/Versions/A/Backup
       0x10959c000 -        0x1095c6ff3  libarchive.2.dylib (54) <8FC28DD8-E315-3C3E-95FE-D1D2CBE49888> /usr/lib/libarchive.2.dylib
       0x1095d1000 -        0x10996bff7  com.apple.CFNetwork (897.15 - 897.15) <0C03AF39-3527-3E0D-8413-8E1B2A962F0D> /System/Library/Frameworks/CFNetwork.framework/Versions/A/CFNetwork
       0x109c97000 -        0x109d07ff3  com.apple.SystemConfiguration (1.17 - 1.17) <8532B8E9-7E30-35A3-BC4A-DDE8E0614FDA> /System/Library/Frameworks/SystemConfiguration.framework/Versions/A/SystemConfiguration
       0x109d3f000 -        0x109d78ff7  libCRFSuite.dylib (41) <FE5EDB68-2593-3C2E-BBAF-1C52D206F296> /usr/lib/libCRFSuite.dylib
       0x109d92000 -        0x109da2ff3  libbsm.0.dylib (39) <6BC96A72-AFBE-34FD-91B1-748A530D8AE6> /usr/lib/libbsm.0.dylib
       0x109dac000 -        0x109db8ff3  libkxld.dylib (4570.51.1) <C2B927F3-E9D9-3ACF-A358-A51A61749FB4> /usr/lib/system/libkxld.dylib
       0x109dbe000 -        0x109dd6ff7  libcoretls.dylib (155.50.1) <D350052E-DC4D-3185-ADBA-BA48EDCEE955> /usr/lib/libcoretls.dylib
       0x109de2000 -        0x109de3ff3  libcoretls_cfhelpers.dylib (155.50.1) <B297F5D8-F2FE-3566-A752-E9D998B9C039> /usr/lib/libcoretls_cfhelpers.dylib
       0x109de9000 -        0x109dedfff  libpam.2.dylib (22) <7B4D2CE2-1438-387A-9802-5CEEFBF26F86> /usr/lib/libpam.2.dylib
       0x109df3000 -        0x109f86ff7  libsqlite3.dylib (274.8.1) <FCAD6A57-829E-3701-B16E-1833D620E0E8> /usr/lib/libsqlite3.dylib
       0x109fae000 -        0x109fbbfff  libxar.1.dylib (400) <0316128D-3B47-3052-995D-97B4FE5491DC> /usr/lib/libxar.1.dylib
       0x109fc5000 -        0x109fd2ffb  libbz2.1.0.dylib (38) <0A5086BB-4724-3C14-979D-5AD4F26B5B45> /usr/lib/libbz2.1.0.dylib
       0x109fd8000 -        0x109ff1ffb  liblzma.5.dylib (10) <3D419A50-961F-37D2-8A01-3DC7AB7B8D18> /usr/lib/liblzma.5.dylib
       0x109ffa000 -        0x10a174fff  libnetwork.dylib (1229.51.2) <D64FE2A1-CBFD-3817-A701-9A0DDBD70DCF> /usr/lib/libnetwork.dylib
       0x10a1ce000 -        0x10a1e4ff7  libapple_nghttp2.dylib (1.24) <01402BC4-4822-3676-9C80-50D83F816424> /usr/lib/libapple_nghttp2.dylib
       0x10a1f1000 -        0x10a225fff  libpcap.A.dylib (79.20.1) <FA13918B-A247-3181-B256-9B852C7BA316> /usr/lib/libpcap.A.dylib
       0x10a235000 -        0x10a2edff3  libboringssl.dylib (109.50.14) <E6813F87-B5E4-3F7F-A725-E6A7F2BD02EC> /usr/lib/libboringssl.dylib
       0x10a366000 -        0x10a3c6ff3  libusrtcp.dylib (1229.51.2) <3D8806D9-4BA9-35EE-BC44-F58BC2A0962D> /usr/lib/libusrtcp.dylib
       0x10a3d4000 -        0x10a3d4fff  libapple_crypto.dylib (109.50.14) <48BA2E76-BF2F-3522-A54E-D7FB7EAF7A57> /usr/lib/libapple_crypto.dylib
       0x10a3d8000 -        0x10a3e0ffb  com.apple.CoreServices.FSEvents (1239.50.1 - 1239.50.1) <3637CEC7-DF0E-320E-9634-44A442925C65> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/FSEvents.framework/Versions/A/FSEvents
       0x10a3e8000 -        0x10a6bffff  com.apple.CoreServices.CarbonCore (1178.4 - 1178.4) <0D5E19BF-18CB-3FA4-8A5F-F6C787C5EE08> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore
       0x10a736000 -        0x10a7e6ff7  com.apple.Metadata (10.7.0 - 1191.4.13) <B5C22E70-C265-3C9F-865F-B138994A418D> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/Metadata.framework/Versions/A/Metadata
       0x10a865000 -        0x10a8c5fff  com.apple.CoreServices.OSServices (822.31 - 822.31) <690E3C93-8799-39FF-8663-190A49B002E3> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/OSServices.framework/Versions/A/OSServices
       0x10a911000 -        0x10a97ffff  com.apple.SearchKit (1.4.0 - 1.4.0) <3662545A-B1CF-3079-BDCD-C83855CEFEEE> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SearchKit.framework/Versions/A/SearchKit
       0x10a9c3000 -        0x10aa37ffb  com.apple.AE (735.1 - 735.1) <08EBA184-20F7-3725-AEA6-C314448161C6> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE
       0x10aa69000 -        0x10ac26ff7  com.apple.LaunchServices (822.31 - 822.31) <BDFAB0FF-C2C6-375B-9E84-E43E267E2F82> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices
       0x10ad37000 -        0x10ad6bfff  com.apple.DictionaryServices (1.2 - 284.2) <6505B075-41C3-3C62-A4C3-85CE3F6825CD> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/DictionaryServices.framework/Versions/A/DictionaryServices
       0x10ad97000 -        0x10adbbffb  com.apple.coreservices.SharedFileList (71.21 - 71.21) <7DB79D78-9925-33F8-96BA-35AB7AEB326A> /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/SharedFileList.framework/Versions/A/SharedFileList
       0x10addf000 -        0x10adebffb  com.apple.NetFS (6.0 - 4.0) <471DD96F-FA2E-3FE9-9746-2519A6780D1A> /System/Library/Frameworks/NetFS.framework/Versions/A/NetFS
       0x10adf5000 -        0x10ae00fff  com.apple.NetAuth (6.2 - 6.2) <B3795F63-C14A-33E1-9EE6-02A2E7661321> /System/Library/PrivateFrameworks/NetAuth.framework/Versions/A/NetAuth
       0x10ae0d000 -        0x10ae0fffb  com.apple.loginsupport (1.0 - 1) <D1232C1B-80EA-3DF8-9466-013695D0846E> /System/Library/PrivateFrameworks/login.framework/Versions/A/Frameworks/loginsupport.framework/Versions/A/loginsupport
       0x10ae15000 -        0x10ae1dff7  com.apple.TCC (1.0 - 1) <E1EB7272-FE6F-39AB-83CA-B2B5F2A88D9B> /System/Library/PrivateFrameworks/TCC.framework/Versions/A/TCC
       0x10ae28000 -        0x10b050ff7  libmecabra.dylib (779.7.6) <F462F170-E872-3D09-B219-973D5E99C09F> /usr/lib/libmecabra.dylib
       0x10b0ae000 -        0x10b114fff  com.apple.ApplicationServices.ATS (377 - 445.3) <000C4E9F-E0D9-371D-B304-83BA37460724> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/ATS
       0x10b140000 -        0x10b144ff3  com.apple.ColorSyncLegacy (4.13.0 - 1) <A5FB2694-1559-34A8-A3D3-2029F68A63CA> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSyncLegacy.framework/Versions/A/ColorSyncLegacy
       0x10b14d000 -        0x10b19fffb  com.apple.HIServices (1.22 - 624) <828E189A-62F9-3961-8A89-22F508870CC5> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices
       0x10b1d9000 -        0x10b1e7fff  com.apple.LangAnalysis (1.7.0 - 1.7.0) <B65FF7E6-E9B5-34D8-8CA7-63D415A8A9A6> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis
       0x10b1f6000 -        0x10b242fff  com.apple.print.framework.PrintCore (13.4 - 503.2) <B90C67C1-0292-3CEC-885D-F1882CD104BE> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/PrintCore
       0x10b271000 -        0x10b2abfff  com.apple.QD (3.12 - 404.2) <38B20AFF-9D54-3B52-A6DC-C0D71380AA5F> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/QD.framework/Versions/A/QD
       0x10b2d7000 -        0x10b2e3fff  com.apple.speech.synthesis.framework (7.5.1 - 7.5.1) <84ADDF38-36F1-3D3B-B28D-8865FA10FCD7> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis
       0x10b2f8000 -        0x10b3ddff7  com.apple.CoreDisplay (1.0 - 97.16) <FCFB2A8C-7A5E-314B-AA12-04D33656A0E6> /System/Library/Frameworks/CoreDisplay.framework/Versions/A/CoreDisplay
       0x10b40c000 -        0x10b90afc3  com.apple.vImage (8.1 - ???) <A243A7EF-0C8E-3A9A-AA38-44AFD7507F00> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vImage.framework/Versions/A/vImage
       0x10b969000 -        0x10b969fff  com.apple.Accelerate.vecLib (3.11 - vecLib 3.11) <54FF3B43-E66C-3F36-B34B-A2B3B0A36502> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/vecLib
       0x10b96d000 -        0x10bb1afc3  libvDSP.dylib (622.50.5) <40690941-CF89-3F90-A0AC-A4D200744A5D> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib
       0x10bb29000 -        0x10bb57fef  libBNNS.dylib (38.1) <7BAEFDCA-3227-3E07-80D8-59B6370B89C6> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBNNS.dylib
       0x10bb61000 -        0x10bb66ff3  libQuadrature.dylib (3) <3D6BF66A-55B2-3692-BAC7-DEB0C676ED29> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libQuadrature.dylib
       0x10bb6b000 -        0x10bc1cfff  libvMisc.dylib (622.50.5) <BA2532DF-2D68-3DD0-9B59-D434BF702AA4> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvMisc.dylib
       0x10bc29000 -        0x10bfe8ff7  libLAPACK.dylib (1211.50.2) <40ADBA5F-8B2D-30AC-A7AD-7B17C37EE52D> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib
       0x10c049000 -        0x10c1a3fe3  libBLAS.dylib (1211.50.2) <62C659EB-3E32-3B5F-83BF-79F5DF30D5CE> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib
       0x10c1c5000 -        0x10c1daff7  libLinearAlgebra.dylib (1211.50.2) <E8E0B7FD-A0B7-31E5-AF01-81781F71EBBE> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLinearAlgebra.dylib
       0x10c1e4000 -        0x10c264fff  libSparse.dylib (79.50.2) <0DC25CDD-F8C1-3D6E-B472-8B060708424F> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libSparse.dylib
       0x10c27e000 -        0x10c291fff  libSparseBLAS.dylib (1211.50.2) <722573CC-31CC-34B2-9032-E4F652A9CCFE> /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libSparseBLAS.dylib
       0x10c299000 -        0x10c29eff7  com.apple.GPUWrangler (3.18.48 - 3.18.48) <D2BA4CFA-ED0A-3FEC-B5FF-2D6C0557334E> /System/Library/PrivateFrameworks/GPUWrangler.framework/Versions/A/GPUWrangler
       0x10c2a5000 -        0x10c2acff7  com.apple.IOAccelerator (378.18.1 - 378.18.1) <E47DDE66-1B2B-310F-A060-638CA5D86F9C> /System/Library/PrivateFrameworks/IOAccelerator.framework/Versions/A/IOAccelerator
       0x10c2b7000 -        0x10c2cffff  com.apple.IOPresentment (1.0 - 35.1) <214AD582-466F-3844-A0A4-DE0742A8B899> /System/Library/PrivateFrameworks/IOPresentment.framework/Versions/A/IOPresentment
       0x10c2ea000 -        0x10c2eeffb  com.apple.DSExternalDisplay (3.1 - 380) <8D03D346-887A-3CE7-9483-4AD7804D1FBB> /System/Library/PrivateFrameworks/DSExternalDisplay.framework/Versions/A/DSExternalDisplay
       0x10c2f5000 -        0x10c2faffb  libCoreFSCache.dylib (162.6.1) <879B2738-2E8A-3596-AFF8-9C3FB1B6828B> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreFSCache.dylib
       0x10c300000 -        0x10c33afff  com.apple.CoreVideo (1.8 - 0.0) <86CCC036-51BB-3DD1-9601-D93798BCCD0F> /System/Library/Frameworks/CoreVideo.framework/Versions/A/CoreVideo
       0x10c363000 -        0x10c372fff  com.apple.GraphVisualizer (1.0 - 5) <B993B8A2-5700-3DFC-9EB7-4CCEE8F959F1> /System/Library/PrivateFrameworks/GraphVisualizer.framework/Versions/A/GraphVisualizer
       0x10c37d000 -        0x10c37dff7  com.apple.MetalPerformanceShaders.MetalPerformanceShaders (1.0 - 1) <20ECB52B-B5C2-39EA-88E3-DFEC0C3CC9FF> /System/Library/Frameworks/MetalPerformanceShaders.framework/Versions/A/MetalPerformanceShaders
       0x10c382000 -        0x10c54cff3  libFosl_dynamic.dylib (17.8) <C58ED77A-4986-31C2-994C-34DDFB8106F0> /usr/lib/libFosl_dynamic.dylib
       0x10c584000 -        0x10c9b2fff  com.apple.vision.FaceCore (3.3.2 - 3.3.2) <B574FE33-4A41-3611-9738-388EBAF03E37> /System/Library/PrivateFrameworks/FaceCore.framework/Versions/A/FaceCore
       0x10cbd0000 -        0x10cc1efff  com.apple.opencl (2.8.15 - 2.8.15) <83ED39D0-1D39-3593-BA25-70A8A911DE71> /System/Library/Frameworks/OpenCL.framework/Versions/A/OpenCL
       0x10cc37000 -        0x10cc4dfff  libcompression.dylib (47.50.1) <491784AE-CB90-3E27-9081-95C3A1211760> /usr/lib/libcompression.dylib
       0x10cc55000 -        0x10cd77fff  libFontParser.dylib (222.1.4) <FF68FAF6-70BB-3E39-A263-E17B6F5E00D0> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontParser.dylib
       0x10cdfa000 -        0x10ce44ff7  libFontRegistry.dylib (221.3) <C84F7112-4764-3F4B-9FBA-4A022CF6346B> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ATS.framework/Versions/A/Resources/libFontRegistry.dylib
       0x10ce78000 -        0x10ce9bff7  libJPEG.dylib (1739.1) <E925D511-B457-3732-9B67-1A7DFB228EA4> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJPEG.dylib
       0x10cea4000 -        0x10cef2fef  libTIFF.dylib (1739.1) <AD819413-29E3-3B2F-8997-2F88A82D9D83> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libTIFF.dylib
       0x10cf03000 -        0x10cf29feb  libPng.dylib (1739.1) <48633B0C-BE01-3D94-9D9D-A95D50466AF9> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libPng.dylib
       0x10cf35000 -        0x10cf39ffb  libGIF.dylib (1739.1) <D39BE184-279C-36AC-B233-EE17CACDEDB3> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib
       0x10cf3f000 -        0x10d026fef  libJP2.dylib (1739.1) <053925CD-59DB-372F-98A8-C2372FF0B899> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libJP2.dylib
       0x10d050000 -        0x10d052ffb  libRadiance.dylib (1739.1) <A6F1064A-FFFC-3B06-8CBF-5204CDFC41C6> /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libRadiance.dylib
       0x10d057000 -        0x10d09fff3  com.apple.AppleJPEG (1.0 - 1) <8DD410CB-76A1-3F22-9A9F-0491FA0CEB4A> /System/Library/PrivateFrameworks/AppleJPEG.framework/Versions/A/AppleJPEG
       0x10d0ac000 -        0x10d0c7fff  com.apple.MetalPerformanceShaders.MPSCore (1.0 - 1) <0B4455FE-5C97-345C-B416-325EC6D88A2A> /System/Library/Frameworks/MetalPerformanceShaders.framework/Frameworks/MPSCore.framework/Versions/A/MPSCore
       0x10d0d9000 -        0x10d148fef  com.apple.MetalPerformanceShaders.MPSImage (1.0 - 1) <87F14199-C445-34C2-90F8-57C29212483E> /System/Library/Frameworks/MetalPerformanceShaders.framework/Frameworks/MPSImage.framework/Versions/A/MPSImage
       0x10d178000 -        0x10d25fff7  com.apple.MetalPerformanceShaders.MPSNeuralNetwork (1.0 - 1) <FBDDCAE6-EC6E-361F-B924-B3EBDEAC2D2F> /System/Library/Frameworks/MetalPerformanceShaders.framework/Frameworks/MPSNeuralNetwork.framework/Versions/A/MPSNeuralNetwork
       0x10d2c5000 -        0x10d2e9fff  com.apple.MetalPerformanceShaders.MPSMatrix (1.0 - 1) <BD50FD9C-CE92-34AF-8663-968BF89202A0> /System/Library/Frameworks/MetalPerformanceShaders.framework/Frameworks/MPSMatrix.framework/Versions/A/MPSMatrix
       0x10d2f9000 -        0x10d362ff7  com.apple.gpusw.MetalTools (1.0 - 1) <B5F66CF4-BE75-3A0B-A6A0-2F22C7C259D9> /System/Library/PrivateFrameworks/MetalTools.framework/Versions/A/MetalTools
       0x10d3e5000 -        0x10d423ffb  libGLU.dylib (16.5.10) <F6844912-1B86-34DF-9FB5-A428CC7B5B18> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLU.dylib
       0x10d433000 -        0x10d43cff7  libGFXShared.dylib (16.5.10) <6024B1FE-ACD7-3314-B390-85972CB9B778> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGFXShared.dylib
       0x10d444000 -        0x10d44ffff  libGL.dylib (16.5.10) <AB8B6C73-8496-3784-83F6-27737ED03B09> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGL.dylib
       0x10d464000 -        0x10d49ffe7  libGLImage.dylib (16.5.10) <5B41D074-3132-3587-91B6-E441BA8C9F13> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libGLImage.dylib
       0x10d4a8000 -        0x10d4aafff  libCVMSPluginSupport.dylib (16.5.10) <BF5D065A-A38B-3446-9418-799F598072EF> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCVMSPluginSupport.dylib
       0x10d4b0000 -        0x10d4b4fff  libCoreVMClient.dylib (162.6.1) <64ED0A84-225F-39BC-BE0D-C896ACF5B50A> /System/Library/Frameworks/OpenGL.framework/Versions/A/Libraries/libCoreVMClient.dylib
       0x10d4bc000 -        0x10d512ff3  libcups.2.dylib (462.2) <64864CBE-03A3-34C7-9DBB-C93601F183FD> /usr/lib/libcups.2.dylib
       0x10d52c000 -        0x10d545ff7  com.apple.Kerberos (3.0 - 1) <F86DCCDF-93C1-38B3-82C2-477C12E8EE6D> /System/Library/Frameworks/Kerberos.framework/Versions/A/Kerberos
       0x10d55f000 -        0x10d58ffff  com.apple.GSS (4.0 - 2.0) <41087278-74AE-3FA5-8C0E-9C78EB696299> /System/Library/Frameworks/GSS.framework/Versions/A/GSS
       0x10d5b1000 -        0x10d5cdffb  libresolv.9.dylib (65) <E8F3415B-4472-3202-8901-41FD87981DB2> /usr/lib/libresolv.9.dylib
       0x10d5d9000 -        0x10d6caff7  libiconv.2.dylib (51.50.1) <2FEC9707-3FAF-3828-A50D-8605086D060F> /usr/lib/libiconv.2.dylib
       0x10d6db000 -        0x10d74ffff  com.apple.Heimdal (4.0 - 2.0) <18607D75-DB78-3CC7-947E-AC769195164C> /System/Library/PrivateFrameworks/Heimdal.framework/Versions/A/Heimdal
       0x10d781000 -        0x10d786ff3  libheimdal-asn1.dylib (520.50.6) <E358445A-B84E-31B5-BCCD-7E1397519D96> /usr/lib/libheimdal-asn1.dylib
       0x10d78d000 -        0x10d798fff  com.apple.OpenDirectory (10.13 - 207.50.1) <220FB6F2-4892-3A66-8838-C134CF657D3A> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/OpenDirectory
       0x10d7ad000 -        0x10d7b6ff3  com.apple.CommonAuth (4.0 - 2.0) <4D237B25-27E5-3577-948B-073659F6D3C0> /System/Library/PrivateFrameworks/CommonAuth.framework/Versions/A/CommonAuth
       0x10d7be000 -        0x10d7daffb  com.apple.CFOpenDirectory (10.13 - 207.50.1) <C2715A7A-2E5C-3A21-ADB4-726F707A1294> /System/Library/Frameworks/OpenDirectory.framework/Versions/A/Frameworks/CFOpenDirectory.framework/Versions/A/CFOpenDirectory
       0x10d7fc000 -        0x10d888ff7  com.apple.securityfoundation (6.0 - 55185.50.5) <087D601E-7813-3F9E-97EE-BC7081F520BD> /System/Library/Frameworks/SecurityFoundation.framework/Versions/A/SecurityFoundation
       0x10d8f7000 -        0x10d98aff7  com.apple.APFS (1.0 - 1) <D1CE52E0-45C0-30C4-B440-E2CF2F74CEE5> /System/Library/PrivateFrameworks/APFS.framework/Versions/A/APFS
       0x10d9a2000 -        0x10d9a5ffb  libutil.dylib (51.20.1) <216D18E5-0BAF-3EAF-A38E-F6AC37CBABD9> /usr/lib/libutil.dylib
       0x10d9ac000 -        0x10d9d4fff  com.apple.applesauce (1.0 - ???) <CCA8B094-1BCE-3AE3-A0A7-D544C818DE36> /System/Library/PrivateFrameworks/AppleSauce.framework/Versions/A/AppleSauce
       0x10d9df000 -        0x10d9e6ff7  com.apple.LinguisticData (1.0 - 238.3) <49A54649-1021-3DBD-99B8-1B2EDFFA5378> /System/Library/PrivateFrameworks/LinguisticData.framework/Versions/A/LinguisticData
       0x10d9ee000 -        0x10da04ff7  libmarisa.dylib (9) <D6D2D55D-1D2E-3442-B152-B18803C0ABB4> /usr/lib/libmarisa.dylib
       0x10da12000 -        0x10da54fff  com.apple.Lexicon-framework (1.0 - 33.5) <DC94CF9E-1EB4-3C0E-B298-CA1190885276> /System/Library/PrivateFrameworks/Lexicon.framework/Versions/A/Lexicon
       0x10da64000 -        0x10da6ffff  libChineseTokenizer.dylib (28) <53633C9B-A3A8-36F7-A53C-432D802F4BB8> /usr/lib/libChineseTokenizer.dylib
       0x10da7e000 -        0x10da8efff  libcmph.dylib (6) <A5509EE8-7E00-3224-8814-015B077A3CF5> /usr/lib/libcmph.dylib
       0x10da97000 -        0x10db8cff7  com.apple.LanguageModeling (1.0 - 159.5.3) <7F0AC200-E3DD-39FB-8A95-00DD70B66A9F> /System/Library/PrivateFrameworks/LanguageModeling.framework/Versions/A/LanguageModeling
       0x10dbb2000 -        0x10dbc2ff7  com.apple.CoreEmoji (1.0 - 69.3) <A4357F5C-0C38-3A61-B456-D7321EB2CEE5> /System/Library/PrivateFrameworks/CoreEmoji.framework/Versions/A/CoreEmoji
       0x10dbcc000 -        0x10dbd0ffb  com.apple.xpc.ServiceManagement (1.0 - 1) <5BFDB3ED-73A7-3035-A5BC-ADA6E4F74BFD> /System/Library/Frameworks/ServiceManagement.framework/Versions/A/ServiceManagement
       0x10dbd8000 -        0x10dbdfff7  com.apple.coreservices.BackgroundTaskManagement (1.0 - 57.1) <51A41CA3-DB1D-3380-993E-99C54AEE518E> /System/Library/PrivateFrameworks/BackgroundTaskManagement.framework/Versions/A/BackgroundTaskManagement
       0x10dbeb000 -        0x10dc13fff  libxslt.1.dylib (15.12) <4A5E011D-8B29-3135-A52B-9A9070ABD752> /usr/lib/libxslt.1.dylib
       0x10dc21000 -        0x10dcb6ffb  com.apple.ink.framework (10.9 - 221) <5206C8B0-22DA-36C9-998E-846EDB626D5B> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Ink.framework/Versions/A/Ink
       0x10dcea000 -        0x10dda7ff7  com.apple.TextureIO (3.7 - 3.7) <F8BAC954-405D-3CC3-AB7B-048C866EF980> /System/Library/PrivateFrameworks/TextureIO.framework/Versions/A/TextureIO
       0x10ddc7000 -        0x10de48fdf  libate.dylib (1.13.1) <178ACDAD-DE7E-346C-A613-1CBF7929AC07> /usr/lib/libate.dylib
       0x10de52000 -        0x10de62ff7  com.apple.CrashReporterSupport (10.13 - 1) <4D0DF741-8BFA-3BCF-971D-6EF849019534> /System/Library/PrivateFrameworks/CrashReporterSupport.framework/Versions/A/CrashReporterSupport
       0x10de74000 -        0x10df86fff  com.apple.Sharing (1019.46 - 1019.46) <1266C41E-3CA9-3EFC-8413-A37D52EA9FB2> /System/Library/PrivateFrameworks/Sharing.framework/Versions/A/Sharing
       0x10e076000 -        0x10e09cffb  com.apple.IconServices (97.6 - 97.6) <A56D826D-20D2-34BE-AACC-A80CFCB4E915> /System/Library/PrivateFrameworks/IconServices.framework/Versions/A/IconServices
       0x10e0be000 -        0x10e0e6fff  com.apple.framework.Apple80211 (13.0 - 1361.7) <16627876-8CF5-3502-A1D6-35FCBDD5E79A> /System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Apple80211
       0x10e0f5000 -        0x10e225ff7  com.apple.CoreUtils (5.5 - 550.44) <DFC364C3-0812-31B5-9C79-C81C2DFDDB8B> /System/Library/PrivateFrameworks/CoreUtils.framework/Versions/A/CoreUtils
       0x10e2dd000 -        0x10e368ff3  com.apple.framework.CoreWLAN (13.0 - 1350.1) <E862CC02-69D2-3503-887B-B6E8223081E7> /System/Library/Frameworks/CoreWLAN.framework/Versions/A/CoreWLAN
       0x10e3c6000 -        0x10e4caffb  com.apple.Bluetooth (6.0.5 - 6.0.5f3) <85F1B5A6-03C5-3D5A-90B8-5FC86349E330> /System/Library/Frameworks/IOBluetooth.framework/Versions/A/IOBluetooth
       0x10e556000 -        0x10e574fff  com.apple.ProtocolBuffer (1 - 260) <40704740-4A53-3010-A49B-08D1D69D1D5E> /System/Library/PrivateFrameworks/ProtocolBuffer.framework/Versions/A/ProtocolBuffer
       0x10e591000 -        0x10e5f5fff  com.apple.framework.CoreWiFi (13.0 - 1350.1) <6EC5DEB3-6E2F-3DC2-BE59-1FD05175FB0C> /System/Library/PrivateFrameworks/CoreWiFi.framework/Versions/A/CoreWiFi
       0x10e657000 -        0x10e680ffb  com.apple.CoreBluetooth (1.0 - 1) <E1335074-9D07-370E-8440-61C4874BAC56> /System/Library/Frameworks/CoreBluetooth.framework/Versions/A/CoreBluetooth
       0x10e69f000 -        0x10e6dfff7  com.apple.DebugSymbols (181.0 - 181.0) <299A0238-ED78-3676-B131-274D972824AA> /System/Library/PrivateFrameworks/DebugSymbols.framework/Versions/A/DebugSymbols
       0x10e6ff000 -        0x10e790fff  com.apple.CoreSymbolication (9.3 - 64026) <BAF3CE6E-8140-3159-BF1B-B953816459A0> /System/Library/PrivateFrameworks/CoreSymbolication.framework/Versions/A/CoreSymbolication
       0x10e7e5000 -        0x10e86efc7  com.apple.Symbolication (9.3 - 64033) <FAA17252-6378-34A4-BBBB-22DF54EC1626> /System/Library/PrivateFrameworks/Symbolication.framework/Versions/A/Symbolication
       0x10e8c8000 -        0x10e8d7fef  com.apple.AppleFSCompression (96.30.2 - 1.0) <ABFF224B-22D6-35F6-A072-9548FD388EB7> /System/Library/PrivateFrameworks/AppleFSCompression.framework/Versions/A/AppleFSCompression
       0x10e8e1000 -        0x10e8eeff7  com.apple.SpeechRecognitionCore (4.0.13 - 4.0.13) <8B5418A4-CDC5-3200-AEF0-F109E0DF9019> /System/Library/PrivateFrameworks/SpeechRecognitionCore.framework/Versions/A/SpeechRecognitionCore
       0x10e8fe000 -        0x10e901ffb  com.apple.CommonPanels (1.2.6 - 98) <2391761C-5CAA-3F68-86B7-50B37927B104> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/CommonPanels.framework/Versions/A/CommonPanels
       0x10e909000 -        0x10e90cffb  com.apple.help (1.3.8 - 66) <DEBADFA8-C189-3195-B0D6-A1F2DE95882A> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Help.framework/Versions/A/Help
       0x10e913000 -        0x10e918fff  com.apple.ImageCapture (9.0 - 9.0) <23B4916F-3B43-3DFF-B956-FC390EECA284> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ImageCapture.framework/Versions/A/ImageCapture
       0x10e928000 -        0x10e942ff7  com.apple.openscripting (1.7 - 174) <1B2A1F9E-5534-3D61-83CA-9199B39E8708> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/OpenScripting.framework/Versions/A/OpenScripting
       0x10e958000 -        0x10e959fff  com.apple.print.framework.Print (12 - 267) <3682ABFB-2561-3419-847D-02C247F4800D> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/Print.framework/Versions/A/Print
       0x10e95f000 -        0x10e961ff7  com.apple.securityhi (9.0 - 55006) <C1406B8D-7D05-3959-808F-9C82189CF57F> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/SecurityHI.framework/Versions/A/SecurityHI
       0x10ed99000 -        0x10ed9afff +_heapq.cpython-37m-darwin.so (???) <3CD355DB-06FD-4E99-E801-06B3ECCCF9F7> /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_heapq.cpython-37m-darwin.so
       0x10ee1e000 -        0x10ee1ffff +_posixsubprocess.cpython-37m-darwin.so (???) <34B55F18-A4D9-36F1-11C7-0FC66AE97445> /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_posixsubprocess.cpython-37m-darwin.so
       0x10ee22000 -        0x10ee25ff7 +select.cpython-37m-darwin.so (???) <3DD32E0F-132E-3613-1CB9-BEB4C4815BDA> /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/select.cpython-37m-darwin.so
       0x10ee2b000 -        0x10ee30fef +math.cpython-37m-darwin.so (???) <9878F8E7-373C-2423-36D4-9DBBAE9D567A> /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/math.cpython-37m-darwin.so
       0x10ee77000 -        0x10ee81fff +_socket.cpython-37m-darwin.so (???) <C08ADF4F-9F1F-D919-B538-10795D149307> /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_socket.cpython-37m-darwin.so
       0x10ef4e000 -        0x10ef4efff +_opcode.cpython-37m-darwin.so (???) <251AA31E-2E67-2250-24DD-7B3EDDDAD9EA> /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_opcode.cpython-37m-darwin.so
       0x10efd1000 -        0x10efd5fff +zlib.cpython-37m-darwin.so (???) <0BE8B1F5-A68E-9802-8043-3CE8271E7450> /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/zlib.cpython-37m-darwin.so
       0x10efdb000 -        0x10efdcfff +_bz2.cpython-37m-darwin.so (???) <EB1A185C-1EDA-6182-24CC-EA76C92B05D5> /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_bz2.cpython-37m-darwin.so
       0x10efe0000 -        0x10efe0fff +grp.cpython-37m-darwin.so (???) <F2B045D2-8CDC-17B4-327E-4ED961454078> /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/grp.cpython-37m-darwin.so
       0x10efe3000 -        0x10efe6ff7 +_hashlib.cpython-37m-darwin.so (???) <786E4EA8-7224-954C-D3F5-33D6CA3AB15C> /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_hashlib.cpython-37m-darwin.so
       0x10efeb000 -        0x10eff4ff7 +_blake2.cpython-37m-darwin.so (???) <78BCCB2C-1863-8A50-91EC-F60557ABCE86> /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_blake2.cpython-37m-darwin.so
       0x10eff9000 -        0x10eff9fff +_bisect.cpython-37m-darwin.so (???) <E138D47F-CDEE-8171-FD12-2BD1FF7A04F3> /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_bisect.cpython-37m-darwin.so
       0x10effc000 -        0x10effdfff +_random.cpython-37m-darwin.so (???) <E1AF77F9-BDC7-959E-CB7D-B5B722B8B543> /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_random.cpython-37m-darwin.so
       0x110440000 -        0x11046efff +_lzma.cpython-37m-darwin.so (???) <EC0EF344-1C71-8B81-1F9F-5077430D0106> /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_lzma.cpython-37m-darwin.so
       0x1105b8000 -        0x110610ff7 +libssl.1.1.dylib (1.1) <266D2584-1056-919E-B3E4-B243BE332899> /Library/Frameworks/Python.framework/Versions/3.7/lib/libssl.1.1.dylib
       0x110630000 -        0x1108347b7 +libcrypto.1.1.dylib (1.1) <649634DF-2DE0-43F0-95B3-E9702FD64B4B> /Library/Frameworks/Python.framework/Versions/3.7/lib/libcrypto.1.1.dylib
       0x1108b3000 -        0x1108c6fff +_sha3.cpython-37m-darwin.so (???) <8473A44B-5561-B9BE-C7BC-71A17C29BBB3> /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_sha3.cpython-37m-darwin.so
       0x11094c000 -        0x110951fff +_struct.cpython-37m-darwin.so (???) <24D14CF9-5325-366E-DEF1-62C5DFEBC1B8> /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_struct.cpython-37m-darwin.so
       0x11095a000 -        0x11096dfff +_pickle.cpython-37m-darwin.so (???) <C852BFFB-37E4-4131-CC1B-E98CAA484E4C> /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_pickle.cpython-37m-darwin.so
       0x11097a000 -        0x11097bfff +_queue.cpython-37m-darwin.so (???) <6709FF22-F75F-B847-D335-00DB34CE04F8> /Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/lib-dynload/_queue.cpython-37m-darwin.so
       0x1123d8000 -        0x112409ff3  com.apple.CoreServicesInternal (309.1 - 309.1) <EB09CAFC-AE9B-3257-BE45-5471D9F64AAD> /System/Library/PrivateFrameworks/CoreServicesInternal.framework/CoreServicesInternal
       0x11268b000 -        0x1126beff7  libTrueTypeScaler.dylib (222.1.4) <4734ECD6-6F41-3A16-AE35-265BDC1572C5> /System/Library/Frameworks/ApplicationServices.framework/Frameworks/ATS.framework/Resources/libTrueTypeScaler.dylib
       0x1126fd000 -        0x112713fef  libCGInterfaces.dylib (417.2) <ED0EAE3C-D963-3DF7-A408-4F00FF1C8C34> /System/Library/Frameworks/Accelerate.framework/Frameworks/vImage.framework/Versions/A/Libraries/libCGInterfaces.dylib
       0x112817000 -        0x112817fff  libmetal_timestamp.dylib (802.4.5) <BCA42032-C91F-3463-BA1E-1433262ACA0A> /System/Library/PrivateFrameworks/GPUCompiler.framework/Versions/3802/Libraries/libmetal_timestamp.dylib
       0x113ebe000 -        0x113fb4ff7  com.apple.driver.AppleIntelBDWGraphicsMTLDriver (10.32.48 - 10.3.2) <CB899415-0073-3FD5-973D-2E49BDF5FC43> /System/Library/Extensions/AppleIntelBDWGraphicsMTLDriver.bundle/Contents/MacOS/AppleIntelBDWGraphicsMTLDriver
       0x1146f9000 -        0x1146fafff  libodfde.dylib (24.50.1) <972F9662-D4FA-304F-9D13-AC440F908A6F> /usr/lib/libodfde.dylib
       0x114940000 -        0x1149defff  ColorSyncDeprecated.dylib (3325) <1938C255-8221-32C4-8D37-9E27E6C9085E> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/ColorSyncLegacy.framework/Versions/A/Resources/ColorSyncDeprecated.dylib
       0x114af8000 -        0x114af9fff  com.apple.TrustEvaluationAgent (2.0 - 31) <39F533B2-211E-3635-AF47-23F27749FF4A> /System/Library/PrivateFrameworks/TrustEvaluationAgent.framework/Versions/A/TrustEvaluationAgent
       0x114e37000 -        0x114e59fff  com.apple.framework.familycontrols (4.1 - 410) <F8720CCF-6E8F-33E1-9328-A2875971B97B> /System/Library/PrivateFrameworks/FamilyControls.framework/Versions/A/FamilyControls
       0x114e6f000 -        0x114e7bffb  com.apple.CommerceCore (1.0 - 656.20) <AF242149-5360-3552-99E6-7C98623C1A08> /System/Library/PrivateFrameworks/CommerceKit.framework/Versions/A/Frameworks/CommerceCore.framework/Versions/A/CommerceCore
       0x114e8b000 -        0x114eb7fff  com.apple.framework.SystemAdministration (1.0 - 1.0) <2916D56F-1F72-3A6B-8F2F-9E6EFE6B962A> /System/Library/PrivateFrameworks/SystemAdministration.framework/Versions/A/SystemAdministration
       0x114ee2000 -        0x114ee5ff3  com.apple.SecCodeWrapper (4.0 - 360.50.7) <D7136CA5-CC5E-3B3C-AF1A-A8E5FF2023DF> /System/Library/PrivateFrameworks/SecCodeWrapper.framework/Versions/A/SecCodeWrapper
       0x114eec000 -        0x114ef1fff  com.apple.LoginUICore (4.0 - 4.0) <29953093-7A93-3547-8BB8-FBBB422CE20D> /System/Library/PrivateFrameworks/LoginUIKit.framework/Versions/A/Frameworks/LoginUICore.framework/Versions/A/LoginUICore
       0x1159da000 -        0x1159f5ff3  com.apple.AppContainer (4.0 - 360.50.7) <59F95A1A-15DF-33CE-9E52-DDEEFDC4D138> /System/Library/PrivateFrameworks/AppContainer.framework/Versions/A/AppContainer
       0x115a0d000 -        0x115afbff7  com.apple.DiskManagement (11.4 - 1428) <BEA3294F-3BF2-3395-A5C2-B26BEF9508C5> /System/Library/PrivateFrameworks/DiskManagement.framework/Versions/A/DiskManagement
       0x115b47000 -        0x115b52ff7  com.apple.DirectoryService.Framework (10.13 - 207.50.1) <29D21437-7B41-3E9D-B5D4-462986AED83F> /System/Library/Frameworks/DirectoryService.framework/Versions/A/DirectoryService
       0x115b5c000 -        0x115c2eff7  com.apple.DiskImagesFramework (480.50.10 - 480.50.10) <08B48BB9-51A4-3AC4-9E24-AA1C338BA548> /System/Library/PrivateFrameworks/DiskImages.framework/Versions/A/DiskImages
       0x115c90000 -        0x115d1dff7  libCoreStorage.dylib (546.50.1) <6AFD6AAE-2EFE-3CF3-90C6-A66F67FCB309> /usr/lib/libCoreStorage.dylib
       0x115d47000 -        0x115d52ff7  libcsfde.dylib (546.50.1) <D02562A4-CCE6-35FE-8BDE-05BB68DA0038> /usr/lib/libcsfde.dylib
       0x115d5f000 -        0x115d92ff7  com.apple.MediaKit (16 - 873) <EC6E742E-305D-362F-9E22-BF313013054C> /System/Library/PrivateFrameworks/MediaKit.framework/Versions/A/MediaKit
       0x115da6000 -        0x115e60fff  com.apple.DiscRecording (9.0.3 - 9030.4.5) <35D1FF9A-432C-39AD-9C1F-9022246EC5C0> /System/Library/Frameworks/DiscRecording.framework/Versions/A/DiscRecording
       0x115ecb000 -        0x115ecefff  com.apple.EFILogin (2.0 - 2) <65FC80C1-965D-3FE9-9666-41DB87A934A6> /System/Library/PrivateFrameworks/EFILogin.framework/Versions/A/EFILogin
       0x115ed7000 -        0x115f2effb  com.apple.ProtectedCloudStorage (1.0 - 1) <351DCB70-4AA2-326E-B14E-0874AA37FA9B> /System/Library/PrivateFrameworks/ProtectedCloudStorage.framework/Versions/A/ProtectedCloudStorage
       0x115f73000 -        0x115fc7ffb  libcurl.4.dylib (105.40.1) <B04E7791-EAF9-3D72-B4ED-DD8F135140EC> /usr/lib/libcurl.4.dylib
       0x115fdd000 -        0x11616efff  libcrypto.35.dylib (22.50.2) <97828BFD-4675-35DF-BE2E-C6D1555BB71D> /usr/lib/libcrypto.35.dylib
       0x1161e3000 -        0x116236ffb  libssl.35.dylib (22.50.2) <AF523E9B-7183-3A87-8FB4-E26936EC4FDB> /usr/lib/libssl.35.dylib
       0x116253000 -        0x116288fff  com.apple.LDAPFramework (2.4.28 - 194.5) <08888215-BBCE-3402-8142-2C9ADB091580> /System/Library/Frameworks/LDAP.framework/Versions/A/LDAP
       0x116296000 -        0x1162a8fff  libsasl2.2.dylib (211) <04EF3F61-12EC-3319-A649-851999F4C7A4> /usr/lib/libsasl2.2.dylib
       0x1162b1000 -        0x1162baff7  com.apple.frameworks.CoreDaemon (1.3 - 1.3) <35A43584-2AF8-3202-A139-27D916E444BE> /System/Library/PrivateFrameworks/CoreDaemon.framework/Versions/B/CoreDaemon
       0x1162c8000 -        0x1162d0ff3  com.apple.AppleSRP (5.0 - 1) <4CEC34CF-63E3-3023-B61B-F8D133698534> /System/Library/PrivateFrameworks/AppleSRP.framework/Versions/A/AppleSRP
    0x7fff6942c000 -     0x7fff694769df  dyld (551.3) <AFAB4EFA-7020-34B1-BBEF-0F26C6D3CA36> /usr/lib/dyld

External Modification Summary:
  Calls made by other processes targeting this process:
    task_for_pid: 1
    thread_create: 0
    thread_set_state: 0
  Calls made by this process:
    task_for_pid: 0
    thread_create: 0
    thread_set_state: 0
  Calls made by all processes on this machine:
    task_for_pid: 50201
    thread_create: 0
    thread_set_state: 0

VM Region Summary:
ReadOnly portion of Libraries: Total=196.0M resident=0K(0%) swapped_out_or_unallocated=196.0M(100%)
Writable regions: Total=109.3M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=109.3M(100%)
 
                                VIRTUAL   REGION 
REGION TYPE                        SIZE    COUNT (non-coalesced) 
===========                     =======  ======= 
Accelerate framework               128K        2 
Activity Tracing                   256K        2 
CG backing stores                 3488K        6 
CG image                             4K        2 
CoreGraphics                         8K        2 
CoreImage                            8K        3 
CoreUI image data                  852K        6 
CoreUI image file                  180K        4 
Dispatch continuations            8192K        2 
Kernel Alloc Once                    8K        2 
MALLOC                            76.4M       58 
MALLOC guard page                   48K       11 
MALLOC_LARGE (reserved)            512K        3         reserved VM address space (unallocated)
Memory Tag 242                      12K        2 
STACK GUARD                         24K        7 
Stack                             2668K        7 
VM_ALLOCATE                        168K       18 
__DATA                            23.3M      335 
__FONT_DATA                          4K        2 
__LINKEDIT                        46.6M      274 
__TEXT                           149.4M      274 
__UNICODE                          560K        2 
__UNIXSTACK                       16.0M        2 
mapped file                       52.3M       18 
shared memory                      628K       10 
===========                     =======  ======= 
TOTAL                            381.3M     1029 
TOTAL, minus reserved VM space   380.8M     1029 

Model: MacBookAir7,2, BootROM MBA71.0176.B00, 2 processors, Intel Core i5, 1.8 GHz, 8 GB, SMC 2.27f2
Graphics: Intel HD Graphics 6000, Intel HD Graphics 6000, Built-In
Memory Module: BANK 0/DIMM0, 4 GB, DDR3, 1600 MHz, 0x80AD, 0x483943434E4E4E424C54424C41522D4E5444
Memory Module: BANK 1/DIMM0, 4 GB, DDR3, 1600 MHz, 0x80AD, 0x483943434E4E4E424C54424C41522D4E5444
AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x117), Broadcom BCM43xx 1.0 (7.77.37.29.1a7)
Bluetooth: Version 6.0.5f3, 3 services, 27 devices, 1 incoming serial ports
Network Service: Wi-Fi, AirPort, en0
Serial ATA Device: APPLE SSD SM0128G, 121.33 GB
USB Device: USB 3.0 Bus
USB Device: BRCM20702 Hub
USB Device: Bluetooth USB Host Controller
Thunderbolt Bus: MacBook Air, Apple Inc., 27.2

----------
files: Screen Shot 2018-09-05 at 15.36.57.png
messages: 324615
nosy: JokeNeverSoke
priority: normal
severity: normal
status: open
title: subprocess
versions: Python 3.7
Added file: https://bugs.python.org/file47787/Screen Shot 2018-09-05 at 15.36.57.png

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

From report at bugs.python.org  Wed Sep  5 06:57:22 2018
From: report at bugs.python.org (Ross Burton)
Date: Wed, 05 Sep 2018 10:57:22 +0000
Subject: [New-bugs-announce] [issue34585] Don't use AC_RUN_IFELSE to
 determine float endian
Message-ID: <1536145042.39.0.56676864532.issue34585@psf.upfronthosting.co.za>


New submission from Ross Burton <ross at burtonini.com>:

Currently configure.ac uses AC_RUN_IFELSE to determine the byte order of floats and doubles.  This hurts when cross-compiling because a default is set, resulting in Python silently falling back to sub-optimal codepaths.

A partial improvement would be to not set a fallback, to force the user to set the right byte order explicitly.

However this test can be done without running anything.  autoconf-archive has a macro that uses a carefully constructed double that encodes to an ASCII string in the binary, which is then examined using grep.  Evil genius.

Attached is a POC using this.  Currently the autoconf-archive macro only handles big and little endian not the ARM OABI mixed-endian format, so configure.ac assumes if the byte order is unknown then it's the crazy mixed-endian.

To be honest OABI is so old now, I don't believe anyone actually uses it anymore: everyone still on ARMv4 should have moved to EABI many years ago, and the mixed-endian support could be removed from Py3 in the future.

----------
components: Build
files: 0001-Don-t-do-runtime-test-to-get-float-byte-order.patch
keywords: patch
messages: 324627
nosy: rossburton
priority: normal
severity: normal
status: open
title: Don't use AC_RUN_IFELSE to determine float endian
versions: Python 3.8
Added file: https://bugs.python.org/file47788/0001-Don-t-do-runtime-test-to-get-float-byte-order.patch

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

From report at bugs.python.org  Wed Sep  5 10:00:10 2018
From: report at bugs.python.org (Zahari Dim)
Date: Wed, 05 Sep 2018 14:00:10 +0000
Subject: [New-bugs-announce] [issue34586] collections.ChainMap should have a
 get_where method
Message-ID: <1536156010.09.0.56676864532.issue34586@psf.upfronthosting.co.za>


New submission from Zahari Dim <zaharid at gmail.com>:

When using ChainMap I have frequently needed to know the mapping inside the list
that contains the effective instance of a particular key. I have needed this
when using ChainMap to contain a piece of configuration with multiple sources,
like for example

```
from mycollections import ChainMap
configsources = ["Command line", "Config file", "Defaults"]
config = ChainMap(config_from_commandline(), config_from_file(),
                  default_config())

class BadConfigError(Exception): pass
def get_key(key):
    try:
        index, value = config.get_where(key)
    except KeyError as e:
        raise BadConfigError(f"No such key: '{key}'") from e
    try:
        result = validate(key, value)
    except ValidationError as e:
        raise BadConfigError(f"Key '{key}' defined in {configsources[index] }"
                             f"is invalid: {e}") from e
    return result
```

I have also needed this when implementing custom DSLs (e.g. specifying which
context is a particular construct allowed to see).

I think this method would be generally useful for the ChainMap class and
moreover the best way of implementing it I can think of is  by copying the
`__getitem__` method and retaining the index:

```
class ChainMap(collections.ChainMap):
    def get_where(self, key):
        for i, mapping in enumerate(self.maps):
            try:
                return i, mapping[key]             # can't use 'key in mapping' with defaultdict
            except KeyError:
                pass
        return self.__missing__(key)            # support subclasses that define __missing__
```

I'd be happy to write a patch that does just this.

----------
components: Library (Lib)
messages: 324632
nosy: Zahari.Dim
priority: normal
severity: normal
status: open
title: collections.ChainMap should have a get_where method
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Wed Sep  5 11:01:19 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Sep 2018 15:01:19 +0000
Subject: [New-bugs-announce] [issue34587] test_socket: testCongestion()
 hangs on my Fedora 28
Message-ID: <1536159679.92.0.56676864532.issue34587@psf.upfronthosting.co.za>


New submission from STINNER Victor <vstinner at redhat.com>:

Hi,

test_socket started to hang recently on my Fedora 28 laptop. No idea why it started to hang.

vstinner at apu$ ./python -m test -v test_socket -m testCongestion --timeout=5
== CPython 3.8.0a0 (heads/master-dirty:39487196c8, Sep 4 2018, 23:08:20) [GCC 8.1.1 20180712 (Red Hat 8.1.1-5)]
== Linux-4.17.19-200.fc28.x86_64-x86_64-with-glibc2.26 little-endian
== cwd: /home/vstinner/prog/python/master/build/test_python_29510
== CPU count: 8
== encodings: locale=UTF-8, FS=utf-8
Run tests sequentially
0:00:00 load avg: 1.34 [1/1] test_socket
testCongestion (test.test_socket.RDSTest) ... Timeout (0:00:05)!
Thread 0x00007fccf51b1700 (most recent call first):
  File "/home/vstinner/prog/python/master/Lib/test/test_socket.py", line 2074 in _testCongestion
  File "/home/vstinner/prog/python/master/Lib/test/test_socket.py", line 332 in clientRun

Thread 0x00007fcd082ee080 (most recent call first):
  File "/home/vstinner/prog/python/master/Lib/threading.py", line 296 in wait
  File "/home/vstinner/prog/python/master/Lib/threading.py", line 552 in wait
  File "/home/vstinner/prog/python/master/Lib/test/test_socket.py", line 2059 in testCongestion
  File "/home/vstinner/prog/python/master/Lib/unittest/case.py", line 610 in run
  File "/home/vstinner/prog/python/master/Lib/unittest/case.py", line 658 in __call__
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122 in run
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 84 in __call__
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 122 in run
  File "/home/vstinner/prog/python/master/Lib/unittest/suite.py", line 84 in __call__
  File "/home/vstinner/prog/python/master/Lib/unittest/runner.py", line 176 in run
  File "/home/vstinner/prog/python/master/Lib/test/support/__init__.py", line 1900 in _run_suite
  File "/home/vstinner/prog/python/master/Lib/test/support/__init__.py", line 1990 in run_unittest
  File "/home/vstinner/prog/python/master/Lib/test/test_socket.py", line 6032 in test_main
  File "/home/vstinner/prog/python/master/Lib/test/libregrtest/runtest.py", line 179 in runtest_inner
  File "/home/vstinner/prog/python/master/Lib/test/libregrtest/runtest.py", line 140 in runtest
  File "/home/vstinner/prog/python/master/Lib/test/libregrtest/main.py", line 384 in run_tests_sequential
  File "/home/vstinner/prog/python/master/Lib/test/libregrtest/main.py", line 488 in run_tests
  File "/home/vstinner/prog/python/master/Lib/test/libregrtest/main.py", line 566 in _main
  File "/home/vstinner/prog/python/master/Lib/test/libregrtest/main.py", line 531 in main
  File "/home/vstinner/prog/python/master/Lib/test/libregrtest/main.py", line 584 in main
  File "/home/vstinner/prog/python/master/Lib/test/__main__.py", line 2 in <module>
  File "/home/vstinner/prog/python/master/Lib/runpy.py", line 85 in _run_code
  File "/home/vstinner/prog/python/master/Lib/runpy.py", line 193 in _run_module_as_main

----------
components: Tests
messages: 324643
nosy: vstinner
priority: normal
severity: normal
status: open
title: test_socket: testCongestion() hangs on my Fedora 28
versions: Python 3.8

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

From report at bugs.python.org  Wed Sep  5 13:52:12 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 05 Sep 2018 17:52:12 +0000
Subject: [New-bugs-announce] [issue34588] traceback module can drop a frame
Message-ID: <1536169932.26.0.56676864532.issue34588@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

Consider the following script:
import traceback

def fill_stack(depth):
    if depth <= 1:
        return traceback.format_stack()
    else:
        return fill_stack(depth - 1)

assert fill_stack(4) != fill_stack(5)

On the Python 3 versions I tested, this script doesn't fail! Somehow traceback is producing identical tracebacks for different callstacks.

----------
components: Library (Lib)
messages: 324648
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: traceback module can drop a frame
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Wed Sep  5 15:36:35 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 05 Sep 2018 19:36:35 +0000
Subject: [New-bugs-announce] [issue34589] Py_Initialize() and Py_Main()
 should not enable C locale coercion
Message-ID: <1536176195.07.0.56676864532.issue34589@psf.upfronthosting.co.za>


New submission from STINNER Victor <vstinner at redhat.com>:

According to Nick Coghlan, author of the PEP 538, the C locale coercion should not be enabled by Py_Initialize() and Py_Main(), only by the python3 program.

Attached PR fix this issue.

----------
components: Interpreter Core
messages: 324649
nosy: vstinner
priority: normal
severity: normal
status: open
title: Py_Initialize() and Py_Main() should not enable C locale coercion
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Wed Sep  5 16:39:26 2018
From: report at bugs.python.org (Nathaniel Manista)
Date: Wed, 05 Sep 2018 20:39:26 +0000
Subject: [New-bugs-announce] [issue34590] "Logging HOWTO" should share an
 example of best practices for using logging in a library
Message-ID: <1536179966.39.0.56676864532.issue34590@psf.upfronthosting.co.za>


New submission from Nathaniel Manista <nathaniel at google.com>:

https://docs.python.org/3.8/howto/logging.html#configuring-logging-for-a-library is a bit too short and doesn't answer some questions that I have as a library author about the best ways to use logging in a library.

Should I make use of a single logger object in my library, multiple loggers in a tree, or multiple unrelated loggers? Since I have just one public module, I'm tempted to say that I should just use one logger object.

Should I present as part of my public API the name of the logger object(s) used? Probably - the documentation starts with "When developing a library which uses logging, you should take care to document how the library uses logging - for example, the names of loggers used.". But should I also include the logger objects in my API? If an application wants to reach my logger, why should they use "logging.getLogger(<name that I shared with them>)" rather than "my_library.LOGGER"?

Should I use my library's fully-qualified name as the name of its logger? This seems like a great idea because it's unlikely to bring up any new conflicts. Is it a best practice? Is there any better practice?

The "Configuring Logging for a Library" text could answer these questions, and maybe it should, but... I really think a toy library example that library authors could follow would also help a great deal.

----------
assignee: docs at python
components: Documentation
messages: 324652
nosy: Nathaniel Manista, docs at python
priority: normal
severity: normal
status: open
title: "Logging HOWTO" should share an example of best practices for using logging in a library
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/issue34590>
_______________________________________

From report at bugs.python.org  Wed Sep  5 16:41:44 2018
From: report at bugs.python.org (Quae Quack)
Date: Wed, 05 Sep 2018 20:41:44 +0000
Subject: [New-bugs-announce] [issue34591] smtplib mixes RFC821 and RFC822
 addresses
Message-ID: <1536180104.03.0.56676864532.issue34591@psf.upfronthosting.co.za>


New submission from Quae Quack <quae at daurnimator.com>:

smtplib.sendmsg is documented to take RFC822 addresses. and e.g. if the `to_addrs` argument isn't provided then it gets the To address directly from the headers (which is in RFC822 form).

However it then proceeds to use it as an RFC821 address and sends it over the SMTP connection. https://github.com/python/cpython/blob/874809ea389e6434787e773a6054a08e0b81f734/Lib/smtplib.py#L542

----------
components: Library (Lib)
messages: 324653
nosy: Quae Quack
priority: normal
severity: normal
status: open
title: smtplib mixes RFC821 and RFC822 addresses
type: security

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

From report at bugs.python.org  Wed Sep  5 17:35:41 2018
From: report at bugs.python.org (Sergei Lebedev)
Date: Wed, 05 Sep 2018 21:35:41 +0000
Subject: [New-bugs-announce] [issue34592] cdll.LoadLibrary allows None as an
 argument
Message-ID: <1536183341.44.0.56676864532.issue34592@psf.upfronthosting.co.za>


New submission from Sergei Lebedev <superbobry at gmail.com>:

LoadLibrary in Python 2.7 through 3.7 accepts None as an argument. I wonder if this has been allowed for a reason? If not, it should probably be changed to raise a TypeError instead.

>>> ctypes.cdll.LoadLibrary(None)
<CDLL 'None', handle fffffffffffffffe at 10eedbe90>

Interestingly, on Python 2.7 LoadLibrary explicitly mentions None as allowed in the error message:

>>> ctypes.cdll.LoadLibrary(42)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "[...]/ctypes/__init__.py", line 444, in LoadLibrary
    return self._dlltype(name)
  File "[...]/ctypes/__init__.py", line 366, in __init__
    self._handle = _dlopen(self._name, mode)
TypeError: dlopen() argument 1 must be string or None, not int

A side-effect of None being allowed is that chaining find_library and LoadLibrary is error-prone:

>>> ctypes.cdll.LoadLibrary(find_library("foobar"))
<CDLL 'None', handle fffffffffffffffe at 10ef35fd0>

----------
messages: 324654
nosy: superbobry
priority: normal
severity: normal
status: open
title: cdll.LoadLibrary allows None as an argument
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/issue34592>
_______________________________________

From report at bugs.python.org  Wed Sep  5 21:10:24 2018
From: report at bugs.python.org (Gary Simpson)
Date: Thu, 06 Sep 2018 01:10:24 +0000
Subject: [New-bugs-announce] [issue34593] Missing inttypes.h
Message-ID: <1536196224.28.0.56676864532.issue34593@psf.upfronthosting.co.za>


New submission from Gary Simpson <gary at garysimpson.org>:

I started with Anaconda3 (python3.64). When I add #include "python.h" to my C++ code, I get the visual studio 2012 compile error:
anaconda3\include\pyport.h(6): fatal error C1083: Cannot open include file: 'inttypes.h': No such file or directory

I then installed python 3.7, and put that include directory into my project. But I get the same error when I try to compile. 
python.h calls pyport.h, which tries to call inttypes.h, which it can't find. I searched and cannot find inttypes.h anywhere on my computer.

----------
messages: 324656
nosy: garyrsimpson
priority: normal
severity: normal
status: open
title: Missing inttypes.h
type: compile error
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Thu Sep  6 01:48:47 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Thu, 06 Sep 2018 05:48:47 +0000
Subject: [New-bugs-announce] [issue34594] Some tests use hardcoded errno
 values
Message-ID: <1536212927.15.0.56676864532.issue34594@psf.upfronthosting.co.za>


New submission from Zackery Spytz <zspytz at gmail.com>:

test_spwd.py and test_tabnanny.py use hardcoded errno values when they test some exception messages.

----------
components: Tests
messages: 324662
nosy: ZackerySpytz
priority: normal
severity: normal
status: open
title: Some tests use hardcoded errno values
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Thu Sep  6 05:13:30 2018
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 06 Sep 2018 09:13:30 +0000
Subject: [New-bugs-announce] [issue34595] PyUnicode_FromFormat(): add %T
 format for an object type name
Message-ID: <1536225210.1.0.56676864532.issue34595@psf.upfronthosting.co.za>


New submission from STINNER Victor <vstinner at redhat.com>:

The PEP 399 requires that C accelerator behaves exactly as Python, but a lot of C code truncates type name to an arbitrary length: 80, 100, 200, up to 500 (not sure if it's a number of bytes or characters).

Py_TYPE(obj)->tp_name is a common pattern: it would be nice to have a new "%T" format in PyUnicode_FromFormat(), so it can be used directly in PyErr_Format(), to format an object type name.

Attached PR implements the proposed %T format and modify unicodeobject.c to use it.

I propose to then write a second PR to modify all C code of CPython using Py_TYPE(obj)->tp_name to use the new %T type.

----------
components: Interpreter Core
messages: 324675
nosy: vstinner
priority: normal
severity: normal
status: open
title: PyUnicode_FromFormat(): add %T format for an object type name
versions: Python 3.8

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

From report at bugs.python.org  Thu Sep  6 09:05:21 2018
From: report at bugs.python.org (Naitree Zhu)
Date: Thu, 06 Sep 2018 13:05:21 +0000
Subject: [New-bugs-announce] [issue34596] [unittest] raise error if @skip is
 used with an argument that looks like a test method
Message-ID: <1536239121.16.0.56676864532.issue34596@psf.upfronthosting.co.za>


New submission from Naitree Zhu <naitreey at gmail.com>:

When using @skip decorator, `reason` argument is required. But one could easily overlook that and use it like so:

    class SomeTest(TestCase):

        @skip
        def test_method(self):
            # ...

The test actually passes when running with unittest, because it's equivalent to

    class SomeTest(TestCase):

        def test_method(self):
            # ...
        test_method = skip(test_method)

This gives the illusion that @skip decorator worked as expected.

I propose we should check the passed in `reason`, and raise error if it looks like a function/method, therefore prevent this erroneous usage.

In practice, this behavior has misled people using the decorator in the unintended way. For example: In this chapter of Test-Driven Development with Python (http://www.obeythetestinggoat.com/book/chapter_organising_test_files.html), the author used @skip decorator without `reason` argument.

----------
components: Library (Lib), Tests
messages: 324688
nosy: Naitree Zhu
priority: normal
severity: normal
status: open
title: [unittest] raise error if @skip is used with an argument that looks like a test method
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/issue34596>
_______________________________________

From report at bugs.python.org  Thu Sep  6 10:59:08 2018
From: report at bugs.python.org (Zorg)
Date: Thu, 06 Sep 2018 14:59:08 +0000
Subject: [New-bugs-announce] [issue34597] Python needs to check existence of
 functions at runtime for targeting older macOS platforms
Message-ID: <1536245948.33.0.56676864532.issue34597@psf.upfronthosting.co.za>


New submission from Zorg <zorgiepoo at gmail.com>:

If one wants to compile Python and embed it in their applications, or more generally, deploy the framework / libraries to older systems, then Python needs to check the existence of functions at runtime that are unavailable to Python's supported minimum OS.

For example, Python makes use of:
clock_gettime
getentropy

These functions are only available on macOS 10.12. Python currently states it supports 10.9. Checking for their existence at compile time isn't good enough; compiling Python on 10.13 and deploying back to 10.9 or 10.11 for example will not work, and cause a crash at runtime. One can make sure the functions are weakly linked and check they aren't NULL to get around this.

There may be more such functions Python is using; I haven't extensively searched for all usages.

Alternatively, Python could state that it does not properly support embedding (probably not desirable), or Python could bump the minimum supported OS requirements in its documentation.

Else one might be able to compile Python by turning off such features? But the user needs to know what those are, Python gives no warnings when MACOSX_DEPLOYMENT_TARGET/--mmacosx-version-min are low enough, and Python wouldn't be able to use those functions when they are actually available on newer systems.

----------
components: macOS
messages: 324698
nosy: Zorg, ned.deily, ronaldoussoren
priority: normal
severity: normal
status: open
title: Python needs to check existence of functions at runtime for targeting older macOS platforms
type: crash
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Thu Sep  6 12:09:03 2018
From: report at bugs.python.org (andy polandski)
Date: Thu, 06 Sep 2018 16:09:03 +0000
Subject: [New-bugs-announce] [issue34598] How to fix? Error in Kali linux
 python 2.7 - Collecting pip From cffi callback <function _verify_callback
 at 0x7f9b12e56050>: Traceback (most recent call last): File
 "/usr/local/lib/python2.7/dist-packages/OpenSSL/SSL.py", line 309,
 in wrapper
Message-ID: <1536250143.3.0.56676864532.issue34598@psf.upfronthosting.co.za>


New submission from andy polandski <peterlandski at gmail.com>:

root at kali:~# python get-pip.py
Collecting pip
>From cffi callback <function _verify_callback at 0x7f9b12e56050>:
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/OpenSSL/SSL.py", line 309, in wrapper
    _lib.X509_up_ref(x509)
AttributeError: 'module' object has no attribute 'X509_up_ref'
  Retrying (Retry(total=4, connect=None, read=None, redirect=None, status=None)) after connection broken by 'SSLError(SSLError("bad handshake: Error([('SSL routines', 'ssl3_get_server_certificate', 'certificate verify failed')],)",),)': /simple/pip/

----------
messages: 324702
nosy: andy polandski
priority: normal
severity: normal
status: open
title: How to fix? Error in Kali linux python 2.7 - Collecting pip From cffi callback <function _verify_callback at 0x7f9b12e56050>: Traceback (most recent call last):   File "/usr/local/lib/python2.7/dist-packages/OpenSSL/SSL.py", line 309, in wrapper
versions: Python 2.7

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

From report at bugs.python.org  Thu Sep  6 14:12:14 2018
From: report at bugs.python.org (Sergey Fedoseev)
Date: Thu, 06 Sep 2018 18:12:14 +0000
Subject: [New-bugs-announce] [issue34599] improve performance of
 _Py_bytes_capitalize()
Message-ID: <1536257534.96.0.56676864532.issue34599@psf.upfronthosting.co.za>


New submission from Sergey Fedoseev <fedoseev.sergey at gmail.com>:

Currently _Py_bytes_capitalize() checks case before using conversion table, performance can be improved by using conversion table unconditionally. Benchmarks:

$ python -m perf timeit --compare-to ~/tmp/cpython-master-venv/bin/python -s "b = b'0'*10000000" "b.capitalize()"
/home/sergey/tmp/cpython-master-venv/bin/python: ..................... 7.26 ms +- 0.03 ms
/home/sergey/tmp/cpython-dev-venv/bin/python: ..................... 7.27 ms +- 0.04 ms
Mean +- std dev: [/home/sergey/tmp/cpython-master-venv/bin/python] 7.26 ms +- 0.03 ms -> [/home/sergey/tmp/cpython-dev-venv/bin/python] 7.27 ms +- 0.04 ms: 1.00x slower (+0%)
Not significant!

$ python -m perf timeit --compare-to ~/tmp/cpython-master-venv/bin/python -s "b = b'a'*10000000" "b.capitalize()"
/home/sergey/tmp/cpython-master-venv/bin/python: ..................... 7.25 ms +- 0.03 ms
/home/sergey/tmp/cpython-dev-venv/bin/python: ..................... 7.26 ms +- 0.03 ms
Mean +- std dev: [/home/sergey/tmp/cpython-master-venv/bin/python] 7.25 ms +- 0.03 ms -> [/home/sergey/tmp/cpython-dev-venv/bin/python] 7.26 ms +- 0.03 ms: 1.00x slower (+0%)

$ python -m perf timeit --compare-to ~/tmp/cpython-master-venv/bin/python -s "b = b'A'*10000000" "b.capitalize()"
/home/sergey/tmp/cpython-master-venv/bin/python: ..................... 18.1 ms +- 0.0 ms
/home/sergey/tmp/cpython-dev-venv/bin/python: ..................... 7.31 ms +- 0.13 ms
Mean +- std dev: [/home/sergey/tmp/cpython-master-venv/bin/python] 18.1 ms +- 0.0 ms -> [/home/sergey/tmp/cpython-dev-venv/bin/python] 7.31 ms +- 0.13 ms: 2.47x faster (-60%)

----------
components: Interpreter Core
messages: 324707
nosy: sir-sigurd
priority: normal
severity: normal
status: open
title: improve performance of _Py_bytes_capitalize()
type: performance
versions: Python 3.8

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

From report at bugs.python.org  Fri Sep  7 02:10:16 2018
From: report at bugs.python.org (Martin Hosken)
Date: Fri, 07 Sep 2018 06:10:16 +0000
Subject: [New-bugs-announce] [issue34600] python3 regression
 ElementTree.iterparse() unable to capture comments
Message-ID: <1536300616.73.0.56676864532.issue34600@psf.upfronthosting.co.za>


New submission from Martin Hosken <martin_hosken at sil.org>:

This is a regression from python2 by being forced to use cElementTree.

I have code that uses iterparse to process an XML file, but I also want to process comments and so I have a comment handling function called by the parser during iterparse. Under python3 I can find no way to achieve the same thing:

```
parser = et.XMLParser(target=et.TreeBuilder())
parser.parser.CommentHandler = myCommentHandler
for event, elem in et.iterparse(fh, parser=parser):
    ...
```

Somewhat ugly but works in python2, but I can find no way to set a comment handler on the parser in python3.


1. There is no way(?) to get to xml.etree.ElementTree.XMLParser since the C implementation completely masks the python versions.
2. It is possible to create a subclass of TreeBuilder to add a comment method. But the C version XMLParser requires that its TreeBuilder not be a subclass, when used in iterparse.

The only solution I found was to copy the XMLParser code out of ElementTree into a private module and use that pure python implementation.

Suggested solutions:
1. Allow access to all the python implementations in ElementTree and not just Element.
2. Allow a comments method to be passed to the XMLParser on creation.

Thank you.

----------
components: XML
messages: 324719
nosy: Martin Hosken
priority: normal
severity: normal
status: open
title: python3 regression ElementTree.iterparse() unable to capture comments
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Fri Sep  7 02:35:02 2018
From: report at bugs.python.org (David Lin)
Date: Fri, 07 Sep 2018 06:35:02 +0000
Subject: [New-bugs-announce] [issue34601] Typo: "which would rather raise
 MemoryError than give up", than or then?
Message-ID: <1536302102.39.0.56676864532.issue34601@psf.upfronthosting.co.za>


New submission from David Lin <david.dl.lin at nokia-sbell.com>:

https://docs.python.org/3/library/exceptions.html

exception OverflowError
Raised when the result of an arithmetic operation is too large to be represented. This cannot occur for integers (which would rather raise MemoryError than give up). However, for historical reasons, OverflowError is sometimes raised for integers that are outside a required range. Because of the lack of standardization of floating point exception handling in C, most floating point operations are not checked.

In sentence: "which would rather raise MemoryError than give up", should we use "then" instead of "than"?

Thanks,
David Lin

----------
assignee: docs at python
components: Documentation
messages: 324720
nosy: davidlin, docs at python
priority: normal
severity: normal
status: open
title: Typo: "which would rather raise MemoryError than give up", than or then?
versions: Python 3.7

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

From report at bugs.python.org  Fri Sep  7 06:34:46 2018
From: report at bugs.python.org (marche147)
Date: Fri, 07 Sep 2018 10:34:46 +0000
Subject: [New-bugs-announce] [issue34602] python3 resource.setrlimit strange
 behaviour under macOS
Message-ID: <1536316486.92.0.56676864532.issue34602@psf.upfronthosting.co.za>


New submission from marche147 <bitmarche at gmail.com>:

Consider the following code:

```
import resource
s, h = resource.getrlimit(resource.RLIMIT_STACK)
resource.setrlimit(resource.RLIMIT_STACK, (h, h))
```

Running this under macOS with python 3.6.5 gives the following exception:

```
bash-3.2$ uname -a
Darwin arch-osx 17.7.0 Darwin Kernel Version 17.7.0: Thu Jun 21 22:53:14 PDT 2018; root:xnu-4570.71.2~1/RELEASE_X86_64 x86_64
bash-3.2$ cat test.py
import resource
s, h = resource.getrlimit(resource.RLIMIT_STACK)
resource.setrlimit(resource.RLIMIT_STACK, (h, h))
bash-3.2$ python3 test.py
Traceback (most recent call last):
  File "test.py", line 3, in <module>
    resource.setrlimit(resource.RLIMIT_STACK, (h, h))
ValueError: current limit exceeds maximum limit
```

Nevertheless, when using python 2.7.10 under the same environment, this code works perfectly without exceptions being thrown. Additionally, neither of these operations fail under the same circumstances :

```
bash-3.2$ cat test.c
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <errno.h>
#include <sys/resource.h>

int main() {
  struct rlimit rl;
  if(getrlimit(RLIMIT_STACK, &rl) < 0) {
    perror("getrlimit");
    exit(1);
  }

  rl.rlim_cur = rl.rlim_max;
  if(setrlimit(RLIMIT_STACK, &rl) < 0) {
    perror("setrlimit");
    exit(1);
  }
  return 0;
}
bash-3.2$ gcc -o test test.c
bash-3.2$ ./test
```

```
bash-3.2$ ulimit -s -H
65532
bash-3.2$ ulimit -s
8192
bash-3.2$ ulimit -s 65532
bash-3.2$ ulimit -s
65532
```

I have also tried to run the above-mentioned python script on linux, also it does not generate exceptions both on python2 (2.7.10) & python3 (3.6.5).

----------
components: Library (Lib)
messages: 324731
nosy: marche147
priority: normal
severity: normal
status: open
title: python3 resource.setrlimit strange behaviour under macOS
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Fri Sep  7 07:15:17 2018
From: report at bugs.python.org (MatteoL)
Date: Fri, 07 Sep 2018 11:15:17 +0000
Subject: [New-bugs-announce] [issue34603] ctypes On Windows: error calling C
 function that returns a struc containing 3 bools
Message-ID: <1536318917.89.0.56676864532.issue34603@psf.upfronthosting.co.za>


New submission from MatteoL <mlovato at gmail.com>:

Marshalling the following C structure with ctypes in Windows (compiled with VS2015) is not working correctly.
As you can see, in the simple demo program I attached, the integer I pass as a parameter gets somehow corrupted. I use cdecl calling convention.

The corruption happens only if the returned structure contains 3 booleans, if I add a fourth bool to the structure than I get expected results.

In linux (compiling with Gcc) the same code (with 3 booleans) work as expected.


typedef uint64_t CustomHandle;

typedef struct
{
	bool first;
	bool second;
	bool third;
} Flags;

CustomHandle GetHandle();
Flags GetFlags(CustomHandle handle);


As already mention I attached all the files to reproduce the issue with the related cmake file

----------
components: ctypes
files: MarshallingTest.zip
messages: 324732
nosy: mattneri
priority: normal
severity: normal
status: open
title: ctypes On Windows: error calling C function that returns a struc containing 3 bools
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7
Added file: https://bugs.python.org/file47789/MarshallingTest.zip

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

From report at bugs.python.org  Fri Sep  7 09:14:54 2018
From: report at bugs.python.org (William Grzybowski)
Date: Fri, 07 Sep 2018 13:14:54 +0000
Subject: [New-bugs-announce] [issue34604] Possible mojibake in pwd.getpwnam
 and grp.getgrnam
Message-ID: <1536326094.99.0.56676864532.issue34604@psf.upfronthosting.co.za>


New submission from William Grzybowski <william88 at gmail.com>:

Issue was spotted by @vstinner while reviewing https://github.com/python/cpython/pull/7081

pwd.getpwnam and grp.getgrnam are susceptible to mojibake as they are using encoded bytes instead of unicode in the error message.

----------
components: Extension Modules
messages: 324738
nosy: wg
priority: normal
severity: normal
status: open
title: Possible mojibake in pwd.getpwnam and grp.getgrnam
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/issue34604>
_______________________________________

From report at bugs.python.org  Fri Sep  7 10:22:00 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 07 Sep 2018 14:22:00 +0000
Subject: [New-bugs-announce] [issue34605] Avoid master/slave terminology
Message-ID: <1536330120.62.0.56676864532.issue34605@psf.upfronthosting.co.za>


New submission from STINNER Victor <vstinner at redhat.com>:

For diversity reasons, it would be nice to try to avoid "master" and "slave" terminology which can be associated to slavery.

For more context, see:

* https://github.com/antirez/redis/issues/3185
* https://www.drupal.org/node/2275877
* https://issues.apache.org/jira/browse/COUCHDB-2248
* https://github.com/django/django/pull/2692

----------
assignee: docs at python
components: 2to3 (2.x to 3.x conversion tool), Argument Clinic, Build, Cross-Build, Demos and Tools, Distutils, Documentation, Extension Modules, FreeBSD, IDLE, IO, Installation, Interpreter Core, Library (Lib), Regular Expressions, SSL, Tests, Tkinter, Unicode, Windows, XML, asyncio, ctypes, email, macOS
messages: 324739
nosy: Alex.Willmer, asvetlov, barry, docs at python, dstufft, eric.araujo, ezio.melotti, koobs, larry, mrabarnett, ned.deily, paul.moore, r.david.murray, ronaldoussoren, steve.dower, terry.reedy, tim.golden, vstinner, yselivanov, zach.ware
priority: normal
severity: normal
status: open
title: Avoid master/slave terminology
versions: Python 3.8

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

From report at bugs.python.org  Fri Sep  7 10:41:59 2018
From: report at bugs.python.org (Kyle Altendorf)
Date: Fri, 07 Sep 2018 14:41:59 +0000
Subject: [New-bugs-announce] [issue34606] Unable to read zip file with extra
Message-ID: <1536331319.28.0.56676864532.issue34606@psf.upfronthosting.co.za>


New submission from Kyle Altendorf <sda at fstab.net>:

This was first found over in Twisted tests.  We probably aren't too terribly worried about it but I wanted to report here anyways.

https://twistedmatrix.com/trac/ticket/9525

Both 3.6 and 3.7 write the same file (sha at the end) based on the script in the first snippet.  3.6 can read both files, 3.7 can't read either.


----
    altendky at lt:~/twisted$ cat ../z.py
    import sys
    import zipfile

    print(sys.version)

    fn = sys.argv[1]
    print(fn)

    with zipfile.ZipFile(fn, 'w') as zf:
        zi = zipfile.ZipInfo("0")
        zi.extra = b"hello, extra"
        zf.writestr(zi, b"the real data")

    zipfile.ZipFile(fn)

----
    altendky at lt:~/twisted$ venv36/bin/python ../z.py 36.zip
    3.6.6 (default, Jul 24 2018, 16:23:12)
    [GCC 6.3.0 20170516]
    36.zip

----
    altendky at lt:~/twisted$ venv37/bin/python ../z.py 37.zip
    3.7.0 (default, Jul  7 2018, 15:49:24)
    [GCC 6.3.0 20170516]
    37.zip
    Traceback (most recent call last):
      File "../z.py", line 14, in <module>
        zipfile.ZipFile(fn)
      File "/home/altendky/.pyenv/versions/3.7.0/lib/python3.7/zipfile.py", line 1200, in __init__
        self._RealGetContents()
      File "/home/altendky/.pyenv/versions/3.7.0/lib/python3.7/zipfile.py", line 1323, in _RealGetContents
        x._decodeExtra()
      File "/home/altendky/.pyenv/versions/3.7.0/lib/python3.7/zipfile.py", line 440, in _decodeExtra
        raise BadZipFile("Corrupt extra field %04x (size=%d)" % (tp, ln))
    zipfile.BadZipFile: Corrupt extra field 6568 (size=27756)

----
    altendky at lt:~/twisted$ cat ../z.py
    import sys
    import zipfile

    print(sys.version)

    fn = sys.argv[1]
    print(fn)

    #with zipfile.ZipFile(fn, 'w') as zf:
    #    zi = zipfile.ZipInfo("0")
    #    zi.extra = b"hello, extra"
    #    zf.writestr(zi, b"the real data")

    zipfile.ZipFile(fn)

----
    altendky at lt:~/twisted$ venv36/bin/python ../z.py 37.zip
    3.6.6 (default, Jul 24 2018, 16:23:12)
    [GCC 6.3.0 20170516]
    37.zip

----
    altendky at lt:~/twisted$ venv37/bin/python ../z.py 36.zip
    3.7.0 (default, Jul  7 2018, 15:49:24)
    [GCC 6.3.0 20170516]
    36.zip
    Traceback (most recent call last):
      File "../z.py", line 14, in <module>
        zipfile.ZipFile(fn)
      File "/home/altendky/.pyenv/versions/3.7.0/lib/python3.7/zipfile.py", line 1200, in __init__
        self._RealGetContents()
      File "/home/altendky/.pyenv/versions/3.7.0/lib/python3.7/zipfile.py", line 1323, in _RealGetContents
        x._decodeExtra()
      File "/home/altendky/.pyenv/versions/3.7.0/lib/python3.7/zipfile.py", line 440, in _decodeExtra
        raise BadZipFile("Corrupt extra field %04x (size=%d)" % (tp, ln))
    zipfile.BadZipFile: Corrupt extra field 6568 (size=27756)

----
    altendky at lt:~/twisted$ sha256sum 36.zip
    0f54bd6ab84facfeefc2c38f12c30eb84101b3be3d91f8826f6fa36e73b86cb6  36.zip

----
    altendky at lt:~/twisted$ sha256sum 37.zip
    0f54bd6ab84facfeefc2c38f12c30eb84101b3be3d91f8826f6fa36e73b86cb6  37.zip

----------
components: Library (Lib)
messages: 324743
nosy: altendky
priority: normal
severity: normal
status: open
title: Unable to read zip file with extra
type: crash
versions: Python 3.7

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

From report at bugs.python.org  Fri Sep  7 11:02:00 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 07 Sep 2018 15:02:00 +0000
Subject: [New-bugs-announce] [issue34607] test_multiprocessing_forkserver is
 altering the environment on AMD64 FreeBSD 10.x Shared 3.7
Message-ID: <1536332520.99.0.56676864532.issue34607@psf.upfronthosting.co.za>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

test_multiprocessing_forkserver is altering the environment on AMD64 FreeBSD 10.x Shared 3.7:

https://buildbot.python.org/all/#/builders/124/builds/545/steps/4/logs/stdio

== Tests result: ENV CHANGED ==
393 tests OK.
10 slowest tests:
- test_tools: 8 min 56 sec
- test_tokenize: 5 min 47 sec
- test_multiprocessing_spawn: 5 min 42 sec
- test_multiprocessing_forkserver: 4 min 29 sec
- test_lib2to3: 4 min 3 sec
- test_multiprocessing_fork: 3 min 46 sec
- test_concurrent_futures: 3 min 43 sec
- test_asyncio: 2 min 36 sec
- test_compile: 1 min 49 sec
- test_io: 1 min 45 sec
1 test altered the execution environment:
    test_multiprocessing_forkserver
22 tests skipped:
    test_dbm_gnu test_devpoll test_epoll test_gdb test_idle test_ioctl
    test_msilib test_ossaudiodev test_smtpnet test_spwd test_ssl
    test_startfile test_tcl test_tix test_tk test_ttk_guionly
    test_ttk_textonly test_turtle test_winconsoleio test_winreg
    test_winsound test_zipfile64
Total duration: 20 min 58 sec
Tests result: ENV CHANGED
*** Error code 3
Stop.
make: stopped in /usr/home/buildbot/python/3.7.koobs-freebsd10/build
program finished with exit code 1
elapsedTime=1260.965772

----------
components: Tests
messages: 324753
nosy: pablogsal
priority: normal
severity: normal
status: open
title: test_multiprocessing_forkserver is altering the environment on AMD64 FreeBSD 10.x Shared 3.7
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Fri Sep  7 12:30:04 2018
From: report at bugs.python.org (Bryan)
Date: Fri, 07 Sep 2018 16:30:04 +0000
Subject: [New-bugs-announce] [issue34608] gc.get_referrers behavior change
 3.6 to 3.7
Message-ID: <1536337804.03.0.56676864532.issue34608@psf.upfronthosting.co.za>


New submission from Bryan <bryanv at ftml.net>:

When called on a local object inside a function, gc.get_referrers no longer returns a Frame as one of the references. I could not find anything in the release notes or changeling that indicated that this is an intentional change. 

The following script generates different output when run on Python 3.6 vs Python 3.7 (on linux, OSX, or Windows):

```
# referrers.py
import gc, sys

class FakeMod(object): pass

extra = []

def test():
    mod = FakeMod()
    extra.append(mod)
    referrers = gc.get_referrers(mod)
    print(".".join(str(x) for x in sys.version_info[:3]), ":", len(referrers), referrers)

test()
```

Output:

~ master*
(py37) ? python test.py
3.7.0 : 1 [[<__main__.FakeMod object at 0x10b65e320>]]

~ master*
(base) ? python test.py
3.6.6 : 2 [[<__main__.FakeMod object at 0x106f3ea90>], <frame object at 0x10684b648>]

----------
components: Library (Lib)
messages: 324771
nosy: bryevdv
priority: normal
severity: normal
status: open
title: gc.get_referrers behavior change 3.6 to 3.7
versions: Python 3.7

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

From report at bugs.python.org  Fri Sep  7 14:30:27 2018
From: report at bugs.python.org (piscvau@yahoo.fr)
Date: Fri, 07 Sep 2018 18:30:27 +0000
Subject: [New-bugs-announce] [issue34609] Idle Unitest
Message-ID: <1536345027.41.0.56676864532.issue34609@psf.upfronthosting.co.za>


New submission from piscvau at yahoo.fr <piscvau at yahoo.fr>:

Idle is unable to import unittest. and raises an attributeError.
Output of the Python shell Idle is included in the file bug idle.

several files raise this exception
on of them is included in this report
the Trace for Idle is as follows :
Python 3.6.5 (default, Apr  1 2018, 05:46:30) 
[GCC 7.3.0] on linux
Type "copyright", "credits" or "license()" for more information.
>>> 
[DEBUG ON]
>>> 
 RESTART: /home/odile/Documents/dev_logiciels/pyhton/openclassrooms/labyrinthe/roboc2/test/test_carte.py 
Traceback (most recent call last):
  File "/home/odile/Documents/dev_logiciels/pyhton/openclassrooms/labyrinthe/roboc2/test/test_carte.py", line 5, in <module>
    import unittest
  File "<frozen importlib._bootstrap>", line 968, in _find_and_load
  File "<frozen importlib._bootstrap>", line 148, in __enter__
  File "<frozen importlib._bootstrap>", line 174, in _get_module_lock
  File "<frozen importlib._bootstrap>", line 59, in __init__
  File "<frozen importlib._bootstrap>", line 59, in __init__
  File "/usr/lib/python3.6/bdb.py", line 51, in trace_dispatch
    return self.dispatch_line(frame)
  File "/usr/lib/python3.6/bdb.py", line 69, in dispatch_line
    self.user_line(frame)
  File "/usr/lib/python3.6/idlelib/debugger.py", line 24, in user_line
    self.gui.interaction(message, frame)
AttributeError: '_ModuleLock' object has no attribute 'name'
[DEBUG ON]

Idle version is 3.6.5

----------
assignee: terry.reedy
components: IDLE
files: test_main.py
messages: 324779
nosy: piscvau at yahoo.fr, terry.reedy
priority: normal
severity: normal
status: open
title: Idle Unitest
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file47790/test_main.py

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

From report at bugs.python.org  Fri Sep  7 19:43:37 2018
From: report at bugs.python.org (deltaclock)
Date: Fri, 07 Sep 2018 23:43:37 +0000
Subject: [New-bugs-announce] [issue34610] Incorrect iteration of
 Manager.dict() method of the multiprocessing module.
Message-ID: <1536363817.94.0.56676864532.issue34610@psf.upfronthosting.co.za>


New submission from deltaclock <deltaclock at protonmail.com>:

The manager class of the multiprocessing module doesnt implement __next__ or __iter__ on its dictionary method and relies on using __getitem__.

This results in an unexpected functionality of an object that is supposed to act like a dict, and instead of looping over the dictionary keys it loops over its values.

The user needs to call dict() on this object in order to loop over it correctly, which is not that obvious.

The problem originates from there https://github.com/python/cpython/blob/master/Lib/multiprocessing/managers.py#L1136

Poc link: https://hastebin.com/codoqihowi.py

----------
components: Library (Lib)
files: test.py
messages: 324813
nosy: deltaclock
priority: normal
severity: normal
status: open
title: Incorrect iteration of Manager.dict() method of the multiprocessing module.
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file47792/test.py

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

From report at bugs.python.org  Sat Sep  8 03:21:56 2018
From: report at bugs.python.org (taketakeyyy)
Date: Sat, 08 Sep 2018 07:21:56 +0000
Subject: [New-bugs-announce] [issue34611] some examples in 'itertools'
 modules docs are inaccuracy.
Message-ID: <1536391316.81.0.56676864532.issue34611@psf.upfronthosting.co.za>


Change by taketakeyyy <taketakeyyy at gmail.com>:


----------
assignee: docs at python
components: Documentation
nosy: docs at python, taketakeyyy at gmail.com
priority: normal
severity: normal
status: open
title: some examples in 'itertools' modules docs are inaccuracy.
versions: Python 3.8

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

From report at bugs.python.org  Sat Sep  8 18:29:55 2018
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9s_Delfino?=)
Date: Sat, 08 Sep 2018 22:29:55 +0000
Subject: [New-bugs-announce] [issue34612] doc Some classes are treated as
 functions in Built-in Functions
Message-ID: <1536445795.33.0.56676864532.issue34612@psf.upfronthosting.co.za>


New submission from Andr?s Delfino <adelfino at gmail.com>:

Beyond other classes documented as functions (classmethod, enumerate, filter, map, reversed, staticmethod, super and zip), the following issues exist:

* memoryview, range, and tuple are marked as functions
* complex and object treat themselves as functions in their descriptions

Attached PR fixes this.

----------
assignee: docs at python
components: Documentation
messages: 324864
nosy: adelfino, docs at python
priority: normal
severity: normal
status: open
title: doc Some classes are treated as functions in Built-in Functions
type: enhancement
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Sun Sep  9 03:00:39 2018
From: report at bugs.python.org (Laurent Peuch)
Date: Sun, 09 Sep 2018 07:00:39 +0000
Subject: [New-bugs-announce] [issue34613] asyncio.StreamReader
 initialization documentation incorrectly declare limit as None
Message-ID: <1536476439.55.0.56676864532.issue34613@psf.upfronthosting.co.za>


New submission from Laurent Peuch <python at worlddomination.be>:

asyncio.StreamReader documentation incorrectly declare its initialization argument "limit" to be "None" by default https://docs.python.org/3/library/asyncio-stream.html#asyncio.StreamReader

In the source code it is set to _DEFAULT_LIMIT https://github.com/python/cpython/blob/0afada163c7ef25c3a9d46ed445481fb69f2ecaf/Lib/asyncio/streams.py#L353 

_DEFAULT_LIMIT is set to "2 ** 16 # 64 KiB" https://github.com/python/cpython/blob/0afada163c7ef25c3a9d46ed445481fb69f2ecaf/Lib/asyncio/streams.py#L19

This information is especially needed when you get the exception "asyncio.streams.LimitOverrunError: Separator is not found, and chunk exceed the limit" and want to increase the limit, but you don't have the initial value and you have to look at the source code to get it.

PS: this is my first ticket, I don't know if I should have open one for such a minor detail in the documentation

----------
assignee: docs at python
components: Documentation, asyncio
messages: 324873
nosy: asvetlov, docs at python, psycojoker, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.StreamReader initialization documentation incorrectly declare limit as None
type: enhancement
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Sun Sep  9 11:47:39 2018
From: report at bugs.python.org (Brandt Bucher)
Date: Sun, 09 Sep 2018 15:47:39 +0000
Subject: [New-bugs-announce] [issue34614] Builtin `abs(Path)` returns
 `Path.absolute()`.
Message-ID: <1536508059.44.0.56676864532.issue34614@psf.upfronthosting.co.za>


New submission from Brandt Bucher <brandtbucher at gmail.com>:

This complements the current Path behavior that overrides division operators for path joining, in that it makes manually-constructed paths easier to form and arguably more readable.

Before:

p = Path("some", "relative", "path")
q = p.absolute() / "some" / "further" / "path"

After:

p = Path("some", "relative", "path")
q = abs(p) / "some" / "further" / "path"

----------
components: Library (Lib)
messages: 324890
nosy: brandtbucher
priority: normal
severity: normal
status: open
title: Builtin `abs(Path)` returns `Path.absolute()`.
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Sun Sep  9 15:02:37 2018
From: report at bugs.python.org (Kay Hayen)
Date: Sun, 09 Sep 2018 19:02:37 +0000
Subject: [New-bugs-announce] [issue34615] subprocess.call wrong exit code
Message-ID: <1536519757.93.0.56676864532.issue34615@psf.upfronthosting.co.za>


New submission from Kay Hayen <kay.hayen at gmail.com>:

Hello there,

I am probably confusing myself. I am using this kind of code in Nuitka to emulate "os.execl" on Windows, and so far it never let me down:

            r = subprocess.call(
                args,
                shell = False
            )

            print (r, args)

            sys.exit(r)

When i execute my tests with Nuitka and Python 3.6 and everything before, this gives:

1 ['test_call.exe']
1 ['C:\\Python36_32\\python.exe', '-S', '..\\..\\nuitka\\__main__.py', '--run', 'test/test_call.py']

And with python 3.7 it gives:

0 ['test_call.exe']
0 ['C:\\Python37_32\\python.exe', '-S', '..\\..\\nuitka\\__main__.py', '--run', 'test/test_call.py']

So I am in Nuitka re-executing itself without the site module, and then immediately the created binary. For 3.7 it doesn't give me an error. I manually confirmed that "test_call.exe" indeed gives error code 1 as well, in both bash and cmd.exe, but it is not seen in the return value. Checking existing issues, I didn't find any hint at all, how this can be. I added "shell = False" to make it clear that no "cmd.exe" should be used, for which there had been issues.

I also confirmed, by adding a exit(27), that if I simulate that "test_call.exe" gave 27, rather then 0, then that one is detected by the exec, so what could be going on here. But I am also sure I don't confuse binaries or so, plus it's working as expected in other Python versions than 3.7.0 here.

This happens with 64 bits too, I am only citing 32 bits. And it is happening with just about every compiled unit test that gives an error exit, where otherwise e.g. tests that check for error exits to be the case work nicely.

Thanks for any help or direction you can give me there. I am at loss.

Yours,
Kay

----------
components: Windows
messages: 324897
nosy: kayhayen, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: subprocess.call wrong exit code
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Sun Sep  9 17:57:12 2018
From: report at bugs.python.org (Matthias Bussonnier)
Date: Sun, 09 Sep 2018 21:57:12 +0000
Subject: [New-bugs-announce] [issue34616] implement "Async exec"
Message-ID: <1536530232.25.0.56676864532.issue34616@psf.upfronthosting.co.za>


New submission from Matthias Bussonnier <bussonniermatthias at gmail.com>:

Hi, 

This is an issue, prompted by twitter (https://twitter.com/Mbussonn/status/1038866329971961859) and by the imminent release of IPython 7.0 that provides an async REPL to discuss the introducion of something I'll call "Async exec", the exact form can vary, but I believe the name si relatively self explanatory. 

The short description would be to allow something akin to `exec` but for asynchronous code. Typically for one to be able to write an async-repl in the generic sens that is not say not obviously liked to asyncio.

For example IPython 7.0 (current master branch) allow the following:

```

In [1]: import asyncio, trio, curio

In [2]: await asyncio.sleep(0)

In [3]: %autoawait trio

In [4]: await trio.sleep(0)

In [5]: %autoawait curio

In [6]: await curio.sleep(0)
Out[6]: 30980.70591396
```


Sleep is here and example, but you can play with aoihttp, asks, and other library and it "just works". Alternatively when using IPython via Jupyter, you can also schedule background tasks that will execute in the currently running loop. 

To reach this, we had to work around a large number of roadblock, and there is a number of missing pieces (or things especially prevented) in core Python we had to work around. To see how we did that see https://github.com/ipython/ipython/pull/11265

The core being if we have a block of async code like `await sleep(0)`, we need an asynchronous way to exec it without blocking, hence the proposal for async-exec.

During the development and test of the above feature of IPython here are some of the challenges we got with top-level async code. 

1) top-level async is invalid syntax. 

It make sens for a module for this to be invalid syntax, but not in a repl.
Since Python 3.7 we can (at least) compile it to AST, but not to bytecode.

2) It would also be extremely convenient to have a util function to tell you whether what you just compiled need to be ran async or not, from Source Code, ast tree, code object. It's surprisingly not trivial to get it always right.

So far in IPython we have to carry-over and recompute whether to actually run the compiled byte code in classical `exec` or our pseudo async-exec. You may think that `await exec()` always cover the case, but when you are already running under asyncio, you may want to tell user "no you can't run async code", and use the normal `exec` path.


3) Have  distinction in this `async exec`/`compile` between "I am compiling a module", currently `exec` mode for both exec and compile, and a "I'm compiling a _multiline_ interactive statement".

4) Not be coupled to a specific async library.

Allow new AIO library like trio/curio/... to use this.

Note that despite both using IPython, the above cover 2 use cases. 
- Terminal IPython were the loop is started/stopped between each user input. 
- Notebook kernel/Jupyter IPython where the loop is already running and task/user code can be process in background w/o pausing the loop. 

AFAICT, this would also be of potential use for other REPL (Xonsh, Bpython).

I'm happy to give more details, but I think that's a enough of a broad overview, as we should be releasing this in IPython in a few days/week, we will likely have further feedback from a wider range of users that can inform the design.

----------
components: Interpreter Core
messages: 324900
nosy: mbussonn
priority: normal
severity: normal
status: open
title: implement "Async exec"
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Sun Sep  9 18:21:11 2018
From: report at bugs.python.org (Anees Ahmed)
Date: Sun, 09 Sep 2018 22:21:11 +0000
Subject: [New-bugs-announce] [issue34617] socket.recvfrom(): docs should
 warn about packet truncation when bufsize is insufficient
Message-ID: <1536531671.36.0.56676864532.issue34617@psf.upfronthosting.co.za>


New submission from Anees Ahmed <aneesahmedpro at gmail.com>:

When one is receiving UDP packets (socket.SOCK_DGRAM) using:

    socket.recvfrom(bufsize, flags)

the UDP packet payload is truncated if it was too big to fit into the buffer (decided by `bufsize` here).


This is documented in Linux Docs:

    All receive operations return only one packet.  When the packet is
    smaller than the passed buffer, only that much data is returned; when
    it is bigger, the packet is truncated and the MSG_TRUNC flag is set.
    MSG_WAITALL is not supported.

    Source: http://man7.org/linux/man-pages/man7/udp.7.html


This is also documented in Windows Docs:

    For message-oriented sockets, data is extracted from the first enqueued message, up to the size of the buffer specified. If the datagram or message is larger than the buffer specified, the buffer is filled with the first part of the datagram, and recvfrom generates the error WSAEMSGSIZE. For unreliable protocols (for example, UDP) the excess data is lost. For UDP if the packet received contains no data (empty), the return value from the recvfrom function function is zero.

    Source: https://docs.microsoft.com/en-us/windows/desktop/api/winsock2/nf-winsock2-recvfrom


** PYTHON DOCS DO NOT WARN ABOUT THIS AT ALL !!! **

The relevant portion of Python Docs is here: https://docs.python.org/3.7/library/socket.html#socket.socket.recvfrom


I, not knowing this simple fact when I started socket programming today, wasted half an hour finding out what was wrong. This is a very important piece of information that MUST be present in the Python Docs, even though it is present at Linux Docs and Windows Docs.


PROPOSED FIX
------------

Include the warning about packet truncation in the docs.

NOTE: I have only pointed out socket.recvfrom(), but there are other related functions too, e.g. socket.recvfrom_into(), which require the same warning in their docs.

----------
assignee: docs at python
components: Documentation
messages: 324901
nosy: Anees Ahmed, docs at python
priority: normal
severity: normal
status: open
title: socket.recvfrom(): docs should warn about packet truncation when bufsize is insufficient
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/issue34617>
_______________________________________

From report at bugs.python.org  Sun Sep  9 21:58:00 2018
From: report at bugs.python.org (Jeremy Kloth)
Date: Mon, 10 Sep 2018 01:58:00 +0000
Subject: [New-bugs-announce] [issue34618] Encoding error running in
 subprocess with captured output
Message-ID: <1536544680.03.0.56676864532.issue34618@psf.upfronthosting.co.za>


New submission from Jeremy Kloth <jeremy.kloth+python-tracker at gmail.com>:

When running Python via subprocess with captured output an encoding error occurs attempting to output a Unicode filename.  The same does not happen when just using spawnl().

Python 3.6.5 (v3.6.5:f59c0932b4, Mar 28 2018, 17:00:18) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os, sys, subprocess
>>> sys.stdout.encoding, sys.stdout.errors
('utf-8', 'surrogateescape')
>>> args = ['-u', '-c', "print('taqdir\\\u0634\u0645\u0627\u0631.py')"]
>>> os.spawnl(os.P_WAIT, sys.executable, '"%s"' % sys.executable, *args)
taqdir\????.py
0
>>> subprocess.run([sys.executable, *args], stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
CompletedProcess(args=['C:\\Program Files (x86)\\Microsoft Visual Studio\\Shared\\Python36_64\\python.exe', '-u', '-c', "print('taqdir\\????.py')"], returncode=1, stdout=b'Traceback (most recent call last):\r\n  File "<string>", line 1, in <module>\r\n  File "C:\\Program Files (x86)\\Microsoft Visual Studio\\Shared\\Python36_64\\lib\\encodings\\cp1252.py", line 19, in encode\r\n    return codecs.charmap_encode(input,self.errors,encoding_table)[0]\r\nUnicodeEncodeError: \'charmap\' codec can\'t encode characters in position 7-10: character maps to <undefined>\r\n')

----------
components: Interpreter Core, Library (Lib), Unicode, Windows
messages: 324904
nosy: ezio.melotti, jkloth, paul.moore, steve.dower, tim.golden, vstinner, zach.ware
priority: normal
severity: normal
status: open
title: Encoding error running in subprocess with captured output
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Sun Sep  9 22:56:30 2018
From: report at bugs.python.org (kuri8ive)
Date: Mon, 10 Sep 2018 02:56:30 +0000
Subject: [New-bugs-announce] [issue34619] Typo in docs.python.jp
Message-ID: <1536548190.7.0.56676864532.issue34619@psf.upfronthosting.co.za>


New submission from kuri8ive <1yen.com at gmail.com>:

Typo in https://docs.python.jp/3/tutorial/index.html
"Python Web ???(htts://www.python.org)"
should be
"Python Web ???(https://www.python.org) "

----------
assignee: docs at python
components: Documentation
messages: 324906
nosy: docs at python, kuri8ive
priority: normal
severity: normal
status: open
title: Typo in docs.python.jp
type: enhancement

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

From report at bugs.python.org  Mon Sep 10 07:57:43 2018
From: report at bugs.python.org (Dan Snider)
Date: Mon, 10 Sep 2018 11:57:43 +0000
Subject: [New-bugs-announce] [issue34620] Octal byte literals with a decimal
 value > 255 are silently truncated
Message-ID: <1536580663.47.0.56676864532.issue34620@psf.upfronthosting.co.za>


New submission from Dan Snider <mr.assume.away at gmail.com>:

>>> b'\542\571\564\545\563', b'\142\171\164\145\163'
(b'bytes', b'bytes')

All the C compilers I know of at the very least generate a warning when one tries to assign an oct literal >= '\400' to a byte. And that's because it's nonsense when bytes have 8 bits, even more so for an 8 bit byte string.

The literal value:

>>> b'\542\571\564\545\563'

should be identical to:

>>> bytes([0o542, 0o571, 0o564, 0o545, 0o563])

That obviously doesn't work:

>>> b'\542\571\564\545\563' == bytes([0o542, 0o571, 0o564, 0o545, 0o563])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: bytes must be in range(0, 256)

This is on Windows/Intel. I haven't looked at the parser in much detail, but I wonder what would happen on a big-endian system?

----------
components: Interpreter Core, Windows
messages: 324918
nosy: bup, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Octal byte literals with a decimal value > 255 are silently truncated
type: behavior
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Mon Sep 10 08:16:57 2018
From: report at bugs.python.org (Tal Einat)
Date: Mon, 10 Sep 2018 12:16:57 +0000
Subject: [New-bugs-announce] [issue34621] uuid.UUID objects can't be
 unpickled in older Python versions (<3.7)
Message-ID: <1536581817.86.0.56676864532.issue34621@psf.upfronthosting.co.za>


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

This affects only 3.7, where the new SafeUUID enum was introduced.

This was fixed on the master branch (3.8) while implementing issue30977.

Fixing this should simply require defining similar __getstate__ and __setstate__ methods as in 3.8.

----------
components: Library (Lib)
messages: 324919
nosy: serhiy.storchaka, taleinat
priority: normal
severity: normal
status: open
title: uuid.UUID objects can't be unpickled in older Python versions (<3.7)
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Mon Sep 10 15:44:24 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 10 Sep 2018 19:44:24 +0000
Subject: [New-bugs-announce] [issue34622] Extract asyncio exceptions into a
 separate file
Message-ID: <1536608664.91.0.56676864532.issue34622@psf.upfronthosting.co.za>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

Their public import paths are still the same, e.g. `asyncio.CancelledError`.

The change pursuits a better asyncio internal code structure.

----------
messages: 324952
nosy: asvetlov
priority: normal
severity: normal
status: open
title: Extract asyncio exceptions into a separate file

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

From report at bugs.python.org  Mon Sep 10 18:47:44 2018
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 10 Sep 2018 22:47:44 +0000
Subject: [New-bugs-announce] [issue34623] _elementtree.c doesn't call
 XML_SetHashSalt()
Message-ID: <1536619664.47.0.56676864532.issue34623@psf.upfronthosting.co.za>


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

The pyexpat module calls XML_SetHashSalt(self->itself,                   (unsigned long)_Py_HashSecret.expat.hashsalt) to initialize the salt for hash randomization of the XML_Parser struct. The _elementree C accelerator doesn't call XML_SetHashSalt().

It's not a security issue with recent versions of libexpat. The library initializes the salt from a good entry source by default.

----------
components: XML
messages: 324954
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: _elementtree.c doesn't call XML_SetHashSalt()
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Mon Sep 10 19:36:34 2018
From: report at bugs.python.org (=?utf-8?b?VGhvbWFzIEdsw6TDn2xl?=)
Date: Mon, 10 Sep 2018 23:36:34 +0000
Subject: [New-bugs-announce] [issue34624] -W option does not accept module
 regexes
Message-ID: <1536622594.77.0.0269046726804.issue34624@psf.upfronthosting.co.za>


New submission from Thomas Gl??le <thomas at coldfix.de>:

Hi,

This command does not report a warning, while it should:

  python -c 'import warnings; warnings.warn("This should show up")' -Wi -W'default:::.*'

If the regex `.*` is replaced by `__main__` it works as expected.

Same applies for regexes in PYTHONWARNINGS and for the `message` part of the argument. 

The reason can be found in Lib/warnings.py:144 (def _setoption):

  module = re.escape(module)

This point-blank escape makes me think that it was intended that no regexes can be passed to message/module. On the other, the documentation reads as if it should be supported.

Specifically, the -W option is documented in [1]. While this page lists only basic examples, it refers to [2] and [3] for more details. [2] states that message/module are regexes. [3] seems to be written to specifically address the syntax of the PYTHONWARNINGS and the -W option and explicitly lists an example with a regex.

[1]: https://docs.python.org/3/using/cmdline.html#cmdoption-w
[2]: https://docs.python.org/3/library/warnings.html#warning-filter
[3]: https://docs.python.org/3/library/warnings.html#describing-warning-filters

I would welcome if we could remove `re.escape` to make the implementation fit the documentation, or are there any downsides to this?


Best regards, Thomas

----------
components: Library (Lib)
messages: 324959
nosy: coldfix
priority: normal
severity: normal
status: open
title: -W option does not accept module regexes
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Mon Sep 10 20:44:23 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 11 Sep 2018 00:44:23 +0000
Subject: [New-bugs-announce] [issue34625] update to expat 2.2.6
Message-ID: <1536626663.69.0.0269046726804.issue34625@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

libexpat 2.2.6 has been released. We should update our vendorized version.

----------
components: XML
messages: 324967
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: update to expat 2.2.6
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Mon Sep 10 21:33:17 2018
From: report at bugs.python.org (Petr Viktorin)
Date: Tue, 11 Sep 2018 01:33:17 +0000
Subject: [New-bugs-announce] [issue34626] PEP 384's PyType_Spec and
 PyType_Slot are not documented
Message-ID: <1536629597.33.0.0269046726804.issue34626@psf.upfronthosting.co.za>


New submission from Petr Viktorin <encukou at gmail.com>:

The documentation of PyType_FromSpec and PyType_FromSpecWithBases is currently not very useful. In particular, PyType_Spec and PyType_Slot are only documented in pep-0384, not in the Python docs.

----------
messages: 324975
nosy: petr.viktorin
priority: normal
severity: normal
status: open
title: PEP 384's PyType_Spec and PyType_Slot are not documented

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

From report at bugs.python.org  Tue Sep 11 04:26:50 2018
From: report at bugs.python.org (badrussians)
Date: Tue, 11 Sep 2018 08:26:50 +0000
Subject: [New-bugs-announce] [issue34627] Python incorrect execution order
Message-ID: <1536654410.3.0.0269046726804.issue34627@psf.upfronthosting.co.za>


New submission from badrussians <oknaassortiment at gmail.com>:

#!/usr/bin/env python3
# -*- coding: utf-8 -*-
print('');
import sys, os, subprocess, re, ctypes, tempfile, shutil, tarfile, urllib.request;
argsCount=len(sys.argv);
scriptDir = os.path.dirname(os.path.abspath(sys.argv[0]));


def FindFullPaths(strPattern, *orderedSearchDirs, \
				  findFile=True, findDir=False, \
				  ignoreCase=False, returnFirst=True):
	print('#  FindFullPaths__In');
	result = [];
	def resultAppendUnique(item):
		if item not in result:
				result.append(item);
	pattern = re.compile(strPattern, \
			re.IGNORECASE | re.DOTALL if ignoreCase else re.DOTALL);
	isFound = False;
	for searchDir in orderedSearchDirs:
		print('#searchDir', searchDir, orderedSearchDirs, '\n');
		for leafName in os.listdir(searchDir):
			leafPath = os.path.join(searchDir, leafName);
			isDir = os.path.isdir(leafPath);
			isFound = (findDir and isDir or \
					   findFile and os.path.isfile(leafPath)) \
						and pattern.search(leafName) is not None;
			print('#leafPath:', leafPath, '\n'); #ERROR = output Last AND last time - no in output!
			print('#isFound:', isFound);         #ERROR = output First AND first time - no in output!
			if isFound:
				resultAppendUnique(leafPath);
			if isDir and not (returnFirst and isFound):
				for partLeafPath in FindFullPaths(strPattern, leafPath, \
						findFile=findFile, findDir=findDir, \
						ignoreCase=ignoreCase, returnFirst=returnFirst):
					resultAppendUnique(partLeafPath);
					isFound = True;
			if returnFirst and isFound:
				break;
		if returnFirst and isFound:
			break;
	print('#  FindFullPaths__Return');
	return result; 

FindFullPaths('^bat$', '/home/user/??????? ????/ttt');
print(sys.version);

#### OUTPUT: ####
'/home/user/??????? ????/test2.py' 

#  FindFullPaths__In
#searchDir /home/user/??????? ????/ttt ('/home/user/??????? ????/ttt',) 

#leafPath: /home/user/??????? ????/ttt/BackupRestore.py 

#isFound: False
#leafPath: /home/user/??????? ????/ttt/temp.py 

#isFound: False
#leafPath: /home/user/??????? ????/ttt/Create ISO.py 

#isFound: False
#  FindFullPaths__Return
3.6.5 (default, Apr  1 2018, 05:46:30) 
[GCC 7.3.0]
###### Environment ######
Russian Ubuntu 18.04.1 and Kali 2018.3
PS: Ru:'/home/user/??????? ????' == Eng'/home/user/Desktop'

----------
components: Interpreter Core
files: test2.py
messages: 324996
nosy: badrussians
priority: normal
severity: normal
status: open
title: Python incorrect execution order
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file47795/test2.py

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

From report at bugs.python.org  Tue Sep 11 12:33:16 2018
From: report at bugs.python.org (Niklas Sombert)
Date: Tue, 11 Sep 2018 16:33:16 +0000
Subject: [New-bugs-announce] [issue34628] urllib.request.urlopen fails when
 userinfo is present in URL
Message-ID: <1536683596.21.0.0269046726804.issue34628@psf.upfronthosting.co.za>


New submission from Niklas Sombert <niklas at ytvwld.de>:

Today I tried to access URLs like this one: http://user:1234 at example.net:8080.

The result was this:
>>> import urllib.request
>>> urllib.request.urlopen("http://user:1234 at example.net:1234/")
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/urllib/request.py", line 1317, in do_open
    encode_chunked=req.has_header('Transfer-encoding'))
  File "/usr/local/lib/python3.7/http/client.py", line 1229, in request
    self._send_request(method, url, body, headers, encode_chunked)
  File "/usr/local/lib/python3.7/http/client.py", line 1275, in _send_request
    self.endheaders(body, encode_chunked=encode_chunked)
  File "/usr/local/lib/python3.7/http/client.py", line 1224, in endheaders
    self._send_output(message_body, encode_chunked=encode_chunked)
  File "/usr/local/lib/python3.7/http/client.py", line 1016, in _send_output
    self.send(msg)
  File "/usr/local/lib/python3.7/http/client.py", line 956, in send
    self.connect()
  File "/usr/local/lib/python3.7/http/client.py", line 928, in connect
    (self.host,self.port), self.timeout, self.source_address)
  File "/usr/local/lib/python3.7/socket.py", line 707, in create_connection
    for res in getaddrinfo(host, port, 0, SOCK_STREAM):
  File "/usr/local/lib/python3.7/socket.py", line 748, in getaddrinfo
    for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
socket.gaierror: [Errno -2] Name does not resolve

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.7/urllib/request.py", line 222, in urlopen
    return opener.open(url, data, timeout)
  File "/usr/local/lib/python3.7/urllib/request.py", line 525, in open
    response = self._open(req, data)
  File "/usr/local/lib/python3.7/urllib/request.py", line 543, in _open
    '_open', req)
  File "/usr/local/lib/python3.7/urllib/request.py", line 503, in _call_chain
    result = func(*args)
  File "/usr/local/lib/python3.7/urllib/request.py", line 1345, in http_open
    return self.do_open(http.client.HTTPConnection, req)
  File "/usr/local/lib/python3.7/urllib/request.py", line 1319, in do_open
    raise URLError(err)
urllib.error.URLError: <urlopen error [Errno -2] Name does not resolve>


At first, I checked my network connection, but that turned out to be okay. Even funnier:

>>> urllib.request.urlopen("http://user:1234 at example.net/")     
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/http/client.py", line 877, in _get_hostport
    port = int(host[i+1:])
ValueError: invalid literal for int() with base 10: '1234 at example.net'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.7/urllib/request.py", line 222, in urlopen
    return opener.open(url, data, timeout)
  File "/usr/local/lib/python3.7/urllib/request.py", line 525, in open
    response = self._open(req, data)
  File "/usr/local/lib/python3.7/urllib/request.py", line 543, in _open
    '_open', req)
  File "/usr/local/lib/python3.7/urllib/request.py", line 503, in _call_chain
    result = func(*args)
  File "/usr/local/lib/python3.7/urllib/request.py", line 1345, in http_open
    return self.do_open(http.client.HTTPConnection, req)
  File "/usr/local/lib/python3.7/urllib/request.py", line 1285, in do_open
    h = http_class(host, timeout=req.timeout, **http_conn_args)
  File "/usr/local/lib/python3.7/http/client.py", line 841, in __init__
    (self.host, self.port) = self._get_hostport(host, port)
  File "/usr/local/lib/python3.7/http/client.py", line 882, in _get_hostport
    raise InvalidURL("nonnumeric port: '%s'" % host[i+1:])
http.client.InvalidURL: nonnumeric port: '1234 at example.net'

So, urllib seems to have problems parsing HTTP URLs which contain a userinfo part. (Requests works.)

----------
components: Library (Lib)
messages: 325022
nosy: ytvwld
priority: normal
severity: normal
status: open
title: urllib.request.urlopen fails when userinfo is present in URL
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/issue34628>
_______________________________________

From report at bugs.python.org  Tue Sep 11 12:36:09 2018
From: report at bugs.python.org (Thibault Kruse)
Date: Tue, 11 Sep 2018 16:36:09 +0000
Subject: [New-bugs-announce] [issue34629] Python3 regression for
 urllib(2).urlopen(...).fp for chunked http responses
Message-ID: <1536683769.28.0.0269046726804.issue34629@psf.upfronthosting.co.za>


New submission from Thibault Kruse <pandora1234 at mt2015.com>:

We had a problem running code that downloads files from github when porting from python2.7 to python3.[3-7]. Not sure if a bug or not.

With the given code, in python3 a file downloaded in chunks will contain the size of chunks when using the undocumented fp from urlopen(...).fp. In python2, only the chunk payload would make it into the file.

We assume that we can just use the urlopen response directly as a fix (without '.fp'), but though it might still be nice to report the difference.

Short code:
resp = urlopen('http://someurl')
fhand = os.fdopen(fdesc, "wb")
shutil.copyfileobj(resp.fp, fhand)   # using .fp here is the dodgy part
fhand.close()

The attached script demonstrates the difference:

$ python --version
Python 2.7.15rc1
$ python urllib_issue.py 
127.0.0.1 - - [12/Sep/2018 01:27:28] "GET /downloads/1.0.tar.gz HTTP/1.1" 200 -

$ python3 --version
Python 3.6.5
$ python3 urllib_issue.py 
127.0.0.1 - - [12/Sep/2018 01:27:37] "GET /downloads/1.0.tar.gz HTTP/1.1" 200 -
Traceback (most recent call last):
  File "urllib_issue.py", line 87, in <module>
    assert data == FILE_CONTENT, '%s, %s'%(len(FILE_CONTENT), len(data))
AssertionError: 100000, 100493
!!! BASH reports ERROR: shell returned 1

----------
components: Library (Lib)
files: urllib_issue.py
messages: 325025
nosy: tkruse
priority: normal
severity: normal
status: open
title: Python3 regression for urllib(2).urlopen(...).fp for chunked http responses
type: behavior
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8
Added file: https://bugs.python.org/file47796/urllib_issue.py

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

From report at bugs.python.org  Tue Sep 11 12:59:29 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 11 Sep 2018 16:59:29 +0000
Subject: [New-bugs-announce] [issue34630] Don't log ssl cert errors in
 asyncio
Message-ID: <1536685169.66.0.0269046726804.issue34630@psf.upfronthosting.co.za>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

It is reported as a regular exception, not need to log it (as we skip logging of connection errors already).

----------
messages: 325032
nosy: asvetlov
priority: normal
severity: normal
status: open
title: Don't log ssl cert errors in asyncio

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

From report at bugs.python.org  Tue Sep 11 13:13:46 2018
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 11 Sep 2018 17:13:46 +0000
Subject: [New-bugs-announce] [issue34631] Upgrade to OpenSSL 1.1.1
Message-ID: <1536686026.27.0.0269046726804.issue34631@psf.upfronthosting.co.za>


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

OpenSSL 1.1.1 was released today. The blog post https://www.openssl.org/blog/blog/2018/09/11/release111/ lists all major improvements.

Highlights:
* TLS 1.3
* API and ABI compatible with OpenSSL 1.1.0
* LTS release (support schedule TBD)

All tests on master are passing with OpenSSL 1.1.1. I still want to hold off and wait a couple of patch releases, before we start to ship Windows and macOS builds with 1.1.1. Some aspects of the TLS 1.3 handshake are different to TLS 1.2. I might have to implement some additional APIs for post handshake authentication.

----------
assignee: christian.heimes
components: SSL
messages: 325034
nosy: alex, christian.heimes, dstufft, janssen
priority: normal
severity: normal
status: open
title: Upgrade to OpenSSL 1.1.1
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Tue Sep 11 14:16:43 2018
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 11 Sep 2018 18:16:43 +0000
Subject: [New-bugs-announce] [issue34632] Port importlib_metadata to Python
 3.8
Message-ID: <1536689803.48.0.0269046726804.issue34632@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

https://importlib_metadata.rtfd.org

We're fleshing out the API and implementation in the standalone library, but once we're confident of the API and semantics, we will want to port this into Python 3.8.

----------
assignee: barry
components: Library (Lib)
messages: 325043
nosy: barry, brett.cannon, jason.coombs
priority: normal
severity: normal
status: open
title: Port importlib_metadata to Python 3.8
versions: Python 3.8

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

From report at bugs.python.org  Tue Sep 11 17:17:51 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 11 Sep 2018 21:17:51 +0000
Subject: [New-bugs-announce] [issue34633] Simplify __reduce__ for ordered
 dict.
Message-ID: <1536700671.8.0.0269046726804.issue34633@psf.upfronthosting.co.za>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

The code for __reduce__ in ordered dictionaries can be simplified in the similar way issue34573 is treating dict and set objects.

----------
components: Interpreter Core
messages: 325063
nosy: pablogsal
priority: normal
severity: normal
status: open
title: Simplify __reduce__ for ordered dict.
type: performance
versions: Python 3.8

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

From report at bugs.python.org  Tue Sep 11 17:18:02 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 11 Sep 2018 21:18:02 +0000
Subject: [New-bugs-announce] [issue34634] New asyncio streams API
Message-ID: <1536700682.14.0.0269046726804.issue34634@psf.upfronthosting.co.za>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

Currently, we have separate classes: reader and writer.

It is very inconvenient: these classes are tightly coupled internally, there is no sense to have two objects to the single logical entity.

The second problem is `writer.write()` synchronous API. To support flow control user should call `await writer.drain()` after every `writer.write()` call. But he/she can forget about drain() easy.

`writer.write()` should be softly deprecated in favor of `await writer.send()`. `writer.writelines()` is not very useful, better to merge all buffers before `await stream.send(data)` call. `writelines` should be softly deprecated as well without async replacement.

The last issue is `writer.close()` which should always be used in conjunction with `await writer.wait_closed()`. Let's return a future from `writer.close()`. The encouraged usage becomes `await writer.close()`. 
To immediate closing let's add `writer.abort()` sync function which cleans up resources without waiting for actual closing.

----------
messages: 325064
nosy: asvetlov
priority: normal
severity: normal
status: open
title: New asyncio streams API

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

From report at bugs.python.org  Tue Sep 11 17:35:42 2018
From: report at bugs.python.org (Benjamin Mintz)
Date: Tue, 11 Sep 2018 21:35:42 +0000
Subject: [New-bugs-announce] [issue34635] inspect: add tools for inspecting
 subclasses
Message-ID: <1536701742.73.0.0269046726804.issue34635@psf.upfronthosting.co.za>


New submission from Benjamin Mintz <benjabean1 at gmail.com>:

Adds inspect.getsubclasses, inspect.getallsubclasses (recursive), and inspect.getsubclasstree (recursive, maintains structure).

See documentation for more details.

----------
components: Library (Lib)
messages: 325068
nosy: bmintz
priority: normal
severity: normal
status: open
title: inspect: add tools for inspecting subclasses
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Tue Sep 11 18:00:58 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 11 Sep 2018 22:00:58 +0000
Subject: [New-bugs-announce] [issue34636] re module microoptimization: speed
 up bytes \w \s \d matching
Message-ID: <1536703258.1.0.0269046726804.issue34636@psf.upfronthosting.co.za>


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

filing this issue to track https://github.com/python/cpython/pull/9170

----------
assignee: gregory.p.smith
messages: 325073
nosy: gregory.p.smith
priority: normal
pull_requests: 8627
severity: normal
status: open
title: re module microoptimization: speed up bytes \w \s \d matching
type: performance
versions: Python 3.8

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

From report at bugs.python.org  Tue Sep 11 19:34:59 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 11 Sep 2018 23:34:59 +0000
Subject: [New-bugs-announce] [issue34637] Make *start* usable as a keyword
 argument for sum().
Message-ID: <1536708899.31.0.0269046726804.issue34637@psf.upfronthosting.co.za>


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

Currently, we can write:

    >>> sum(range(10), 50)
    95

What we want to allow:

    >>> sum(range(10), start=50)
    95

The positional form would still be allowed.

----------
assignee: rhettinger
components: Library (Lib)
messages: 325092
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Make *start* usable as a keyword argument for sum().
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Tue Sep 11 19:47:26 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 11 Sep 2018 23:47:26 +0000
Subject: [New-bugs-announce] [issue34638] Avoid circular references in
 asyncio streams
Message-ID: <1536709646.23.0.0269046726804.issue34638@psf.upfronthosting.co.za>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

Now we have a cross-reference between asyncio stream reader and protocol.

It prevents objects deletion on ref-counting and requires a garbage collector run to destroy the stream.

----------
components: asyncio
messages: 325095
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Avoid circular references in asyncio streams
versions: Python 3.8

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

From report at bugs.python.org  Tue Sep 11 19:47:42 2018
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 11 Sep 2018 23:47:42 +0000
Subject: [New-bugs-announce] [issue34639] PYTHONCOERCECLOCALE is ignored
 when using -E or -I option
Message-ID: <1536709662.94.0.0269046726804.issue34639@psf.upfronthosting.co.za>


New submission from STINNER Victor <vstinner at redhat.com>:

I modified Py_Main() to ignore the PYTHONCOERCECLOCALE environment variable if -E or -I command line option is used. But Nick asks to always read PYTHONCOERCECLOCALE.

We should either update the PEP or change the code.

I am not sure why PYTHONCOERCECLOCALE should be handled differently than other PYTHON* variable like PYTHONWARNINGS or PYTHONUTF8. Is it because it impacts the encodings? Is it because there was a chicken-and-egg issue before I reworked Py_Main() code? (PYTHONCOERCECLOCALE env var was read before reading command line arguments.)

--

Copy of Nick Coghlan's msg325009:

(The one exception to "nothing gets decoded incorrectly" is that PYTHONCOERCECLOCALE itself is always interpreted as an ASCII field: the values that it checks for are actually ASCII byte sequences, not Unicode code points.

The documentation could definitely be much clearer on that point though, as even in the PEP it's only implied by the final paragraph in https://www.python.org/dev/peps/pep-0538/#legacy-c-locale-coercion-in-the-standalone-python-interpreter-binary which is mostly talking about the fact that this particular environment variable is still checked, even if you pass the -I or -E command line options.

----------
components: Interpreter Core
messages: 325096
nosy: vstinner
priority: normal
severity: normal
status: open
title: PYTHONCOERCECLOCALE is ignored when using -E or -I option
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Tue Sep 11 20:26:31 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Sep 2018 00:26:31 +0000
Subject: [New-bugs-announce] [issue34640] remove the configure check
 TANH_PRESERVES_ZERO_SIGN
Message-ID: <1536711991.62.0.0269046726804.issue34640@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

configure.ac currently has to check for a bug in FreeBSD 6.2:

# On FreeBSD 6.2, it appears that tanh(-0.) returns 0. instead of
# -0. on some architectures.
AC_MSG_CHECKING(whether tanh preserves the sign of zero)
...

FreeBSD 6.2 is nearing 12 years old. It looks like the FreeBSD 10 bot is passing this check. So, I think we should remove this configure check.

----------
messages: 325106
nosy: benjamin.peterson, mark.dickinson
priority: normal
severity: normal
status: open
title: remove the configure check TANH_PRESERVES_ZERO_SIGN

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

From report at bugs.python.org  Tue Sep 11 20:31:54 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 12 Sep 2018 00:31:54 +0000
Subject: [New-bugs-announce] [issue34641] Curiosity: f((a)=1) is not a
 syntax error -- why?
Message-ID: <1536712314.2.0.0269046726804.issue34641@psf.upfronthosting.co.za>


New submission from Guido van Rossum <guido at python.org>:

Emily and I just discovered that f((a)=1) is accepted and compiled the same as f(a=1). This goes against the intention that keyword arguments have the syntax f(NAME=expr).

I suspect that this behavior was introduced at the time we switched from generating from the (concrete) parse tree to first converting to an ast and then generating code from there. I.e. in the distant past (long before 2.7 even).

But I still think it ought to be fixed. Thoughts? Anyone have an idea *where* to fix it?

----------
messages: 325107
nosy: emilyemorehouse, gvanrossum
priority: normal
severity: normal
status: open
title: Curiosity: f((a)=1) is not a syntax error -- why?
versions: Python 3.8

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

From report at bugs.python.org  Tue Sep 11 23:01:23 2018
From: report at bugs.python.org (William Chaseling)
Date: Wed, 12 Sep 2018 03:01:23 +0000
Subject: [New-bugs-announce] [issue34642] time.ctime() uses %3d instead of
 %.2d to format.
Message-ID: <1536721283.17.0.956365154283.issue34642@psf.upfronthosting.co.za>


New submission from William Chaseling <williamchaseling2000 at gmail.com>:

time.ctime() returns _asctime from a C module.
_asctime returns a PyUnicode_FromFormat() result using "%s %s%3d %.2d:%.2d:%.2d %d" as the string formatter.

This works: 'Wed Sep 12 22:30:00 2018'
Except when day <10, because it uses %3d instead of %.2d
'Wed Sep  2 22:30:00 2018'

This seems like it might be intended behavior for some reason, but I don't see the reason.

----------
components: Library (Lib)
messages: 325114
nosy: William Chaseling
priority: normal
severity: normal
status: open
title: time.ctime() uses %3d instead of %.2d to format.
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Tue Sep 11 23:42:45 2018
From: report at bugs.python.org (Valentin Zhao)
Date: Wed, 12 Sep 2018 03:42:45 +0000
Subject: [New-bugs-announce] [issue34643] How to build Release Version of
 Python in Windows?
Message-ID: <1536723765.14.0.956365154283.issue34643@psf.upfronthosting.co.za>


New submission from Valentin Zhao <jmsqzzl at gmail.com>:

I am going to build a Python.exe to migrate it to another PC, in order to build a seemingly virtual *environment* of Python which could run python files. What I do to implement this is to *COPY* \win32 folder to another pc then execute python.exe with specific python file path tagged along.

For now, it works well, however, I met with a strange problem that I cannot find *tcl* under current file hierarchy and this library is generated very deeply so I have to extract it to the root directory manually. 

Surprisingly, I found that I can directly *COPY* all the folders generated by *msi installer* to another pc then use it. Nevertheless, I fret about there could be some registration thing during installation.

So how could I compile the source and make it generate folder hierarchy like the release version(like the snapshot I attached below)? I have read README.md in the \PCBuild yet it helps little.

----------
components: Windows
files: build???.png
messages: 325116
nosy: Valentin Zhao, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: How to build Release Version of Python in Windows?
type: compile error
versions: Python 3.6
Added file: https://bugs.python.org/file47797/build???.png

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

From report at bugs.python.org  Wed Sep 12 08:55:11 2018
From: report at bugs.python.org (Rajesh)
Date: Wed, 12 Sep 2018 12:55:11 +0000
Subject: [New-bugs-announce] [issue34644] Bug in reverse method
Message-ID: <1536756911.75.0.956365154283.issue34644@psf.upfronthosting.co.za>


New submission from Rajesh <rajesh99div99 at gmail.com>:

List.reverse()    .... this is working in reverse order 
List.reverse      ....this is not giving syntax error and printing the list as it is.

Can you consider this as bug and fix it in further versions ?

----------
messages: 325136
nosy: rajesh99div99
priority: normal
severity: normal
status: open
title: Bug in reverse method
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Wed Sep 12 10:27:30 2018
From: report at bugs.python.org (Floris van Manen)
Date: Wed, 12 Sep 2018 14:27:30 +0000
Subject: [New-bugs-announce] [issue34645] math and numpy yield different
 results (nan)
Message-ID: <1536762450.41.0.956365154283.issue34645@psf.upfronthosting.co.za>


New submission from Floris van Manen <vm at klankschap.nl>:

when using numpy defined values i get nan results.
when using math defined values, no nan errors occur.

check2 bb [5.0, 2.285379077161093, nan, nan, 2.285379077161092]

check2 cc [5.0, 2.285379077161093, 4.341186402706317, 4.341186402706317, 2.285379077161092]

how to get identical results?

----------
files: nan-test.py
messages: 325139
nosy: klankschap
priority: normal
severity: normal
status: open
title: math and numpy yield different results  (nan)
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file47799/nan-test.py

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

From report at bugs.python.org  Wed Sep 12 13:22:24 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Sep 2018 17:22:24 +0000
Subject: [New-bugs-announce] [issue34646] remove PyAPI_* from function
 definitions
Message-ID: <1536772944.12.0.956365154283.issue34646@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

It suffices to have PyAPI_FUNC and PyAPI_DATA on the forward declaration in a header file. We should remove the usages we have in .c files.

----------
components: Interpreter Core
messages: 325147
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: remove PyAPI_* from function definitions
versions: Python 3.8

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

From report at bugs.python.org  Wed Sep 12 15:08:22 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Sep 2018 19:08:22 +0000
Subject: [New-bugs-announce] [issue34647] print sys.thread_info in regrtest
 header
Message-ID: <1536779302.68.0.956365154283.issue34647@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

It might be useful to see the thread implementation info in the header.

----------
components: Tests
messages: 325170
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: print sys.thread_info in regrtest header
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Wed Sep 12 16:03:24 2018
From: report at bugs.python.org (Nathaniel Manista)
Date: Wed, 12 Sep 2018 20:03:24 +0000
Subject: [New-bugs-announce] [issue34648] Confirm the type of
 traceback.format_list post-3.5
Message-ID: <1536782604.59.0.956365154283.issue34648@psf.upfronthosting.co.za>


New submission from Nathaniel Manista <nathaniel at google.com>:

So I'm fixing a bug in typeshed's accounting of the traceback module (https://github.com/python/typeshed/pull/2436) and the documented semantics of traceback.format_list don't quite smell to me what I think they might be intended to be:

1) I know it has the name "format_list", but is it really intended to require a list? Why not a sequence, or a collection, or an iterable? I would think it would be fine to pass an iterable to traceback.format_list. Is it fine?

2) What is the desired component type for the aggregate passed to format_list? In 3.4-and-earlier it was Tuple[str, int, str, Optional[str]], and that still works in 3.5-through-3.8, but is that just backwards compatibility or is that something that users of traceback.format_list should feel encouraged to continue passing into the future?

Sorry for filing a bug just to ask "huh; really?" but... please confirm?

----------
assignee: docs at python
components: Documentation
messages: 325175
nosy: Nathaniel Manista, docs at python
priority: normal
severity: normal
status: open
title: Confirm the type of traceback.format_list post-3.5
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/issue34648>
_______________________________________

From report at bugs.python.org  Wed Sep 12 16:42:59 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Wed, 12 Sep 2018 20:42:59 +0000
Subject: [New-bugs-announce] [issue34649] Modules/_json.c: Missing NULL
 checks in _encoded_const()
Message-ID: <1536784979.36.0.956365154283.issue34649@psf.upfronthosting.co.za>


New submission from Alexey Izbyshev <izbyshev at ispras.ru>:

The return value of PyUnicode_InternFromString() is not checked for NULL and then dereferenced at three places in https://github.com/python/cpython/blob/0bd1a2dcfdf36b181385ae61361e7692f4ebb0fd/Modules/_json.c#L1369

Reported by Svace static analyzer.

----------
components: Extension Modules
messages: 325177
nosy: benjamin.peterson, berker.peksag, izbyshev, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Modules/_json.c: Missing NULL checks in _encoded_const()
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/issue34649>
_______________________________________

From report at bugs.python.org  Wed Sep 12 16:51:22 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Sep 2018 20:51:22 +0000
Subject: [New-bugs-announce] [issue34650] test_posix fails with musl
Message-ID: <1536785482.95.0.956365154283.issue34650@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

ERROR: test_get_and_set_scheduler_and_param (test.test_posix.PosixTester)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/buildbot/buildarea/3.x.ware-alpine/build/Lib/test/test_posix.py", line 1280, in test_get_and_set_scheduler_and_param
    mine = posix.sched_getscheduler(0)
OSError: [Errno 38] Function not implemented
======================================================================
ERROR: test_setscheduler_only_param (test.test_posix.TestPosixSpawn)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/buildbot/buildarea/3.x.ware-alpine/build/Lib/test/test_posix.py", line 1651, in test_setscheduler_only_param
    policy = os.sched_getscheduler(0)
OSError: [Errno 38] Function not implemented
======================================================================
ERROR: test_setscheduler_with_policy (test.test_posix.TestPosixSpawn)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/buildbot/buildarea/3.x.ware-alpine/build/Lib/test/test_posix.py", line 1669, in test_setscheduler_with_policy
    policy = os.sched_getscheduler(0)
OSError: [Errno 38] Function not implemented
----------------------------------------------------------------------

----------
components: Tests
messages: 325179
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: test_posix fails with musl
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Wed Sep 12 17:04:23 2018
From: report at bugs.python.org (Eric Snow)
Date: Wed, 12 Sep 2018 21:04:23 +0000
Subject: [New-bugs-announce] [issue34651] Disallow fork in a subinterpreter.
Message-ID: <1536786263.28.0.956365154283.issue34651@psf.upfronthosting.co.za>


New submission from Eric Snow <ericsnowcurrently at gmail.com>:

os.fork() potentially has some problematic behavior when called from a subinterpreter.  In additional to the normal fork+threads madness, there's the question of what to do with existing subinterpreters.  The simplest solution is to simply disallow fork in a subinterpreter and then wipe out all subinterpreters in the child process post-fork (if os.fork() called in the main interpreter).

----------
assignee: eric.snow
components: Interpreter Core
messages: 325181
nosy: eric.snow, gregory.p.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: Disallow fork in a subinterpreter.
versions: Python 3.8

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

From report at bugs.python.org  Wed Sep 12 17:43:38 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Sep 2018 21:43:38 +0000
Subject: [New-bugs-announce] [issue34652] never enable lchmod on Linux
Message-ID: <1536788618.14.0.956365154283.issue34652@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

You can't modify the mode of symbolic links on Linux. Thus, lchmod is a useless function. libc may, however, define a lchmod stub that always returns an error. autoconf has a check that detects the dummy stub for glibc, but it detects lchmod as working on musl. I propose we simply always disable lchmod if the target system is Linux.

----------
components: Build
messages: 325185
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: never enable lchmod on Linux
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Wed Sep 12 17:58:05 2018
From: report at bugs.python.org (Eric V. Smith)
Date: Wed, 12 Sep 2018 21:58:05 +0000
Subject: [New-bugs-announce] [issue34653] PyParser_SimpleParseStringFilename
 should be deleted
Message-ID: <1536789485.93.0.956365154283.issue34653@psf.upfronthosting.co.za>


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

There are 6 PyParser_SimpleParse* functions in pythonrun.c. 5 of them are documented in c-api/veryhigh.rst and appear in pythonrun.h. But PyParser_SimpleParseStringFilename is not documented and is not in any .h file.

I propose we delete PyParser_SimpleParseStringFilename. It's not documented, it's not in a .h file, and it's not called from within Python's source. It's also trivial to implement in terms of PyParser_SimpleParseStringFlagsFilename.

----------
assignee: eric.smith
components: Interpreter Core
messages: 325189
nosy: eric.smith
priority: normal
severity: normal
status: open
title: PyParser_SimpleParseStringFilename should be deleted
type: enhancement
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Wed Sep 12 18:39:41 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 12 Sep 2018 22:39:41 +0000
Subject: [New-bugs-announce] [issue34654] test_time needs to handle '+' at
 the beginning of large years
Message-ID: <1536791981.88.0.956365154283.issue34654@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

POSIX allows the '%Y' format in strftime to start with a '+' sign for years with more than 4 digits. test_time is not tolerant of that, which leads to failures like this with musl:

======================================================================
FAIL: test_large_year (test.test_time.TestStrftime4dyear)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/buildbot/buildarea/3.x.ware-alpine/build/Lib/test/test_time.py", line 683, in test_large_year
    return super().test_large_year()
  File "/buildbot/buildarea/3.x.ware-alpine/build/Lib/test/test_time.py", line 706, in test_large_year
    self.assertEqual(self.yearstr(12345), '12345')
AssertionError: '+12345' != '12345'
- +12345
? -
+ 12345

----------
components: Tests
messages: 325203
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: test_time needs to handle '+' at the beginning of large years
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Wed Sep 12 19:49:59 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Wed, 12 Sep 2018 23:49:59 +0000
Subject: [New-bugs-announce] [issue34655] Support sendfile in asyncio
 streams API
Message-ID: <1536796199.79.0.956365154283.issue34655@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: Support sendfile in asyncio streams API
versions: Python 3.8

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

From report at bugs.python.org  Thu Sep 13 00:38:47 2018
From: report at bugs.python.org (shuoz)
Date: Thu, 13 Sep 2018 04:38:47 +0000
Subject: [New-bugs-announce] [issue34656] memory exhaustion in
 Modules/_pickle.c:1393
Message-ID: <1536813527.13.0.956365154283.issue34656@psf.upfronthosting.co.za>


New submission from shuoz <zzw20124321 at gmail.com>:

python version:
   Python 3.8.0a0 (heads/master:4ae8ece, Sep 13 2018, 09:48:16) 
   [GCC 5.4.0 20160609] on linux


I found a bug in python pickle.load func. Can cause memory exhaustion DDOS.

./python pk.py poc


cat ./pk.py
import pickle
import sys
filename = sys.argv[1]
with open(filename, 'rb') as f:
    aa = pickle.load(f)
    print(aa)

----------
components: FreeBSD
files: poc
messages: 325230
nosy: koobs, shuoz
priority: normal
severity: normal
status: open
title: memory exhaustion in Modules/_pickle.c:1393
type: security
versions: Python 3.8
Added file: https://bugs.python.org/file47801/poc

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

From report at bugs.python.org  Thu Sep 13 02:10:52 2018
From: report at bugs.python.org (Mark Mikofski)
Date: Thu, 13 Sep 2018 06:10:52 +0000
Subject: [New-bugs-announce] [issue34657] pyconfig.h macro "timezone" name
 clashes with user source are likely
Message-ID: <1536819052.42.0.956365154283.issue34657@psf.upfronthosting.co.za>


New submission from Mark Mikofski <bwana.marko at yahoo.com>:

TL;DR: if PC user compiles source which defines "timezone" in a header, and includes Python.h after the header, then the macro also called "timezone" in pyconfig.h will redefine the users source, yielding unexpected results.

see Cython google group for an actual use case where this occurred:
https://groups.google.com/forum/#!topic/cython-users/pjbhYrpl_rU

trying to compile NREL SPA code which has a header file with a struct with a timezone field fails with the following traceback:
spa.h(88): error C2032: '__timezone': function cannot be member of struct '<anonymous-tag>'

here's the macro in PC/pyconfig.h in master as of 5489bdad
https://github.com/python/cpython/blob/5489bdad5143050b8bb89b648b3c00d951b72d4f/PC/pyconfig.h#L202

/* VS 2015 defines these names with a leading underscore */
#if _MSC_VER >= 1900
#define timezone _timezone
#define daylight _daylight
#define tzname _tzname
#endif

----------
components: Build
messages: 325235
nosy: bwanamarko
priority: normal
severity: normal
status: open
title: pyconfig.h macro "timezone" name clashes with user source are likely
type: enhancement
versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Thu Sep 13 06:57:27 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 13 Sep 2018 10:57:27 +0000
Subject: [New-bugs-announce] [issue34658] subprocess with preexec_fn when
 fork() fails could corrupt PyErr state
Message-ID: <1536836247.9.0.956365154283.issue34658@psf.upfronthosting.co.za>


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

Found in the stdlib test suite while testing the fix for bpo-6721: When subprocess is called with a preexec_fn and os.register_at_fork has been used and the fork() system call fails, the Python error state is set before the "after fork in parent process" function calls that were registered were called.  So they'd call back into Python code with a pending unreturned exception set.

boom.  SystemError (or assertion failure in pydebug builds).

----------
assignee: gregory.p.smith
messages: 325238
nosy: gregory.p.smith
priority: normal
severity: normal
status: open
title: subprocess with preexec_fn when fork() fails could corrupt PyErr state
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Thu Sep 13 09:16:58 2018
From: report at bugs.python.org (Azat Ishmukhametovich Ibrakov)
Date: Thu, 13 Sep 2018 13:16:58 +0000
Subject: [New-bugs-announce] [issue34659] Inconsistency between
 functools.reduce & itertools.accumulate
Message-ID: <1536844618.98.0.956365154283.issue34659@psf.upfronthosting.co.za>


New submission from Azat Ishmukhametovich Ibrakov <azatibrakov at gmail.com>:

Why there is an optional `initial` parameter for `functools.reduce` function, but there is no such for `itertools.accumulate`, when they both are doing kind of similar things except that `itertools.accumulate` yields intermediate results and `functools.reduce` only the final one?

----------
components: Library (Lib)
messages: 325243
nosy: lycantropos
priority: normal
severity: normal
status: open
title: Inconsistency between functools.reduce & itertools.accumulate
type: enhancement
versions: Python 3.5

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

From report at bugs.python.org  Thu Sep 13 12:15:57 2018
From: report at bugs.python.org (25.45)
Date: Thu, 13 Sep 2018 16:15:57 +0000
Subject: [New-bugs-announce] [issue34660] Remove ableist terms and
 pejoratives from source code and docs
Message-ID: <1536855357.36.0.956365154283.issue34660@psf.upfronthosting.co.za>


New submission from 25.45 <resister at mailinator.com>:

It has come to my attention that CPython's source code contains problematic ableist/saneist terms and/or pejoratives, namely

sanity check    144
silly           26
insane          13
crazy           13
stupid          6
lame            2
lunatic         1

Some of those slipped into the documentation. In an attempt to make Python community more inclusive and welcoming, we should clean up these usages and replace them with something neutral (where applicable). Unfortunately, to this day many developers deem such efforts as "trolling", so please note that the precedent has already been set by many major projects. Here're just a few:

https://github.com/unpkg/unpkg.com/pull/81
https://github.com/reduxjs/redux/pull/2335
https://github.com/rtfd/readthedocs.org/pull/3752
https://github.com/krzysztofzablocki/Sourcery/issues/2
https://github.com/google/xi-editor/pull/126

Other resources:

https://english.stackexchange.com/q/282282
http://isthisableism.tumblr.com/sluralternatives

The goal of this issue is not to stir up arguments, but to figure out the alternatives and ways to replace those problematic terms.

----------
messages: 325260
nosy: 25.45
priority: normal
severity: normal
status: open
title: Remove ableist terms and pejoratives from source code and docs
versions: Python 3.8

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

From report at bugs.python.org  Thu Sep 13 12:52:18 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 13 Sep 2018 16:52:18 +0000
Subject: [New-bugs-announce] [issue34661] test_shutil fails with busybox
 unzip
Message-ID: <1536857538.58.0.956365154283.issue34661@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

BusyBox has a unzip command, but it doesn't support -t.

======================================================================
FAIL: test_unzip_zipfile (test.test_shutil.TestShutil)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/buildbot/buildarea/3.x.ware-alpine/build/Lib/test/test_shutil.py", line 1181, in test_unzip_zipfile
    subprocess.check_output(zip_cmd, stderr=subprocess.STDOUT)
subprocess.CalledProcessError: Command '['unzip', '-t', '/tmp/tmp92zs6lmt/archive.zip']' returned non-zero exit status 1.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "/buildbot/buildarea/3.x.ware-alpine/build/Lib/test/test_shutil.py", line 1185, in test_unzip_zipfile
    self.fail(msg.format(exc, details))
AssertionError: Command '['unzip', '-t', '/tmp/tmp92zs6lmt/archive.zip']' returned non-zero exit status 1.
**Unzip Output**
unzip: unrecognized option: t
BusyBox v1.27.2 (2017-12-12 10:41:50 GMT) multi-call binary.
Usage: unzip [-lnopq] FILE[.zip] [FILE]... [-x FILE...] [-d DIR]
Extract FILEs from ZIP archive
	-l	List contents (with -q for short form)
	-n	Never overwrite files (default: ask)
	-o	Overwrite
	-p	Print to stdout
	-q	Quiet
	-x FILE	Exclude FILEs
	-d DIR	Extract into DIR

----------
components: Tests
messages: 325262
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: test_shutil fails with busybox unzip
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Thu Sep 13 13:20:55 2018
From: report at bugs.python.org (Daniel Pope)
Date: Thu, 13 Sep 2018 17:20:55 +0000
Subject: [New-bugs-announce] [issue34662] tarfile.TarFile may write corrupt
 files if not closed
Message-ID: <1536859255.56.0.956365154283.issue34662@psf.upfronthosting.co.za>


New submission from Daniel Pope <lord.mauve at gmail.com>:

A tarfile.TarFile object open for writing may silently write corrupt tar files if it is destroyed before being closed.

While explicitly calling close() or using the object as a context manager is recommended, I would not expect this in basic usage.

There are two steps needed for a TarFile to be closed properly:

* According to https://github.com/python/cpython/blob/3.7/Lib/tarfile.py#L1726, two zero blocks must be written (though GNU tar seems to work even if these are absent)
* The underlying fileobj (an io.BufferedWriter) must then be flushed

A BufferedWriter is flushed in its __del__(); the problem is that TarFile objects form a reference cycle with their TarInfo members due to this line, which has the comment "Not Needed": https://github.com/python/cpython/blob/3.7/Lib/tarfile.py#L1801

Under PEP-442, when the TarFile becomes unreferenced the following Cycle Isolate is formed:

    TarInfo <=> TarFile -> BufferedWriter -> FileIO

Finalisers for these objects are run in an undefined order. If the FileIO finaliser is run before the BufferedWriter finaliser, then the fd is closed, buffered data in the BufferedWriter is not committed to disk, and the tar file is corrupt.

Additionally, while ResourceWarning is issued if the BufferedWriter or FileIO are left unclosed, no such warning is emitted by the TarFile.

----------
components: Library (Lib)
messages: 325266
nosy: lordmauve
priority: normal
severity: normal
status: open
title: tarfile.TarFile may write corrupt files if not closed
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Thu Sep 13 14:11:38 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Thu, 13 Sep 2018 18:11:38 +0000
Subject: [New-bugs-announce] [issue34663] Support POSIX_SPAWN_USEVFORK flag
 in posix_spawn
Message-ID: <1536862298.62.0.956365154283.issue34663@psf.upfronthosting.co.za>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

In some systems, posix_spawn has an optional flag (POSIX_SPAWN_USEVFORK) that is GNU specific and allows the user to force posix_spawn to spawn the child using vfork instead of fork. This is very beneficial as it gives great speedups compare with normal fork+execv.

----------
components: Extension Modules
messages: 325272
nosy: pablogsal
priority: normal
severity: normal
status: open
title: Support POSIX_SPAWN_USEVFORK flag in posix_spawn
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Thu Sep 13 14:22:08 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 13 Sep 2018 18:22:08 +0000
Subject: [New-bugs-announce] [issue34664]
 test.test_os.MakedirTests.test_mode is too strict
Message-ID: <1536862928.9.0.956365154283.issue34664@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

If TESTFN is in a directory with S_ISGID set in its mode, test_os will fail:

======================================================================
FAIL: test_mode (test.test_os.MakedirTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/buildbot/buildarea/3.x.ware-alpine/build/Lib/test/test_os.py", line 1134, in test_mode
    self.assertEqual(stat.S_IMODE(os.stat(path).st_mode), 0o555)
AssertionError: 1389 != 365

The problem is we're checking the entire file mode when we should just be checking the permission bits.

----------
components: Tests
messages: 325273
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: test.test_os.MakedirTests.test_mode is too strict
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Thu Sep 13 14:25:52 2018
From: report at bugs.python.org (Johannes M.)
Date: Thu, 13 Sep 2018 18:25:52 +0000
Subject: [New-bugs-announce] [issue34665] Py_FinalizeEx() - Bugs & caveats -
 Add info that NumPy and Pandas don't support reinitialization
Message-ID: <1536863152.32.0.956365154283.issue34665@psf.upfronthosting.co.za>


New submission from Johannes M. <jcmueller at posteo.de>:

Since about a decade, it's a know problem that NumPy and Pandas initialization function crashes on reinitialization after a call to Py_Finalize() + Py_Initialize().

[https://github.com/numpy/numpy/issues/8097]
[https://github.com/numpy/numpy/issues/11925]

It seems to be unlikely that this problem gets fixed soon. Due to the popularity of the modules, it would be good to add this information to the documentation of Py_FinalizeEx(), such that developers, who are planning to embed Python get this information already at the moment when they read the documentation.

I would suggest to change the following sentence:

    Some extensions may not work properly if their
    initialization routine is called more than once;

to

    Some extensions, like NumPy and Pandas, may not work properly if their
    initialization routine is called more than once;

----------
assignee: docs at python
components: Documentation
messages: 325275
nosy: docs at python, jcmuel
priority: normal
severity: normal
status: open
title: Py_FinalizeEx() - Bugs & caveats - Add info that NumPy and Pandas don't support reinitialization
type: enhancement
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Thu Sep 13 14:46:09 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Thu, 13 Sep 2018 18:46:09 +0000
Subject: [New-bugs-announce] [issue34666] Implement async write and async
 close in asyncio StreamWriter
Message-ID: <1536864369.03.0.956365154283.issue34666@psf.upfronthosting.co.za>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

Methods are needed for providing consistent stream API with control flow switched on by default.

----------
components: asyncio
messages: 325279
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Implement async write and async close in asyncio StreamWriter
versions: Python 3.8

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

From report at bugs.python.org  Thu Sep 13 16:31:15 2018
From: report at bugs.python.org (Carol Willing)
Date: Thu, 13 Sep 2018 20:31:15 +0000
Subject: [New-bugs-announce] [issue34667] Review documentation section by
 section
Message-ID: <1536870675.97.0.956365154283.issue34667@psf.upfronthosting.co.za>


New submission from Carol Willing <willingc at gmail.com>:

This issue is a placeholder for a comprehensive documentation review by content sections. I will develop a more detailed workplan in the coming weeks.

----------
assignee: willingc
messages: 325292
nosy: willingc
priority: normal
severity: normal
status: open
title: Review documentation section by section
type: enhancement

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

From report at bugs.python.org  Thu Sep 13 16:31:38 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 13 Sep 2018 20:31:38 +0000
Subject: [New-bugs-announce] [issue34668] test_resource fails if test has
 CAP_SYS_RESOURCE but isn't root
Message-ID: <1536870698.96.0.956365154283.issue34668@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

test_prlimit tries to test that raising the hardlimit of an unprivileged process. It tries to raise the hardlimit of pid 1, which usually raises a PermissionError. However, if the tests are privileged, this test can't work. The test tries to avoid this by only running the test if os.geteuid() != 0. However, there are other cases. For example, if the test process isn't root but has CAP_SYS_RESOURCE. While we could check for these other cases, I think we should just delete this test. There's no special logic in the prlimit implementation for handling permission errors, so it's not adding much value.

======================================================================
FAIL: test_prlimit (test.test_resource.ResourceTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/buildbot/buildarea/3.x.ware-alpine/build/Lib/test/support/__init__.py", line 587, in wrapper
    return func(*args, **kw)
  File "/buildbot/buildarea/3.x.ware-alpine/build/Lib/test/test_resource.py", line 152, in test_prlimit
    1, resource.RLIMIT_AS)
AssertionError: PermissionError not raised by prlimit

----------
components: Tests
messages: 325293
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: test_resource fails if test has CAP_SYS_RESOURCE but isn't root
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Thu Sep 13 19:11:27 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 13 Sep 2018 23:11:27 +0000
Subject: [New-bugs-announce] [issue34669] test_ssl fails if SSLv2 is enabled
Message-ID: <1536880287.69.0.956365154283.issue34669@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

I modified multissltests.py to enable-ssl2:

--- a/Tools/ssl/multissltests.py
+++ b/Tools/ssl/multissltests.py
@@ -275,7 +275,8 @@ class AbstractBuilder(object):
         cmd = [
             "./config",
             "shared", "--debug",
-            "--prefix={}".format(self.install_dir)
+            "--prefix={}".format(self.install_dir),
+            "enable-ssl2",
         ]
         env = os.environ.copy()

This results in some test_ssl failures, which all seem to have the same root cause:

$ Tools/ssl/multissltests.py  --openssl 1.0.2o
....
======================================================================
ERROR: test_constructor (test.test_ssl.ContextTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/benjamin/dev/python/cpython/Lib/test/test_ssl.py", line 965, in test_constructor
    ssl.SSLContext(protocol)
  File "/home/benjamin/dev/python/cpython/Lib/ssl.py", line 388, in __new__
    self = _SSLContext.__new__(cls, protocol)
ssl.SSLError: [SSL: NO_CIPHER_MATCH] no cipher match (_ssl.c:3008)

======================================================================
ERROR: test_protocol (test.test_ssl.ContextTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/benjamin/dev/python/cpython/Lib/test/test_ssl.py", line 973, in test_protocol
    ctx = ssl.SSLContext(proto)
  File "/home/benjamin/dev/python/cpython/Lib/ssl.py", line 388, in __new__
    self = _SSLContext.__new__(cls, protocol)
ssl.SSLError: [SSL: NO_CIPHER_MATCH] no cipher match (_ssl.c:3008)

======================================================================
ERROR: test_session_stats (test.test_ssl.ContextTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/benjamin/dev/python/cpython/Lib/test/test_ssl.py", line 1320, in test_session_stats
    ctx = ssl.SSLContext(proto)
  File "/home/benjamin/dev/python/cpython/Lib/ssl.py", line 388, in __new__
    self = _SSLContext.__new__(cls, protocol)
ssl.SSLError: [SSL: NO_CIPHER_MATCH] no cipher match (_ssl.c:3008)

======================================================================
ERROR: test_echo (test.test_ssl.ThreadedTests) (protocol='PROTOCOL_SSLv2')
Basic test of an SSL client connecting to a server
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/benjamin/dev/python/cpython/Lib/test/test_ssl.py", line 2569, in test_echo
    context = ssl.SSLContext(protocol)
  File "/home/benjamin/dev/python/cpython/Lib/ssl.py", line 388, in __new__
    self = _SSLContext.__new__(cls, protocol)
ssl.SSLError: [SSL: NO_CIPHER_MATCH] no cipher match (_ssl.c:3008)

======================================================================
ERROR: test_protocol_sslv2 (test.test_ssl.ThreadedTests)
Connecting to an SSLv2 server with various client options
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/benjamin/dev/python/cpython/Lib/test/test_ssl.py", line 2960, in test_protocol_sslv2
    try_protocol_combo(ssl.PROTOCOL_SSLv2, ssl.PROTOCOL_SSLv2, True)
  File "/home/benjamin/dev/python/cpython/Lib/test/test_ssl.py", line 2521, in try_protocol_combo
    client_context = ssl.SSLContext(client_protocol)
  File "/home/benjamin/dev/python/cpython/Lib/ssl.py", line 388, in __new__
    self = _SSLContext.__new__(cls, protocol)
ssl.SSLError: [SSL: NO_CIPHER_MATCH] no cipher match (_ssl.c:3008)

======================================================================
ERROR: test_protocol_sslv3 (test.test_ssl.ThreadedTests)
Connecting to an SSLv3 server with various client options
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/benjamin/dev/python/cpython/Lib/test/test_ssl.py", line 3026, in test_protocol_sslv3
    try_protocol_combo(ssl.PROTOCOL_SSLv3, ssl.PROTOCOL_SSLv2, False)
  File "/home/benjamin/dev/python/cpython/Lib/test/test_ssl.py", line 2521, in try_protocol_combo
    client_context = ssl.SSLContext(client_protocol)
  File "/home/benjamin/dev/python/cpython/Lib/ssl.py", line 388, in __new__
    self = _SSLContext.__new__(cls, protocol)
ssl.SSLError: [SSL: NO_CIPHER_MATCH] no cipher match (_ssl.c:3008)

======================================================================
ERROR: test_protocol_tlsv1 (test.test_ssl.ThreadedTests)
Connecting to a TLSv1 server with various client options
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/benjamin/dev/python/cpython/Lib/test/test_ssl.py", line 3043, in test_protocol_tlsv1
    try_protocol_combo(ssl.PROTOCOL_TLSv1, ssl.PROTOCOL_SSLv2, False)
  File "/home/benjamin/dev/python/cpython/Lib/test/test_ssl.py", line 2521, in try_protocol_combo
    client_context = ssl.SSLContext(client_protocol)
  File "/home/benjamin/dev/python/cpython/Lib/ssl.py", line 388, in __new__
    self = _SSLContext.__new__(cls, protocol)
ssl.SSLError: [SSL: NO_CIPHER_MATCH] no cipher match (_ssl.c:3008)

======================================================================
ERROR: test_protocol_tlsv1_1 (test.test_ssl.ThreadedTests)
Connecting to a TLSv1.1 server with various client options.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/benjamin/dev/python/cpython/Lib/test/test_ssl.py", line 3058, in test_protocol_tlsv1_1
    try_protocol_combo(ssl.PROTOCOL_TLSv1_1, ssl.PROTOCOL_SSLv2, False)
  File "/home/benjamin/dev/python/cpython/Lib/test/test_ssl.py", line 2521, in try_protocol_combo
    client_context = ssl.SSLContext(client_protocol)
  File "/home/benjamin/dev/python/cpython/Lib/ssl.py", line 388, in __new__
    self = _SSLContext.__new__(cls, protocol)
ssl.SSLError: [SSL: NO_CIPHER_MATCH] no cipher match (_ssl.c:3008)

======================================================================
ERROR: test_protocol_tlsv1_2 (test.test_ssl.ThreadedTests)
Connecting to a TLSv1.2 server with various client options.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/benjamin/dev/python/cpython/Lib/test/test_ssl.py", line 3079, in test_protocol_tlsv1_2
    try_protocol_combo(ssl.PROTOCOL_TLSv1_2, ssl.PROTOCOL_SSLv2, False)
  File "/home/benjamin/dev/python/cpython/Lib/test/test_ssl.py", line 2521, in try_protocol_combo
    client_context = ssl.SSLContext(client_protocol)
  File "/home/benjamin/dev/python/cpython/Lib/ssl.py", line 388, in __new__
    self = _SSLContext.__new__(cls, protocol)
ssl.SSLError: [SSL: NO_CIPHER_MATCH] no cipher match (_ssl.c:3008)

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

----------
assignee: christian.heimes
components: SSL
messages: 325304
nosy: benjamin.peterson, christian.heimes
priority: normal
severity: normal
status: open
title: test_ssl fails if SSLv2 is enabled
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Thu Sep 13 20:16:08 2018
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 14 Sep 2018 00:16:08 +0000
Subject: [New-bugs-announce] [issue34670] Add set_post_handshake_auth for
 TLS 1.3
Message-ID: <1536884168.95.0.956365154283.issue34670@psf.upfronthosting.co.za>


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

TLS 1.3 removed renegotiation in favor of rekeying and post handshake authentication (PHA). With PHA, a server can request a client certificate from a client at some point after the handshake. The feature is commonly used by HTTP server for conditional and path specific TLS client auth. For example a server can decide to require a cert based on HTTP method and/or path. A client must announce support for PHA during the handshake

Apache mod_ssl uses PHA, https://github.com/apache/httpd/blob/trunk/modules/ssl/ssl_engine_kernel.c#L1207

As of OpenSSL ticket https://github.com/openssl/openssl/issues/6933, TLS 1.3 clients no longer send the PHA TLS extension by default. Nikos and I requested the change, because PHA breaks some assumptions of TLS 1.2 clients. For on-demand auth, PHA extension must be enabled with SSL_CTX_set_post_handshake_auth(), https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_post_handshake_auth.html .

I propose to add a property on SSLContext to enable PHA and backport the change to Python 2.7, 3.6 and 3.7.

In order to test the feature, I'd also have to add some flags and a function for the server side: (SSL_VERIFY_CLIENT_ONCE, SSL_VERIFY_POST_HANDSHAKE, SSL_verify_client_post_handshake()).

----------
assignee: christian.heimes
components: SSL
messages: 325314
nosy: benjamin.peterson, christian.heimes, ned.deily
priority: normal
severity: normal
stage: needs patch
status: open
title: Add set_post_handshake_auth for TLS 1.3
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/issue34670>
_______________________________________

From report at bugs.python.org  Thu Sep 13 21:00:22 2018
From: report at bugs.python.org (Sebastian Bassi)
Date: Fri, 14 Sep 2018 01:00:22 +0000
Subject: [New-bugs-announce] [issue34671] Remove references to Benevolent
 Dictator
Message-ID: <1536886822.26.0.956365154283.issue34671@psf.upfronthosting.co.za>


New submission from Sebastian Bassi <sbassi at users.sourceforge.net>:

Following the trend initiated at https://bugs.python.org/issue34605, I want to point out that the term dictator has a negative connotation in Argentina and other countries where we suffered bloody dictatorship (30000 dead and missing persons, or "desaparecidos" as we call it).
I understand that the former title BDFL may be funny for most developers, but the term "benevolent dictatorship" (or it Spanish equivalent "dictablanda") was used in Chile by the Pinochet's regime.
This title doesn't reflect the democratic nature of the whole project.
My suggestion is to take this into account when defining PEP-8010 and related documentation.

----------
assignee: docs at python
components: Documentation
messages: 325315
nosy: docs at python, sbassi
priority: normal
severity: normal
status: open
title: Remove references to Benevolent Dictator
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Fri Sep 14 00:01:29 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 14 Sep 2018 04:01:29 +0000
Subject: [New-bugs-announce] [issue34672] '%Z' strftime specifier never
 works with musl
Message-ID: <1536897689.03.0.956365154283.issue34672@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

With the musl C library, one has failures like this:

======================================================================
FAIL: test_strptime (test.test_time.TimeTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/buildbot/buildarea/3.x.ware-alpine/build/Lib/test/test_time.py", line 273, in test_strptime
    time.strptime(strf_output, format)
ValueError: time data '' does not match format '%Z'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
  File "/buildbot/buildarea/3.x.ware-alpine/build/Lib/test/test_time.py", line 276, in test_strptime
    (format, strf_output))
AssertionError: conversion specifier '%Z' failed with '' input.
----------------------------------------------------------------------

The root problem is that time.strptime('%Z', time.gmtime()) won't work?it returns an empty string?even though time.gmtime() will probably have a valid tm_zone field. This is because musl has a safety mechanism where it refuses to process a tm_zone entry unless it produced the string. (See https://git.musl-libc.org/cgit/musl/commit/?id=d78be392e144c338f58ce6a51d82c859126c137d.)

As a partial workaround, I propose we check whether an incoming time.struct_time instance has an tm_zone member equal to tzname[0] or tzname[1], and place one of those global strings into the C-level tm struct if they do match.

----------
components: Library (Lib)
messages: 325319
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: '%Z' strftime specifier never works with musl
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Fri Sep 14 00:14:32 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 14 Sep 2018 04:14:32 +0000
Subject: [New-bugs-announce] [issue34673] make the eval loop more editable
Message-ID: <1536898472.44.0.956365154283.issue34673@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

The TARGET macro in ceval.c hides control flow, most importantly the case statement. This confuses my editor and makes it indent things automatically improperly. This can be fixed by moving the case statements out of the TARGET macro.

----------
components: Interpreter Core
messages: 325320
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: make the eval loop more editable
versions: Python 3.8

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

From report at bugs.python.org  Fri Sep 14 00:28:45 2018
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 14 Sep 2018 04:28:45 +0000
Subject: [New-bugs-announce] [issue34674] assume unistd.h exists
Message-ID: <1536899325.09.0.956365154283.issue34674@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <benjamin at python.org>:

We still have some conditional code under HAVE_UNISTD. However, we also unconditionally include it many other places, so let's just get rid of the condition and configure check.

----------
components: Build
messages: 325322
nosy: benjamin.peterson
priority: normal
severity: normal
status: open
title: assume unistd.h exists
versions: Python 3.8

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

From report at bugs.python.org  Fri Sep 14 03:29:31 2018
From: report at bugs.python.org (Freed_Slave)
Date: Fri, 14 Sep 2018 07:29:31 +0000
Subject: [New-bugs-announce] [issue34675] Avoid terminology related to
 slavery
Message-ID: <1536910171.17.0.956365154283.issue34675@psf.upfronthosting.co.za>


New submission from Freed_Slave <Freed_Slave at notmailinator.com>:

It is very good to see that "master" and "slave" terminology was removed from the project, however there are still references to "owned" references, as if these references were property. There are also things needing to be "freed" as if they were indentured servants.

I would like to open up discussion about better terminology - and when better terminology has been agreed upon I do not mind submitting a PR to get rid of this exclusive language.

"Freed" terminology:

* https://github.com/python/cpython/search?q=freed&unscoped_q=freed

There are also additional instances were "free" is used instead of "clear" but the context makes it harder to discover with a naive search.

"Owned" terminology:

* https://github.com/python/cpython/search?utf8=%E2%9C%93&q=owned&type=

"Master/Slave" terminology, now removed:

* https://bugs.python.org/issue34605

On the topic of inclusive/exclusive terminology, there are other problematic things that should be addressed - either here or in separate issues. However I'd like to draw attention to one particularly sexist email in `test_smtplib.py` "my_mom at great.cooker.com" - hilarious! Not. It especially sticks out among the more generic and inclusive test emails. I particularly like the inclusion of "P?olo <f?o at bar.com>" but then in a test email he makes a sexual innuendo.

* https://github.com/python/cpython/search?utf8=%E2%9C%93&q=mom&type=

* Said innuendo: "oh l? l?, know what I mean, know what I mean?\n\n")"

----------
assignee: docs at python
components: Documentation
messages: 325331
nosy: Freed_Slave, docs at python
priority: normal
severity: normal
status: open
title: Avoid terminology related to slavery
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Fri Sep 14 06:13:50 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 14 Sep 2018 10:13:50 +0000
Subject: [New-bugs-announce] [issue34676] Guarantie that divmod() and
 PyNumber_Divmod() return a 2-tuple
Message-ID: <1536920030.35.0.956365154283.issue34676@psf.upfronthosting.co.za>


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

It is documented that divmod() returns a pair of numbers, but the implementation doesn't enforce this. Actually divmod() just returns the result of __divmod__() or __rdivmod__() without checking it. PyNumber_Divmod() is documented as the C equivalent of divmod(). But since it returns a 2-tuple in all implemented cases, the user code can expect that it always return a 2-tuple. This can lead to hidden bugs similar to issue31577.

I think there are no reasons of returning anything except a 2-tuple from divmod(). Forcing this conditions can save third-party code from crashes. The following PR make divmod() and PyNumber_Divmod() always returning a 2-tuple.

----------
components: Interpreter Core
messages: 325341
nosy: mark.dickinson, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Guarantie that divmod() and PyNumber_Divmod() return a 2-tuple
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Fri Sep 14 08:17:49 2018
From: report at bugs.python.org (mediator42)
Date: Fri, 14 Sep 2018 12:17:49 +0000
Subject: [New-bugs-announce] [issue34677] Event scheduler page example
Message-ID: <1536927469.93.0.956365154283.issue34677@psf.upfronthosting.co.za>


New submission from mediator42 <h.lensch at lmt.uni-saarland.de>:

Hi,
I am pretty confident, that the example you put on the Event scheduler page (https://docs.python.org/3.7/library/sched.html) is somehow strange. 

If the priority argument behave as described, it should print the "keyword" line before the "positional" line, since these events are scheduled for the same time but "keyword" has a higher priority than "positional".

When I run this script on my PC it behaves correctly.

Best reagrds

----------
assignee: docs at python
components: Documentation
messages: 325345
nosy: docs at python, mediator42
priority: normal
severity: normal
status: open
title: Event scheduler page example
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Fri Sep 14 08:56:13 2018
From: report at bugs.python.org (dwayne gigleum)
Date: Fri, 14 Sep 2018 12:56:13 +0000
Subject: [New-bugs-announce] [issue34678] need to remove the term "white
 space"
Message-ID: <1536929773.36.0.956365154283.issue34678@psf.upfronthosting.co.za>


New submission from dwayne gigleum <dwaygig at gmail.com>:

As we are purging offensive language

"white space" needs removing, as this can be offensive.

as seen in lots of places: https://github.com/python/cpython/search?p=1&q=white+space

----------
messages: 325346
nosy: dwaygig
priority: normal
severity: normal
status: open
title: need to remove the term "white space"

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

From report at bugs.python.org  Fri Sep 14 11:27:45 2018
From: report at bugs.python.org (Nic Watson)
Date: Fri, 14 Sep 2018 15:27:45 +0000
Subject: [New-bugs-announce] [issue34679] asyncio.add_signal_handler call
 fails if not on main thread
Message-ID: <1536938865.53.0.956365154283.issue34679@psf.upfronthosting.co.za>


New submission from Nic Watson <pythonbugs at nicwatson.org>:

Summary:  essentially asyncio.add_signal_handler doesn't work when called off the main thread.  One might consider this a documentation failure.

(Note: there's also a bigger issue with cleanup, which I'll submit separately)

Exception in thread Thread-1:
Traceback (most recent call last):
  File "/home/nic/.pyenv/versions/3.6.4/lib/python3.6/asyncio/unix_events.py", line 91, in add_signal_handler
    signal.set_wakeup_fd(self._csock.fileno())
ValueError: set_wakeup_fd only works in main thread

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/nic/.pyenv/versions/3.6.4/lib/python3.6/threading.py", line 916, in _bootstrap_inner
    self.run()
  File "/home/nic/.pyenv/versions/3.6.4/lib/python3.6/threading.py", line 864, in run
    self._target(*self._args, **self._kwargs)
  File "/home/nic/tmp/signal_event_loop_bug.py", line 14, in do_loop
    loop.add_signal_handler(signal.SIGINT, mysighandler)
  File "/home/nic/.pyenv/versions/3.6.4/lib/python3.6/asyncio/unix_events.py", line 93, in add_signal_handler
    raise RuntimeError(str(exc))
RuntimeError: set_wakeup_fd only works in main thread

Code:

import asyncio
import signal
import threading

def mysighandler():
    pass

def do_loop():
    loop = asyncio.new_event_loop()
    # This will fail with RuntimeError: set_wakeup_fd only works in main thread
    loop.add_signal_handler(signal.SIGINT, mysighandler)
    loop.close()

t = threading.Thread(target=do_loop)
t.start()
t.join()

----------
components: asyncio
messages: 325350
nosy: asvetlov, jnwatson, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.add_signal_handler call fails if not on main thread
type: behavior
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Fri Sep 14 11:33:28 2018
From: report at bugs.python.org (Nic Watson)
Date: Fri, 14 Sep 2018 15:33:28 +0000
Subject: [New-bugs-announce] [issue34680] asyncio event_loop close fails off
 main thread if signal handler registered
Message-ID: <1536939208.48.0.956365154283.issue34680@psf.upfronthosting.co.za>


New submission from Nic Watson <pythonbugs at nicwatson.org>:

If a signal handler callback is registered on an event loop, and the event loop has close() called on it, the close will fail.

Exception:
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/home/nic/.pyenv/versions/3.7.0/lib/python3.7/threading.py", line 917, in _bootstrap_inner
    self.run()
  File "/home/nic/.pyenv/versions/3.7.0/lib/python3.7/threading.py", line 865, in run
    self._target(*self._args, **self._kwargs)
  File "/home/nic/tmp/signal_event_loop_bug.py", line 9, in do_loop
    loop.close()
  File "/home/nic/.pyenv/versions/3.7.0/lib/python3.7/asyncio/unix_events.py", line 58, in close
    self.remove_signal_handler(sig)
  File "/home/nic/.pyenv/versions/3.7.0/lib/python3.7/asyncio/unix_events.py", line 147, in remove_signal_handler
    signal.signal(sig, handler)
  File "/home/nic/.pyenv/versions/3.7.0/lib/python3.7/signal.py", line 47, in signal
    handler = _signal.signal(_enum_to_int(signalnum), _enum_to_int(handler))
ValueError: signal only works in main thread

Code:
import asyncio
import signal
import threading

def mysighandler():
    pass

def do_loop(loop):
    loop.close()

loop = asyncio.new_event_loop()
loop.add_signal_handler(signal.SIGINT, mysighandler)
t = threading.Thread(target=do_loop, args=(loop,))
t.start()
t.join()

----------
components: asyncio
messages: 325354
nosy: asvetlov, jnwatson, yselivanov
priority: normal
severity: normal
status: open
title: asyncio event_loop close fails off main thread if signal handler registered
type: behavior
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Fri Sep 14 12:22:32 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Fri, 14 Sep 2018 16:22:32 +0000
Subject: [New-bugs-announce] [issue34681] Incorrect class name Pattern in
 sre_parse.py
Message-ID: <1536942152.74.0.956365154283.issue34681@psf.upfronthosting.co.za>


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

In 8a3ebf8ca87a7d2989148d7c218974ab4235ca5d, with synchronizing regex engine with SRE 0.9.6, the class State in sre_parse.py was renamed to Pattern and the following comment was added: "master pattern object.  keeps track of global attributes".

This name is incorrect and misleading. This class doesn't represents a pattern in any sense. It just keeps global flags and groups information for parser. There is a class SupParser in sre_parse.py that represents a pattern or its part in intermediate representation, and there is a class Pattern defined in sre.c and exposed publicly, that represents a compiled pattern.

The proposed PR renames Pattern back to State and renames attribute, parameter and variable names for referring to objects of this class from pattern to state. All this is an internal API, but since there may be a third-party that uses it, it is for developer version only.

----------
components: Library (Lib), Regular Expressions
messages: 325359
nosy: effbot, ezio.melotti, mrabarnett, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Incorrect class name Pattern in sre_parse.py
versions: Python 3.8

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

From report at bugs.python.org  Fri Sep 14 12:49:47 2018
From: report at bugs.python.org (Zachary Ware)
Date: Fri, 14 Sep 2018 16:49:47 +0000
Subject: [New-bugs-announce] [issue34682] Typo reports on docs@
Message-ID: <1536943787.72.0.956365154283.issue34682@psf.upfronthosting.co.za>


New submission from Zachary Ware <zachary.ware at gmail.com>:

>From ZooDSS (?????? ????????) on docs@:

https://mail.python.org/pipermail/docs/2018-September/037223.html :
"""
https://docs.python.org/3/reference/datamodel.html#metaclass-example - 
    "uses an collections.OrderedDict to remember" when it is better to use "uses a collections.OrderedDict to remember"

https://docs.python.org/3/reference/executionmodel.html#exceptions
"Exceptions are a means" - Is it correct to use "a" here? "means" means a lot of them. "a" means one.

"In either case, it prints a stack backtrace" - most of the time in Python documentation term "traceback" is used instead of "backtrace". It may mislead newcomers, so they will think, that this is potentially a new term.

https://docs.python.org/3/reference/expressions.html#yield-expressions
"Due to their side effects on the containing scope, yield expressions are not permitted as part of the implicitly defined scopes used to implement comprehensions and generator expressions (in Python 3.7, such expressions emit DeprecationWarning when compiled, in Python 3.8+ they will emit SyntaxError).." - two periods in the end of the sentence.

https://docs.python.org/3/reference/expressions.html#yield-expressions
"...or automatically when the sub-iterator is a generator (by returning a value from the sub-generator)." - inconsistent use of "sub-iterator" term. Previously subiterator was referenced several times as "subiterator" not "sub-iterator".

If i understood something wrong, then i am sorry.
"""

https://mail.python.org/pipermail/docs/2018-September/037224.html :
"""
https://docs.python.org/3/reference/expressions.html#yield-expressions

Term "sub-generator" is used in PEP 280 without dash ("-") symbol - "subgenerator". At the same time it is used as "sub-generator" 2 times on this page:

"generator (by returning a value from the sub-generator)." - here.

"The proposal to introduce the yield_from syntax, making delegation to sub-generators easy." - and here.
"""

https://mail.python.org/pipermail/docs/2018-September/037237.html :
"""
https://docs.python.org/3/reference/expressions.html#asynchronous-generator-functions
"function as a asynchronous generator function." - it's better to say "function as an asynchronous generator function."

https://docs.python.org/3/reference/expressions.html#agen.__anext__
"When an asynchronous generator function is resumed with a __anext__() method" - may be better "...function is resumed with an __anext__() method".

"the awaitable instead raises an StopAsyncIteration exception" - at the same time here may be better to use "the awaitable instead raises a StopAsyncIteration exception".

https://docs.python.org/3/reference/expressions.html#agen.athrow
"an StopAsyncIteration exception is raised" - here is the same situation as previously. "a" instead of "an" may be better.

Here goes very special case, and if i am wrong you can laugh on me as much as you wish! =)

https://docs.python.org/3/reference/expressions.html#parenthesized-forms
"Since tuples are immutable, the rules for literals apply" - Tuples are immutable, but not literals. So may be "the same rules as for literals apply" is better? Or does it apply exactly those rules, that apply for literals? "()" - this is a literal, that yelds an empty tuple. But this doesn't connect, or i am wrong? If i am - then i am very sorry.

Again, if i mistook something - i am sorry. Thanks for the good work. This is the best documentation i've ever seen.
"""

----------
assignee: docs at python
components: Documentation
messages: 325362
nosy: docs at python, zach.ware
priority: normal
severity: normal
stage: needs patch
status: open
title: Typo reports on docs@
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Fri Sep 14 13:22:22 2018
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 14 Sep 2018 17:22:22 +0000
Subject: [New-bugs-announce] [issue34683] Caret positioned wrong for
 SyntaxError reported by ast.c
Message-ID: <1536945742.16.0.956365154283.issue34683@psf.upfronthosting.co.za>


New submission from Guido van Rossum <guido at python.org>:

Input file with a subtle error: a number where an assignment target is required:

for 1 in []: pass

Run it, it gives a SyntaxError.  Note how the caret pointing to the incorrect token is position one to the left of where you'd expect it:

  File "s.py", line 1
    for 1 in []: pass
       ^
SyntaxError: can't assign to literal

For every syntax error I've seen that's produced by ast.c this seems to be the case -- the caret is always positioned 1 too far left.

I tried to understand how this is happening but my AST-fu is lacking. It seems this has been happening since ast.c started added column numbers -- in Python 2.7 there's no caret at all, but in 3.4 and later there's a caret and it has the same problem. (Also in 3.3; I don't have 3.2 or older 3.x lying around to test.)

----------
messages: 325366
nosy: gvanrossum
priority: low
severity: normal
status: open
title: Caret positioned wrong for SyntaxError reported by ast.c
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/issue34683>
_______________________________________

From report at bugs.python.org  Fri Sep 14 13:35:00 2018
From: report at bugs.python.org (shirish)
Date: Fri, 14 Sep 2018 17:35:00 +0000
Subject: [New-bugs-announce] [issue34684] Generate _geoslib.c with Cython
 0.28.2 for Python 3.7 transition
Message-ID: <1536946500.32.0.956365154283.issue34684@psf.upfronthosting.co.za>


New submission from shirish <shirishag75 at gmail.com>:

umm... I do not know about python other than python $something.py to run a python script. 

At Debian people are having an issue with not having _geoslib.c generated with a more recent Cython 0.28.2 for the transition. 

There is a patch and the bug has been put at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903579

Could somebody have a look at it and recommend either at the bug-report or here what could be done to fix the issue.

----------
components: Build
messages: 325367
nosy: shirish
priority: normal
severity: normal
status: open
title: Generate _geoslib.c with Cython 0.28.2 for Python 3.7 transition
type: compile error
versions: Python 3.7

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

From report at bugs.python.org  Fri Sep 14 13:41:12 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Fri, 14 Sep 2018 17:41:12 +0000
Subject: [New-bugs-announce] [issue34685] scheduler tests for posix_spawn
 fail on AMD64 FreeBSD 10.x Shared 3.x
Message-ID: <1536946872.72.0.956365154283.issue34685@psf.upfronthosting.co.za>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

https://buildbot.python.org/all/#/builders/87/builds/1428/steps/4/logs/stdio


======================================================================
ERROR: test_setscheduler_with_policy (test.test_posix.TestPosixSpawn)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/test_posix.py", line 1693, in test_setscheduler_with_policy
    scheduler=(policy, os.sched_param(priority))
PermissionError: [Errno 1] Operation not permitted: '/usr/home/buildbot/python/3.x.koobs-freebsd10/build/python'
======================================================================
FAIL: test_setscheduler_only_param (test.test_posix.TestPosixSpawn)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/test_posix.py", line 1677, in test_setscheduler_only_param
    self.assertEqual(os.waitpid(pid, 0), (pid, 0))
AssertionError: Tuples differ: (96981, 256) != (96981, 0)
First differing element 1:
256
0
- (96981, 256)
?         ^^^
+ (96981, 0)
?         ^
----------------------------------------------------------------------

----------
components: Tests
messages: 325370
nosy: pablogsal
priority: normal
severity: normal
status: open
title: scheduler tests for posix_spawn fail on AMD64 FreeBSD 10.x Shared 3.x
versions: Python 3.8

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

From report at bugs.python.org  Fri Sep 14 13:42:00 2018
From: report at bugs.python.org (Erwan Le Pape)
Date: Fri, 14 Sep 2018 17:42:00 +0000
Subject: [New-bugs-announce] [issue34686] Add `-r`,
 as opposed to `-R` to Python core interpreter
Message-ID: <1536946920.27.0.956365154283.issue34686@psf.upfronthosting.co.za>


New submission from Erwan Le Pape <lepaperwan3 at gmail.com>:

I'm attempting to leverage PEP 552 to make the core interpreter build process more deterministic. However, the standard Python Makefile uses `python -E` when calling the compileall (and all other setup scripts), which forces randomization since it can only be turned off through environment variables (which in turn leads to nondeterministic behaviour as noted in PEP 552 [1],[2]).

Also, is adding a flag that disables randomization something that would be acceptable? Or are options to the core interpreter to be kept to a minimum and this does not represent a large enough use-case?

This would basically hold in Modules/main.c in something as short as:
+ case 'r':
+     config->use_hash_seed = 1;
+     config->hash_seed = 0;
+     break;

----------
components: Interpreter Core
messages: 325371
nosy: lepaperwan
priority: normal
severity: normal
status: open
title: Add `-r`, as opposed to `-R` to Python core interpreter
type: enhancement
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Fri Sep 14 15:35:17 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 14 Sep 2018 19:35:17 +0000
Subject: [New-bugs-announce] [issue34687] asyncio: is it time to make
 ProactorEventLoop as the default event loop?
Message-ID: <1536953717.98.0.956365154283.issue34687@psf.upfronthosting.co.za>


New submission from STINNER Victor <vstinner at redhat.com>:

Is it time to make ProactorEventLoop as the default event loop?

Since 2014, many features have been added to ProactorEventLoop (ex: SSL support) and the implementation is way more today than it was 4 years ago.

Comparison of SelectorEventLoop and ProactorEventLoop on Windows:
https://docs.python.org/dev/library/asyncio-platforms.html#windows

----------
components: asyncio
messages: 325391
nosy: asvetlov, vstinner, yselivanov
priority: normal
severity: normal
status: open
title: asyncio: is it time to make ProactorEventLoop as the default event loop?
versions: Python 3.8

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

From report at bugs.python.org  Fri Sep 14 15:52:29 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Fri, 14 Sep 2018 19:52:29 +0000
Subject: [New-bugs-announce] [issue34688] Segfault in pandas that works fine
 on 3.7
Message-ID: <1536954749.8.0.956365154283.issue34688@psf.upfronthosting.co.za>


New submission from Karthikeyan Singaravelan <tir.karthi at gmail.com>:

I have tried running pandas test suite under Python 3.8 and the below code segfault as part of the test suite. Pandas uses Python 3.7 in Travis and it runs fine. There is also NumPy related code in the trace but it also seems to run fine under Python 3.7. I suppose this is a crash in CPython master and I didn't try latest Python 3.7 branch yet. Attaching the sample program and stack trace as below : 

# Program 

from pandas import DataFrame
import pandas as pd

df = DataFrame({'A': [1, 2, 3],
                'B': [1., 2., 3.],
                'C': ['foo', 'bar', 'baz'],
                'D': pd.date_range('20130101', periods=3)})

print(df.agg('sum'))

# Python 3.7 output

$ virtualenv -p /usr/bin/python3.7 py-37-venv
$ source py-37-venv/bin/activate
$ python
Python 3.7.0 (default, Jun 28 2018, 02:32:19)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>

$ pip install pandas

$ python foo.py
A            6
B            6
C    foobarbaz
dtype: object


# Crash on Python 3.8 (CPython master)

$ ./python -m venv ../pandas-venv
$ cd ../ && source pandas-venv/bin/activate
$ python
Python 3.8.0a0 (heads/master:73820a6, Sep 14 2018, 18:33:26)
[GCC 5.4.0 20160609] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>
$ pip install pandas
$ python foo.py
<frozen importlib._bootstrap>:219: ImportWarning: can't resolve package from __spec__ or __package__, falling back on __name__ and __path__
/home/karthi/pandas/pandas/core/dtypes/inference.py:6: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working
  from collections import Iterable
/home/karthi/pandas/pandas/core/tools/datetimes.py:3: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working
  from collections import MutableMapping
python: Objects/call.c:90: _PyObject_FastCallDict: Assertion `!PyErr_Occurred()' failed.


# Stack trace

$ gdb --args python foo.py
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from python...done.
warning: File "/home/karthi/cpython/python-gdb.py" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load".
To enable execution of this file add
	add-auto-load-safe-path /home/karthi/cpython/python-gdb.py
line to your configuration file "/home/karthi/.gdbinit".
To completely disable this security protection add
	set auto-load safe-path /
line to your configuration file "/home/karthi/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
	info "(gdb)Auto-loading safe path"
(gdb)
(gdb) set pagination off
(gdb) r
Starting program: /home/karthi/pandas-venv/bin/python foo.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
<frozen importlib._bootstrap>:219: ImportWarning: can't resolve package from __spec__ or __package__, falling back on __name__ and __path__
/home/karthi/pandas/pandas/core/dtypes/inference.py:6: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working
  from collections import Iterable
/home/karthi/pandas/pandas/core/tools/datetimes.py:3: DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working
  from collections import MutableMapping
python: Objects/call.c:90: _PyObject_FastCallDict: Assertion `!PyErr_Occurred()' failed.

Program received signal SIGABRT, Aborted.
0x00007ffff7115428 in __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
54	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007ffff7115428 in __GI_raise (sig=sig at entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1  0x00007ffff711702a in __GI_abort () at abort.c:89
#2  0x00007ffff710dbd7 in __assert_fail_base (fmt=<optimized out>, assertion=assertion at entry=0x5fa699 "!PyErr_Occurred()", file=file at entry=0x5fa650 "Objects/call.c", line=line at entry=90, function=function at entry=0x5fade0 <__PRETTY_FUNCTION__.13021> "_PyObject_FastCallDict") at assert.c:92
#3  0x00007ffff710dc82 in __GI___assert_fail (assertion=assertion at entry=0x5fa699 "!PyErr_Occurred()", file=file at entry=0x5fa650 "Objects/call.c", line=line at entry=90, function=function at entry=0x5fade0 <__PRETTY_FUNCTION__.13021> "_PyObject_FastCallDict") at assert.c:101
#4  0x0000000000432229 in _PyObject_FastCallDict (callable=callable at entry=0x7fffe8f33350, args=0x7fffffffba90, nargs=nargs at entry=1, kwargs=kwargs at entry=0x0) at Objects/call.c:90
#5  0x0000000000479dcd in call_unbound (unbound=<optimized out>, func=func at entry=0x7fffe8f33350, self=self at entry=0x7fffe8f284e8, args=args at entry=0x7fffffffba90, nargs=nargs at entry=1) at Objects/typeobject.c:1484
#6  0x0000000000483783 in call_maybe (obj=obj at entry=0x7fffe8f284e8, name=name at entry=0x8cf800 <op_id>, args=args at entry=0x7fffffffba90, nargs=nargs at entry=1) at Objects/typeobject.c:1534
#7  0x00000000004851d2 in slot_nb_add (self=0x7fffe8f284e8, other=0x7fffe8f28638) at Objects/typeobject.c:6167
#8  0x00000000005a47cc in binary_op1 (v=v at entry=0x7fffe8f284e8, w=w at entry=0x7fffe8f28638, op_slot=op_slot at entry=0) at Objects/abstract.c:804
#9  0x00000000005a5d2c in PyNumber_Add (v=0x7fffe8f284e8, w=0x7fffe8f28638) at Objects/abstract.c:954
#10 0x00007ffff61db5bb in PyUFunc_OO_O (args=<optimized out>, dimensions=<optimized out>, steps=<optimized out>, func=0x5a5d18 <PyNumber_Add>) at numpy/core/src/umath/loops.c.src:592
#11 0x00007ffff6332c24 in reduce_loop (iter=0x1295500, dataptrs=dataptrs at entry=0x12955e0, strides=strides at entry=0x12955d0, countptr=0x12955a8, iternext=iternext at entry=0x7ffff6971611 <npyiter_buffered_reduce_iternext_iters2>, needs_api=1, skip_first_count=<optimized out>, data=0x994fa0) at numpy/core/src/umath/ufunc_object.c:3263
#12 0x00007ffff61d00c5 in PyUFunc_ReduceWrapper (operand=operand at entry=0x7fffe8f16bc0, out=out at entry=0x0, wheremask=wheremask at entry=0x0, operand_dtype=<optimized out>, result_dtype=<optimized out>, casting=casting at entry=NPY_UNSAFE_CASTING, axis_flags=0x7fffffffbda0 "\001", reorderable=1, keepdims=0, subok=0, identity=0x8cb3c0 <_Py_NoneStruct>, loop=0x7ffff6332a23 <reduce_loop>, data=0x994fa0, buffersize=8192, funcname=0x7ffff6375457 "add", errormask=9) at numpy/core/src/umath/reduction.c:567
#13 0x00007ffff633a8a4 in PyUFunc_Reduce (ufunc=ufunc at entry=0x994fa0, arr=arr at entry=0x7fffe8f16bc0, out=0x0, naxes=naxes at entry=1, axes=axes at entry=0x7fffffffbe90, odtype=0x7ffff6c2c1a0 <OBJECT_Descr>, keepdims=0, initial=0x8cb3c0 <_Py_NoneStruct>) at numpy/core/src/umath/ufunc_object.c:3359
#14 0x00007ffff633c9fd in PyUFunc_GenericReduction (ufunc=ufunc at entry=0x994fa0, args=args at entry=0x7ffff6ec62f8, kwds=kwds at entry=0x0, operation=operation at entry=0) at numpy/core/src/umath/ufunc_object.c:4333
#15 0x00007ffff633cef7 in ufunc_reduce (ufunc=ufunc at entry=0x994fa0, args=args at entry=0x7ffff6ec62f8, kwds=kwds at entry=0x0) at numpy/core/src/umath/ufunc_object.c:5251
#16 0x00000000004315cd in _PyMethodDef_RawFastCallKeywords (method=0x7ffff65ba380 <ufunc_methods>, self=0x994fa0, args=args at entry=0x12953e0, nargs=nargs at entry=6, kwnames=<optimized out>) at Objects/call.c:690
#17 0x000000000043175a in _PyCFunction_FastCallKeywords (func=func at entry=0x7ffff5747980, args=args at entry=0x12953e0, nargs=nargs at entry=6, kwnames=kwnames at entry=0x0) at Objects/call.c:730
#18 0x00000000004eaccf in call_function (kwnames=0x0, oparg=6, pp_stack=<synthetic pointer>) at Python/ceval.c:4575
#19 _PyEval_EvalFrameDefault (f=0x1295230, throwflag=<optimized out>) at Python/ceval.c:3200
#20 0x00000000004dfd63 in PyEval_EvalFrameEx (f=f at entry=0x1295230, throwflag=throwflag at entry=0) at Python/ceval.c:536
#21 0x00000000004e07ab in _PyEval_EvalCodeWithName (_co=_co at entry=0x7ffff5755dc0, globals=globals at entry=0x7ffff5756d00, locals=locals at entry=0x0, args=args at entry=0x7fffe8f3d7c8, argcount=argcount at entry=2, kwnames=kwnames at entry=0x7fffe8f3d760, kwargs=0x7fffe8f3d768, kwcount=2, kwstep=2, defs=0x7ffff573dbf8, defcount=5, kwdefs=0x0, closure=0x0, name=0x7ffff5757c70, qualname=0x7ffff5757c70) at Python/ceval.c:3951
#22 0x0000000000430df7 in _PyFunction_FastCallDict (func=func at entry=0x7ffff57583c0, args=args at entry=0x7fffe8f3d7c8, nargs=2, kwargs=kwargs at entry=0x7fffeb60e7c0) at Objects/call.c:376
#23 0x00000000004335ca in PyObject_Call (callable=callable at entry=0x7ffff57583c0, args=args at entry=0x7fffe8f3d7a0, kwargs=kwargs at entry=0x7fffeb60e7c0) at Objects/call.c:226
#24 0x00007ffff695aff8 in forward_ndarray_method (self=self at entry=0x7fffe8f16bc0, args=args at entry=0x7ffff7e9f050, kwds=kwds at entry=0x7fffeb60e7c0, forwarding_callable=0x7ffff57583c0) at numpy/core/src/multiarray/methods.c:104
#25 0x00007ffff695b0ee in array_sum (self=self at entry=0x7fffe8f16bc0, args=args at entry=0x7ffff7e9f050, kwds=kwds at entry=0x7fffeb60e7c0) at numpy/core/src/multiarray/methods.c:1991
#26 0x00000000004315cd in _PyMethodDef_RawFastCallKeywords (method=0x7ffff6c3bb00 <array_methods+1792>, self=0x7fffe8f16bc0, args=args at entry=0x1294ad8, nargs=nargs at entry=1, kwnames=<optimized out>) at Objects/call.c:690
#27 0x000000000043175a in _PyCFunction_FastCallKeywords (func=func at entry=0x7fffe8f30910, args=args at entry=0x1294ad8, nargs=nargs at entry=1, kwnames=kwnames at entry=0x7fffed36e110) at Objects/call.c:730
#28 0x00000000004eb312 in call_function (kwnames=0x7fffed36e110, oparg=<optimized out>, pp_stack=<synthetic pointer>) at Python/ceval.c:4575
#29 _PyEval_EvalFrameDefault (f=0x1294910, throwflag=<optimized out>) at Python/ceval.c:3215
#30 0x00000000004dfd63 in PyEval_EvalFrameEx (f=f at entry=0x1294910, throwflag=throwflag at entry=0) at Python/ceval.c:536
#31 0x00000000004e07ab in _PyEval_EvalCodeWithName (_co=_co at entry=0x7fffed36c7c0, globals=globals at entry=0x7fffed3dae50, locals=locals at entry=0x0, args=args at entry=0x7ffff7fa4438, argcount=argcount at entry=1, kwnames=kwnames at entry=0x7fffe8f31100, kwargs=0x7fffe8f31108, kwcount=6, kwstep=2, defs=0x7fffed3742a8, defcount=3, kwdefs=0x0, closure=0x0, name=0x7ffff34a5248, qualname=0x7ffff34a5248) at Python/ceval.c:3951
#32 0x0000000000430df7 in _PyFunction_FastCallDict (func=func at entry=0x7fffed37a310, args=args at entry=0x7ffff7fa4438, nargs=1, kwargs=kwargs at entry=0x7fffe8f24f30) at Objects/call.c:376
#33 0x00000000004335ca in PyObject_Call (callable=0x7fffed37a310, args=0x7ffff7fa4410, kwargs=0x7fffe8f24f30) at Objects/call.c:226
#34 0x00000000004dee12 in do_call_core (func=func at entry=0x7fffed37a310, callargs=callargs at entry=0x7ffff7fa4410, kwdict=kwdict at entry=0x7fffe8f24f30) at Python/ceval.c:4652
#35 0x00000000004eba01 in _PyEval_EvalFrameDefault (f=0x12946b0, throwflag=<optimized out>) at Python/ceval.c:3267
#36 0x00000000004dfd63 in PyEval_EvalFrameEx (f=f at entry=0x12946b0, throwflag=throwflag at entry=0) at Python/ceval.c:536
#37 0x00000000004e07ab in _PyEval_EvalCodeWithName (_co=_co at entry=0x7fffed3657c0, globals=globals at entry=0x7fffed3dae50, locals=locals at entry=0x0, args=args at entry=0x7ffff6eb1f18, argcount=argcount at entry=1, kwnames=kwnames at entry=0x7fffe8f31078, kwargs=0x7fffe8f31080, kwcount=6, kwstep=2, defs=0x0, defcount=0, kwdefs=0x0, closure=0x7fffed378120, name=0x7ffff34a5248, qualname=0x7ffff34a5248) at Python/ceval.c:3951
#38 0x0000000000430df7 in _PyFunction_FastCallDict (func=func at entry=0x7fffed37a3c0, args=args at entry=0x7ffff6eb1f18, nargs=1, kwargs=kwargs at entry=0x7fffe9e5d750) at Objects/call.c:376
#39 0x00000000004335ca in PyObject_Call (callable=0x7fffed37a3c0, args=0x7ffff6eb1ef0, kwargs=0x7fffe9e5d750) at Objects/call.c:226
#40 0x00000000004dee12 in do_call_core (func=func at entry=0x7fffed37a3c0, callargs=callargs at entry=0x7ffff6eb1ef0, kwdict=kwdict at entry=0x7fffe9e5d750) at Python/ceval.c:4652
#41 0x00000000004eba01 in _PyEval_EvalFrameDefault (f=0x7fffe8f40850, throwflag=<optimized out>) at Python/ceval.c:3267
#42 0x00000000004dfd63 in PyEval_EvalFrameEx (f=f at entry=0x7fffe8f40850, throwflag=throwflag at entry=0) at Python/ceval.c:536
#43 0x00000000004e07ab in _PyEval_EvalCodeWithName (_co=0x7fffeb0df7c0, globals=<optimized out>, locals=locals at entry=0x0, args=args at entry=0x1293920, argcount=1, kwnames=0x0, kwargs=0x1293928, kwcount=0, kwstep=1, defs=0x0, defcount=0, kwdefs=0x0, closure=0x7fffe9f0b2a8, name=0x7ffff7f281e0, qualname=0x7fffeb153d40) at Python/ceval.c:3951
#44 0x00000000004310a8 in _PyFunction_FastCallKeywords (func=func at entry=0x7fffe8f32940, stack=stack at entry=0x1293920, nargs=nargs at entry=1, kwnames=kwnames at entry=0x0) at Objects/call.c:433
#45 0x00000000004eaf60 in call_function (kwnames=0x0, oparg=<optimized out>, pp_stack=<synthetic pointer>) at Python/ceval.c:4623
#46 _PyEval_EvalFrameDefault (f=0x12936f0, throwflag=<optimized out>) at Python/ceval.c:3200
#47 0x00000000004dfd63 in PyEval_EvalFrameEx (f=f at entry=0x12936f0, throwflag=throwflag at entry=0) at Python/ceval.c:536
#48 0x00000000004e07ab in _PyEval_EvalCodeWithName (_co=0x7fffeb0df880, globals=<optimized out>, locals=locals at entry=0x0, args=args at entry=0x1293410, argcount=3, kwnames=0x7fffec0834b0, kwargs=0x1293428, kwcount=4, kwstep=1, defs=0x7fffeb0deb40, defcount=4, kwdefs=0x0, closure=0x0, name=0x7fffed3b4da8, qualname=0x7fffeb0de400) at Python/ceval.c:3951
#49 0x00000000004310a8 in _PyFunction_FastCallKeywords (func=func at entry=0x7fffea4a5ec0, stack=stack at entry=0x1293410, nargs=nargs at entry=3, kwnames=kwnames at entry=0x7fffec083488) at Objects/call.c:433
#50 0x00000000004eb599 in call_function (kwnames=0x7fffec083488, oparg=<optimized out>, pp_stack=<synthetic pointer>) at Python/ceval.c:4623
#51 _PyEval_EvalFrameDefault (f=0x1293250, throwflag=<optimized out>) at Python/ceval.c:3215
#52 0x00000000004dfd63 in PyEval_EvalFrameEx (f=f at entry=0x1293250, throwflag=throwflag at entry=0) at Python/ceval.c:536
#53 0x00000000004e07ab in _PyEval_EvalCodeWithName (_co=_co at entry=0x7fffec07ec40, globals=globals at entry=0x7fffec541a60, locals=locals at entry=0x0, args=args at entry=0x7fffffffd0d0, argcount=argcount at entry=1, kwnames=kwnames at entry=0x0, kwargs=0x0, kwcount=0, kwstep=2, defs=0x7fffec0812f8, defcount=5, kwdefs=0x0, closure=0x7fffeb101738, name=0x7ffff7f83588, qualname=0x7fffea4a44a0) at Python/ceval.c:3951
#54 0x0000000000430df7 in _PyFunction_FastCallDict (func=func at entry=0x7fffea4a6f70, args=args at entry=0x7fffffffd0d0, nargs=nargs at entry=1, kwargs=kwargs at entry=0x7fffe8f308a0) at Objects/call.c:376
#55 0x00000000004322d9 in _PyObject_FastCallDict (callable=callable at entry=0x7fffea4a6f70, args=args at entry=0x7fffffffd0d0, nargs=nargs at entry=1, kwargs=kwargs at entry=0x7fffe8f308a0) at Objects/call.c:98
#56 0x00000000004325ee in _PyObject_Call_Prepend (callable=0x7fffea4a6f70, obj=0x7ffff7e52890, args=0x7ffff7fa5050, kwargs=0x7fffe8f308a0) at Objects/call.c:904
#57 0x00000000005b7bd4 in method_call (method=<optimized out>, args=<optimized out>, kwargs=<optimized out>) at Objects/classobject.c:306
#58 0x000000000043364b in PyObject_Call (callable=0x7ffff7ed4d50, args=0x7ffff7fa5050, kwargs=0x7fffe8f308a0) at Objects/call.c:245
#59 0x00000000004dee12 in do_call_core (func=func at entry=0x7ffff7ed4d50, callargs=callargs at entry=0x7ffff7fa5050, kwdict=kwdict at entry=0x7fffe8f308a0) at Python/ceval.c:4652
#60 0x00000000004eba01 in _PyEval_EvalFrameDefault (f=0x7fffe8f3e248, throwflag=<optimized out>) at Python/ceval.c:3267
#61 0x00000000004dfd63 in PyEval_EvalFrameEx (f=f at entry=0x7fffe8f3e248, throwflag=throwflag at entry=0) at Python/ceval.c:536
#62 0x00000000004e07ab in _PyEval_EvalCodeWithName (_co=_co at entry=0x7fffed3d0400, globals=globals at entry=0x7fffed3c2750, locals=locals at entry=0x0, args=args at entry=0x7fffffffd490, argcount=argcount at entry=2, kwnames=kwnames at entry=0x0, kwargs=0x0, kwcount=0, kwstep=2, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name=0x7fffed3c4dc0, qualname=0x7fffed3c3790) at Python/ceval.c:3951
#63 0x0000000000430df7 in _PyFunction_FastCallDict (func=func at entry=0x7fffed3883c0, args=args at entry=0x7fffffffd490, nargs=nargs at entry=2, kwargs=kwargs at entry=0x7fffee1bdfa0) at Objects/call.c:376
#64 0x00000000004322d9 in _PyObject_FastCallDict (callable=callable at entry=0x7fffed3883c0, args=args at entry=0x7fffffffd490, nargs=nargs at entry=2, kwargs=kwargs at entry=0x7fffee1bdfa0) at Objects/call.c:98
#65 0x00000000004325ee in _PyObject_Call_Prepend (callable=0x7fffed3883c0, obj=0x7ffff7e52890, args=0x7ffff6ece0b0, kwargs=0x7fffee1bdfa0) at Objects/call.c:904
#66 0x00000000005b7bd4 in method_call (method=<optimized out>, args=<optimized out>, kwargs=<optimized out>) at Objects/classobject.c:306
#67 0x000000000043364b in PyObject_Call (callable=0x7ffff7e30258, args=0x7ffff6ece0b0, kwargs=0x7fffee1bdfa0) at Objects/call.c:245
#68 0x00000000004dee12 in do_call_core (func=func at entry=0x7ffff7e30258, callargs=callargs at entry=0x7ffff6ece0b0, kwdict=kwdict at entry=0x7fffee1bdfa0) at Python/ceval.c:4652
#69 0x00000000004eba01 in _PyEval_EvalFrameDefault (f=0x1292d00, throwflag=<optimized out>) at Python/ceval.c:3267
#70 0x00000000004dfd63 in PyEval_EvalFrameEx (f=f at entry=0x1292d00, throwflag=throwflag at entry=0) at Python/ceval.c:536
#71 0x00000000004e07ab in _PyEval_EvalCodeWithName (_co=_co at entry=0x7fffed3d0e80, globals=globals at entry=0x7fffed3c2750, locals=locals at entry=0x0, args=args at entry=0x7fffffffd850, argcount=argcount at entry=2, kwnames=kwnames at entry=0x0, kwargs=0x0, kwcount=0, kwstep=2, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name=0x7fffed3cff90, qualname=0x7fffed3d61c0) at Python/ceval.c:3951
#72 0x0000000000430df7 in _PyFunction_FastCallDict (func=func at entry=0x7fffed388470, args=args at entry=0x7fffffffd850, nargs=nargs at entry=2, kwargs=kwargs at entry=0x7fffe8f30830) at Objects/call.c:376
#73 0x00000000004322d9 in _PyObject_FastCallDict (callable=callable at entry=0x7fffed388470, args=args at entry=0x7fffffffd850, nargs=nargs at entry=2, kwargs=kwargs at entry=0x7fffe8f30830) at Objects/call.c:98
#74 0x00000000004325ee in _PyObject_Call_Prepend (callable=0x7fffed388470, obj=0x7ffff7e52890, args=0x7ffff7e52ef0, kwargs=0x7fffe8f30830) at Objects/call.c:904
#75 0x00000000005b7bd4 in method_call (method=<optimized out>, args=<optimized out>, kwargs=<optimized out>) at Objects/classobject.c:306
#76 0x000000000043364b in PyObject_Call (callable=0x7ffff7f532c0, args=0x7ffff7e52ef0, kwargs=0x7fffe8f30830) at Objects/call.c:245
#77 0x00000000004dee12 in do_call_core (func=func at entry=0x7ffff7f532c0, callargs=callargs at entry=0x7ffff7e52ef0, kwdict=kwdict at entry=0x7fffe8f30830) at Python/ceval.c:4652
#78 0x00000000004eba01 in _PyEval_EvalFrameDefault (f=0x1292ad0, throwflag=<optimized out>) at Python/ceval.c:3267
#79 0x00000000004dfd63 in PyEval_EvalFrameEx (f=f at entry=0x1292ad0, throwflag=throwflag at entry=0) at Python/ceval.c:536
#80 0x00000000004e07ab in _PyEval_EvalCodeWithName (_co=_co at entry=0x7fffeb159880, globals=globals at entry=0x7fffec541f30, locals=locals at entry=0x0, args=args at entry=0x7fffffffdc10, argcount=argcount at entry=2, kwnames=kwnames at entry=0x7ffff6ed4690, kwargs=0x7ffff6ed4698, kwcount=2, kwstep=2, defs=0x7fffeb0e60d8, defcount=1, kwdefs=0x0, closure=0x7fffeb0f0890, name=0x7fffed3cff90, qualname=0x7fffeb157b80) at Python/ceval.c:3951
#81 0x0000000000430df7 in _PyFunction_FastCallDict (func=func at entry=0x7fffea4a5520, args=args at entry=0x7fffffffdc10, nargs=nargs at entry=2, kwargs=kwargs at entry=0x7ffff6ed26e0) at Objects/call.c:376
#82 0x00000000004322d9 in _PyObject_FastCallDict (callable=callable at entry=0x7fffea4a5520, args=args at entry=0x7fffffffdc10, nargs=nargs at entry=2, kwargs=kwargs at entry=0x7ffff6ed26e0) at Objects/call.c:98
#83 0x00000000004325ee in _PyObject_Call_Prepend (callable=0x7fffea4a5520, obj=0x7ffff7e52890, args=0x7ffff7e97fb0, kwargs=0x7ffff6ed26e0) at Objects/call.c:904
#84 0x00000000005b7bd4 in method_call (method=<optimized out>, args=<optimized out>, kwargs=<optimized out>) at Objects/classobject.c:306
#85 0x000000000043364b in PyObject_Call (callable=0x7ffff7f3fce8, args=0x7ffff7e97fb0, kwargs=0x7ffff6ed26e0) at Objects/call.c:245
#86 0x00000000004dee12 in do_call_core (func=func at entry=0x7ffff7f3fce8, callargs=callargs at entry=0x7ffff7e97fb0, kwdict=kwdict at entry=0x7ffff6ed26e0) at Python/ceval.c:4652
#87 0x00000000004eba01 in _PyEval_EvalFrameDefault (f=0x1292880, throwflag=<optimized out>) at Python/ceval.c:3267
#88 0x00000000004dfd63 in PyEval_EvalFrameEx (f=f at entry=0x1292880, throwflag=throwflag at entry=0) at Python/ceval.c:536
#89 0x00000000004e07ab in _PyEval_EvalCodeWithName (_co=0x7fffeb1597c0, globals=<optimized out>, locals=locals at entry=0x0, args=args at entry=0x9a7c90, argcount=2, kwnames=0x0, kwargs=0x9a7ca0, kwcount=0, kwstep=1, defs=0x7fffeb0e6078, defcount=1, kwdefs=0x0, closure=0x0, name=0x7fffed3cf510, qualname=0x7fffeb157a90) at Python/ceval.c:3951
#90 0x00000000004310a8 in _PyFunction_FastCallKeywords (func=func at entry=0x7fffea4a5470, stack=stack at entry=0x9a7c90, nargs=nargs at entry=2, kwnames=kwnames at entry=0x0) at Objects/call.c:433
#91 0x00000000004ea4f5 in call_function (kwnames=0x0, oparg=<optimized out>, pp_stack=<synthetic pointer>) at Python/ceval.c:4623
#92 _PyEval_EvalFrameDefault (f=0x9a7b10, throwflag=<optimized out>) at Python/ceval.c:3169
#93 0x00000000004dfd63 in PyEval_EvalFrameEx (f=f at entry=0x9a7b10, throwflag=throwflag at entry=0) at Python/ceval.c:536
#94 0x00000000004e07ab in _PyEval_EvalCodeWithName (_co=0x7ffff7e9a640, globals=<optimized out>, locals=<optimized out>, args=<optimized out>, argcount=argcount at entry=0, kwnames=0x0, kwargs=0x0, kwcount=0, kwstep=2, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name=0x0, qualname=0x0) at Python/ceval.c:3951
#95 0x00000000004e09a4 in PyEval_EvalCodeEx (_co=_co at entry=0x7ffff7e9a640, globals=globals at entry=0x7ffff7eb3fa0, locals=locals at entry=0x7ffff7eb3fa0, args=args at entry=0x0, argcount=argcount at entry=0, kws=kws at entry=0x0, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:3980
#96 0x00000000004e09cd in PyEval_EvalCode (co=co at entry=0x7ffff7e9a640, globals=globals at entry=0x7ffff7eb3fa0, locals=locals at entry=0x7ffff7eb3fa0) at Python/ceval.c:513
#97 0x0000000000521840 in run_mod (mod=mod at entry=0x9bc540, filename=filename at entry=0x7ffff6ed4110, globals=globals at entry=0x7ffff7eb3fa0, locals=locals at entry=0x7ffff7eb3fa0, flags=flags at entry=0x7fffffffe360, arena=arena at entry=0x7ffff7e88040) at Python/pythonrun.c:1031
#98 0x000000000052448a in PyRun_FileExFlags (fp=fp at entry=0x9ba2e0, filename_str=filename_str at entry=0x7ffff7e983e0 "foo.py", start=start at entry=257, globals=globals at entry=0x7ffff7eb3fa0, locals=locals at entry=0x7ffff7eb3fa0, closeit=closeit at entry=1, flags=0x7fffffffe360) at Python/pythonrun.c:984
#99 0x000000000052481f in PyRun_SimpleFileExFlags (fp=fp at entry=0x9ba2e0, filename=<optimized out>, filename at entry=0x7ffff7e983e0 "foo.py", closeit=closeit at entry=1, flags=flags at entry=0x7fffffffe360) at Python/pythonrun.c:425
#100 0x00000000005249db in PyRun_AnyFileExFlags (fp=fp at entry=0x9ba2e0, filename=0x7ffff7e983e0 "foo.py", closeit=closeit at entry=1, flags=flags at entry=0x7fffffffe360) at Python/pythonrun.c:84
#101 0x0000000000420c3b in pymain_run_file (pymain=pymain at entry=0x7fffffffe3c0, config=config at entry=0x9483a8, cf=cf at entry=0x7fffffffe360) at Modules/main.c:1159
#102 0x0000000000421146 in pymain_run_python (pymain=pymain at entry=0x7fffffffe3c0, interp=0x948320) at Modules/main.c:1607
#103 0x0000000000422da0 in pymain_main (pymain=pymain at entry=0x7fffffffe3c0) at Modules/main.c:1755
#104 0x0000000000422e74 in _Py_UnixMain (argc=<optimized out>, argv=<optimized out>) at Modules/main.c:1792
#105 0x000000000041f96f in main (argc=<optimized out>, argv=<optimized out>) at ./Programs/python.c:15



Thanks

----------
components: Interpreter Core
messages: 325392
nosy: xtreak
priority: normal
severity: normal
status: open
title: Segfault in pandas that works fine on 3.7
type: crash
versions: Python 3.8

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

From report at bugs.python.org  Fri Sep 14 16:11:33 2018
From: report at bugs.python.org (Erwan Le Pape)
Date: Fri, 14 Sep 2018 20:11:33 +0000
Subject: [New-bugs-announce] [issue34689] Lib/sysconfig.py expands
 non-variables
Message-ID: <1536955893.22.0.956365154283.issue34689@psf.upfronthosting.co.za>


New submission from Erwan Le Pape <lepaperwan3 at gmail.com>:

Lib/sysconfig.py _parse_makefile needs to expand Makefile-style variables which includes `$()` `${}` variables with a litteral `$` being `$$`.

That last particular point is properly accounted for in the first half of the function when determining values that need expansion and those that don't. However, the second half that actually performs variable expansion doesn't.

Sample breaking input:
VAR1=  VALUE1
VAR2=  VALUE2
VAR3=$${VAR1} ${VAR2}

Output:
Expect: {'VAR1': 'VALUE1', 'VAR2': 'VALUE2', 'VAR3': '$${VAR1} VALUE2'}
Actual: {'VAR1': 'VALUE1', 'VAR2': 'VALUE2', 'VAR3': '$VALUE1 VALUE2'}

I'm working on patching this but I'm putting this here as feedback is welcome.

As far as I could tell, this is a side effect of b2b1217, which patched #24705.

----------
components: Library (Lib)
messages: 325393
nosy: lepaperwan
priority: normal
severity: normal
status: open
title: Lib/sysconfig.py expands non-variables
type: behavior
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/issue34689>
_______________________________________

From report at bugs.python.org  Fri Sep 14 17:23:50 2018
From: report at bugs.python.org (Larry Hastings)
Date: Fri, 14 Sep 2018 21:23:50 +0000
Subject: [New-bugs-announce] [issue34690] Store startup modules as C
 structures for 20%+ startup speed improvement
Message-ID: <1536960230.65.0.956365154283.issue34690@psf.upfronthosting.co.za>


New submission from Larry Hastings <larry at hastings.org>:

This patch was sent to me privately by Jeethu Rao at Facebook.  It's a change they're working with internally to improve startup time.  What I've been told by Carl Shapiro at Facebook is that we have their blessing to post it publicly / merge it / build upon it for CPython.  Their patch was written for 3.6, I have massaged it to the point where it minimally works with 3.8.

What the patch does: it takes all the Python modules that are loaded as part of interpreter startup and deserializes the marshalled .pyc file into precreated objects stored as static C data.  You add this .C file to the Python build.  Then there's a patch to Python itself (about 250 lines iirc) that teaches it to load modules from these data structures.

I wrote a quick dumb test harness to compare this patch vs 3.8 stock.  It runs a command line 500 times and uses time.perf_counter to time the process.  On a fast quiescent laptop I observe a 21-22% improvement:

cmdline: ['./python', '-c', 'pass']
500 runs:

sm38
  average time 0.006302303705982922
          best 0.006055746000129147
         worst 0.00816565500008437

clean38
  average time 0.007969956444008858
          best 0.007829047999621253
         worst 0.008812210000542109

improvement 0.20924239043734505 %

cmdline: ['./python', '-c', 'import io']
500 runs:

sm38
  average time 0.006297688038004708
          best 0.005980765999993309
         worst 0.0072462130010535475

clean38
  average time 0.007996319670004595
          best 0.0078091849991324125
         worst 0.009175700999549008

improvement 0.21242667903482038 %


The downside of the patch: for these modules it ignores the Python files on disk--it doesn't even stat them.  If you add stat calls you lose half of the speed improvement.  I believe they added a work-around, where you can set a flag (command-line? environment variable? I don't know, I didn't go looking for it) that tells Python "don't use the frozen modules" and it loads all those files from disk.


I don't propose to merge the patch in its current state.  I think it would need a lot of work both in terms of "doing things the way Python does it" as well as just code smell (the serializer is implemented in both C and Python and jumps back and forth, also the build process for the serialized modules is pretty tiresome).

Is it worth working on?

----------
assignee: larry
components: Interpreter Core
messages: 325401
nosy: larry
priority: normal
severity: normal
stage: needs patch
status: open
title: Store startup modules as C structures for 20%+ startup speed improvement
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Fri Sep 14 23:03:02 2018
From: report at bugs.python.org (Tim Peters)
Date: Sat, 15 Sep 2018 03:03:02 +0000
Subject: [New-bugs-announce] [issue34691] _contextvars missing in x64 master
 branch Windows build?
Message-ID: <1536980580.92.0.956365154283.issue34691@psf.upfronthosting.co.za>


New submission from Tim Peters <tim at python.org>:

Using Visual Studio 2017 to build the current master branch of Python (something I'm trying for the first time in about two years - maybe I'm missing something obvious!), with the x64 target, under both the Release and Debug builds I get a Python that can't even start to run the test suite.  Here's output from the Release build - the Debug build output is nearly identical.  The problem does not appear with the Win32 target.  Of course I'm doing this on a 64-bit box (under Win 10 Pro):

C:\Code\Python\PCbuild>rt -q -x64

C:\Code\Python\PCbuild>"C:\Code\Python\PCbuild\amd64\python.exe"  -u -Wd -E -bb -m test
Traceback (most recent call last):
  File "C:\Code\Python\lib\runpy.py", line 193, in _run_module_as_main
    "__main__", mod_spec)
  File "C:\Code\Python\lib\runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "C:\Code\Python\lib\test\__main__.py", line 1, in <module>
    from test.libregrtest import main
  File "C:\Code\Python\lib\test\libregrtest\__init__.py", line 4, in <module>
    from test.libregrtest.cmdline import _parse_args, RESOURCE_NAMES, ALL_RESOURCES
  File "C:\Code\Python\lib\test\libregrtest\cmdline.py", line 4, in <module>
    from test import support
  File "C:\Code\Python\lib\test\support\__init__.py", line 6, in <module>
    import asyncio.events
  File "C:\Code\Python\lib\asyncio\__init__.py", line 8, in <module>
    from .base_events import *
  File "C:\Code\Python\lib\asyncio\base_events.py", line 39, in <module>
    from . import events
  File "C:\Code\Python\lib\asyncio\events.py", line 14, in <module>
    import contextvars
  File "C:\Code\Python\lib\contextvars.py", line 1, in <module>
    from _contextvars import Context, ContextVar, Token, copy_context
ModuleNotFoundError: No module named '_contextvars'


_contextvarsmodule.c is in the list of Modules under the pythoncore project, and it appears to compile without incident when the Solution is built.

The executable appears to be fine in other respects I checked; e.g.,

C:\Code\Python\PCbuild>amd64\python.exe
Python 3.8.0a0 (heads/master:24f6846920, Sep 14 2018, 18:55:33) [MSC v.1915 64 bit (AMD64)] on win32

Type "help", "copyright", "credits" or "license" for more information.
>>> import math
>>> from collections import Counter
>>> Counter("abab")
Counter({'a': 2, 'b': 2})
>>> import _contextvars
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ModuleNotFoundError: No module named '_contextvars'

Clue?

----------
components: Build, Library (Lib), Windows
messages: 325419
nosy: paul.moore, steve.dower, tim.golden, tim.peters, zach.ware
priority: normal
severity: normal
status: open
title: _contextvars missing in x64 master branch Windows build?
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Sat Sep 15 03:40:31 2018
From: report at bugs.python.org (arul)
Date: Sat, 15 Sep 2018 07:40:31 +0000
Subject: [New-bugs-announce] [issue34692] ok
Message-ID: <1536997231.82.0.9629360145.issue34692@psf.upfronthosting.co.za>


Change by arul <iamarulraj at gmail.com>:


----------
nosy: arulpython
priority: normal
severity: normal
status: open
title: ok

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

From report at bugs.python.org  Sat Sep 15 10:01:11 2018
From: report at bugs.python.org (John Joyce)
Date: Sat, 15 Sep 2018 14:01:11 +0000
Subject: [New-bugs-announce] [issue34693] PEPping distutils/core.py
Message-ID: <1537020071.95.0.956365154283.issue34693@psf.upfronthosting.co.za>


New submission from John Joyce <dangerwillrobinsondanger at gmail.com>:

In distutils/core.py ...

Line 227 is over-indented, inconsistent with the rest of the file.
Line 226 is over-indented, inconsistent with the rest of the file.

Line 114 is over-indented by 2 characters, inconsistent with the rest of the file.
        else:
            raise SystemExit("error in %s setup command: %s" % \
                  (attrs['name'], msg))


Line 113 backslash should not be needed to continue the line between brackets.

Line 102 there is an extra space before the "not" keyword.
    if 'script_args'  not in attrs:


Line 57 could use 1 more blank line above it.

Line 33 'script' is assigned but not used.

Line 32 could use 1 more blank line above it.


run_setup and setup had space before (

----------
components: Distutils
messages: 325433
nosy: dangerwillrobinsondanger, dstufft, eric.araujo
priority: normal
pull_requests: 8752
severity: normal
status: open
title: PEPping distutils/core.py
type: compile error
versions: Python 3.8

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

From report at bugs.python.org  Sat Sep 15 10:50:44 2018
From: report at bugs.python.org (Jose Angel Acosta)
Date: Sat, 15 Sep 2018 14:50:44 +0000
Subject: [New-bugs-announce] [issue34694] Dismiss To Avoid Slave/Master
 wording cause it easier for non English spoken programmers
Message-ID: <1537023044.18.0.956365154283.issue34694@psf.upfronthosting.co.za>


New submission from Jose Angel Acosta <acostaja at gmail.com>:

A request have been srecentrly uddenly committed to avoid Slave/Master wording in python code, I think the "issue"was not enough peer-reviewed, me having slave roots from my african and jewish heritage I dont consider this matter an Issue, but the Wording Slave/Master widely used to depict component relationship is better for understanding the purpose of the component relation than the non-traditional wording schemes as Parent/Worker, specially for those being non-native English readers the change has issues on code readability specially for non-English readers.

Simple, its much easier to understand the meaning of Slave/Master relationship in device functionality than Worker/Helper, I consider the whole issue as an intrusion of the "politically correct" puritanism in areas where is not required.

The main force behind Python success is CODE READABILITY, not  political rightfulness, this should be stopped here,Python itself the language name its an word which remembers snakes a creature considered impure by both Jew/Islamic/Christian religions, by appling the same political rightfulness code to this, Python language should be renamed to something non-offensive to Jew/Islamic/Christians as Bunny, (and this at least doesnt affect language readbility, since "run bunny code" vs "run python code" its easier to understand than "Process Master delegate X Data to Slave process" vs "Parent process Delegate X Data to Worker Process", the later meaning is not as easy to understand, since Parent can be translated in N ways across different languages, I.E. Spanish: Parent could means mother, father, cause while Worker just means Worker (not intrinsically related to cause or mother).

I think the python language should be kept from explicitly offensive wordings not those "niche" offensive wordings when the whole language is named after an animal that is offensive on most cultures (And its not a problem), the same naming process slave/master doesn't denote support to slavery, are just words that its more easy to understand its meaning (given its more uniform) across multiple human languages.

I consider the voting mechanism should consider polls among programmers before commit matters like this in the future, which respectfully I consider ridiculous and I said it with respect to my slave ancestors.

----------
assignee: docs at python
components: 2to3 (2.x to 3.x conversion tool), Argument Clinic, Build, Cross-Build, Demos and Tools, Distutils, Documentation, Extension Modules, FreeBSD, IDLE, IO, Installation, Interpreter Core, Library (Lib), Regular Expressions, SSL, Tests, Tkinter, Unicode, Windows, XML, asyncio, ctypes, email, macOS
messages: 325434
nosy: AcostaJA, Alex.Willmer, asvetlov, barry, docs at python, dstufft, eric.araujo, ezio.melotti, koobs, larry, mrabarnett, ned.deily, paul.moore, r.david.murray, ronaldoussoren, steve.dower, terry.reedy, tim.golden, vstinner, yselivanov, zach.ware
priority: normal
severity: normal
status: open
title: Dismiss To Avoid Slave/Master wording cause it easier for non English spoken programmers
type: enhancement

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

From report at bugs.python.org  Sat Sep 15 11:52:33 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Sat, 15 Sep 2018 15:52:33 +0000
Subject: [New-bugs-announce] [issue34695] sqlite3: Cache.get() crashes if
 Cache.__init__() was not called
Message-ID: <1537026753.58.0.956365154283.issue34695@psf.upfronthosting.co.za>


New submission from Alexey Izbyshev <izbyshev at ispras.ru>:

sqlite3.Cache allows users to create uninitialized instances because it relies on __init__() instead of __new__() for initialization, which can be skipped. Cache.get() crashes if called on an uninitialized instance:

>>> from sqlite3 import Cache
>>> Cache.__new__(Cache, None).get(42)
Segmentation fault (core dumped)

I see the following ways to fix this:

1) Explicitly check that the instance is initialized in Cache methods (this is what sqlite3 does for Connection and Cursor).

2) Move initialization from __init__() to __new__(). The latter can't be skipped due to Python safety checks. The issue here is that pysqlite_cache_init() is declared in Modules/_sqlite/cache.h, and while it's not directly called anywhere in Python sources, removing or changing it might be considered a change in public API.

3) Remove Cache from sqlite3 module dictionary. It's not clear to me why it's there because it's only used internally by Connection, is not documented, and there is no API to supply user-created Cache instances to sqlite3. Also, there are no tests for Cache.

I'll submit a PR implementing the first (most backwards-compatible) fix, but will be happy if (2), (3) or any other more reliable fixes can be considered.

----------
components: Extension Modules
messages: 325440
nosy: berker.peksag, ghaering, izbyshev, serhiy.storchaka
priority: normal
severity: normal
status: open
title: sqlite3: Cache.get() crashes if Cache.__init__() was not called
type: crash
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Sat Sep 15 12:24:14 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Sat, 15 Sep 2018 16:24:14 +0000
Subject: [New-bugs-announce] [issue34696] PyByteArray_FromObject() has
 undocumented (and untested) behavior
Message-ID: <1537028654.15.0.956365154283.issue34696@psf.upfronthosting.co.za>


New submission from Zackery Spytz <zspytz at gmail.com>:

The documentation states that PyByteArray_FromObject() creates a bytearray object from an object that implements the buffer protocol, but PyByteArray_FromObject() simply calls the bytearray constructor with its argument (the buffer protocol part is not enforced).

This was mentioned in #26759. Either the documentation or the behavior should be changed.

----------
messages: 325444
nosy: ZackerySpytz
priority: normal
severity: normal
status: open
title: PyByteArray_FromObject() has undocumented (and untested) behavior
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Sat Sep 15 13:13:13 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Sat, 15 Sep 2018 17:13:13 +0000
Subject: [New-bugs-announce] [issue34697] ctypes: Crash if manually-created
 CField instance is used
Message-ID: <1537031593.26.0.956365154283.issue34697@psf.upfronthosting.co.za>


New submission from Alexey Izbyshev <izbyshev at ispras.ru>:

It is possible to manually create an instance of private CField type which is used by ctypes to represent fields of Structure and Union types. This instance will be uninitialized because it's normally initialized when instances of Structure/Union are created, so calling its methods may crash the interpreter:

from ctypes import *

class S(Structure):
    _fields_ = [('x', c_int)]

CField = type(S.x)
f = CField()
repr(f) # Crash here

Is this issue worth fixing?

If so, is the correct way to set tp_new slot to NULL and fix the internal callers so that users wouldn't be able to create CField instances?

----------
components: ctypes
messages: 325448
nosy: amaury.forgeotdarc, belopolsky, berker.peksag, izbyshev, meador.inge, serhiy.storchaka
priority: normal
severity: normal
status: open
title: ctypes: Crash if manually-created CField instance is used
type: crash
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Sat Sep 15 13:17:31 2018
From: report at bugs.python.org (Tim Burke)
Date: Sat, 15 Sep 2018 17:17:31 +0000
Subject: [New-bugs-announce] [issue34698] urllib.request.Request.set_proxy
 doesn't (necessarily) replace type
Message-ID: <1537031851.88.0.956365154283.issue34698@psf.upfronthosting.co.za>


New submission from Tim Burke <tim.burke at gmail.com>:

Not sure if this is a documentation or behavior bug, but... the docs for urllib.request.Request.set_proxy (https://docs.python.org/3/library/urllib.request.html#urllib.request.Request.set_proxy) say

> Prepare the request by connecting to a proxy server. *The host and type will replace those of the instance*, and the instance?s selector will be the original URL given in the constructor.

(Emphasis mine.) In practice, behavior is more nuanced than that:

>>> from urllib.request import Request
>>> req = Request('http://hostame:port/some/path')
>>> req.host, req.type
('hostame:port', 'http')
>>> req.set_proxy('proxy:other-port', 'https')
>>> req.host, req.type # So far, so good...
('proxy:other-port', 'https')
>>>
>>> req = Request('https://hostame:port/some/path')
>>> req.host, req.type
('hostame:port', 'https')
>>> req.set_proxy('proxy:other-port', 'http')
>>> req.host, req.type # Type doesn't change!
('proxy:other-port', 'https')

Looking at the source (https://github.com/python/cpython/blob/v3.7.0/Lib/urllib/request.py#L397) it's obvious why https is treated specially.

The behavior is consistent with how things worked on py2...

>>> from urllib2 import Request
>>> req = Request('http://hostame:port/some/path')
>>> req.get_host(), req.get_type()
('hostame:port', 'http')
>>> req.set_proxy('proxy:other-port', 'https')
>>> req.get_host(), req.get_type()
('proxy:other-port', 'https')
>>>
>>> req = Request('https://hostame:port/some/path')
>>> req.get_host(), req.get_type()
('hostame:port', 'https')
>>> req.set_proxy('proxy:other-port', 'http')
>>> req.get_host(), req.get_type()
('proxy:other-port', 'https')


... but only if you're actually inspecting host/type along the way!

>>> from urllib2 import Request
>>> req = Request('https://hostame:port/some/path')
>>> req.set_proxy('proxy:other-port', 'http')
>>> req.get_host(), req.get_type()
('proxy:other-port', 'http')

(FWIW, this came up while porting an application from py2 to py3; there was a unit test expecting that last behavior of proxying a https connection through a http proxy.)

----------
components: Library (Lib)
messages: 325449
nosy: tburke
priority: normal
severity: normal
status: open
title: urllib.request.Request.set_proxy doesn't (necessarily) replace type

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

From report at bugs.python.org  Sat Sep 15 15:20:16 2018
From: report at bugs.python.org (Guo Ci Teo)
Date: Sat, 15 Sep 2018 19:20:16 +0000
Subject: [New-bugs-announce] [issue34699] allows path-like objects in
 program arguments in Windows
Message-ID: <1537039216.54.0.956365154283.issue34699@psf.upfronthosting.co.za>


New submission from Guo Ci Teo <zguoci at gmail.com>:

Currently, the `subprocess.Popen` function allows for path-like objects in the argument list for POSIX but not in Windows.
This PR makes Windows' `subprocess.Popen` accept path-like objects in the argument list.

----------
components: Library (Lib)
messages: 325454
nosy: guoci
priority: normal
severity: normal
status: open
title: allows path-like objects in program arguments in Windows
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Sat Sep 15 16:10:00 2018
From: report at bugs.python.org (Ben Darnell)
Date: Sat, 15 Sep 2018 20:10:00 +0000
Subject: [New-bugs-announce] [issue34700] typing.get_type_hints doesn't know
 about typeshed
Message-ID: <1537042200.54.0.956365154283.issue34700@psf.upfronthosting.co.za>


New submission from Ben Darnell <ben.darnell at gmail.com>:

Currently, most type annotations for the standard library are provided in typeshed rather than in the library itself. Not all consumers of type annotations are aware of typeshed, and this can cause problems. Specifically, Sphinx 1.8 accesses type hints via `typing.get_type_hints()`, which fails for some hints which are (implicitly) relying on typeshed. This currently manifests as failures to build Tornado's docs with Sphinx 1.8 (Tornado is using inline type annotations).

Concretely, the issue involves the `concurrent.futures.Future` class. In typeshed, this class is a `Generic[T]`, but in the standard library it's just a normal class. Consider a function that returns a parameterized Future type:

    from concurrent.futures import Future

    def do_something_background() -> 'Future[int]':
        return executor.submit(do_something)

Note that the type annotation is already a string. We can't use `Future[int]` directly because at runtime, the real Future type is not subscriptable. The string defers resolution of the subscript until something tries to access the annotation *as a type hint*. When mypy does this, it uses the typeshed definition of Future, so everything passes. But when Sphinx calls `typing.get_type_hints()` on this function, it fails:

```
>>> typing.get_type_hints(do_something_background)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/typing.py", line 1543, in get_type_hints
    value = _eval_type(value, globalns, localns)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/typing.py", line 350, in _eval_type
    return t._eval_type(globalns, localns)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/typing.py", line 245, in _eval_type
    eval(self.__forward_code__, globalns, localns),
  File "<string>", line 1, in <module>
TypeError: 'type' object is not subscriptable
```


What can be done about this? I see a few approaches:

1. Require that any use of type hints consults typeshed. This would entail either making typing.get_type_hints aware of typeshed or deprecating and removing it.

2. Disallow references to typeshed from inline type annotations; types that require typeshed must only appear in `.pyi` stubs, which will only be interpreted by tools like mypy that know about typeshed. (is this true, or are there tools that know about pyi files but not typeshed?)

3. Annotate types in the standard library as generic. So far, this problem has always taken the form of "type is not subscriptable", and it could be resolved by making all generic types in the stdlib subclasses of `typing.Generic[T]`. This would bring enough typing detail into the stdlib to allow the annotations to be parsed without typeshed. This would also avoid the need for the awkward quotes in the example above.

----------
messages: 325455
nosy: Ben.Darnell
priority: normal
severity: normal
status: open
title: typing.get_type_hints doesn't know about typeshed
type: enhancement
versions: Python 3.7

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

From report at bugs.python.org  Sat Sep 15 23:54:15 2018
From: report at bugs.python.org (Azaria Zornberg)
Date: Sun, 16 Sep 2018 03:54:15 +0000
Subject: [New-bugs-announce] [issue34701] Asyncio documentation for
 recursive coroutines is lacking
Message-ID: <1537070055.79.0.956365154283.issue34701@psf.upfronthosting.co.za>


New submission from Azaria Zornberg <a.zornberg96 at gmail.com>:

When an asynchronous coroutine in asyncio awaits or yields from itself, any call to the function is executed somewhat synchronously.

Once the recursive coroutine begins, if it never awaits any other coroutines besides itself, nothing else will be scheduled to run until it has completely finished recursively calling itself and returning.
However, if it ever awaits a different coroutine (even something as small as asyncio.sleep(0)) then other coroutines will be scheduled to run.

It seems, from other documentation, that this is intentional. Other documentation sort of dances around the specifics of how coroutines work with recursion, and only examples of coroutines yielding from each other recursively are provided.

However, this behavior is never explicitly called out. This is confusing for people who write a recursive asyncio coroutine and are perplexed by why it seems to execute synchronously, assuming they ever notice.

I've attached a short script that can be run to exhibit the behavior.
A PR is going to be filed shortly against the python 3.7 branch (as the documentation page for asyncio in 3.8 does not fully exist right now).

----------
assignee: docs at python
components: Documentation, asyncio
files: asyncio_await_from_self_example.py
messages: 325468
nosy: asvetlov, azaria.zornberg, docs at python, yselivanov
priority: normal
severity: normal
status: open
title: Asyncio documentation for recursive coroutines is lacking
type: enhancement
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7
Added file: https://bugs.python.org/file47805/asyncio_await_from_self_example.py

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

From report at bugs.python.org  Sun Sep 16 04:18:19 2018
From: report at bugs.python.org (Guillaume Ayoub)
Date: Sun, 16 Sep 2018 08:18:19 +0000
Subject: [New-bugs-announce] [issue34702] urlopen doesn't handle query
 strings with "file" scheme
Message-ID: <1537085899.9.0.956365154283.issue34702@psf.upfronthosting.co.za>


New submission from Guillaume Ayoub <xovni at wanadoo.fr>:

urlopen includes query strings in the filename with "file"-scheme URLs.

>>> from urllib.request import urlopen
>>> urlopen('file:///tmp/test')
<addinfourl at 140059890562888 whose fp = <_io.BufferedReader name='/tmp/test'>>
>>> urlopen('file:///tmp/test?q')
Traceback (most recent call last):
  File "/usr/lib/python3.7/urllib/request.py", line 1473, in open_local_file
    stats = os.stat(localfile)
FileNotFoundError: [Errno 2] No such file or directory: '/tmp/test?q'

This behavior seems to be OK with what RFC 8089 tells, but many other implementations (including browsers and curl) remove query strings from the filename.

----------
messages: 325475
nosy: liZe
priority: normal
severity: normal
status: open
title: urlopen doesn't handle query strings with "file" scheme
type: behavior

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

From report at bugs.python.org  Sun Sep 16 07:05:14 2018
From: report at bugs.python.org (chengxuncc)
Date: Sun, 16 Sep 2018 11:05:14 +0000
Subject: [New-bugs-announce] [issue34703] Unexpected Arithmetic Result
Message-ID: <1537095914.48.0.956365154283.issue34703@psf.upfronthosting.co.za>


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

>>> 2359296/10/1000**2
0.23592960000000002

>>> 2359296/10000000
0.2359296

You can see it.

----------
components: Interpreter Core
messages: 325478
nosy: chengxuncc
priority: normal
severity: normal
status: open
title: Unexpected Arithmetic Result
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Sun Sep 16 08:35:22 2018
From: report at bugs.python.org (Neil Schemenauer)
Date: Sun, 16 Sep 2018 12:35:22 +0000
Subject: [New-bugs-announce] [issue34704] Do not access ob_type directly,
 introduce Py_TP
Message-ID: <1537101322.11.0.956365154283.issue34704@psf.upfronthosting.co.za>


New submission from Neil Schemenauer <nas-python at arctrix.com>:

My long term goal is to make it possible to make PyObject an opaque structure.  Obviously that would break nearly every 3rd party extension at this point.  However, to allow freedom on certain interpreter implementation strategies, it is helpful if code does not access ob_type, ob_refcnt and ob_size directly.  Cleaning up core Python is not too hard.

There is closed bug #26824 which proposed a similar change.  There was two main issues with that patch.  One, it causes a fair amount of code churn.  This patch does that too.  Second, replace ob->ob_type with Py_TYPE(ob) adds an extra type-cast to PyObject*.  That's not good.

In this patch, I introduce Py_TP() as a non-typecast version of Py_TYPE().  I think the name is nice as it is short and matches the struct field prefix.

This change overlaps with Victor's proposed %t or %T format code change.  The code churn is mostly caused by code that does ob->ob_type->tp_name.  I'm not against the format code idea but personally I think trying to remove borrowed references is a difficult problem and it should not hold up the relatively simple task of allowing PyObject to be opaque.

Also, I doesn't see any immediate need to make PyTypeObject opaque.  The tp_* are used everywhere and so making access macros or functions for those would be hugely disruptive.  PyTypeObject is already opaque for the limited API.  I think that's good enough for now.

If this change gets accepted, I have follow-up patches to fix access to ob_refcnt and ob_size.  Those are much smaller patches since those fields are not often accessed.

----------
components: Interpreter Core
files: py_tp_macro.txt
keywords: needs review, patch
messages: 325482
nosy: nascheme, serhiy.storchaka, vstinner
priority: normal
severity: normal
stage: patch review
status: open
title: Do not access ob_type directly, introduce Py_TP
type: enhancement
Added file: https://bugs.python.org/file47806/py_tp_macro.txt

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

From report at bugs.python.org  Sun Sep 16 09:15:56 2018
From: report at bugs.python.org (Ned Batchelder)
Date: Sun, 16 Sep 2018 13:15:56 +0000
Subject: [New-bugs-announce] [issue34705] Python 3.8 changes how returns
 through finally clauses are traced
Message-ID: <1537103756.04.0.956365154283.issue34705@psf.upfronthosting.co.za>


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

When a return statement also executes a finally clause, the sequence of lines reported to the trace function is different in 3.8 than it has been before 3.8:

$ cat finally_trace.py
def return_from_finally():
    try:
        print("returning")
        return 17
    finally:
        print("finally")

def trace(frame, event, arg):
    print(frame.f_lineno, event)
    return trace

import sys
sys.settrace(trace)
return_from_finally()

$ python3.7 finally_trace.py
1 call
2 line
3 line
returning
4 line
6 line
finally
6 return

$ python3.8 finally_trace.py
1 call
2 line
3 line
returning
4 line
6 line
finally
4 line
4 return


Is this intentional? Is it a bug? Will it change back before 3.8 is shipped?

----------
components: Interpreter Core
messages: 325484
nosy: nedbat
priority: normal
severity: normal
status: open
title: Python 3.8 changes how returns through finally clauses are traced
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Sun Sep 16 17:12:01 2018
From: report at bugs.python.org (Buck Evan)
Date: Sun, 16 Sep 2018 21:12:01 +0000
Subject: [New-bugs-announce] [issue34706] Signature.from_callable sometimes
 drops subclassing
Message-ID: <1537132321.64.0.956365154283.issue34706@psf.upfronthosting.co.za>


New submission from Buck Evan <buck.2019 at gmail.com>:

Specifically in the case of a class that does not override its constructor signature inherited from object.

Github PR incoming shortly.

----------
components: Library (Lib)
messages: 325501
nosy: bukzor
priority: normal
severity: normal
status: open
title: Signature.from_callable sometimes drops subclassing
versions: Python 3.7

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

From report at bugs.python.org  Sun Sep 16 22:04:35 2018
From: report at bugs.python.org (john skaller)
Date: Mon, 17 Sep 2018 02:04:35 +0000
Subject: [New-bugs-announce] [issue34707] Python not reentrant
Message-ID: <1537149875.51.0.956365154283.issue34707@psf.upfronthosting.co.za>


New submission from john skaller <skaller at users.sourceforge.net>:

Executive Summary: Python currently is not properly re-entrant. This comment applies to the CAPI and particularly embedding. A fix is not possible in Python 3.x but should be scheduled for Python 4. On Linux all binary plugins are broken as well.

The fault is exhibited by the need to first call PyInitialise(). This is clearly wrong because there is nowhere to put the initialised data. The correct sequence should be to first create an interpreter handle, and then initialise that. Other API calls exhibit the same fault. For example PyErr_Occured().

Use of thread local storage is NOT enough.

A general embedding scenario is this: a thunk program is used to dynamically load a shared library and execute a function in it. That function may load other shared libraries. Note carefully there is no global data, the libraries are pure code. [This is not an imagined scenario, my whole system works this way]

The same library may be loaded several times. For example, A can load B and C, and both B and C can load D. Proper visibility control means A cannot see any symbols of D.

In this scenario if D wishes to run a Python interpreter, it must call PyInitialise(), and it will be called twice, since D is called twice, once from A, and once from B. Indeed, if the top level spawns multiple threads, it can be called many more times than that. 

Remember the libraries are pure code and fully reentrant. There is no way to record if a function has been called already.

In order for Python to be fully re-entrant there is a simple test: if the C code of the Python library contains ANY global variables at all then Python is wrong. Global variables INCLUDE thread local storage. ALL data and ALL functions must hang off a handle so that all functionality and behaviour is fully isolated to each handle.

Exceptions to the rule: poorly designed OS such as Unix have some non-reentrant features. The worst of these in Unix is signal handling. It is not possible to handle signals without a global variable to communicate between the signal handler and application. The right way to do this would have been to use a polling service to detect the signal. In any case systems like Python do have to work with badly designed API's sometimes and therefore these special cases do form legitimate exceptions to the requirement that the API be re-entrant. My recommendation is to provide a cheat API which looks re-entrant but actually isn't, because it delegates to a hidden lower level which isn't, of necessity. YMMV: how to handle bad underlying API's should be open for discussion.

Other consequences: On linux at least ALL plugin extensions are built incorrectly. The correct way to build a plugin requires explicitly linking against the Python library, so that symbols in the Python API can be found. These symbols must NOT be found in the application because this is, quite simply, not possible, if the application does not include those symbols. In my scenario, the top level application is three lines of C than does nothing other than load a library and run a fixed function in it. And that library has no idea that one of the libraries IT loads may call another library which happens to want to run some Python code. Indeed my system can *generate* Python modules, and compile and link them against the Python library, but it cannot load any existing plugins on Linux, because those plugins were incorrectly built and do not link to the Python library as they should. They expect to find symbols in the symbol table magically provided but those symbols are not there.

On OSX, however, it works. That is because on OSX, a --framework is used to contain the Python library and all plugins HAVE to be linked against the framework. I expect the Windows builds to work too, for the same reason (but I'm not sure).

This issue is related to the lack of re-entrancy because the same principle is broken in both cases. If you need a service, you must ask for it, and when you get it, it is exclusively yours.

----------
components: Interpreter Core
messages: 325508
nosy: skaller
priority: normal
severity: normal
status: open
title: Python not reentrant
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Sun Sep 16 22:53:01 2018
From: report at bugs.python.org (Harrison Chudleigh)
Date: Mon, 17 Sep 2018 02:53:01 +0000
Subject: [New-bugs-announce] [issue34708] Odd crashes/freezes when
 sys.stdout.shell.console is typed
Message-ID: <1537152781.74.0.956365154283.issue34708@psf.upfronthosting.co.za>


New submission from Harrison Chudleigh <harrison.chudleigh1 at education.nsw.gov.au>:

If sys is imported and sys.stdout.shell.console is typed, IDLE does not return to the prompt. Ctrl-C has no effect and after a restart with Ctrl-F6, IDLE does not react after a command is typed in. This also occurs when other variables such as sys.stdout.shell.stdout are used, but not with non-existent variables such as sys.stdout.shell.not_a_variable. No such issue occurs using the command line; however, sys.stdout.shell is not defined in the command line. This behaviour exists in at least Python 3.6.1 and 3.7.0 on Mac OS X 10.9.

This might be related to a similar issue that occurs in at least Python 3.2 on Windows 2000. Entering sys.stdout.shell.console causes IDLE to crash immediately; a crash also occurs when you type sys.stdout.shell.console. and wait for IDLE to bring up the list of attributes.

I know that this bug shouldn't be encountered unless you're using the IDLE PyShell object for some reason, but it still seems weird that getting the value of a variable causes crashes and hangs, especially when I know that the variable exists from looking at idlelib.

This is marked as Python 3.4 to 3.7 because I tested with 3.7, 3.6 and 3.2 and I don't think that this would have been fixed and then broken again. I don't know about 3.8, though.

----------
assignee: terry.reedy
components: IDLE
files: fail.py
messages: 325509
nosy: Harrison Chudleigh, terry.reedy
priority: normal
severity: normal
status: open
title: Odd crashes/freezes when sys.stdout.shell.console is typed
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7
Added file: https://bugs.python.org/file47808/fail.py

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

From report at bugs.python.org  Mon Sep 17 00:57:38 2018
From: report at bugs.python.org (Amos S)
Date: Mon, 17 Sep 2018 04:57:38 +0000
Subject: [New-bugs-announce] [issue34709] Suggestion: make getuser.getpass()
 also look at SUDO_USER environment variable
Message-ID: <1537160258.21.0.956365154283.issue34709@psf.upfronthosting.co.za>


New submission from Amos S <amos.shapira at gmail.com>:

When doing "sudo python-script.py", the output of "getpass.getuser()" is pretty much useless for what it's used (I assume mainly logging and tracking purposes, that's what we use it for ourselves).

I worked around this limitation by using it in expression likes:

  username = os.environ.get("SUDO_USER") or getpass.getuser()

I think it'll be useful to many other users if getpass.getuser() could integrate this behavior.

I'd love to provide the code change if this is approved.

----------
messages: 325511
nosy: Amos S
priority: normal
severity: normal
status: open
title: Suggestion: make getuser.getpass() also look at SUDO_USER environment variable
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/issue34709>
_______________________________________

From report at bugs.python.org  Mon Sep 17 06:06:35 2018
From: report at bugs.python.org (Alexandru Ardelean)
Date: Mon, 17 Sep 2018 10:06:35 +0000
Subject: [New-bugs-announce] [issue34710] SSL Module build fails with more
 pedantic compiler flags
Message-ID: <1537178795.41.0.956365154283.issue34710@psf.upfronthosting.co.za>


New submission from Alexandru Ardelean <ardeleanalex at gmail.com>:

See: https://github.com/openwrt/packages/pull/7051
The issue seems a bit older ; see comment: 
https://github.com/python/cpython/pull/3943#discussion_r148949292

Build error happens on OpenWrt as well:


---------------------------------------------------------------
<openwrt>/build_dir/target-i386_pentium4_musl/Python-3.7.0/Modules/_ssl.c:4000:5: error: implicit declaration of function 'DH_free'; did you mean 'lh_free'? [-Werror=implicit-function-declaration]
     DH_free(dh);
     ^~~~~~~
     lh_free
cc1: some warnings being treated as errors

Python build finished successfully!
The necessary bits to build these optional modules were not found:
_tkinter              _uuid                 nis
To find the necessary bits, look in setup.py in detect_modules() for the module's name.

The following modules found by detect_modules() in setup.py, have been
built by the Makefile instead, as configured by the Setup files:
_abc                  atexit                pwd
time                  zlib

Failed to build these modules:
_ssl

Makefile:618: recipe for target 'sharedmods' failed

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

The fix seems to be to include <openssl/dh.h>.

----------
assignee: christian.heimes
components: Build, SSL
messages: 325518
nosy: Alexandru Ardelean, christian.heimes
priority: normal
severity: normal
status: open
title: SSL Module build fails with more pedantic compiler flags
versions: Python 3.7

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

From report at bugs.python.org  Mon Sep 17 06:23:18 2018
From: report at bugs.python.org (Michael Felt)
Date: Mon, 17 Sep 2018 10:23:18 +0000
Subject: [New-bugs-announce] [issue34711] Fix test_httpservers on AIX
Message-ID: <1537179798.31.0.956365154283.issue34711@psf.upfronthosting.co.za>


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

Going back to issue17234 - there has been a test to check that a URL with a trailing slash reports 404 status.

On AIX a trailing-slash is ignored - if the rest of the path is a valid filename.

At a very low-level, in Modules/_io/fileio.c the code could be adjusted to always look for a trailing slash, and if AIX considers the name to be a file (S_ISREG(mode)) then this could be promoted to an error. just as it does for "posix" opens directories with trailing slashes (and fileio.c deals with that in a Python way).

A quick fix is to skip the test issue17324 introduced;
A medium fix would be to modify Lib/http/server.py to verify that a URL with trailing slash is a directory, and otherwise raise an exception;
A deeper fix would be to add "a hack" specific to AIX, and raise (emulate) an OSError when there is a trailing slash and the pathname is a file.

In short, the simple resolution - without impacting core in any way is:
diff --git a/Lib/test/test_httpservers.py b/Lib/test/test_httpservers.py
index cc829a522b..31be9b4479 100644
--- a/Lib/test/test_httpservers.py
+++ b/Lib/test/test_httpservers.py
@@ -13,6 +13,7 @@ import sys
 import re
 import base64
 import ntpath
+import platform
 import shutil
 import email.message
 import email.utils
@@ -29,6 +30,7 @@ from io import BytesIO
 import unittest
 from test import support

+AIX = platform.system() == 'AIX'

 class NoLogRequestHandler:
     def log_message(self, *args):
@@ -417,9 +419,11 @@ class SimpleHTTPServerTestCase(BaseTestCase):
         #constructs the path relative to the root directory of the HTTPServer
         response = self.request(self.base_url + '/test')
         self.check_status_and_reason(response, HTTPStatus.OK, data=self.data)
-        # check for trailing "/" which should return 404. See Issue17324
-        response = self.request(self.base_url + '/test/')
-        self.check_status_and_reason(response, HTTPStatus.NOT_FOUND)
+        # AIX open() will open a filename with a trailing slash - as a file
+        if not AIX:
+            # check for trailing "/" which should return 404. See Issue17324
+            response = self.request(self.base_url + '/test/')
+            self.check_status_and_reason(response, HTTPStatus.NOT_FOUND)
         response = self.request(self.base_url + '/')
         self.check_status_and_reason(response, HTTPStatus.OK)
         response = self.request(self.base_url)
@@ -519,8 +523,9 @@ class SimpleHTTPServerTestCase(BaseTestCase):
     def test_path_without_leading_slash(self):
         response = self.request(self.tempdir_name + '/test')
         self.check_status_and_reason(response, HTTPStatus.OK, data=self.data)
-        response = self.request(self.tempdir_name + '/test/')
-        self.check_status_and_reason(response, HTTPStatus.NOT_FOUND)
+        if not AIX:
+            response = self.request(self.tempdir_name + '/test/')
+            self.check_status_and_reason(response, HTTPStatus.NOT_FOUND)
         response = self.request(self.tempdir_name + '/')
         self.check_status_and_reason(response, HTTPStatus.OK)
         response = self.request(self.tempdir_name)

Comments!

----------
components: Tests
messages: 325519
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: Fix test_httpservers on AIX
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Mon Sep 17 12:36:31 2018
From: report at bugs.python.org (Ben Hoyt)
Date: Mon, 17 Sep 2018 16:36:31 +0000
Subject: [New-bugs-announce] [issue34712] Style fixes in examples of "Input
 and Output" tutorial section
Message-ID: <1537202191.62.0.956365154283.issue34712@psf.upfronthosting.co.za>


New submission from Ben Hoyt <benhoyt at gmail.com>:

There are a couple of examples in the "Input and Output" section of the tutorial that use an unusual / non-PEP 8 Python style or whitespace. I think our examples, especially in the tutorial, should reflect good, PEP 8 style. I'll fix these in a PR which I'll attach soon.

----------
assignee: docs at python
components: Documentation
messages: 325550
nosy: akuchling, benhoyt, docs at python, rhettinger
priority: normal
severity: normal
status: open
title: Style fixes in examples of "Input and Output" tutorial section
versions: Python 3.8

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

From report at bugs.python.org  Mon Sep 17 13:14:05 2018
From: report at bugs.python.org (Nicholas Chammas)
Date: Mon, 17 Sep 2018 17:14:05 +0000
Subject: [New-bugs-announce] [issue34713] csvwriter.writerow()'s return type
 is undocumented
Message-ID: <1537204445.4.0.956365154283.issue34713@psf.upfronthosting.co.za>


New submission from Nicholas Chammas <nicholas.chammas at gmail.com>:

It _looks_ like csvwriter.writerow() returns the number of bytes (or is it characters?) written. However, there is no documentation of this:

https://docs.python.org/3.7/library/csv.html#csv.csvwriter.writerow

Is this behavior part of the method's "contract"? And if so, shouldn't we document it?

The same goes for csvwriter.writerows().

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 325557
nosy: docs at python, nchammas
priority: normal
severity: normal
status: open
title: csvwriter.writerow()'s return type is undocumented
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Mon Sep 17 15:06:27 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 17 Sep 2018 19:06:27 +0000
Subject: [New-bugs-announce] [issue34714] timeout in
 test_multiprocessing_spawn x86 Windows7 3.x buildbot
Message-ID: <1537211187.89.0.956365154283.issue34714@psf.upfronthosting.co.za>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

https://buildbot.python.org/all/#/builders/58/builds/1338/steps/3/logs/stdio

Timeout (0:15:00)!
Thread 0x000009d8 (most recent call first):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\multiprocessing\popen_spawn_win32.py", line 91 in wait
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\multiprocessing\process.py", line 140 in join
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\_test_multiprocessing.py", line 612 in test_error_on_stdio_flush_1
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\case.py", line 610 in run
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\unittest\case.py", line 658 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 1900 in _run_suite
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\support\__init__.py", line 1990 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 179 in runtest_inner
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\runtest.py", line 140 in runtest
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 286 in rerun_failed_tests
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 570 in _main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 531 in main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\libregrtest\main.py", line 584 in main
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\__main__.py", line 2 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 192 in _run_module_as_main
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\multiprocessing\spawn.py", line 107, in spawn_main
    new_handle = reduction.duplicate(pipe_handle,
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\multiprocessing\reduction.py", line 79, in duplicate
    return _winapi.DuplicateHandle(
PermissionError: [WinError 5] Access is denied

----------
components: Tests, Windows
messages: 325564
nosy: pablogsal, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: timeout in test_multiprocessing_spawn x86 Windows7 3.x buildbot
versions: Python 3.8

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

From report at bugs.python.org  Mon Sep 17 15:32:14 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Mon, 17 Sep 2018 19:32:14 +0000
Subject: [New-bugs-announce] [issue34715] timemodule.c fails to compile on
 BSD
Message-ID: <1537212734.38.0.956365154283.issue34715@psf.upfronthosting.co.za>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

Example:

https://buildbot.python.org/all/#/builders/87/builds/1434

./Modules/timemodule.c:573:24: warning: assigning to 'char *' from 'const char *' discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers]
            p->tm_zone = PyUnicode_AsUTF8(item);
                       ^ ~~~~~~~~~~~~~~~~~~~~~~
./Modules/timemodule.c:1545:44: warning: incompatible pointer to integer conversion passing 'char *(int, int)' to parameter of type 'long' [-Wint-conversion]
    PyModule_AddIntConstant(m, "timezone", timezone);
                                           ^~~~~~~~
./Include/modsupport.h:118:71: note: passing argument to parameter here
PyAPI_FUNC(int) PyModule_AddIntConstant(PyObject *, const char *, long);
                                                                      ^
./Modules/timemodule.c:1568:44: error: use of undeclared identifier 'daylight'
    PyModule_AddIntConstant(m, "daylight", daylight);
                                           ^
2 warnings and 1 error generated.
*** [Modules/timemodule.o] Error code 1
make: stopped in /usr/home/buildbot/python/3.x.koobs-freebsd10/build
make: stopped in /usr/home/buildbot/python/3.x.koobs-freebsd10/build
1 error

----------
components: Build, FreeBSD
messages: 325566
nosy: koobs, pablogsal
priority: normal
severity: normal
status: open
title: timemodule.c fails to compile on BSD
type: compile error
versions: Python 3.8

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

From report at bugs.python.org  Mon Sep 17 15:45:58 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Mon, 17 Sep 2018 19:45:58 +0000
Subject: [New-bugs-announce] [issue34716] MagicMock.__divmod__ should return
 a pair
Message-ID: <1537213558.4.0.956365154283.issue34716@psf.upfronthosting.co.za>


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

It is documented, that divmod() returns a pair. It is usually used with tuple unpacking:

    x, y = divmod(a, b)

But this doesn't work when one of arguments is a MagicMock.

>>> from unittest.mock import *
>>> x, y = divmod(MagicMock(), 2)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: not enough values to unpack (expected 2, got 0)

I expect that tuple unpacking will work with the result of MagicMock.__divmod__(). There possible following options:

1. Return some constant value, e.g. (1, 0).

2. Return a pair of new MagicMock instances.

3. Define __divmod__ in terms of __floordiv__ and __mod__. This will automatically return a pair of MagicMock instances by default, but setting return values for __floordiv__ and __mod__ will affect the result of __divmod__.

What is more preferable?

----------
components: Library (Lib)
messages: 325571
nosy: michael.foord, serhiy.storchaka
priority: normal
severity: normal
status: open
title: MagicMock.__divmod__ should return a pair
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Mon Sep 17 17:13:57 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 17 Sep 2018 21:13:57 +0000
Subject: [New-bugs-announce] [issue34717] docs: disable numbered sections
 for stdlib in html
Message-ID: <1537218837.12.0.956365154283.issue34717@psf.upfronthosting.co.za>


New submission from Yury Selivanov <yselivanov at gmail.com>:

I'd like to remove the ":numbered:" option from Doc/library/index.rst TOC.  Most standard library modules don't have extensive documentation, but some, for example asyncio, have.  For such modules, numbering makes title to contain too much noise.  Sphinx does not allow to opt-out from sections numbering if it's enabled on the top level.

----------
assignee: docs at python
components: Documentation
files: now_2.png
messages: 325577
nosy: docs at python, yselivanov
priority: normal
severity: normal
status: open
title: docs: disable numbered sections for stdlib in html
type: enhancement
Added file: https://bugs.python.org/file47809/now_2.png

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

From report at bugs.python.org  Tue Sep 18 00:37:34 2018
From: report at bugs.python.org (=?utf-8?q?Miguel_=C3=81ngel?=)
Date: Tue, 18 Sep 2018 04:37:34 +0000
Subject: [New-bugs-announce] [issue34718] Syntax error on factorial example
Message-ID: <1537245454.25.0.956365154283.issue34718@psf.upfronthosting.co.za>


New submission from Miguel ?ngel <miguelangel.garcia at gmail.com>:

In the example on https://docs.python.org/3/library/asyncio-task.html#running-tasks-concurrently, there is a double closing parenthesis, but just one is needed for the `gather` method. This makes the example to fail.

----------
assignee: docs at python
components: Documentation
messages: 325614
nosy: docs at python, magmax
priority: normal
severity: normal
status: open
title: Syntax error on factorial example
type: enhancement
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Tue Sep 18 07:57:29 2018
From: report at bugs.python.org (Javier Dehesa)
Date: Tue, 18 Sep 2018 11:57:29 +0000
Subject: [New-bugs-announce] [issue34719] Deprecate set to frozenset
 conversion in set.__contains__
Message-ID: <1537271849.84.0.956365154283.issue34719@psf.upfronthosting.co.za>


New submission from Javier Dehesa <javidcf at gmail.com>:

This comes from this SO question: https://stackoverflow.com/q/52382983/1782792

Currently, this works:

    > print({1, 2} in {frozenset({1, 2}))
    # True

This is strange because set is unhashable. Apparently, it is a case-specific feature implemented back in 2003 (https://github.com/python/cpython/commit/19c2d77842290af9b5f470c1eea2a71d1f77c9fe), by which set objects are converted to frozensets when checking for membership in another set. Personally I feel this is a bit surprising and inconsistent, but that is not the only issue with it. In the original implementation, this conversion was basically free because the created frozenset used the same storage as the given one. In the current implementation, however (https://github.com/python/cpython/blob/3.7/Objects/setobject.c#L1888-L1906), a new frozenset object is created, copied from the previous one. It seems this was done for thread-safety. The problem with that is that it is significantly more expensive:

    s = set(range(100000))
    sf = frozenset(s)
    t = { sf }
    %timeit sf in t  # True
    >>> 31.6 ns ? 1.04 ns per loop (mean ? std. dev. of 7 runs, 10000000 loops each)
    %timeit s in t  # True
    >>> 4.9 ms ? 168 ?s per loop (mean ? std. dev. of 7 runs, 100 loops each)

In the above case, using the conversion takes five order of magnitude more time than the regular check. I suppose there is a memory impact too.

I think this (as far as I know) undocumented feature does not provide a significant usability gain, is inconsistent with the documented behavior of set and gives rise to obscurely underperfoming code. Removing it would be a breaking change, but again, affected code would be relying on undocumented behavior (or even "against-documentation" behavior).

----------
components: Interpreter Core
messages: 325631
nosy: Javier Dehesa
priority: normal
severity: normal
status: open
title: Deprecate set to frozenset conversion in set.__contains__
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/issue34719>
_______________________________________

From report at bugs.python.org  Tue Sep 18 08:03:05 2018
From: report at bugs.python.org (Michael Felt)
Date: Tue, 18 Sep 2018 12:03:05 +0000
Subject: [New-bugs-announce] [issue34720] Fix test_importlib for AIX
Message-ID: <1537272185.7.0.956365154283.issue34720@psf.upfronthosting.co.za>


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

Issue32374 added a new subtest (test_bad_traverse) in test_importlib. The test succeeds when a script calling a bad_traverse exits with a non-zero status (e.g., crashes because of segmentation violation)

This patch "fixes" Modules/_testmultiphase.c so that it exits with a non-zero status when a NULL pointer is accessed. This is what was causing other systems to 'crash' expectedly - while AIX was not.

A simple demo program to demonstrate the difference behavior of AIX:

/*
 * Program to show whether an executable crashes, or not
 * when a NULL pointer is accessed
 * Author: AIXTOOLS
 */

#include<stdio.h>
main()
{
        long *vpt = NULL;

        fprintf(stdout, "vpt = %08lx\n", (long) vpt);
        if (*vpt)
                fprintf(stdout,"True\n");
        else
                fprintf(stdout,"False\n");

}

On AIX:
root at x066:[/data/prj/python/git]make nullpr; ./nullpr
cc     nullpr.c   -o nullpr
vpt = 00000000
False

On a Linux server:
root at x074:/data/prj/python/git# rm nullpr; make nullpr; ./nullpr
make: Warning: File 'nullpr.c' has modification time 352 s in the future
cc     nullpr.c   -o nullpr
nullpr.c:8:1: warning: return type defaults to 'int' [-Wimplicit-int]
 main()
 ^
make: warning:  Clock skew detected.  Your build may be incomplete.
vpt = 00000000
Segmentation fault

----------
components: Tests
messages: 325632
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: Fix test_importlib for AIX
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Tue Sep 18 09:18:10 2018
From: report at bugs.python.org (zack)
Date: Tue, 18 Sep 2018 13:18:10 +0000
Subject: [New-bugs-announce] [issue34721] json module loads function
Message-ID: <1537276690.81.0.956365154283.issue34721@psf.upfronthosting.co.za>


New submission from zack <j9001552 at gmail.com>:

the json.loads function think a string variable is a json type, but the variable is "123"

----------
components: Library (Lib)
files: json_test.py
messages: 325639
nosy: jaihong
priority: normal
severity: normal
status: open
title: json module loads function
type: behavior
versions: Python 3.5
Added file: https://bugs.python.org/file47813/json_test.py

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

From report at bugs.python.org  Tue Sep 18 09:53:47 2018
From: report at bugs.python.org (Peter Ebden)
Date: Tue, 18 Sep 2018 13:53:47 +0000
Subject: [New-bugs-announce] [issue34722] Non-deterministic bytecode
 generation
Message-ID: <1537278827.47.0.956365154283.issue34722@psf.upfronthosting.co.za>


New submission from Peter Ebden <peter.ebden at gmail.com>:

We've found that the following code produces non-deterministic bytecode,
even post PEP-552:

def test(x):
    if x in {'ONE', 'TWO', 'THREE'}:
        pass

It's not too hard to test it:

$ python3.7 -m compileall --invalidation-mode=unchecked-hash test.py
Compiling 'test.py'...
$ sha1sum __pycache__/test.cpython-37.pyc
61e5682ca95e8707b4ef2a79f64566664dafd800  __pycache__/test.cpython-37.pyc
$ rm __pycache__/test.cpython-37.pyc
$ python3.7 -m compileall --invalidation-mode=unchecked-hash test.py
Compiling 'test.py'...
$ sha1sum __pycache__/test.cpython-37.pyc
222a06621b491879e5317b34e9dd715bacd89b7d  __pycache__/test.cpython-37.pyc

It looks like the peephole optimiser is converting the LOAD_CONST instructions
for the set into a single LOAD_CONST for a frozenset which then serialises in
nondeterministic order. One can hence work around it by setting PYTHONHASHSEED
to a known value.

I'm happy to help out with this if needed, although I don't have a lot of
familiarity with the relevant code.

----------
components: Interpreter Core
messages: 325644
nosy: Peter Ebden
priority: normal
severity: normal
status: open
title: Non-deterministic bytecode generation
versions: Python 3.7

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

From report at bugs.python.org  Tue Sep 18 10:02:16 2018
From: report at bugs.python.org (Dogan)
Date: Tue, 18 Sep 2018 14:02:16 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue34723=5D_lower=28=29_on_Tu?=
 =?utf-8?q?rkish_letter_=22=C4=B0=22_returns_a_2-chars-long_string?=
Message-ID: <1537279336.26.0.956365154283.issue34723@psf.upfronthosting.co.za>


New submission from Dogan <dogankocabas at gmail.com>:

Hey there,

I believe I've come across a bug. It occurs when you try to lower() the Turkish uppercase letter "?". Gonna explain it with example code since it's easier:

>>> len("?")
1
>>> len("?".lower())
1
>>> len("?")
1
>>> len("?".lower())
1
>>> len("?")
1
>>> len("?".lower())
1
>>> len("?")
1
>>> len("?".lower())
1
>>> len("?")
1
>>> len("?".lower())
2

When you lower() the Turkish uppercase letter ???, it returns a 2 chars long string with the first character being ?i?, and the second being chr(775).

Should it not simply return ?i??

----------
components: Unicode
messages: 325646
nosy: ezio.melotti, vstinner, zamsalak
priority: normal
severity: normal
status: open
title: lower() on Turkish letter "?" returns a 2-chars-long string
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Tue Sep 18 12:49:27 2018
From: report at bugs.python.org (Jeremiah Rosen)
Date: Tue, 18 Sep 2018 16:49:27 +0000
Subject: [New-bugs-announce] [issue34724] argparse subparser help indent too
 short
Message-ID: <1537289367.73.0.956365154283.issue34724@psf.upfronthosting.co.za>


New submission from Jeremiah Rosen <takingitcasual at gmail.com>:

The help is indented too early for subparsers with long argument names. I'm currently using the ProperIndentParser class from the following gist to create my top level parser, which fixes the issue:

https://gist.github.com/TakingItCasual/df40932dcc30012325bfed241bdaabd0

----------
components: Library (Lib)
messages: 325663
nosy: Jeremiah Rosen
priority: normal
severity: normal
status: open
title: argparse subparser help indent too short
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Tue Sep 18 13:26:47 2018
From: report at bugs.python.org (Mario)
Date: Tue, 18 Sep 2018 17:26:47 +0000
Subject: [New-bugs-announce] [issue34725] Py_GetProgramFullPath() odd
 behaviour in Windows
Message-ID: <1537291607.58.0.956365154283.issue34725@psf.upfronthosting.co.za>


New submission from Mario <mariofutire at gmail.com>:

According to the doc Py_GetProgramFullPath() should return the full path of the program name as set by Py_SetProgramName().

https://docs.python.org/3/c-api/init.html#c.Py_GetProgramFullPath

This works well in Linux, but in Windows it is always the name of the current executable (from GetModuleFileNameW).

This is because the 2 files Modules/getpath.c and PC/getpathp.c have completely different logic in calculate_program_full_path() vs get_program_full_path().

This difference is harmless when running in the normal interpreter (python.exe), but can be quite dramatic when embedding python into a C application.

The value returned by Py_GetProgramFullPath() is the same as sys.executable in python.

Why this matters? For instance in Linux virtual environments work out of the box for embedded applications, while they are completely ignored in Windows.

python -m venv abcd

and then if I run my app inside the (activated) abcd environment in Linux I can access the same modules as if I were executing python, while in Windows I still get the system module search path.

If you execute the attached program in Linux you get

EXECUTABLE /tmp/abcd/bin/python3
PATH ['/usr/lib/python37.zip', '/usr/lib/python3.7', '/usr/lib/python3.7/lib-dynload', '/tmp/abcd/lib/python3.7/site-packages']

in Windows

EXECUTABLE c:\TEMP\vsprojects\ConsoleApplication1\x64\Release\ConsoleApplication1.exe
PATH ['C:\\TEMP\\venv\\abcd\\Scripts\\python37.zip', 'C:\\Python37\\Lib', 'C:\\Python37\\DLLs', 'c:\\TEMP\\vsprojects\\ConsoleApplication1\\x64\\Relea
se', 'C:\\Python37', 'C:\\Python37\\lib\\site-packages']

with a mixture of paths from the venv, system and my app folder.
But more importantly site-packages comes from the system (bad!).

This is because site.py at lines 454 uses the path of the interpreter to locate the venv configuration file.

So in the end, virtual environments work out of the box in Linux even for an embedded python, but not in Windows.

----------
components: Interpreter Core, Windows
files: poc.c
messages: 325666
nosy: mariofutire, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Py_GetProgramFullPath() odd behaviour in Windows
versions: Python 3.6, Python 3.7
Added file: https://bugs.python.org/file47814/poc.c

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

From report at bugs.python.org  Tue Sep 18 15:49:50 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Tue, 18 Sep 2018 19:49:50 +0000
Subject: [New-bugs-announce] [issue34726] Add support of checked hash-based
 pycs in zipimport
Message-ID: <1537300190.96.0.956365154283.issue34726@psf.upfronthosting.co.za>


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

Currently zipimport refuses to handle checked hash-based pycs (PEP 552).

----------
components: Library (Lib)
messages: 325675
nosy: brett.cannon, eric.snow, ncoghlan, serhiy.storchaka, twouters
priority: normal
severity: normal
status: open
title: Add support of checked hash-based pycs in zipimport
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Tue Sep 18 15:54:36 2018
From: report at bugs.python.org (cowlinator)
Date: Tue, 18 Sep 2018 19:54:36 +0000
Subject: [New-bugs-announce] [issue34727] Windows/2.7.15 IOError [Errno 0]
 when user interacts with cmd console
Message-ID: <1537300476.3.0.956365154283.issue34727@psf.upfronthosting.co.za>


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

I can consistently reproduce a bug in 2.7.15 on Windows which causes an unexpected IOError.

Steps to reproduce:

Enter the following code in a plain-vanilla windows command line console:

>>> import sys
>>> while True:
...     sys.stdout.write('.')

Then, pause the output, either by clicking and holding the scrollbar for 10 seconds, or by highlighting text with the mouse for 10 seconds and then pressing 'enter' to un-highlight.
Upon resuming, the following error is seen:

Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
IOError: [Errno 0] Error

----------
components: IO, Windows
messages: 325676
nosy: cowlinator, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Windows/2.7.15 IOError [Errno 0] when user interacts with cmd console
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Tue Sep 18 17:44:05 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Tue, 18 Sep 2018 21:44:05 +0000
Subject: [New-bugs-announce] [issue34728] deprecate *loop* argument for
 asyncio.sleep
Message-ID: <1537307045.18.0.956365154283.issue34728@psf.upfronthosting.co.za>


New submission from Yury Selivanov <yselivanov at gmail.com>:

asyncio.sleep is a coroutine; passing a *loop* argument to it makes no sense anymore.

We should raise a DeprecationWarning in Python 3.8 and 3.9 and remove it in 4.0.

----------
components: asyncio
keywords: easy
messages: 325684
nosy: asvetlov, yselivanov
priority: normal
severity: normal
stage: needs patch
status: open
title: deprecate *loop* argument for asyncio.sleep
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Tue Sep 18 18:49:05 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Tue, 18 Sep 2018 22:49:05 +0000
Subject: [New-bugs-announce] [issue34729] bz2/lzma: Compressor/decompressor
 crash if __init__ is not called
Message-ID: <1537310945.11.0.956365154283.issue34729@psf.upfronthosting.co.za>


New submission from Alexey Izbyshev <izbyshev at ispras.ru>:

The compressor/decompressor classes from bz2 and lzma modules rely on __init__() for initialization, but it is not guaranteed to be called. Method calls on an uninitialized object crash:

>>> from bz2 import BZ2Compressor as C
>>> c = C.__new__(C)
>>> c.compress(b'')
Segmentation fault (core dumped)

I see two ways to fix this:

1) Move some initialization (notably, for "lock" field) to __new__() and add initialization checks to other methods. This should be backwards-compatible.

2) Move all initialization to __new__(). Since compressor/decompressor classes are not subclassable, it'll break only code than repeatedly calls __init__() on the same object. The simplicity of the fix might outweigh the necessity to support such code.
(However, in 2.7, classes in bz2 *are* subclassable; lzma is not present in 2.7).

Which way is more preferable?

----------
components: Extension Modules
messages: 325691
nosy: berker.peksag, izbyshev, serhiy.storchaka
priority: normal
severity: normal
status: open
title: bz2/lzma: Compressor/decompressor crash if __init__ is not called
type: crash
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Tue Sep 18 20:27:26 2018
From: report at bugs.python.org (Devin Fee)
Date: Wed, 19 Sep 2018 00:27:26 +0000
Subject: [New-bugs-announce] [issue34730] aclose() doesn't stop raise
 StopAsyncIteration / GeneratorExit to __anext__()
Message-ID: <1537316846.03.0.956365154283.issue34730@psf.upfronthosting.co.za>


New submission from Devin Fee <devin at devinfee.com>:

I expected an async-generator's aclose() method to cancel it's __anext__(). Instead, the task isn't cancelled, and (it seems) manually cleanup is necessary.


@pytest.mark.asyncio
async def test_aclose_cancels():
    done = False
    event = asyncio.Event()
    agen = None

    async def make_agen():
        try:
            await event.wait()
            raise NotImplementedError()
            yield  # pylint: disable=W0101, unreachable
        finally:
            nonlocal done
            done = True

    async def run():
        nonlocal agen
        agen = make_agen()
        await agen.__anext__()

    task = asyncio.ensure_future(run())
    await asyncio.sleep(.01)

    await agen.aclose()
    await asyncio.sleep(.01)

    assert done
    assert task.done() and task.exception()


Looking at the tests for CPython, the implementation seems to expect it, but I'm unclear if PEP-525 actually intends for this to be the case: https://github.com/python/cpython/blob/e42b705188271da108de42b55d9344642170aa2b/Lib/test/test_asyncgen.py#L657

Alternatively, maybe I shouldn't be calling aclose, and instead I should be cancelling the task:

@pytest.mark.asyncio
async def test_cancel_finalizes():
    done = False
    event = asyncio.Event()
    agen = None

    async def make_agen():
        try:
            await event.wait()
            raise NotImplementedError()
            yield  # pylint: disable=W0101, unreachable
        finally:
            nonlocal done
            done = True

    async def run():
        nonlocal agen
        agen = make_agen()
        await agen.__anext__()

    task = asyncio.ensure_future(run())
    await asyncio.sleep(.01)
    task.cancel()
    await asyncio.sleep(.01)

    assert done
    assert task.done()

So the "bug" here is one of PEP-525 clarification.

----------
components: asyncio
messages: 325699
nosy: asvetlov, dfee, yselivanov
priority: normal
severity: normal
status: open
title: aclose() doesn't stop raise StopAsyncIteration / GeneratorExit to __anext__()
versions: Python 3.7

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

From report at bugs.python.org  Wed Sep 19 01:34:46 2018
From: report at bugs.python.org (Ronny Pfannschmidt)
Date: Wed, 19 Sep 2018 05:34:46 +0000
Subject: [New-bugs-announce] [issue34731] pathlib path.match misshandles
 multiple `**`
Message-ID: <1537335286.28.0.956365154283.issue34731@psf.upfronthosting.co.za>


New submission from Ronny Pfannschmidt <bugs.python.org at ronnypfannschmidt.de>:

when porting parts of pytest to pathlib we noted that `path.match` does not quite match normal fnmatch for usages of `**`

i believe this is related to always splitting the patter completely and not handling `**` in that case

Bruno wrote https://github.com/pytest-dev/pytest/pull/3980/files#diff-63fc5ed688925b327a5af20405bf4b09R19 as a workaround

----------
components: Library (Lib)
messages: 325701
nosy: Ronny.Pfannschmidt
priority: normal
severity: normal
status: open
title: pathlib path.match misshandles multiple `**`

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

From report at bugs.python.org  Wed Sep 19 02:33:06 2018
From: report at bugs.python.org (jophine antony)
Date: Wed, 19 Sep 2018 06:33:06 +0000
Subject: [New-bugs-announce] [issue34732] uuid returns version more than 5
Message-ID: <1537338786.65.0.956365154283.issue34732@psf.upfronthosting.co.za>


New submission from jophine antony <jophinep at gmail.com>:

When I validate the invalid uuid (RFC 4122 variant) for example '481a8de5-f0d1-f211-b425-e41f134196da'. It returns version number as 15 which is invalid. We need to retrun None in this case as we do for invalid UUIDs  based on RFC 4122.

------snip snip-------
from uuid import UUID
test_uuid_str = '481a8de5-f0d1-f211-b425-e41f134196da'
print("UUID version: {}".format(UUID(test_uuid_str).version))
print("UUID variant: {}".format(UUID(test_uuid_str).variant))
------snip snip-------

------Result----------
UUID version: 15
UUID variant: specified in RFC 4122
------Result----------

----------
messages: 325707
nosy: jophine pranjal
priority: normal
severity: normal
status: open
title: uuid returns version more than 5
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Wed Sep 19 05:28:10 2018
From: report at bugs.python.org (Harrison Chudleigh)
Date: Wed, 19 Sep 2018 09:28:10 +0000
Subject: [New-bugs-announce] [issue34733] Missing search bar on
 docs.python.org
Message-ID: <1537349290.73.0.956365154283.issue34733@psf.upfronthosting.co.za>


New submission from Harrison Chudleigh <harrison.chudleigh1 at education.nsw.gov.au>:

The search bar is missing from docs.python.org, probably as a result of a minor error in the webpage. This is a quite recent change, as the search bar is still there in a web.archive.org snapshot from the 13th of September (last week). Could someone please fix this? Thanks.

----------
assignee: docs at python
components: Documentation
messages: 325737
nosy: Harrison Chudleigh, docs at python
priority: normal
severity: normal
status: open
title: Missing search bar on docs.python.org
type: behavior

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

From report at bugs.python.org  Wed Sep 19 05:51:51 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Wed, 19 Sep 2018 09:51:51 +0000
Subject: [New-bugs-announce] [issue34734] Azure linux buildbot failure
Message-ID: <1537350711.76.0.956365154283.issue34734@psf.upfronthosting.co.za>


New submission from Karthikeyan Singaravelan <tir.karthi at gmail.com>:

It seems there is a sporadic failure in Azure linux buildbots while installing dependencies with the following error. It also fails sporadically on separate PRs that trigger the build. I noticed it for the few days since README Azure badge had the error for a couple of days with Linux builds passing on Travis.

Error message : 

2018-09-19T09:08:43.7414966Z Hit:17 http://packages.erlang-solutions.com/debian xenial Release
2018-09-19T09:08:45.1584376Z Reading package lists...
2018-09-19T09:08:45.2045716Z E: Could not get lock /var/lib/dpkg/lock - open (11: Resource temporarily unavailable)
2018-09-19T09:08:45.2063210Z E: Unable to lock the administration directory (/var/lib/dpkg/), is another process using it?
2018-09-19T09:08:45.2200826Z ##[error]Bash exited with code '100'.
2018-09-19T09:08:45.2734828Z ##[section]Finishing: Install dependencies

Reference buildbot failure : https://dev.azure.com/python/cpython/_build/results?buildId=30061&view=logs

Adding Victor and Pablo for notification. I don't think this is a requirement but just something I noticed and it also blocks miss-islington from auto-merging backport PRs in some cases like https://github.com/python/cpython/pull/9401#issuecomment-422505327

Thanks

----------
components: Build
messages: 325739
nosy: pablogsal, vstinner, xtreak
priority: normal
severity: normal
status: open
title: Azure linux buildbot failure
versions: Python 3.8

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

From report at bugs.python.org  Wed Sep 19 08:55:23 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Wed, 19 Sep 2018 12:55:23 +0000
Subject: [New-bugs-announce] [issue34735] Modules/timemodule.c: Memory leak
 in time_strftime()
Message-ID: <1537361723.97.0.956365154283.issue34735@psf.upfronthosting.co.za>


New submission from Zackery Spytz <zspytz at gmail.com>:

There is a missing PyMem_Free(format) in time_strftime(). I'll create a PR.

----------
components: Extension Modules
messages: 325754
nosy: ZackerySpytz
priority: normal
severity: normal
status: open
title: Modules/timemodule.c: Memory leak in time_strftime()
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Wed Sep 19 09:00:53 2018
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 19 Sep 2018 13:00:53 +0000
Subject: [New-bugs-announce] [issue34736] Confusing base64.b64decode output
Message-ID: <1537362053.96.0.956365154283.issue34736@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

The following error message in Python 3.7 is confusing and unhelpful:

    >>> s = "FS9qzW_oliGH_Yo="
    >>> base64.b64decode(s)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "/opt/local/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/base64.py", line 87, in b64decode
        return binascii.a2b_base64(s)
    binascii.Error: Invalid base64-encoded string: length cannot be 1 more than a multiple of 4
    >>> len(s) % 4
    0

This had me staring at the string s and scratching my head, thinking: "s doesn't have length 1 more than a multiple of 4, either with or without the "=" padding byte. What's this talking about?"

The actual user error here is a failure to use the "altchars" argument correctly:

>>> base64.b64decode(s, altchars="-_")
b'\x15/j\xcdo\xe8\x96!\x87\xfd\x8a'

The error message in versions prior to Python 3.7 is no more helpful, but it's not quite as misleading, either.

Python 3.6.6 (default, Jun 28 2018, 05:43:53) 
[GCC 4.2.1 Compatible Apple LLVM 9.1.0 (clang-902.0.39.2)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import base64
>>> s = "FS9qzW_oliGH_Yo="
>>> base64.b64decode(s)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/base64.py", line 87, in b64decode
    return binascii.a2b_base64(s)
binascii.Error: Incorrect padding

Related: #1466065, #33770

----------
messages: 325757
nosy: mark.dickinson
priority: normal
severity: normal
status: open
title: Confusing base64.b64decode output
versions: Python 3.7

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

From report at bugs.python.org  Wed Sep 19 09:44:34 2018
From: report at bugs.python.org (Jatin Goel)
Date: Wed, 19 Sep 2018 13:44:34 +0000
Subject: [New-bugs-announce] [issue34737] Python upgrade with SYSTEM account
 uninstalls python
Message-ID: <1537364674.32.0.956365154283.issue34737@psf.upfronthosting.co.za>


New submission from Jatin Goel <jatingoel1037 at gmail.com>:

Team,

I have some Windows machines where Python version 3.6.2 is installed.

We are now upgrading them to 3.6.6

As part of our Install process, we launch the installation script with the SYSTEM account with the command:

python-3.6.6-amd64.exe /quiet InstallAllUsers=1 log "[logpath]\InstallPython"

This command works fine if I launch it interactively, i.e., from an Administrator account from command prompt, and version is upgraded successfully.


But when launching the same command from the SYSTEM account, it tries to install Just for Me, and not all users and some checks fails, and it removes the installed python as well.



[1C18:1F24][2018-09-19T16:25:58]i000: Setting numeric variable 'InstallLauncherAllUsers' to value 1
[1C18:1F24][2018-09-19T16:25:58]i000: Setting numeric variable 'Include_launcher' to value 1
[1C18:1F24][2018-09-19T16:25:58]i000: Setting numeric variable 'DetectedLauncher' to value 1
[1C18:1F24][2018-09-19T16:25:58]i000: Setting string variable 'Include_launcherState' to value 'disable'
[1C18:1F24][2018-09-19T16:25:58]i000: Setting string variable 'InstallLauncherAllUsersState' to value 'disable'

[1C18:1F24][2018-09-19T16:25:58]w208: Plan disabled rollback for package: tcltk_JustForMe, due to incomplete cache: None, original rollback action: Install
[1C18:1F24][2018-09-19T16:25:58]i000: Setting string variable 'WixBundleLog_tcltk_JustForMe' to value 'C:\ProgramData\Commvault Systems\Galaxy\LogFiles\Instance001\\InstallPython_007_tcltk_JustForMe.log'
[1C18:1F24][2018-09-19T16:25:58]i052: Condition 'not InstallAllUsers and Include_tcltk and Include_symbols and not LauncherOnly' evaluates to false.
[1C18:1F24][2018-09-19T16:25:58]i052: Condition 'not InstallAllUsers and Include_tcltk and Include_symbols and not LauncherOnly' evaluates to false.
[1C18:1F24][2018-09-19T16:25:58]i204: Plan 1 msi features for package: tcltk_JustForMe_pdb
[1C18:1F24][2018-09-19T16:25:58]i203: Planned feature: Symbols, state: Absent, default requested: Unknown, ba requested: Local, execute action: AddLocal, rollback action: Remove

[1C18:1F24][2018-09-19T16:26:03]i319: Applied execute package: dev_JustForMe, result: 0x0, restart: None
[1C18:1F24][2018-09-19T16:26:03]i329: Removed package dependency provider: {5CE3EB5B-1823-4B8E-BE10-95262BDD1148}, package: exe_JustForMe
[1C18:1F24][2018-09-19T16:26:03]i301: Applying execute package: exe_JustForMe, action: Uninstall, path: (null), arguments: ' ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" TARGETDIR="C:\Program Files\Python36\" OPTIONALFEATURESREGISTRYKEY="Software\Python\PythonCore\3.6\InstalledFeatures"'
[1C18:1F24][2018-09-19T16:26:04]i319: Applied execute package: exe_JustForMe, result: 0x0, restart: None
[1C18:1F24][2018-09-19T16:26:04]i329: Removed package dependency provider: {4D137679-6FB4-446B-9BDB-279292FA2D2C}, package: lib_JustForMe
[1C18:1F24][2018-09-19T16:26:04]i301: Applying execute package: lib_JustForMe, action: Uninstall, path: (null), arguments: ' ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" TARGETDIR="C:\Program Files\Python36\" OPTIONALFEATURESREGISTRYKEY="Software\Python\PythonCore\3.6\InstalledFeatures"'
[1C18:1F24][2018-09-19T16:26:47]i319: Applied execute package: lib_JustForMe, result: 0x0, restart: None
[1C18:1F24][2018-09-19T16:26:47]i329: Removed package dependency provider: {C9596636-022D-4123-B369-98819F772985}, package: test_JustForMe
[1C18:1F24][2018-09-19T16:26:47]i301: Applying execute package: test_JustForMe, action: Uninstall, path: (null), arguments: ' ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" TARGETDIR="C:\Program Files\Python36\" OPTIONALFEATURESREGISTRYKEY="Software\Python\PythonCore\3.6\InstalledFeatures"'
[1C18:1F24][2018-09-19T16:27:15]i319: Applied execute package: test_JustForMe, result: 0x0, restart: None
[1C18:1F24][2018-09-19T16:27:15]i329: Removed package dependency provider: {16EF5AB7-4A89-4F06-B20B-209DA4FE0533}, package: doc_JustForMe
[1C18:1F24][2018-09-19T16:27:16]i301: Applying execute package: doc_JustForMe, action: Uninstall, path: (null), arguments: ' ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" TARGETDIR="C:\Program Files\Python36\" OPTIONALFEATURESREGISTRYKEY="Software\Python\PythonCore\3.6\InstalledFeatures"'
[1C18:1F24][2018-09-19T16:27:17]i319: Applied execute package: doc_JustForMe, result: 0x0, restart: None
[1C18:1F24][2018-09-19T16:27:17]i329: Removed package dependency provider: {E95CEC86-EFB3-47B8-A5F6-C8FB757AD060}, package: tools_JustForMe
[1C18:1F24][2018-09-19T16:27:17]i301: Applying execute package: tools_JustForMe, action: Uninstall, path: (null), arguments: ' ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" TARGETDIR="C:\Program Files\Python36\" OPTIONALFEATURESREGISTRYKEY="Software\Python\PythonCore\3.6\InstalledFeatures"'
[1C18:1F24][2018-09-19T16:27:23]i319: Applied execute package: tools_JustForMe, result: 0x0, restart: None
[1C18:1F24][2018-09-19T16:27:23]i329: Removed package dependency provider: {44EC13CA-E201-433B-B2D3-386B9609B859}, package: tcltk_JustForMe
[1C18:1F24][2018-09-19T16:27:23]i301: Applying execute package: tcltk_JustForMe, action: Uninstall, path: (null), arguments: ' ARPSYSTEMCOMPONENT="1" MSIFASTINSTALL="7" TARGETDIR="C:\Program Files\Python36\" OPTIONALFEATURESREGISTRYKEY="Software\Python\PythonCore\3.6\InstalledFeatures"'
[1C18:1F24][2018-09-19T16:27:23]e000: Error 0x80070643: Failed to uninstall MSI package.
[1C18:1F24][2018-09-19T16:27:23]e000: Error 0x80070643: Failed to configure per-user MSI package.
[1C18:1F24][2018-09-19T16:27:23]i319: Applied execute package: tcltk_JustForMe, result: 0x80070643, restart: None



Any help would be much appreciated on this.


Regards,
Jatin Goel

----------
components: Installation, Windows
messages: 325760
nosy: JatinGoel, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: Python upgrade with SYSTEM account uninstalls python
versions: Python 3.6

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

From report at bugs.python.org  Wed Sep 19 09:47:27 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Sep 2018 13:47:27 +0000
Subject: [New-bugs-announce] [issue34738] Distutils: ZIP files don't include
 directory entries
Message-ID: <1537364847.56.0.956365154283.issue34738@psf.upfronthosting.co.za>


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

ZIP files created by distutils don't include entries for directories. For example, if the directory structure is

    dist/
        file1.py
        sub/
            file2.py

the ZIP file will contain entries 'dist/file1.py' and 'dist/sub/file2.py', but not 'dist/' and 'dist/sub/'.

This only when use the zipfile module. If it is not available for some reasons, the zip command is used. In that case directory entries are created. The are created also in TAR files.

All other methods of packing a tree to a ZIP in the stdlib (shutil.make_archive(), zipfile CLI, zipapp, Tools/msi/make_zip.py) create directory entries too.

zipimport doesn't support implicit namespace packages if directory entries are not added (issue14905).

The proposed PR makes distutils adding directory entries in a ZIP file.

----------
components: Distutils
messages: 325761
nosy: dstufft, eric.araujo, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Distutils: ZIP files don't include directory entries
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/issue34738>
_______________________________________

From report at bugs.python.org  Wed Sep 19 10:25:12 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Sep 2018 14:25:12 +0000
Subject: [New-bugs-announce] [issue34739] Get rid of tp_getattro in
 xml.etree.ElementTree.XMLParser
Message-ID: <1537367112.3.0.956365154283.issue34739@psf.upfronthosting.co.za>


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

Currently xml.etree.ElementTree.XMLParser has the tp_getattro slot for handling some attributes. The proposed PR replaces it with tp_members and tp_getset.

Benefits: constant time access, names of these attributes are added to the result of dir() and help(), better structured code.

----------
components: Extension Modules
messages: 325766
nosy: eli.bendersky, scoder, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Get rid of tp_getattro in xml.etree.ElementTree.XMLParser
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Wed Sep 19 10:31:29 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Sep 2018 14:31:29 +0000
Subject: [New-bugs-announce] [issue34740] Get rid of tp_getattro in
 ossaudiodev.oss_audio_device
Message-ID: <1537367489.08.0.956365154283.issue34740@psf.upfronthosting.co.za>


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

Currently ossaudiodev.oss_audio_device has the tp_getattro slot for handling some attributes. The proposed PR replaces it with tp_members and tp_getset.

Benefits: constant time access, names of these attributes are added to the result of dir() and help(), better structured code.

----------
components: Extension Modules
messages: 325768
nosy: serhiy.storchaka
priority: normal
severity: normal
status: open
title: Get rid of tp_getattro in ossaudiodev.oss_audio_device
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Wed Sep 19 10:38:57 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Wed, 19 Sep 2018 14:38:57 +0000
Subject: [New-bugs-announce] [issue34741] Get rid of tp_getattro and
 tp_setattro in pyexpat.xmlparser
Message-ID: <1537367937.72.0.956365154283.issue34741@psf.upfronthosting.co.za>


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

Currently pyexpat.xmlparser has the tp_getattro and tp_setattro slot for handling some attributes. The proposed PR replaces it with tp_members and tp_getset.

Benefits: constant time access, names of these attributes are added to the result of help(), no need of the __dir__() method, better structured code.

----------
components: Extension Modules
messages: 325769
nosy: eli.bendersky, scoder, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Get rid of tp_getattro and tp_setattro in pyexpat.xmlparser
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Wed Sep 19 14:27:13 2018
From: report at bugs.python.org (Ankit Goel)
Date: Wed, 19 Sep 2018 18:27:13 +0000
Subject: [New-bugs-announce] [issue34742] Add optional argument for exit
 status in argparse.ArgumentParser.error
Message-ID: <1537381633.99.0.956365154283.issue34742@psf.upfronthosting.co.za>


New submission from Ankit Goel <ankitgoel616 at gmail.com>:

argparse.ArgumentParser.error currently uses a hard coded exit status (2).
An optional argument (with default value 2) would be useful to change the status without needing to overwrite the method in a subclass like here: 
https://github.com/pytest-dev/pytest/pull/3925

----------
components: Library (Lib)
messages: 325779
nosy: Ankit Goel
priority: normal
severity: normal
status: open
title: Add optional argument for exit status in argparse.ArgumentParser.error
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/issue34742>
_______________________________________

From report at bugs.python.org  Wed Sep 19 15:36:44 2018
From: report at bugs.python.org (Berker Peksag)
Date: Wed, 19 Sep 2018 19:36:44 +0000
Subject: [New-bugs-announce] [issue34743] test_database_source_name fails
 with SQLite 3.7.9
Message-ID: <1537385804.37.0.956365154283.issue34743@psf.upfronthosting.co.za>


New submission from Berker Peksag <berker.peksag at gmail.com>:

======================================================================
FAIL: test_database_source_name (sqlite3.test.backup.BackupTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/berker/projects/cpython/master/Lib/sqlite3/test/backup.py", line 144, in test_database_source_name
    self.assertIn(
AssertionError: 'unrecognized error code: 1' not found in ['SQL logic error', 'SQL logic error or missing database']

A PR is on the way.

----------
assignee: berker.peksag
components: Extension Modules
messages: 325786
nosy: berker.peksag
priority: normal
severity: normal
stage: needs patch
status: open
title: test_database_source_name fails with SQLite 3.7.9
type: behavior
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Wed Sep 19 15:44:40 2018
From: report at bugs.python.org (helmsman helmsman)
Date: Wed, 19 Sep 2018 19:44:40 +0000
Subject: [New-bugs-announce] [issue34744] New %(flag)s format specifier for
 argparse.add_argument help string
Message-ID: <1537386280.08.0.956365154283.issue34744@psf.upfronthosting.co.za>


New submission from helmsman helmsman <whalebot.helmsman at gmail.com>:

Sometimes you want to provide format description in help message for argparse.add_argument, e.g. for comma-separated key/value set "--flag key1=value1,key2=value2". At this moment there is no format specifier for flag or name of arguments.
I propose add new %(flag)s specifier for help strings, see example.py

----------
components: Library (Lib)
files: example.py
messages: 325788
nosy: helmsman helmsman
priority: normal
severity: normal
status: open
title: New %(flag)s format specifier for argparse.add_argument help string
type: enhancement
Added file: https://bugs.python.org/file47815/example.py

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

From report at bugs.python.org  Wed Sep 19 18:41:00 2018
From: report at bugs.python.org (Alexander Mohr)
Date: Wed, 19 Sep 2018 22:41:00 +0000
Subject: [New-bugs-announce] [issue34745] asyncio ssl memory leak
Message-ID: <1537396860.59.0.956365154283.issue34745@psf.upfronthosting.co.za>


New submission from Alexander Mohr <thehesiod at gmail.com>:

I've been trying to track down a leak in aiohttp: https://github.com/aio-libs/aiohttp/issues/3010

it seems like this leak now occurs with raw asyncio SSL sockets.

when the gist script is run like so: python3.7 `which mprof` run --interval=1 ~/dev/test_leak.py -test asyncio_test

it slowly leaks memory.  This is effectively doing the following:

URLS = {
    'https://s3.us-west-2.amazonaws.com/archpi.dabase.com/style.css': {
        'method': 'get',
        'headers': {'User-Agent': 'Botocore/1.8.21 Python/3.6.4 Darwin/17.5.0', 'X-Amz-Date': '20180518T025044Z', 'X-Amz-Content-SHA256': 'e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855', 'Authorization': f'AWS4-HMAC-SHA256 Credential={CREDENTIAL}/20180518/us-west-2/s3/aws4_request, SignedHeaders=host;x-amz-content-sha256;x-amz-date, Signature=ae552641b9aa9a7a267fcb4e36960cd5863e55d91c9b45fd39b30fdcd2e81489', 'Accept-Encoding': 'identity'}
    },

    'https://s3.ap-southeast-1.amazonaws.com/archpi.dabase.com/doesnotexist': {
        'method': 'GET' if sys.argv[1] == 'get_object' else 'HEAD',
        'headers': {'User-Agent': 'Botocore/1.8.21 Python/3.6.4 Darwin/17.5.0', 'X-Amz-Date': '20180518T025221Z', 'X-Amz-Content-SHA256': 'e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855', 'Authorization': f'AWS4-HMAC-SHA256 Credential={CREDENTIAL}/20180518/ap-southeast-1/s3/aws4_request, SignedHeaders=host;x-amz-content-sha256;x-amz-date, Signature=7a7675ef6d70cb647ed59e02d532ffa80d437fb03976d8246ea9ef102d118794', 'Accept-Encoding': 'identity'}
    }
}


class HttpClient(asyncio.streams.FlowControlMixin):
    transport = None

    def __init__(self, *args, **kwargs):
        self.__url = kwargs.pop('url')
        self.__logger = logging.getLogger()
        super().__init__()

    def connection_made(self, transport):
        self.transport = transport

        url_parts = urlparse(self.__url)
        entry = URLS[self.__url]

        body = f'{entry["method"]} {url_parts.path} HTTP/1.1\r\nAccept: */*\r\nHost: {url_parts.hostname}\r\n'
        for name, value in entry['headers'].items():
            body += f'{name}: {value}\r\n'

        body += '\r\n'
        self.transport.write(body.encode('ascii'))
        self.__logger.info(f'data sent: {body}')

    def data_received(self, data):
        self.__logger.info(f'data received: {data}')

        self.transport.close()
        # asyncio.get_event_loop().call_later(1.0, )

    def eof_received(self):
        self.__logger.info('eof_received')

    def connection_lost(self, exc):
        self.__logger.info(f'connection lost: {exc}')
        super().connection_lost(exc)

    @classmethod
    def create_factory(cls, url: str):
        def factory(*args, **kwargs):
            return cls(*args, url=url, **kwargs)

        return factory


async def test_asyncio(ssl_context):
    loop = asyncio.get_event_loop()

    url = 'https://s3.ap-southeast-1.amazonaws.com/archpi.dabase.com/doesnotexist'
    url_parts = urlparse(url)
    port = url_parts.port or (80 if url_parts.scheme == 'http' else 443)
    infos = await loop.getaddrinfo(url_parts.hostname, port, family=socket.AF_INET)
    family, type, proto, canonname, sockaddr = infos[0]
    await loop.create_connection(HttpClient.create_factory(url), sockaddr[0], port, ssl=ssl_context, family=family, proto=proto, flags=socket.AI_NUMERICHOST, server_hostname=url_parts.hostname, local_addr=None)


async def asyncio_test():
    ssl_context = ssl.create_default_context()

    while True:
        await test_asyncio(ssl_context)


await asyncio_test()

----------
components: asyncio
messages: 325811
nosy: asvetlov, thehesiod, yselivanov
priority: normal
severity: normal
status: open
title: asyncio ssl memory leak
type: resource usage
versions: Python 3.7

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

From report at bugs.python.org  Thu Sep 20 00:55:09 2018
From: report at bugs.python.org (lanzhiwang)
Date: Thu, 20 Sep 2018 04:55:09 +0000
Subject: [New-bugs-announce] [issue34746] Asyncio documentation have a error
Message-ID: <1537419309.05.0.956365154283.issue34746@psf.upfronthosting.co.za>


New submission from lanzhiwang <hzhilamp at 163.com>:

https://docs.python.org/3.7/library/asyncio-llapi-index.html

loop.stop() Close the event loop.
fix
loop.close() Close the event loop.

----------
components: asyncio
messages: 325838
nosy: asvetlov, docs at python, hzhilamp at 163.com, yselivanov
priority: normal
severity: normal
status: open
title: Asyncio documentation have a error
type: enhancement
versions: Python 3.7

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

From report at bugs.python.org  Thu Sep 20 03:39:05 2018
From: report at bugs.python.org (Vincent Pelletier)
Date: Thu, 20 Sep 2018 07:39:05 +0000
Subject: [New-bugs-announce] [issue34747] SSLSocket.context cannot be
 changed on non-connected sockets
Message-ID: <1537429145.63.0.956365154283.issue34747@psf.upfronthosting.co.za>


New submission from Vincent Pelletier <vincent at nexedi.com>:

>From ssl.py, both on 2.7.15 and 3.6.6:
class SSLSocket(...):
...
    @context.setter
    def context(self, ctx):
        self._context = ctx
        self._sslobj.context = ctx

_sslobj is only set when socket is connected. While this is not a big issue for client sockets as user could just wrap the socket with correct context to begin with, and not a big issue for server sockets for the same reason, it is an issue for listening sockets: they are never connected, by definition, and do not care about _sslobj: upon accept() they only use self._context to wrap created socket.

Suggested fix:
    @context.setter
    def context(self, ctx):
        self._context = ctx
        if self._sslobj:
            self._sslobj.context = ctx
(consistently with how _sslobj is evaluated as a boolean elsewhere in the same class)

Suggested workaround (ex: if this fix is not backported to 2.7):
    try:
        ssl_socket.context = new_context
    except AttributeError:
        pass
as _context is changed first, and it's all that matters.

----------
messages: 325847
nosy: vincent-nexedi
priority: normal
severity: normal
status: open
title: SSLSocket.context cannot be changed on non-connected sockets
type: behavior
versions: Python 2.7, Python 3.6

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

From report at bugs.python.org  Thu Sep 20 07:25:13 2018
From: report at bugs.python.org (xitop)
Date: Thu, 20 Sep 2018 11:25:13 +0000
Subject: [New-bugs-announce] [issue34748] Incorrect HTML link in
 functools.partial
Message-ID: <1537442713.28.0.956365154283.issue34748@psf.upfronthosting.co.za>


New submission from xitop <reg.bugs at poti.sk>:

There is a minor issue regarding the page https://docs.python.org/3/library/functools.html

The description of functools.partial starts with text "Return a new partial object" which contains a link. This link does not point to the partial object (#partial-objects anchor) as it should. It points back
to the partial function (#functools.partial anchor) which is not helpful. The partial object docs can be thus easily overseen.

----------
assignee: docs at python
components: Documentation
messages: 325856
nosy: docs at python, xitop
priority: normal
severity: normal
status: open
title: Incorrect HTML link in functools.partial
versions: Python 3.7

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

From report at bugs.python.org  Thu Sep 20 07:45:10 2018
From: report at bugs.python.org (Sergey Fedoseev)
Date: Thu, 20 Sep 2018 11:45:10 +0000
Subject: [New-bugs-announce] [issue34749] improve performance of
 binascii.a2b_base64()
Message-ID: <1537443910.98.0.956365154283.issue34749@psf.upfronthosting.co.za>


New submission from Sergey Fedoseev <fedoseev.sergey at gmail.com>:

I reworked implementation of binascii.a2b_base64() and there is significant speedup:

$ python -m perf timeit --compare-to ~/tmp/cpython-master-venv/bin/python -s "from binascii import b2a_base64, a2b_base64; s = b2a_base64(1000 * b'b')" "a2b_base64(s)"
/home/sergey/tmp/cpython-master-venv/bin/python: ..................... 3.43 us +- 0.01 us
/home/sergey/tmp/cpython-dev-venv/bin/python: ..................... 1.52 us +- 0.01 us
Mean +- std dev: [/home/sergey/tmp/cpython-master-venv/bin/python] 3.43 us +- 0.01 us -> [/home/sergey/tmp/cpython-dev-venv/bin/python] 1.52 us +- 0.01 us: 2.26x faster (-56%)

$ python -m perf timeit --compare-to ~/tmp/cpython-master-venv/bin/python -s "from binascii import b2a_base64, a2b_base64; s = b2a_base64(1 * b'b')" "a2b_base64(s)"
/home/sergey/tmp/cpython-master-venv/bin/python: ..................... 76.0 ns +- 0.2 ns
/home/sergey/tmp/cpython-dev-venv/bin/python: ..................... 69.2 ns +- 0.1 ns
Mean +- std dev: [/home/sergey/tmp/cpython-master-venv/bin/python] 76.0 ns +- 0.2 ns -> [/home/sergey/tmp/cpython-dev-venv/bin/python] 69.2 ns +- 0.1 ns: 1.10x faster (-9%)

----------
components: Extension Modules
messages: 325860
nosy: sir-sigurd
priority: normal
severity: normal
status: open
title: improve performance of binascii.a2b_base64()
type: performance
versions: Python 3.8

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

From report at bugs.python.org  Thu Sep 20 08:39:23 2018
From: report at bugs.python.org (Antony Lee)
Date: Thu, 20 Sep 2018 12:39:23 +0000
Subject: [New-bugs-announce] [issue34750] locals().update doesn't work in
 Enum body, even though direct assignment to locals() does
Message-ID: <1537447163.92.0.956365154283.issue34750@psf.upfronthosting.co.za>


New submission from Antony Lee <anntzer.lee at gmail.com>:

A quick check suggests that enum entries can be programmatically created by assigning to locals() in the Enum body:

   class E(Enum): locals()["a"] = 1
   E.a  # -> <E.a: 'a'>

However, using locals().update(...) doesn't, and silently does the wrong thing:

   class E(Enum): locals().update({"a": "a"})
   E.a  # -> 'a'

(Yes, in this simple case, I could just use the functional API (`E = Enum("E", [("a", "a")])`), but the above is simpler if I also want e.g. to define methods for the Enum.

----------
components: Library (Lib)
messages: 325864
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: locals().update doesn't work in Enum body, even though direct assignment to locals() does
versions: Python 3.7

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

From report at bugs.python.org  Thu Sep 20 09:27:27 2018
From: report at bugs.python.org (Jeroen Demeyer)
Date: Thu, 20 Sep 2018 13:27:27 +0000
Subject: [New-bugs-announce] [issue34751] Hash collisions for tuples
Message-ID: <1537450047.43.0.956365154283.issue34751@psf.upfronthosting.co.za>


New submission from Jeroen Demeyer <J.Demeyer at UGent.be>:

It's not hard to come up with a hash collision for tuples:

>>> hash( (1,0,0) )
2528505496374819208
>>> hash( (1,-2,-2) )
2528505496374819208

The underlying reason is that the hashing code mixes ^ and *. This can create collisions because, for odd x, we have x ^ (-2) == -x and this minus operation commutes with multiplication.

This can be fixed by replacing ^ with +. On top of that, the hashing code for tuples looks needlessly complicated. A simple Bernstein hash suffices.

----------
messages: 325870
nosy: jdemeyer
priority: normal
severity: normal
status: open
title: Hash collisions for tuples

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

From report at bugs.python.org  Thu Sep 20 10:15:37 2018
From: report at bugs.python.org (Nicholas Parslow)
Date: Thu, 20 Sep 2018 14:15:37 +0000
Subject: [New-bugs-announce] [issue34752] warnings.warn fails silently with
 unicode input
Message-ID: <1537452937.66.0.956365154283.issue34752@psf.upfronthosting.co.za>


New submission from Nicholas Parslow <nick.parslow at soapboxlabs.com>:

example:

Python 2.7.14 |Anaconda, Inc.| (default, Dec  7 2017, 17:05:42) 
[GCC 7.2.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import warnings
>>> warnings.warn(u'bl?')
>>> warnings.warn('blah')
__main__:1: UserWarning: blah

the warnings.warn_explicit function seems to be the part that is failing. On a machine which doesn't use anaconda it fails in an identical manner.

if you do:
>>> with warnings.catch_warnings(record=True) as w:
...   warnings.warn(u'bl?')
... 
>>> w
[<warnings.WarningMessage object at 0x7ffadb35b190>]
>>> w[0].message
UserWarning(u'bl\xe9',)


I can get that it fails with unicode (though it's annoying) but the silent fail is really bad imo.

----------
components: Extension Modules
messages: 325880
nosy: nparslow
priority: normal
severity: normal
status: open
title: warnings.warn fails silently with unicode input
versions: Python 2.7

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

From report at bugs.python.org  Thu Sep 20 11:22:10 2018
From: report at bugs.python.org (Windson Yang)
Date: Thu, 20 Sep 2018 15:22:10 +0000
Subject: [New-bugs-announce] [issue34753] Use coroutine object or coroutine
 function instead of coroutine
Message-ID: <1537456930.09.0.956365154283.issue34753@psf.upfronthosting.co.za>


New submission from Windson Yang <wiwindson at gmail.com>:

A PR https://github.com/python/cpython/pull/9408 solved an ambiguous problem about coroutine. Which led me to https://docs.python.org/3/library/asyncio-task.html#awaitables

> Note that in this documentation the term ?coroutine? can be used for two closely related concepts:

> a coroutine function: an async def function;
> a coroutine object: object returned by calling a coroutine function.

This will let people confused. IMO we should use `coroutine object` or `coroutine function` instead of coroutine when it means an object. For instance, L22 in https://github.com/python/cpython/blob/471503954a91d86cf04228c38134108c67a263b0/Doc/library/asyncio-api-index.rst

> Create event loop, run a coroutine, close the loop.
should be
> Create event loop, run a coroutine object, close the loop.

----------
assignee: docs at python
components: Documentation
messages: 325886
nosy: Windson Yang, docs at python
priority: normal
severity: normal
status: open
title: Use coroutine object or coroutine function instead of coroutine
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Thu Sep 20 11:43:30 2018
From: report at bugs.python.org (Berker Peksag)
Date: Thu, 20 Sep 2018 15:43:30 +0000
Subject: [New-bugs-announce] [issue34754] test_flush_return_value fails on
 FreeBSD
Message-ID: <1537458210.16.0.956365154283.issue34754@psf.upfronthosting.co.za>


New submission from Berker Peksag <berker.peksag at gmail.com>:

======================================================================
FAIL: test_flush_return_value (test.test_mmap.MmapTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/buildbot/python/3.x.koobs-freebsd10/build/Lib/test/test_mmap.py", line 754, in test_flush_return_value
    self.assertRaises(OSError, mm.flush, 1, len(b'python'))
AssertionError: OSError not raised by flush

I think I was relying on the behavior of Linux in that assert, it might be better to run that assert only under Linux.

----------
assignee: berker.peksag
components: Tests
messages: 325890
nosy: berker.peksag, koobs
priority: normal
severity: normal
stage: needs patch
status: open
title: test_flush_return_value fails on FreeBSD
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Thu Sep 20 12:50:56 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 20 Sep 2018 16:50:56 +0000
Subject: [New-bugs-announce] [issue34755] Few minor optimizations in
 _asynciomodule.c
Message-ID: <1537462256.95.0.956365154283.issue34755@psf.upfronthosting.co.za>


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

* Perform cheap comparison with None before expensive checks in task_step_impl().
* Use more efficient private API for getting and setting an optional attribute.
* Use PyGen_Check() instead of inspect.isgenerator().
* Use faster and more idiomatic way of getting the name of the type.

----------
messages: 325902
nosy: asvetlov, serhiy.storchaka, yselivanov
priority: normal
severity: normal
status: open
title: Few minor optimizations in _asynciomodule.c
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Thu Sep 20 13:33:39 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 20 Sep 2018 17:33:39 +0000
Subject: [New-bugs-announce] [issue34756] Few changes in sys.breakpointhook()
Message-ID: <1537464819.33.0.956365154283.issue34756@psf.upfronthosting.co.za>


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

The proposed PR makes the following changes in sys.breakpointhook():

* Use _PyObject_GetBuiltin() for getting a builtin. This simplifies the code.

* The only effect of using the "from" list is when the imported name is a submodule. But it should be a callable. Callable module is very rare bird, I don't think we need to support such weird case. Removing the "from" list simplifies the code.

* Only ImportError and AttributeError raised from import are ignored. Other errors are exposed to the user as is. This is most likely a KeyboardInterrupt or MemoryError. They shouldn't be silenced.

sys.breakpointhook() was added in issue31353.

----------
components: Interpreter Core
messages: 325914
nosy: barry, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Few changes in sys.breakpointhook()
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Thu Sep 20 14:11:35 2018
From: report at bugs.python.org (Michael Felt)
Date: Thu, 20 Sep 2018 18:11:35 +0000
Subject: [New-bugs-announce] [issue34757] Placeholder for discussion on
 Combined patches for AIX - to resolve failig tests
Message-ID: <1537467095.33.0.956365154283.issue34757@psf.upfronthosting.co.za>


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

One PR to Rule them all :p

----------
components: Tests
messages: 325918
nosy: Michael.Felt
priority: normal
severity: normal
status: open
title: Placeholder for discussion on Combined patches for AIX - to resolve failig tests
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Thu Sep 20 20:09:24 2018
From: report at bugs.python.org (Travis O'Neill)
Date: Fri, 21 Sep 2018 00:09:24 +0000
Subject: [New-bugs-announce] [issue34758] http.server module sets incorrect
 mimetype for WebAssembly files
Message-ID: <1537488564.12.0.956365154283.issue34758@psf.upfronthosting.co.za>


New submission from Travis O'Neill <travis.h.oneill at gmail.com>:

Mimetype is set to application/octet-stream for .wasm files instead of the correct application/wasm.  This causes streaming compile feature to fail (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WebAssembly/instantiateStreaming).

----------
components: Library (Lib)
messages: 325935
nosy: Travis O'Neill
priority: normal
severity: normal
status: open
title: http.server module sets incorrect mimetype for WebAssembly files
versions: Python 3.7

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

From report at bugs.python.org  Thu Sep 20 22:05:23 2018
From: report at bugs.python.org (Nathaniel Smith)
Date: Fri, 21 Sep 2018 02:05:23 +0000
Subject: [New-bugs-announce] [issue34759] Possible regression in ssl module
 in 3.7.1 and master
Message-ID: <1537495523.32.0.956365154283.issue34759@psf.upfronthosting.co.za>


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

Hey Ned, we just noticed that since a few days ago the trio testsuite is failing on 3.7-dev (but not 3.7.0), in a test checking an obscure feature in the ssl module: https://travis-ci.org/python-trio/trio/builds/431291929

And I just reproduced the issue locally with a build of the 3.7 branch HEAD, so somehow whatever is happening is definitely new in 3.7.1.

It could just be a bug in the test or something, I don't know because I haven't debugged it yet (I'll do that now). But with 3.7.1rc1 imminent I figured you'd rather know earlier rather than later.

----------
assignee: christian.heimes
components: SSL
keywords: 3.7regression
messages: 325940
nosy: christian.heimes, ned.deily, njs
priority: normal
severity: normal
status: open
title: Possible regression in ssl module in 3.7.1 and master
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Fri Sep 21 04:28:36 2018
From: report at bugs.python.org (Christoph Glaubitz)
Date: Fri, 21 Sep 2018 08:28:36 +0000
Subject: [New-bugs-announce] [issue34760] Regression in abc in combination
 with issubclass
Message-ID: <1537518516.08.0.956365154283.issue34760@psf.upfronthosting.co.za>


New submission from Christoph Glaubitz <chris+lp at chrigl.de>:

I'm not sure if this is a bug, or a known breaking change. I didn't find anything related in the changelog, except for a rewrite of abc. But hovever, I want this to be documented.

In 3.7.0:

import abc
def f():
    pass

class A(metaclass=abc.ABCMeta):
    pass

issubclass(f, A)

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python3.7/abc.py", line 143, in __subclasscheck__
    return _abc_subclasscheck(cls, subclass)
TypeError: issubclass() arg 1 must be a class


python up to 3.6 (including 2.7) happily return false.

Found real world usage in osc-lib
* https://github.com/openstack/osc-lib/blob/46e2fb0a58fc06cfce1bb535f432405767d6b78b/osc_lib/utils/__init__.py#L495
* https://storyboard.openstack.org/#!/story/2003322

----------
messages: 325975
nosy: glaubich
priority: normal
severity: normal
status: open
title: Regression in abc in combination with issubclass
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Fri Sep 21 04:37:47 2018
From: report at bugs.python.org (Guillaume Dominici)
Date: Fri, 21 Sep 2018 08:37:47 +0000
Subject: [New-bugs-announce] [issue34761] str(super()) != super().__str__()
Message-ID: <1537519067.65.0.956365154283.issue34761@psf.upfronthosting.co.za>


New submission from Guillaume Dominici <guillaumedominici at gmail.com>:

The super proxy does not seem to forward call to .__str__() when the call occurs via str() function.
It may be an expected behavior, but it looks unexpected to me.

Minimal reproduction (tested on Python 3.6, but I believe may newer versions have similar behavior):

class Parent():
  def __str__(self):
    return "Parent"

class Child(Parent):
  def foo(self):
    s = super(Child, self)
    print(s.__str__())
    print(str(s))


c = Child()
c.foo()

# Output :
### Parent
### <super: <class 'Child'>, <Child object>>

----------
messages: 325976
nosy: Guillaume Dominici
priority: normal
severity: normal
status: open
title: str(super()) != super().__str__()
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Fri Sep 21 11:06:32 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 21 Sep 2018 15:06:32 +0000
Subject: [New-bugs-announce] [issue34762] Change contextvars C API to use
 PyObject
Message-ID: <1537542392.41.0.956365154283.issue34762@psf.upfronthosting.co.za>


New submission from Yury Selivanov <yselivanov at gmail.com>:

Unfortunately, the current C API for PEP 567 has a flaw: it uses non-PyObject pointers.  

This causes problems with integrating with tools like Cython, where PyObject is special and a lot of machinery recognizes it and manages refcounts correctly.

It also goes against the recent push to improve C API; one of the things we want to fix is to eliminate non-PyObject pointer types from public APIs entirely.

Because this C API is new (landed in 3.7.0) I think it might make sense to change it in 3.7.1.  I *think* this is a relatively safe (albeit annoying) change:

1. I don't expect that a lot of people use this new C API.  I googled recently if anyone uses contextvars at all, and found that some people are using the Python API.  The only user of C API that I'm aware of is uvloop, which I'll be happy to fix.

2. My current understanding is that this change won't break existing extensions compiled against Python 3.7.0, as it's just a change in pointers' types.

3. For example, clang spits out the following *warning* if it sees mismatched pointer types (and still compiles the extension):

   warning: incompatible pointer types passing 'PyContextVar *' (aka
      'struct _pycontextvarobject *') to parameter of type 'PyObject *' (aka 'struct _object *')
      [-Wincompatible-pointer-types]

4. This would make it slightly harder to create extension that supports both 3.7.0 and 3.7.1 and compiles without warnings.  (It's possible to avoid warnings by adding some #ifdefs macro).

If we don't change this API now, we'll likely have to either live with it, or face a very slow deprecation period.

----------
components: Interpreter Core
messages: 325989
nosy: ned.deily, yselivanov
priority: normal
severity: normal
status: open
title: Change contextvars C API to use PyObject
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Fri Sep 21 11:30:20 2018
From: report at bugs.python.org (=?utf-8?b?6I2J5pyo5bu6?=)
Date: Fri, 21 Sep 2018 15:30:20 +0000
Subject: [New-bugs-announce] [issue34763] Python lacks 0x4E17
Message-ID: <1537543820.35.0.956365154283.issue34763@psf.upfronthosting.co.za>


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

This is very easy issue.

? meanning is 30.(? is 0x4E17)
"?".isnumeric() must returns true.
but "?".isnumeric()  returns  False.

----------
components: Unicode
messages: 325992
nosy: ezio.melotti, vstinner, ???
priority: normal
severity: normal
status: open
title: Python lacks 0x4E17
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Fri Sep 21 11:41:31 2018
From: report at bugs.python.org (ChrisRands)
Date: Fri, 21 Sep 2018 15:41:31 +0000
Subject: [New-bugs-announce] [issue34764] Improve documentation example for
 using iter() with sentinel value
Message-ID: <1537544491.72.0.956365154283.issue34764@psf.upfronthosting.co.za>


New submission from ChrisRands <chrisrands0 at gmail.com>:

This arose from this SO question: https://stackoverflow.com/questions/52446415/line-in-iterfp-readline-rather-than-line-in-fp 

The example given in the docs:

with open('mydata.txt') as fp:
    for line in iter(fp.readline, ''):
        process_line(line)

Is exactly equivalent to the following because an empty string is only returned by readline at the EOF:

with open('mydata.txt') as fp:
    for line in fp:
        process_line(line)

The empty string '' sentinel value could be changed to another value to provide a possibly more meaningful example where the 2nd code snippet would not always produce the same result?

----------
assignee: docs at python
components: Documentation
messages: 325995
nosy: ChrisRands, docs at python
priority: normal
severity: normal
status: open
title: Improve documentation example for using iter() with sentinel value

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

From report at bugs.python.org  Fri Sep 21 11:47:07 2018
From: report at bugs.python.org (Charalampos Stratakis)
Date: Fri, 21 Sep 2018 15:47:07 +0000
Subject: [New-bugs-announce] [issue34765] Update install-sh
Message-ID: <1537544827.56.0.956365154283.issue34765@psf.upfronthosting.co.za>


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

The install-sh file that python uses for autotools is horribly outdated. Last update was 16 years ago and it's being copied from automake's source code.

Updating it to modern standards could potentially fix issues for systems that use autotools, but it has the downside of having some backwards incompatible changes e.g. [0][1] (or you can search at their NEWS file [2]) which could break some previous applied workarounds.

As things stand, there is no bug at the moment and autotools just work so would a PR for updating install-sh to a newer version be considered? 

[0] http://git.savannah.gnu.org/cgit/automake.git/commit/lib/install-sh?id=84a98180dd37a32891800fb9aafdf685bab74252
[1] http://git.savannah.gnu.org/cgit/automake.git/commit/lib/install-sh?id=bd44db1abdeea3643ba0387de24af7539da644e4
[2] http://git.savannah.gnu.org/cgit/automake.git/tree/NEWS

----------
components: Build
messages: 325996
nosy: cstratak
priority: normal
severity: normal
status: open
title: Update install-sh
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Fri Sep 21 11:48:45 2018
From: report at bugs.python.org (Yongnan Wu)
Date: Fri, 21 Sep 2018 15:48:45 +0000
Subject: [New-bugs-announce] [issue34766] BaseProxy cache should be cleaned
 when Manager client is reconnected
Message-ID: <1537544925.1.0.956365154283.issue34766@psf.upfronthosting.co.za>


Change by Yongnan Wu <wynfred at yeah.net>:


----------
components: Library (Lib)
nosy: wynfred
priority: normal
severity: normal
status: open
title: BaseProxy cache should be cleaned when Manager client is reconnected
type: behavior
versions: Python 2.7, Python 3.6, Python 3.7

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

From report at bugs.python.org  Fri Sep 21 11:54:44 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Fri, 21 Sep 2018 15:54:44 +0000
Subject: [New-bugs-announce] [issue34767] Optimize asyncio.Lock
Message-ID: <1537545284.93.0.956365154283.issue34767@psf.upfronthosting.co.za>


New submission from Yury Selivanov <yselivanov at gmail.com>:

There's no point in always creating a deque() for waiters in Lock.__init__.  Not all locks end up using waiters.

----------
components: asyncio
messages: 325997
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Optimize asyncio.Lock
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Fri Sep 21 15:26:19 2018
From: report at bugs.python.org (Benito Kestelman)
Date: Fri, 21 Sep 2018 19:26:19 +0000
Subject: [New-bugs-announce] [issue34768] Add documentation for the purpose
 of __init__.py in packages
Message-ID: <1537557979.62.0.956365154283.issue34768@psf.upfronthosting.co.za>


New submission from Benito Kestelman <beni.kestel001 at gmail.com>:

I just learned how to make my own package in python and upload it to pypi. I mainly used the documentation here: https://packaging.python.org/tutorials/packaging-projects/

Other than the toy example, there is no explanation of __init__.py, its purpose, or what I should put in it to get my code to work. 

It took me a lot of time and guessing to figure it out, and I had to look at several projects on Github to see how others did it. I found a couple that looked correct because they were concise, but others looked horrendous - one was several thousand lines long. 

A clear explanation of how to use __init__.py when making a package would be extremely helpful.

----------
assignee: docs at python
components: Documentation
messages: 326020
nosy: bkestelman, docs at python
priority: normal
severity: normal
status: open
title: Add documentation for the purpose of __init__.py in packages

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

From report at bugs.python.org  Sat Sep 22 10:39:44 2018
From: report at bugs.python.org (twisteroid ambassador)
Date: Sat, 22 Sep 2018 14:39:44 +0000
Subject: [New-bugs-announce] [issue34769] _asyncgen_finalizer_hook running
 in wrong thread
Message-ID: <1537627184.81.0.956365154283.issue34769@psf.upfronthosting.co.za>


New submission from twisteroid ambassador <twisteroid.ambassador at gmail.com>:

When testing my happy eyeballs library, I occasionally run into issues with async generators seemingly not finalizing. After setting loop.set_debug(True), I have been seeing log entries like these:


Exception ignored in: <async_generator object builtin_resolver at 0x7fca945c8158>
Traceback (most recent call last):
  File "/opt/Python3.7.0/lib/python3.7/asyncio/base_events.py", line 466, in _asyncgen_finalizer_hook
    self.create_task(agen.aclose())
  File "/opt/Python3.7.0/lib/python3.7/asyncio/base_events.py", line 386, in create_task
    task = tasks.Task(coro, loop=self)
  File "/opt/Python3.7.0/lib/python3.7/asyncio/base_events.py", line 674, in call_soon
    self._check_thread()
  File "/opt/Python3.7.0/lib/python3.7/asyncio/base_events.py", line 712, in _check_thread
    "Non-thread-safe operation invoked on an event loop other "
RuntimeError: Non-thread-safe operation invoked on an event loop other than the current one
ERROR    asyncio Task was destroyed but it is pending!
source_traceback: Object created at (most recent call last):
  File "/opt/Python3.7.0/lib/python3.7/threading.py", line 885, in _bootstrap
    self._bootstrap_inner()
  File "/opt/Python3.7.0/lib/python3.7/threading.py", line 917, in _bootstrap_inner
    self.run()
  File "/opt/Python3.7.0/lib/python3.7/threading.py", line 865, in run
    self._target(*self._args, **self._kwargs)
  File "/opt/Python3.7.0/lib/python3.7/concurrent/futures/thread.py", line 80, in _worker
    work_item.run()
  File "/opt/Python3.7.0/lib/python3.7/concurrent/futures/thread.py", line 57, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/opt/Python3.7.0/lib/python3.7/asyncio/base_events.py", line 746, in _getaddrinfo_debug
    msg.append(f'type={type!r}')
  File "/opt/Python3.7.0/lib/python3.7/enum.py", line 572, in __repr__
    self.__class__.__name__, self._name_, self._value_)
  File "/opt/Python3.7.0/lib/python3.7/asyncio/base_events.py", line 466, in _asyncgen_finalizer_hook
    self.create_task(agen.aclose())
  File "/opt/Python3.7.0/lib/python3.7/asyncio/base_events.py", line 386, in create_task
    task = tasks.Task(coro, loop=self)
task: <Task pending coro=<<async_generator_athrow without __name__>()> created at /opt/Python3.7.0/lib/python3.7/asyncio/base_events.py:386>



This is a typical instance. Usually several instances like this occur at once.

I'll try to reproduce these errors in a simple program. Meanwhile, here are some details about the actual program, which may or may not be related to the errors:

* I have several nested async generators (async for item in asyncgen: yield do_something(item); ), and when the errors appear, the above error messages and stack traces repeat several times, with the object names mentioned in "Exception ignored in: ..." being each of the nested async generators. Other parts of the error messages, including the stack traces, are exactly the same.

* I never used threads or loop.run_in_executor() explicitly in the program. However, the innermost async generator calls loop.getaddrinfo(), and that is implemented by running a Python function, socket.getaddrinfo(), with loop.run_in_executor(), so the program implicitly uses threads. (socket.getaddrinfo() is a Python function that calls a C function, _socket.getaddrinfo().)

* The outermost async generator is not iterated using `async for`. Instead, it is iterated by calling its `__aiter__` method, saving the returned async iterator object, and then awaiting on the `__anext__` method of the async iterator repeatedly. Of course, all of these are done in the same event loop.


Environment: Python 3.7.0 compiled from source, on Debian stretch.

----------
components: asyncio
messages: 326090
nosy: asvetlov, twisteroid ambassador, yselivanov
priority: normal
severity: normal
status: open
title: _asyncgen_finalizer_hook running in wrong thread
type: behavior
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Sat Sep 22 13:00:58 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Sat, 22 Sep 2018 17:00:58 +0000
Subject: [New-bugs-announce] [issue34770] pyshellext.cpp: Possible null
 pointer dereference
Message-ID: <1537635658.43.0.956365154283.issue34770@psf.upfronthosting.co.za>


New submission from Zackery Spytz <zspytz at gmail.com>:

The GlobalLock() call in UpdateDropDescription() is not checked for failure.

----------
messages: 326098
nosy: ZackerySpytz
priority: normal
severity: normal
status: open
title: pyshellext.cpp: Possible null pointer dereference
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Sat Sep 22 13:56:12 2018
From: report at bugs.python.org (Frank Schaefer)
Date: Sat, 22 Sep 2018 17:56:12 +0000
Subject: [New-bugs-announce] [issue34771] test_ctypes failing on Linux
 SPARC64
Message-ID: <1537638972.94.0.956365154283.issue34771@psf.upfronthosting.co.za>


New submission from Frank Schaefer <kelledin at gmail.com>:

Python 3.6.6 on Linux 4.16.18 SPARC64 fails test_ctypes.  Specifically, it appears to be due to the _testfunc_large_struct_update_value() or _testfunc_reg_struct_update_value():

0:00:44 load avg: 46.24 [137/407/1] test_ctypes failed -- running: test_socket (44 sec), test_subprocess (35 sec), test_venv (43 sec), test_normalization (43 sec), test_signal (43 sec), test_multiprocessing_spawn (43 sec), test_concurrent_futures (43 sec), test_email (34 sec), test_cmd_line_script (43 sec), test_tools (43 sec), test_pickletools (34 sec), test_zipfile (30 sec), test_multiprocessing_fork (33 sec), test_pyclbr (31 sec), test_math (42 sec), test_calendar (35 sec), test_datetime (33 sec), test_distutils (30 sec)
test test_ctypes failed -- Traceback (most recent call last):
  File "/usr/src/dist/new/Python-3.6.6/Lib/ctypes/test/test_structures.py", line 416, in test_pass_by_value
    self.assertEqual(s.first, 0xdeadbeef)
AssertionError: 195948557 != 3735928559

Obviously, the "0xbadf00d" field setting is propagating back up through something that's supposed to be passed-by-value, and the test case quite rightly picks up on it.  I suspect this bug exists in 2.7.15 as well (2.7 just doesn't have the testcase to catch it).
 
This is built with gcc-8.2.0, glibc-2.27, kernel 4.16.18, CFLAGS="-O1 -mcpu=v9 -mtune=v9".  (FYI I had to turn down optimization to resolve another test failure, hence the "-O1".)

I'm guessing SPARC64 calling conventions are still passing certain large values by reference, and libffi isn't dealing with this?  I'm still investigating.  I've tried it with and without --with-system-libffi, with no difference (my system libffi is 3.2.1).

----------
components: ctypes
messages: 326102
nosy: kelledin-3
priority: normal
severity: normal
status: open
title: test_ctypes failing on Linux SPARC64
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Sat Sep 22 16:13:10 2018
From: report at bugs.python.org (heiahh)
Date: Sat, 22 Sep 2018 20:13:10 +0000
Subject: [New-bugs-announce] [issue34772] Python will suddenly not plot
Message-ID: <1537647190.0.0.956365154283.issue34772@psf.upfronthosting.co.za>


New submission from heiahh <haldorn at gmail.com>:

Hi! I am experience a very strange behavior. As a student I've been using Spyder for my Python coding assignments. But some days ago I wanted to try out the Python environment in Visual Studio. So, I installed python environment in VS. But after that, none of even my simplest codes will produce any plots anymore. Even if I try the exact same code as I for sure know been showing a plot before. Initally I had a error message saying something like "mkl_aa_fw_init_workdivision...." + some more info and directory reference. So after some googling I deleted a mkl file in the directory witch was mentioned in the error message. After that there is no error message, but still no plot. If I try a simple test code like this:

import matplotlib.pyplot as plt
import numpy as np
x = np.linspace(0,5,11)
y = x**2
plt.plot(x,y)

The only thing happening is Ipython console says "Kernel died, restarting". Also in Visual Studio, there is no plot coming up.I have no idea about the cause and how to fix it, even after hours of search and trial. Really frustrating to use time on this instead of my assignments. The only difference befor, when it was working, and after, is that I tried the Visual Studio environment. I highly appreciate help on this issue!

----------
messages: 326112
nosy: heihaa
priority: normal
severity: normal
status: open
title: Python will suddenly not plot
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Sun Sep 23 01:13:20 2018
From: report at bugs.python.org (Shankar)
Date: Sun, 23 Sep 2018 05:13:20 +0000
Subject: [New-bugs-announce] [issue34773] sqlite3 module inconsistently
 returning only some rows from a table
Message-ID: <1537679600.14.0.956365154283.issue34773@psf.upfronthosting.co.za>


New submission from Shankar <shankargopal at myfastmail.com>:

I am running a Python based system on an Android phone. The database is in Sqlite3.  It has been running well for approximately five years now, with various upgraded phones, changes to the system, etc.

However, in the last week or so, there has been a problem in the system that is very peculiar.  One of the tables on the system is called "Invoices" and it currently has approximately 21,500 records in it.  However, reading the database from Python on the phone, using the sqlite3 module, will suddenly return only around 2,400 records.  If I copy the database over to a PC and open it in Python via Linux, the same thing will happen.  If I then open it with the command line `sqlite3` tool, the table will read correctly.  After that, it will start working correctly in Python as well.  If I copy the same database back to the phone, it will work correctly there as well - for approximately three or four hours (i.e., given the usual frequency of my program, about 90 - 120 reads / writes).  Then the problem will return.

I have changed phones in case this was a problem in the phone's memory, but that didn't help.  I have run `vacuum` on the sqlite3 database in question as well, to no avail.  There do not appear to be any other obvious errors in the database. 

What could be the reason for this behaviour?  

Below I've posted some of the code that I use to read the database.  Have cut out some extraneous stuff so you may see variables that are not defined etc. But I'm fairly sure it's not the code, as this same code has been running for years with no trouble.


    def sqlite_exec(sqlcommand, dbname, inserttable = "", insertstuff = None, returndict = 0, override_stop = False, returncheck = False, nojournal = False, onlyjournal = False):
        #...
        if sqlcommand == "insert":
            # Substitute single quotes with double quotes in input text to avoid sqlite syntax errors
            actual_command = "INSERT INTO {0} ({1}) VALUES ({2});".format(inserttable, ", ".join(insertstuff.keys()), ", ".join(["'" + re.sub("'",'"',valuetext) + "'" for valuetext in insertstuff.values()]))
        else:
            actual_command = sqlcommand
        conn = sqlite3.connect(dbname,timeout = 40.0,isolation_level=None, detect_types=sqlite3.PARSE_DECLTYPES)
        if returndict:
            # Using the sqlite module documentation example; this happens to be better suited for our purposes than the sqlite.Row object
            def dict_factory(cursor, row):
                d = dict((col[0],row[idx]) for idx,col in enumerate(cursor.description))
                return d
            conn.row_factory = dict_factory
        sqliteobj = conn.cursor()
        # ...
        if not onlyjournal:
            try:
                sqliteobj.execute(actual_command)
            # except...
        return sqliteobj

----------
components: Extension Modules
messages: 326132
nosy: shankargopal
priority: normal
severity: normal
status: open
title: sqlite3 module inconsistently returning only some rows from a table
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Sun Sep 23 01:34:58 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 23 Sep 2018 05:34:58 +0000
Subject: [New-bugs-announce] [issue34774] IDLE: use theme colors for help
 viewer
Message-ID: <1537680898.84.0.956365154283.issue34774@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Follow-up to #34548.  Use user-selected color theme for Help => IDLE Help.  (Patch coming.)

----------
messages: 326133
nosy: terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: IDLE: use theme colors for help viewer
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Sun Sep 23 03:02:08 2018
From: report at bugs.python.org (Roger Aiudi)
Date: Sun, 23 Sep 2018 07:02:08 +0000
Subject: [New-bugs-announce] [issue34775] pathlib.PurePath division raises
 TypeError instead of returning NotImplemented
Message-ID: <1537686128.89.0.956365154283.issue34775@psf.upfronthosting.co.za>


New submission from Roger Aiudi <aiudirog at gmail.com>:

PurePath.__truediv__ and __rtruediv__ raise a TypeError when passed something which is not an instance of string or PurePath. This prevents creating any sort of compatible class that doesn't inherit from the previously mentioned types.

----------
components: Library (Lib)
messages: 326140
nosy: Roger Aiudi
priority: normal
pull_requests: 8915
severity: normal
status: open
title: pathlib.PurePath division raises TypeError instead of returning NotImplemented
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/issue34775>
_______________________________________

From report at bugs.python.org  Sun Sep 23 06:45:29 2018
From: report at bugs.python.org (David Hagen)
Date: Sun, 23 Sep 2018 10:45:29 +0000
Subject: [New-bugs-announce] [issue34776] Postponed annotations break
 inspection of dataclasses
Message-ID: <1537699529.98.0.956365154283.issue34776@psf.upfronthosting.co.za>


New submission from David Hagen <david at drhagen.com>:

The new postponed annotations have an unexpected interaction with dataclasses. Namely, you cannot get the type hints of any of the data classes methods.

For example, I have some code that inspects the type parameters of a class's `__init__` method. (The real use case is to provide a default serializer for the class, but that is not important here.)  

```
from dataclasses import dataclass
from typing import get_type_hints

class Foo:
    pass

@dataclass
class Bar:
    foo: Foo

print(get_type_hints(Bar.__init__))
```

In Python 3.6 and 3.7, this does what is expected; it prints `{'foo': <class '__main__.Foo'>, 'return': <class 'NoneType'>}`.

However, if in Python 3.7, I add `from __future__ import annotations`, then this fails with an error:

```
NameError: name 'Foo' is not defined
```

I know why this is happening. The `__init__` method is defined in the `dataclasses` module which does not have the `Foo` object in its environment, and the `Foo` annotation is being passed to `dataclass` and attached to `__init__` as the string `"Foo"` rather than as the original object `Foo`, but `get_type_hints` for the new annotations only does a name lookup in the module where `__init__` is defined not where the annotation is defined.

I know that the use of lambdas to implement PEP 563 was rejected for performance reasons. I could be wrong, but I think this was motivated by variable annotations because the lambda would have to be constructed each time the function body ran. I was wondering if I could motivate storing the annotations as lambdas in class bodies and function signatures, in which the environment is already being captured and is code that usually only runs once.

Original mailing list discussion: https://mail.python.org/pipermail/python-dev/2018-September/155289.html

----------
messages: 326148
nosy: drhagen
priority: normal
severity: normal
status: open
title: Postponed annotations break inspection of dataclasses
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Sun Sep 23 12:07:48 2018
From: report at bugs.python.org (Jose Gama)
Date: Sun, 23 Sep 2018 16:07:48 +0000
Subject: [New-bugs-announce] [issue34777] urllib.request accepts anything as
 a header parameter for some URLs
Message-ID: <1537718868.74.0.956365154283.issue34777@psf.upfronthosting.co.za>


New submission from Jose Gama <josephgama at yahoo.com>:

It is possible to use urllib.request defining a header that can be junk in some cases and still get the contents without any warning or error.
The behavior depends on the URL and also on the header.

----------
components: IO
files: header-illegal.py
messages: 326162
nosy: tuxcell
priority: normal
severity: normal
status: open
title: urllib.request accepts anything as a header parameter for some URLs
type: behavior
versions: Python 3.6
Added file: https://bugs.python.org/file47819/header-illegal.py

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

From report at bugs.python.org  Sun Sep 23 13:51:38 2018
From: report at bugs.python.org (Laurent Gautier)
Date: Sun, 23 Sep 2018 17:51:38 +0000
Subject: [New-bugs-announce] [issue34778] Memoryview for column-major
 (f_contiguous) arrays from bytes impossible to achieve
Message-ID: <1537725098.47.0.956365154283.issue34778@psf.upfronthosting.co.za>


New submission from Laurent Gautier <lgautier at gmail.com>:

The buffer protocol is accounting for the row-major or column-major arrays, and that information is shown in the attributes, `c_contiguous` and `f_contiguous` respectively, of a memoryview object.

Using the method `cast` allows one to specify a shape but does not allow
to specify whether row or column major:

```
# column-major 3x2 array of bytes that was serialized
b = bytearray([1,2,3,4,5,6])

mv = memoryview(b)
mv_b = mv.cast('b', shape=(3,2))
```

The result object is believed to be row-major and little can be done
to correct it:


```
>>> mv_int.c_contiguous
True
>>> mv_int.c_contiguous = False
AttributeError: attribute 'c_contiguous' of 'memoryview' objects is not writable
```

----------
components: Interpreter Core
messages: 326167
nosy: lgautier
priority: normal
severity: normal
status: open
title: Memoryview for column-major (f_contiguous) arrays from bytes impossible to achieve
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/issue34778>
_______________________________________

From report at bugs.python.org  Sun Sep 23 14:39:03 2018
From: report at bugs.python.org (ppperry)
Date: Sun, 23 Sep 2018 18:39:03 +0000
Subject: [New-bugs-announce] [issue34779] IDLE internals show up in
 tracebacks when returning objects that cannot be `repr`ed
Message-ID: <1537727943.66.0.956365154283.issue34779@psf.upfronthosting.co.za>


New submission from ppperry <mapreader at olum.org>:

>>> class NoRepr:
	def __repr__(self):
		raise ValueError
>>> NoRepr()
Traceback (most recent call last):
  File "<pyshell#44>", line 1, in <module>
    NoRepr()
  File "C:\Program Files\Python37\lib\idlelib\rpc.py", line 617, in displayhook
    text = repr(value)
  File "<pyshell#43>", line 3, in __repr__
    raise ValueError
ValueError

What should happen in this case isn't exactly clear, but the current traceback is wrong in multiple ways.

----------
assignee: terry.reedy
components: IDLE
messages: 326172
nosy: ppperry, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE internals show up in tracebacks when returning objects that cannot be `repr`ed
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Sun Sep 23 16:00:35 2018
From: report at bugs.python.org (Alexey Izbyshev)
Date: Sun, 23 Sep 2018 20:00:35 +0000
Subject: [New-bugs-announce] [issue34780] Hang on startup if stdin refers to
 a pipe with an outstanding concurrent operation on Windows
Message-ID: <1537732835.69.0.956365154283.issue34780@psf.upfronthosting.co.za>


New submission from Alexey Izbyshev <izbyshev at ispras.ru>:

In the following code inspired by a production issue I had to debug recently subprocess.call() won't return:

import os
import subprocess
import sys
import time

r, w = os.pipe()
p1 = subprocess.Popen([sys.executable, '-c',
                       'import sys; sys.stdin.read()'],
                      stdin=r)

time.sleep(1)
subprocess.call([sys.executable, '-c', ''], stdin=r)

os.close(w)
p1.wait()

The underlying reason is the same as in #22976. Python performs certain operations on stdin during it's initialization (different in 2.7 and 3.x), which block because there is an outstanding ReadFile() on the pipe end stdin refers to. Assuming that subprocess.call() runs some app that doesn't use stdin at all, if a developer doesn't control how the app is run (which was my case), I don't see any way to workaround this in pure Python. (An obvious workaround is to make a wrapper which closes stdin or redirects it to something else, but this wrapper can't be run with CPython).

I propose to fix this in CPython. The details are slightly different for 2.7 and 3.x.

2.7 calls fstat(stdin) in dircheck() (Objects/fileobject.c). This hangs because msvcrt calls PeekNamedPipe() if stdin refers to a pipe. Ironically, this fstat() call is completely useless on Windows because msvcrt never sets S_IFDIR in st_mode (it can't distinguish between a file and a directory because it uses GetFileType() and doesn't perform extra checks). I've implemented a PR that skips dircheck() on Windows. (If we do want to add a proper dircheck() to 2.7, it should do something similar to 3.x).

3.x performs the dir check without relying on fstat(), but it also calls lseek() (in _buffered_init() (Modules/_io/bufferedio.c), if removed, there is another one in _io_TextIOWrapper___init___impl (Modules/_io/textio.c). mscvrt calls SetFilePointerEx(), which hangs too, which is somewhat surprising because its docs [1] say:

You cannot use the SetFilePointerEx function with a handle to a nonseeking device such as a pipe or a communications device.

The wording is unclear though -- it doesn't say what happens if I try. lseek() docs [2] contain the following:

On devices incapable of seeking (such as terminals and printers), the return value is undefined.

In practice, lseek() succeeds on pipes on Windows, but is nearly useless:

Python 3.7.0 (v3.7.0:1bf9cc5093, Jun 27 2018, 04:59:51) [MSC v.1914 64 bit (AMD64)] on win32
>>> import os
>>> r, w = os.pipe()
>>> os.write(w, b'xyz')
3
>>> os.lseek(r, 0, os.SEEK_CUR)
0
>>> os.lseek(r, 0, os.SEEK_END)
3
>>> os.lseek(r, 2, os.SEEK_SET)
2
>>> os.read(r, 1)
b'x'
>>> os.lseek(r, 0, os.SEEK_CUR)
2
>>> os.read(r, 1)
b'y'
>>> os.lseek(r, 0, os.SEEK_CUR)
2
>>> os.lseek(r, 0, os.SEEK_END)
1

So lseek() can be used to check the current pipe buffer size, and that seems about it. Given the above, I suggest two solutions for the hang on Windows:

1) Make lseek() fail on pipes on Windows, as it does on Unix. A number of projects have already done that:

https://referencesource.microsoft.com/#mscorlib/system/io/filestream.cs,1029
https://go.googlesource.com/go/+/ce58a39fca067a19c505220c0c907ccf32793427/src/syscall/syscall_windows.go#374
https://trac.ffmpeg.org/ticket/986 (workaround: https://lists.ffmpeg.org/pipermail/ffmpeg-cvslog/2012-June/051590.html)
https://github.com/erikd/libsndfile/blob/123cb9f9a5a356b951a23e9e2ab8527f967425cc/src/file_io.c#L266

2) Delay lseek() until it's really needed. In both cases (BufferedIO and TextIO), lseek() is used to set some cached fields, so ISTM it's not necessary to do it during initialization. This would also be an optimization (skip lseek() syscall until a user really wants to tell()/seek()). This can be done as a sole fix or can be combined with the above (as an optimization).

I'd like to hear other people's opinions before doing anything for Python 3.

[1] https://docs.microsoft.com/en-us/windows/desktop/api/fileapi/nf-fileapi-setfilepointerex
[2] https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/lseek-lseeki64

----------
components: IO, Windows
messages: 326175
nosy: eryksun, izbyshev, paul.moore, steve.dower, tim.golden, vstinner, zach.ware
priority: normal
severity: normal
status: open
title: Hang on startup if stdin refers to a pipe with an outstanding concurrent operation on Windows
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/issue34780>
_______________________________________

From report at bugs.python.org  Sun Sep 23 16:30:41 2018
From: report at bugs.python.org (=?utf-8?b?VG9tw6HFoSBCb3VkYQ==?=)
Date: Sun, 23 Sep 2018 20:30:41 +0000
Subject: [New-bugs-announce] [issue34781] infinite waiting in
 multiprocessing.Pool
Message-ID: <1537734641.75.0.956365154283.issue34781@psf.upfronthosting.co.za>


New submission from Tom?? Bouda <tomas.bouda at gmail.com>:

I have encountered a possible bug inside multiprocessing.Pool which behaves like race-condition while I don't believe it is a typical one.

Simply put, Pool from time to time freezes. It is occasional and hard to reproduce, but e.g. unit-tests running 3/day freeze several times a week.

We are using Pool heavily in our applications. Usually tens of workers and heavy load for each one of them. This production environment is using Python 2.7 (RHEL) and custom build, etc. However, I reproduced the same behavior in Python 3.6 (OSX) on my local machine.

When I run the following script like 20x, I get one or two frozen instances. You may notice in the output that ForkPoolWorker-42 never calls self.run(). The application than freezes as-is since it is probably waiting for the process.

It is easier to reproduce the behavior using debugger (PyCharm-Pro in my case), however, in our production environment there is just clean run, the bug occurs more often since multiprocessing is used quite a lot in there.

Thanks,
Tomas


--- My script:

import logging
from multiprocessing.pool import Pool
from multiprocessing.util import log_to_stderr

def f(i):
    print(i)

log_to_stderr(logging.DEBUG)

pool = Pool(50)
pool.map(f, range(2))
pool.close()
pool.join()

--- Output:

[DEBUG/MainProcess] created semlock with handle 9
[DEBUG/MainProcess] created semlock with handle 10
[DEBUG/MainProcess] created semlock with handle 13
[DEBUG/MainProcess] created semlock with handle 14
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-1] child process calling self.run()
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-2] child process calling self.run()
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-3] child process calling self.run()
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-4] child process calling self.run()
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-5] child process calling self.run()
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-6] child process calling self.run()
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-7] child process calling self.run()
[INFO/ForkPoolWorker-9] child process calling self.run()
[INFO/ForkPoolWorker-10] child process calling self.run()
[INFO/ForkPoolWorker-8] child process calling self.run()
[INFO/ForkPoolWorker-12] child process calling self.run()
[INFO/ForkPoolWorker-13] child process calling self.run()
[INFO/ForkPoolWorker-11] child process calling self.run()
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-14] child process calling self.run()
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-15] child process calling self.run()
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-16] child process calling self.run()
[INFO/ForkPoolWorker-17] child process calling self.run()
[INFO/ForkPoolWorker-18] child process calling self.run()
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-19] child process calling self.run()
[INFO/ForkPoolWorker-20] child process calling self.run()
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-21] child process calling self.run()
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-22] child process calling self.run()
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-23] child process calling self.run()
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-24] child process calling self.run()
[INFO/ForkPoolWorker-25] child process calling self.run()
[INFO/ForkPoolWorker-26] child process calling self.run()
[INFO/ForkPoolWorker-27] child process calling self.run()
[INFO/ForkPoolWorker-28] child process calling self.run()
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-29] child process calling self.run()
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-30] child process calling self.run()
[INFO/ForkPoolWorker-31] child process calling self.run()
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-32] child process calling self.run()
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-33] child process calling self.run()
[INFO/ForkPoolWorker-34] child process calling self.run()
[INFO/ForkPoolWorker-35] child process calling self.run()
[INFO/ForkPoolWorker-36] child process calling self.run()
[INFO/ForkPoolWorker-37] child process calling self.run()
[INFO/ForkPoolWorker-38] child process calling self.run()
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-39] child process calling self.run()
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-40] child process calling self.run()
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-41] child process calling self.run()
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-43] child process calling self.run()
[INFO/ForkPoolWorker-44] child process calling self.run()
[INFO/ForkPoolWorker-45] child process calling self.run()
[INFO/ForkPoolWorker-46] child process calling self.run()
[DEBUG/MainProcess] added worker
[INFO/ForkPoolWorker-47] child process calling self.run()
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
[DEBUG/MainProcess] added worker
0
1
[INFO/ForkPoolWorker-48] child process calling self.run()
[DEBUG/MainProcess] closing pool
[DEBUG/MainProcess] joining pool
[DEBUG/MainProcess] worker handler exiting
[DEBUG/MainProcess] task handler got sentinel
[DEBUG/MainProcess] task handler sending sentinel to result handler
[DEBUG/MainProcess] task handler sending sentinel to workers
[DEBUG/ForkPoolWorker-3] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-4] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-5] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-3] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-6] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-4] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-7] worker got sentinel -- exiting
[INFO/ForkPoolWorker-3] process shutting down
[DEBUG/ForkPoolWorker-5] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-10] worker got sentinel -- exiting
[INFO/ForkPoolWorker-4] process shutting down
[DEBUG/ForkPoolWorker-6] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-7] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-3] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-4] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-8] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-10] worker exiting after 0 tasks
[INFO/ForkPoolWorker-5] process shutting down
[INFO/ForkPoolWorker-7] process shutting down
[INFO/ForkPoolWorker-6] process shutting down
[DEBUG/ForkPoolWorker-3] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-8] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-4] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-7] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-6] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-5] running all "atexit" finalizers with priority >= 0
[INFO/ForkPoolWorker-10] process shutting down
[INFO/ForkPoolWorker-8] process shutting down
[INFO/ForkPoolWorker-3] process exiting with exitcode 0
[INFO/ForkPoolWorker-4] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-10] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-7] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-8] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-5] running the remaining "atexit" finalizers
[INFO/ForkPoolWorker-7] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-10] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-9] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-6] running the remaining "atexit" finalizers
[INFO/ForkPoolWorker-5] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-8] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-9] worker exiting after 0 tasks
[INFO/ForkPoolWorker-10] process exiting with exitcode 0
[INFO/ForkPoolWorker-6] process exiting with exitcode 0
[INFO/ForkPoolWorker-8] process exiting with exitcode 0
[INFO/ForkPoolWorker-9] process shutting down
[DEBUG/ForkPoolWorker-9] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-12] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-12] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-13] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-11] worker got sentinel -- exiting
[INFO/ForkPoolWorker-12] process shutting down
[DEBUG/ForkPoolWorker-14] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-13] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-11] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-15] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-12] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-14] worker exiting after 0 tasks
[INFO/ForkPoolWorker-13] process shutting down
[DEBUG/ForkPoolWorker-16] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-15] worker exiting after 0 tasks
[INFO/ForkPoolWorker-11] process shutting down
[DEBUG/ForkPoolWorker-12] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-13] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-16] worker exiting after 0 tasks
[INFO/ForkPoolWorker-14] process shutting down
[DEBUG/ForkPoolWorker-17] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-11] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-18] worker got sentinel -- exiting
[INFO/ForkPoolWorker-15] process shutting down
[INFO/ForkPoolWorker-12] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-14] running all "atexit" finalizers with priority >= 0
[INFO/ForkPoolWorker-16] process shutting down
[DEBUG/ForkPoolWorker-13] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-17] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-15] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-18] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-19] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-16] running all "atexit" finalizers with priority >= 0
[INFO/ForkPoolWorker-13] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-11] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-14] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-15] running the remaining "atexit" finalizers
[INFO/ForkPoolWorker-11] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-19] worker exiting after 0 tasks
[INFO/ForkPoolWorker-17] process shutting down
[INFO/ForkPoolWorker-14] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-16] running the remaining "atexit" finalizers
[INFO/ForkPoolWorker-15] process exiting with exitcode 0
[INFO/ForkPoolWorker-19] process shutting down
[INFO/ForkPoolWorker-16] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-20] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-17] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-19] running all "atexit" finalizers with priority >= 0
[INFO/ForkPoolWorker-18] process shutting down
[DEBUG/ForkPoolWorker-20] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-19] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-18] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-17] running the remaining "atexit" finalizers
[INFO/ForkPoolWorker-20] process shutting down
[DEBUG/ForkPoolWorker-21] worker got sentinel -- exiting
[INFO/ForkPoolWorker-19] process exiting with exitcode 0
[DEBUG/MainProcess] result handler got sentinel
[INFO/ForkPoolWorker-17] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-18] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-20] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-21] worker exiting after 0 tasks
[DEBUG/MainProcess] ensuring that outqueue is not full
[DEBUG/ForkPoolWorker-22] worker got sentinel -- exiting
[INFO/ForkPoolWorker-18] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-20] running the remaining "atexit" finalizers
[INFO/ForkPoolWorker-21] process shutting down
[DEBUG/ForkPoolWorker-23] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-22] worker exiting after 0 tasks
[INFO/ForkPoolWorker-20] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-21] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-23] worker exiting after 0 tasks
[INFO/ForkPoolWorker-22] process shutting down
[DEBUG/ForkPoolWorker-24] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-21] running the remaining "atexit" finalizers
[DEBUG/MainProcess] result handler exiting: len(cache)=0, thread._state=0
[INFO/ForkPoolWorker-23] process shutting down
[DEBUG/ForkPoolWorker-22] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-25] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-24] worker exiting after 0 tasks
[INFO/ForkPoolWorker-21] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-23] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-25] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-22] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-26] worker got sentinel -- exiting
[INFO/ForkPoolWorker-24] process shutting down
[DEBUG/ForkPoolWorker-23] running the remaining "atexit" finalizers
[INFO/ForkPoolWorker-25] process shutting down
[INFO/ForkPoolWorker-22] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-26] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-24] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-27] worker got sentinel -- exiting
[INFO/ForkPoolWorker-23] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-25] running all "atexit" finalizers with priority >= 0
[INFO/ForkPoolWorker-26] process shutting down
[DEBUG/ForkPoolWorker-27] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-24] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-28] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-25] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-26] running all "atexit" finalizers with priority >= 0
[INFO/ForkPoolWorker-24] process exiting with exitcode 0
[INFO/ForkPoolWorker-27] process shutting down
[DEBUG/ForkPoolWorker-28] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-29] worker got sentinel -- exiting
[INFO/ForkPoolWorker-25] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-26] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-27] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-30] worker got sentinel -- exiting
[INFO/ForkPoolWorker-28] process shutting down
[DEBUG/ForkPoolWorker-29] worker exiting after 0 tasks
[INFO/ForkPoolWorker-26] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-31] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-30] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-27] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-28] running all "atexit" finalizers with priority >= 0
[INFO/ForkPoolWorker-29] process shutting down
[DEBUG/ForkPoolWorker-31] worker exiting after 0 tasks
[INFO/ForkPoolWorker-27] process exiting with exitcode 0
[INFO/ForkPoolWorker-30] process shutting down
[DEBUG/ForkPoolWorker-28] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-29] running all "atexit" finalizers with priority >= 0
[INFO/ForkPoolWorker-31] process shutting down
[DEBUG/ForkPoolWorker-30] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-33] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-32] worker got sentinel -- exiting
[INFO/ForkPoolWorker-28] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-29] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-31] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-33] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-30] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-32] worker exiting after 0 tasks
[INFO/ForkPoolWorker-29] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-31] running the remaining "atexit" finalizers
[INFO/ForkPoolWorker-33] process shutting down
[INFO/ForkPoolWorker-30] process exiting with exitcode 0
[INFO/ForkPoolWorker-32] process shutting down
[DEBUG/ForkPoolWorker-34] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-35] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-33] running all "atexit" finalizers with priority >= 0
[INFO/ForkPoolWorker-31] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-32] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-34] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-35] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-33] running the remaining "atexit" finalizers
[INFO/ForkPoolWorker-34] process shutting down
[DEBUG/ForkPoolWorker-32] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-36] worker got sentinel -- exiting
[INFO/ForkPoolWorker-35] process shutting down
[INFO/ForkPoolWorker-33] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-34] running all "atexit" finalizers with priority >= 0
[INFO/ForkPoolWorker-32] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-37] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-35] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-36] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-38] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-34] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-37] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-39] worker got sentinel -- exiting
[INFO/ForkPoolWorker-36] process shutting down
[DEBUG/ForkPoolWorker-35] running the remaining "atexit" finalizers
[INFO/ForkPoolWorker-34] process exiting with exitcode 0
[INFO/ForkPoolWorker-37] process shutting down
[DEBUG/ForkPoolWorker-36] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-38] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-39] worker exiting after 0 tasks
[INFO/ForkPoolWorker-35] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-37] running all "atexit" finalizers with priority >= 0
[INFO/ForkPoolWorker-38] process shutting down
[DEBUG/ForkPoolWorker-36] running the remaining "atexit" finalizers
[INFO/ForkPoolWorker-39] process shutting down
[DEBUG/ForkPoolWorker-37] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-38] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-39] running all "atexit" finalizers with priority >= 0
[INFO/ForkPoolWorker-36] process exiting with exitcode 0
[INFO/ForkPoolWorker-37] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-38] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-39] running the remaining "atexit" finalizers
[INFO/ForkPoolWorker-38] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-9] running the remaining "atexit" finalizers
[INFO/ForkPoolWorker-39] process exiting with exitcode 0
[INFO/ForkPoolWorker-9] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-40] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-41] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-40] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-41] worker exiting after 0 tasks
[INFO/ForkPoolWorker-40] process shutting down
[DEBUG/ForkPoolWorker-40] running all "atexit" finalizers with priority >= 0
[INFO/ForkPoolWorker-41] process shutting down
[DEBUG/ForkPoolWorker-41] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-43] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-40] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-44] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-41] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-43] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-45] worker got sentinel -- exiting
[INFO/ForkPoolWorker-40] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-44] worker exiting after 0 tasks
[INFO/ForkPoolWorker-41] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-45] worker exiting after 0 tasks
[INFO/ForkPoolWorker-43] process shutting down
[INFO/ForkPoolWorker-44] process shutting down
[DEBUG/ForkPoolWorker-43] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-44] running all "atexit" finalizers with priority >= 0
[INFO/ForkPoolWorker-45] process shutting down
[DEBUG/ForkPoolWorker-43] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-45] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-44] running the remaining "atexit" finalizers
[INFO/ForkPoolWorker-43] process exiting with exitcode 0
[INFO/ForkPoolWorker-44] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-45] running the remaining "atexit" finalizers
[INFO/ForkPoolWorker-45] process exiting with exitcode 0
[INFO/ForkPoolWorker-50] child process calling self.run()
[INFO/ForkPoolWorker-49] child process calling self.run()
[DEBUG/ForkPoolWorker-46] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-46] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-1] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-47] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-2] worker got sentinel -- exiting
[INFO/ForkPoolWorker-46] process shutting down
[DEBUG/ForkPoolWorker-1] worker exiting after 1 tasks
[DEBUG/ForkPoolWorker-47] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-2] worker exiting after 1 tasks
[INFO/ForkPoolWorker-1] process shutting down
[INFO/ForkPoolWorker-47] process shutting down
[DEBUG/ForkPoolWorker-46] running all "atexit" finalizers with priority >= 0
[INFO/ForkPoolWorker-2] process shutting down
[DEBUG/ForkPoolWorker-1] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-47] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-2] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-46] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-1] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-47] running the remaining "atexit" finalizers
[INFO/ForkPoolWorker-46] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-2] running the remaining "atexit" finalizers
[INFO/ForkPoolWorker-1] process exiting with exitcode 0
[INFO/ForkPoolWorker-47] process exiting with exitcode 0
[INFO/ForkPoolWorker-2] process exiting with exitcode 0
[DEBUG/MainProcess] task handler exiting
[DEBUG/ForkPoolWorker-50] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-48] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-48] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-50] worker exiting after 0 tasks
[INFO/ForkPoolWorker-48] process shutting down
[INFO/ForkPoolWorker-50] process shutting down
[DEBUG/ForkPoolWorker-49] worker got sentinel -- exiting
[DEBUG/ForkPoolWorker-48] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-50] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-49] worker exiting after 0 tasks
[DEBUG/ForkPoolWorker-50] running the remaining "atexit" finalizers
[DEBUG/ForkPoolWorker-48] running the remaining "atexit" finalizers
[INFO/ForkPoolWorker-49] process shutting down
[INFO/ForkPoolWorker-50] process exiting with exitcode 0
[INFO/ForkPoolWorker-48] process exiting with exitcode 0
[DEBUG/ForkPoolWorker-49] running all "atexit" finalizers with priority >= 0
[DEBUG/ForkPoolWorker-49] running the remaining "atexit" finalizers
[INFO/ForkPoolWorker-49] process exiting with exitcode 0

----------
messages: 326178
nosy: coells
priority: normal
severity: normal
status: open
title: infinite waiting in multiprocessing.Pool
type: behavior
versions: Python 2.7, Python 3.6

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

From report at bugs.python.org  Sun Sep 23 17:38:01 2018
From: report at bugs.python.org (ppperry)
Date: Sun, 23 Sep 2018 21:38:01 +0000
Subject: [New-bugs-announce] [issue34782] Pdb crashes when code is executed
 in a mapping that does not define `__contains__`
Message-ID: <1537738681.57.0.956365154283.issue34782@psf.upfronthosting.co.za>


New submission from ppperry <mapreader at olum.org>:

class FakeContainer:
	def __getitem__(self, key)
		raise KeyError(key)
pdb.run("pass",{},FakeContainer())

Traceback (most recent call last):
  File "<pyshell#5>", line 1, in <module>
    pdb.run("pass",{},FakeContainer())
  File "C:\Program Files\Python37\lib\pdb.py", line 1590, in run
    Pdb().run(statement, globals, locals)
  File "C:\Program Files\Python37\lib\bdb.py", line 585, in run
    exec(cmd, globals, locals)
  File "<string>", line 1, in <module>
  File "<string>", line 1, in <module>
  File "C:\Program Files\Python37\lib\bdb.py", line 88, in trace_dispatch
    return self.dispatch_line(frame)
  File "C:\Program Files\Python37\lib\bdb.py", line 112, in dispatch_line
    self.user_line(frame)
  File "C:\Program Files\Python37\lib\pdb.py", line 261, in user_line
    self.interaction(frame, None)
  File "C:\Program Files\Python37\lib\pdb.py", line 351, in interaction
    self.print_stack_entry(self.stack[self.curindex])
  File "C:\Program Files\Python37\lib\pdb.py", line 1453, in print_stack_entry
    self.format_stack_entry(frame_lineno, prompt_prefix))
  File "C:\Program Files\Python37\lib\bdb.py", line 549, in format_stack_entry
    if '__args__' in frame.f_locals:
  File "<pyshell#3>", line 3, in __getitem__
    raise KeyError
KeyError: 0

Obviously, the debugger shouldn't crash in this case (running code outside of the debugger works as expected, producing a NameError on variable reads and a TypeError whenever a name is assigned).

----------
components: Library (Lib)
messages: 326186
nosy: ppperry
priority: normal
severity: normal
status: open
title: Pdb crashes when code is executed in a mapping that does not define `__contains__`
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Sun Sep 23 20:00:48 2018
From: report at bugs.python.org (eohm)
Date: Mon, 24 Sep 2018 00:00:48 +0000
Subject: [New-bugs-announce] [issue34783] segmentation-fault/core dump when
 try to run non-existing file specified on commandline
Message-ID: <1537747248.54.0.956365154283.issue34783@psf.upfronthosting.co.za>


New submission from eohm <info at eliasohm.de>:

segmentation-fault/core dump when try to run non-existing file specified on commandline (pymain_run_filename)

https://github.com/docker-library/python/issues/320

----------
messages: 326191
nosy: eohm
priority: normal
severity: normal
status: open
title: segmentation-fault/core dump when try to run non-existing file specified on commandline
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Mon Sep 24 03:23:17 2018
From: report at bugs.python.org (Eddie Elizondo)
Date: Mon, 24 Sep 2018 07:23:17 +0000
Subject: [New-bugs-announce] [issue34784] Heap-allocated StructSequences
Message-ID: <1537773797.44.0.956365154283.issue34784@psf.upfronthosting.co.za>


New submission from Eddie Elizondo <eduardo.elizondorueda at gmail.com>:

PyStructSequence_NewType does not currently work. Read the full analysis here: https://mail.python.org/pipermail/python-dev/2018-September/155069.html

This aims to fix the implementation of PyStructSequence_NewType.

----------
components: Library (Lib)
messages: 326205
nosy: eelizondo
priority: normal
severity: normal
status: open
title: Heap-allocated StructSequences
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Mon Sep 24 03:25:19 2018
From: report at bugs.python.org (Jarry Shaw)
Date: Mon, 24 Sep 2018 07:25:19 +0000
Subject: [New-bugs-announce] [issue34785] pty.spawn -- auto-termination
 after child process is dead (a zombie)
Message-ID: <1537773919.52.0.956365154283.issue34785@psf.upfronthosting.co.za>


New submission from Jarry Shaw <jarryshaw at icloud.com>:

As in pty.spawn, once started, the parent process will be hanged, even if the child process is already dead (or a zombie), and must wait for a KeyboardInterrupt or else to terminate the whole process.

Thus, I propose to revise `_copy` function, where the parent process hung, to check if the child process is dead periodically and if so, terminate the whole process then return as shown in the patch file.

----------
components: Library (Lib)
files: pty-diff.patch
keywords: patch
messages: 326206
nosy: jarryshaw
priority: normal
severity: normal
status: open
title: pty.spawn -- auto-termination after child process is dead (a zombie)
type: enhancement
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8
Added file: https://bugs.python.org/file47820/pty-diff.patch

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

From report at bugs.python.org  Mon Sep 24 08:32:16 2018
From: report at bugs.python.org (=?utf-8?b?Sm9uaSBLw6Row6Ryw6Q=?=)
Date: Mon, 24 Sep 2018 12:32:16 +0000
Subject: [New-bugs-announce] [issue34786] ProcessPoolExecutor documentation
 reports wrong exception being raised
Message-ID: <1537792336.1.0.956365154283.issue34786@psf.upfronthosting.co.za>


New submission from Joni K?h?r? <joni.kahara at async.fi>:

https://docs.python.org/3.8/library/concurrent.futures.html

"initializer is an optional callable that is called at the start of each worker process; initargs is a tuple of arguments passed to the initializer. Should initializer raise an exception, all currently pending jobs will raise a BrokenThreadPool, as well any attempt to submit more jobs to the pool."

This should be BrokenProcessPool?

----------
assignee: docs at python
components: Documentation
messages: 326226
nosy: Joni K?h?r?, docs at python
priority: normal
severity: normal
status: open
title: ProcessPoolExecutor documentation reports wrong exception being raised
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Mon Sep 24 10:21:07 2018
From: report at bugs.python.org (lorenzogotuned)
Date: Mon, 24 Sep 2018 14:21:07 +0000
Subject: [New-bugs-announce] [issue34787] imghdr raise TypeError for PNG
Message-ID: <1537798867.67.0.956365154283.issue34787@psf.upfronthosting.co.za>


New submission from lorenzogotuned <tunedconsulting at gmail.com>:

Found on Python 3.6

This line https://github.com/python/cpython/blob/master/Lib/imghdr.py#L45
always raises`TypeError`as `startswith` does not accept bytes.

----------
messages: 326237
nosy: lorenzogotuned
priority: normal
severity: normal
status: open
title: imghdr raise TypeError for PNG
type: crash

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

From report at bugs.python.org  Mon Sep 24 10:30:03 2018
From: report at bugs.python.org (Jeremy McMillan)
Date: Mon, 24 Sep 2018 14:30:03 +0000
Subject: [New-bugs-announce] [issue34788] ipaddress module fails on rfc4007
 scoped IPv6 addresses
Message-ID: <1537799403.03.0.956365154283.issue34788@psf.upfronthosting.co.za>


New submission from Jeremy McMillan <jeremy.mcmillan at gmail.com>:

ipaddress module has no support for scoped IPv6 addresses which prevents the use of ipaddress.ip_address() and ipaddress.IPv6Address() with (always available by default on IPv6 systems) RFC conforming IPv6 link local addresses that specify interface scope.

https://tools.ietf.org/html/rfc4007

This is bad because interface scope is required for connect() and bind() operations on multihomed machines, and virtualized or software defined networking will make this case very common.

eg.

>>> ipaddress.IPv6Address('fe80::dead:dead:beef:ffff')
IPv6Address('fe80::dead:dead:beef:ffff')
>>> ipaddress.IPv6Address('fe80::dead:dead:beef:ffff%eth0')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/ipaddress.py", line 1900, in __init__
    self._ip = self._ip_int_from_string(addr_str)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/ipaddress.py", line 1716, in _ip_int_from_string
    raise AddressValueError("%s in %r" % (exc, ip_str)) from None
ipaddress.AddressValueError: Only hex digits permitted in 'ffff%eth0' in 'fe80::dead:dead:beef:ffff%eth0'
>>> ipaddress.IPv6Interface('fe80::dead:dead:beef:ffff%eth0')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/ipaddress.py", line 2060, in __init__
    IPv6Address.__init__(self, addr[0])
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/ipaddress.py", line 1900, in __init__
    self._ip = self._ip_int_from_string(addr_str)
  File "/opt/local/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/ipaddress.py", line 1716, in _ip_int_from_string
    raise AddressValueError("%s in %r" % (exc, ip_str)) from None
ipaddress.AddressValueError: Only hex digits permitted in 'ffff%eth0' in 'fe80::dead:dead:beef:ffff%eth0'

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 326240
nosy: Jeremy McMillan, docs at python
priority: normal
severity: normal
status: open
title: ipaddress module fails on rfc4007 scoped IPv6 addresses
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/issue34788>
_______________________________________

From report at bugs.python.org  Mon Sep 24 12:04:07 2018
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9s_Delfino?=)
Date: Mon, 24 Sep 2018 16:04:07 +0000
Subject: [New-bugs-announce] [issue34789] doc xml.sax.make_parser expects a
 list not just any sequence
Message-ID: <1537805047.54.0.956365154283.issue34789@psf.upfronthosting.co.za>


New submission from Andr?s Delfino <adelfino at gmail.com>:

Doc says:

"If parser_list is provided, it must be a *sequence* of strings which name modules that have a function named create_parser()"

but code concatenas parser_list with an existing list:

for parser_name in parser_list + default_parser_list:

Fix this by stating parser_list must be a specific kind of sequence, that is, a list.

----------
assignee: docs at python
components: Documentation
messages: 326261
nosy: adelfino, docs at python
priority: normal
severity: normal
status: open
title: doc xml.sax.make_parser expects a list not just any sequence
type: enhancement
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Mon Sep 24 12:42:33 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 24 Sep 2018 16:42:33 +0000
Subject: [New-bugs-announce] [issue34790] Deprecate passing coroutine
 objects to asyncio.wait()
Message-ID: <1537807353.36.0.956365154283.issue34790@psf.upfronthosting.co.za>


New submission from Yury Selivanov <yselivanov at gmail.com>:

asyncio.wait() accepts coroutines, wraps them into Tasks, and later returns those implicitly created Tasks in (done, pending) sets.  This is very confusing to new asyncio users and it's almost impossible to figure out what is going on.  See the first PR to the docs for more info.

Andrew, I think we should deprecate passing coroutines to asyncio.wait() in 3.8, and disallow that in 4.0.

----------
components: asyncio
messages: 326265
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Deprecate passing coroutine objects to asyncio.wait()
type: behavior

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

From report at bugs.python.org  Mon Sep 24 12:47:30 2018
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 24 Sep 2018 16:47:30 +0000
Subject: [New-bugs-announce] [issue34791] xml package does not obey
 sys.flags.ignore_environment
Message-ID: <1537807650.53.0.956365154283.issue34791@psf.upfronthosting.co.za>


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

On two occasions, the xml package uses environment variables to override parser / DOM implementations: xml.sax package and xml.dom.domreg module. On both occasions, the code should not use env vars to override module names, when the interpreter is started with flags like -E or -I.

----------
components: XML
messages: 326267
nosy: christian.heimes
priority: normal
severity: normal
status: open
title: xml package does not obey sys.flags.ignore_environment
type: security
versions: Python 2.7, Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Mon Sep 24 13:58:52 2018
From: report at bugs.python.org (Mark Diekhans)
Date: Mon, 24 Sep 2018 17:58:52 +0000
Subject: [New-bugs-announce] [issue34792] Tutorial doesn''t discuss / and *
 function arguments
Message-ID: <1537811932.84.0.956365154283.issue34792@psf.upfronthosting.co.za>


New submission from Mark Diekhans <markd at kermodei.com>:

https://docs.python.org/3/tutorial/controlflow.html doest not discuss / and * arguments (end of positional, keyword required)

----------
assignee: docs at python
components: Documentation
messages: 326277
nosy: diekhans, docs at python
priority: normal
severity: normal
status: open
title: Tutorial doesn''t discuss / and * function arguments
type: enhancement
versions: Python 3.7

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

From report at bugs.python.org  Mon Sep 24 14:57:32 2018
From: report at bugs.python.org (Yury Selivanov)
Date: Mon, 24 Sep 2018 18:57:32 +0000
Subject: [New-bugs-announce] [issue34793] Raise DeprecationWarning for "with
 (await lock):"
Message-ID: <1537815452.21.0.545547206417.issue34793@psf.upfronthosting.co.za>


Change by Yury Selivanov <yselivanov at gmail.com>:


----------
components: asyncio
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Raise DeprecationWarning for "with (await lock):"
versions: Python 3.8

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

From report at bugs.python.org  Mon Sep 24 17:30:12 2018
From: report at bugs.python.org (David Talkin)
Date: Mon, 24 Sep 2018 21:30:12 +0000
Subject: [New-bugs-announce] [issue34794] memory leak in
 TkApp:_createbytearray
Message-ID: <1537824612.19.0.545547206417.issue34794@psf.upfronthosting.co.za>


New submission from David Talkin <dtalkin at gmail.com>:

The Tkinter.PhotoImage class leaks memory with each change of the 'data' Attribute due to Image calling tk._createbytearray, which allocates memory, but never frees it.

The offending method is in the TkApp class, _createbytearray().

----------
components: Tkinter
messages: 326289
nosy: dtalkin
priority: normal
severity: normal
status: open
title: memory leak in TkApp:_createbytearray
type: resource usage
versions: Python 2.7

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

From report at bugs.python.org  Mon Sep 24 17:40:22 2018
From: report at bugs.python.org (Neil Booth)
Date: Mon, 24 Sep 2018 21:40:22 +0000
Subject: [New-bugs-announce] [issue34795] loop.sock_recv failure because of
 delayed callback handling
Message-ID: <1537825222.42.0.545547206417.issue34795@psf.upfronthosting.co.za>


New submission from Neil Booth <kyuupichan at gmail.com>:

In certain circumstances the coroutine loop.sock_recv() registers a callback internally, which is called on e.g. task cancellation.  The callback assumes a file descriptor that was open and valid at the time the callback was registered is still open and valid when the callback is called, and this need not be the case.  For example, when client code handling exceptions (in particular, cancellation) closes the socket itself.

I have reports of this error for Python 3.6 and 3.7 by a user of my library which uses asyncio, and that bad things happen on both Windows (the event loop dies) and Linux (a traceback happens but no loop death).
It likely happens in earlier versions of Python too but my library requires >= Python 3.6

I hope the above description in addition to pointing out the problematic lines in asyncio make the bug clear.  I tried to produce a simplified testcase but it doesn't trigger the issue on Linux.  I am told it does trigger it on Windows (I don't have Windows to test on).

Here are the problematic lines in selector_events.py where the FD is registered; the callback above them assumes the DF remains valid (but the socket might have been closed in the meantime):

https://github.com/python/cpython/blob/master/Lib/asyncio/selector_events.py#L378-L380

The same problem is evident in sock_recv_into, and perhaps other calls.

Here is code I am told triggers the problem on Windows; it seems to require something a little more complex to trigger reliably on Unix platforms:


import asyncio
import socket


class MyProtocol(asyncio.Protocol):

    def connection_made(self, transport):
        transport.write(b'123')   # just in case a write is needed


port = 6666


async def connect_and_recv(loop, sock):
    try:
        await loop.sock_connect(sock, ('127.0.0.1', port))
        while True:
            await loop.sock_recv(sock, 20)
    except asyncio.CancelledError:
        print("Cancelled")
        sock.close()


async def main(loop):
    server = await loop.create_server(MyProtocol, '127.0.0.1', port)
    sock = socket.socket()
    sock.setblocking(False)
    task = loop.create_task(connect_and_recv(loop, sock))
    await asyncio.sleep(0.1)
    task.cancel()
    await asyncio.sleep(0.1)


loop = asyncio.get_event_loop()
loop.run_until_complete(main(loop))



Here are backtraces from a client application doing things more complex but similar in spirit to the snippet above:

  File "C:\Users\User\AppData\Local\Programs\Python\Python36-32\lib\asyncio\base_events.py", line 455, in run_until_complete
    self.run_forever()
  File "C:\Users\User\AppData\Local\Programs\Python\Python36-32\lib\asyncio\base_events.py", line 422, in run_forever
    self._run_once()
  File "C:\Users\User\AppData\Local\Programs\Python\Python36-32\lib\asyncio\base_events.py", line 1398, in _run_once
    event_list = self._selector.select(timeout)
  File "C:\Users\User\AppData\Local\Programs\Python\Python36-32\lib\selectors.py", line 323, in select
    r, w, _ = self._select(self._readers, self._writers, [], timeout)
  File "C:\Users\User\AppData\Local\Programs\Python\Python36-32\lib\selectors.py", line 314, in _select
    r, w, x = select.select(r, w, w, timeout)
OSError: [WinError 10038] An operation was attempted on something that is not a socket

and one for Linux:

Exception in callback BaseSelectorEventLoop._sock_recv(<Future cancelled>, True, <socket.socke...2049, proto=0>, 5)
handle: <Handle BaseSelectorEventLoop._sock_recv(<Future cancelled>, True, <socket.socke...2049, proto=0>, 5)>
Traceback (most recent call last):
  File "/usr/lib/python3.6/asyncio/events.py", line 127, in _run
    self._callback(*self._args)
  File "/usr/lib/python3.6/asyncio/selector_events.py", line 378, in _sock_recv
    self.remove_reader(fd)
  File "/usr/lib/python3.6/asyncio/selector_events.py", line 342, in remove_reader
    return self._remove_reader(fd)
  File "/usr/lib/python3.6/asyncio/selector_events.py", line 279, in _remove_reader
    key = self._selector.get_key(fd)
  File "/usr/lib/python3.6/selectors.py", line 189, in get_key
    return mapping[fileobj]
  File "/usr/lib/python3.6/selectors.py", line 70, in __getitem__
    fd = self._selector._fileobj_lookup(fileobj)
  File "/usr/lib/python3.6/selectors.py", line 224, in _fileobj_lookup
    return _fileobj_to_fd(fileobj)
  File "/usr/lib/python3.6/selectors.py", line 41, in _fileobj_to_fd
    raise ValueError("Invalid file descriptor: {}".format(fd))
ValueError: Invalid file descriptor: -1

----------
components: asyncio
messages: 326291
nosy: asvetlov, kyuupichan, yselivanov
priority: normal
severity: normal
status: open
title: loop.sock_recv failure because of delayed callback handling
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Mon Sep 24 20:08:44 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 25 Sep 2018 00:08:44 +0000
Subject: [New-bugs-announce] [issue34796] Tkinter scrollbar issues on Mac.
Message-ID: <1537834124.67.0.545547206417.issue34796@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

#34047 was about scrollbar issues on MacOS in 3.7.0 and 3.6.6.  One was due to an IDLE bug, which was fixed on the issue.  Others, which can be demonstrated in the pure tkinter code below, are the subject of this issue.

1. Slider does not move properly when at top or bottom.
2. Clicking trough near slider at top or bottom has no effect.
See #34047 for more discussions and details.

Vlad Tudorache posted the code below as msg323349 of #34047 and attached as tktest.py, along with tkinter_scroll_issues.mov.
---

import tkinter

root = tkinter.Tk()

text = tkinter.Text(root)
vbar = tkinter.Scrollbar(root)

vbar.pack(side=tkinter.RIGHT, fill=tkinter.Y)
text.pack(side=tkinter.LEFT, fill=tkinter.BOTH, expand=1)

text.config(yscrollcommand=vbar.set)
vbar.config(command=text.yview)

lines = ['This is the line number %d.\n' % i for i in range(256)]
text.insert(tkinter.END, ''.join(lines))
 
def click_trace(event):
    text.insert('%d.%d' % (1, 0), 'Clicked at (%d,%d) on %s.\n' % (event.x, event.y, vbar.identify(event.x, event.y)))

vbar.bind('<Button-1>', click_trace)

root.mainloop()
---

"Clicking at the top on the slider shows that the Scrollbar considers it as being on "through1" (in Tk the zone between the upper arrow and the "slider") and NOT on the "slider". Please, play with the script (python3 tktest.py) and see the results for yourselves."

----------
components: Tkinter, macOS
messages: 326299
nosy: ned.deily, ronaldoussoren, serhiy.storchaka, terry.reedy, wordtech
priority: normal
severity: normal
stage: needs patch
status: open
title: Tkinter scrollbar issues on Mac.
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Tue Sep 25 07:55:41 2018
From: report at bugs.python.org (Pablo Galindo Salgado)
Date: Tue, 25 Sep 2018 11:55:41 +0000
Subject: [New-bugs-announce] [issue34797] Convert heapq to the argument
 clinic
Message-ID: <1537876541.13.0.545547206417.issue34797@psf.upfronthosting.co.za>


New submission from Pablo Galindo Salgado <pablogsal at gmail.com>:

Convert the accelerator module `_heapqmodule.c` to the argument clinic.

----------
components: Argument Clinic
messages: 326344
nosy: larry, pablogsal
priority: normal
severity: normal
status: open
title: Convert heapq to the argument clinic
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Tue Sep 25 10:45:41 2018
From: report at bugs.python.org (Nicolas Hug)
Date: Tue, 25 Sep 2018 14:45:41 +0000
Subject: [New-bugs-announce] [issue34798] pprint ignores the compact
 parameter for dicts
Message-ID: <1537886741.82.0.545547206417.issue34798@psf.upfronthosting.co.za>


New submission from Nicolas Hug <niourf at gmail.com>:

Dict representations that exceed the line width are printed with one line per key-value pair, ignoring the compact=True parameter:

>>> pprint.pprint({i: 0 for i in range(15)}, compact=True)
{0: 0,
 1: 0,
 2: 0,
 3: 0,
 4: 0,
 5: 0,
 6: 0,
 7: 0,
 8: 0,
 9: 0,
 10: 0,
 11: 0,
 12: 0,
 13: 0,
 14: 0}

Expected behavior:

>>> pprint.pprint({i: 0 for i in range(15)}, compact=True)
{0: 0, 1: 0, 2: 0, 3: 0, 4: 0, 5: 0, 6: 0, 7: 0, 8: 0, 9: 0, 10: 0, 11: 0,
 12: 0, 13: 0, 14: 0}

Note that lists are correctly compacted, and that dicts that don't exceed line width are printed on a single line, regardless on the compact parameter.

I could try to work on that if needed?

----------
messages: 326358
nosy: Nicolas Hug
priority: normal
severity: normal
status: open
title: pprint ignores the compact parameter for dicts
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Tue Sep 25 11:06:20 2018
From: report at bugs.python.org (Fabio Zadrozny)
Date: Tue, 25 Sep 2018 15:06:20 +0000
Subject: [New-bugs-announce] [issue34799] When function in tracing returns
 None, tracing continues.
Message-ID: <1537887980.13.0.545547206417.issue34799@psf.upfronthosting.co.za>


New submission from Fabio Zadrozny <fabioz at users.sourceforge.net>:

https://docs.python.org/3/library/sys.html#sys.settrace explicitly states:

The local trace function should return a reference to itself (or to another function for further tracing in that scope), or None to turn off tracing in that scope.

Yet, it seems this happens only on the return of a 'call'. If None is returned in a 'line' event, apparently the previous tracing function is reused (but if a new function is returned, the new function is used properly).

I'm attaching a test case which shows the issue. I've tested on 2.7, 3.6 and 3.7 and this issue is present on all.

If I set frame.f_trace = None before returning it seems to work though (so, I think that either this behavior should be fixed or the docs should be updated to reflect that).

----------
files: issue_in_tracing_func.py
messages: 326360
nosy: fabioz
priority: normal
severity: normal
status: open
title: When function in tracing returns None, tracing continues.
type: behavior
versions: Python 2.7, Python 3.6, Python 3.7
Added file: https://bugs.python.org/file47822/issue_in_tracing_func.py

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

From report at bugs.python.org  Tue Sep 25 11:36:08 2018
From: report at bugs.python.org (silane)
Date: Tue, 25 Sep 2018 15:36:08 +0000
Subject: [New-bugs-announce] [issue34800] email.contentmanager raises error
 when policy.max_line_length==None or 0
Message-ID: <1537889768.86.0.545547206417.issue34800@psf.upfronthosting.co.za>


New submission from silane <michiwatsuki at gmail.com>:

The document of the email.policy.Policy says max_line_length=0 or None indicates that no line wrapping should be done at all.
But email.contentmanager doesn't handle this properly and raises error when calling set_content() with bytes or non-ascii str.


---Code to reproduce the bug---

from email.message import EmailMessage
from email.policy import default
msg=EmailMessage(default.clone(max_line_length=None)) # or max_line_length=0

msg.set_content('?') # raise error
# or
msg.set_content(b'a',maintype='application',subtype='octet-stream') # raise error

---


This bug is caused by contentmanager._encode_text() and contentmanager.set_bytes_content().
These don't assume policy.max_line_length to be None or 0.

I tested this on python3.7 3.6 3.5, but probably 3.4 has the same bug.

----------
components: email
messages: 326364
nosy: barry, r.david.murray, silane
priority: normal
severity: normal
status: open
title: email.contentmanager raises error when policy.max_line_length==None or 0
versions: Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Tue Sep 25 14:05:24 2018
From: report at bugs.python.org (Neil Schemenauer)
Date: Tue, 25 Sep 2018 18:05:24 +0000
Subject: [New-bugs-announce] [issue34801] codecs.getreader() splits lines
 containing control characters
Message-ID: <1537898724.68.0.545547206417.issue34801@psf.upfronthosting.co.za>


New submission from Neil Schemenauer <nas-python at arctrix.com>:

This seems to be a bug in codecs.getreader().  io.TextIOWrapper(fp, encoding) works correctly.

----------
files: codecs_bug.py
messages: 326382
nosy: nascheme
priority: low
severity: normal
status: open
title: codecs.getreader() splits lines containing control characters
type: behavior
Added file: https://bugs.python.org/file47823/codecs_bug.py

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

From report at bugs.python.org  Tue Sep 25 16:32:06 2018
From: report at bugs.python.org (Gefn)
Date: Tue, 25 Sep 2018 20:32:06 +0000
Subject: [New-bugs-announce] [issue34802] asyncio.iscoroutine()
 documentation is wrong
Message-ID: <1537907526.37.0.545547206417.issue34802@psf.upfronthosting.co.za>


New submission from Gefn <insomgla at gmail.com>:

The documentation states that "This method is different from inspect.iscoroutine() because it returns True for generator-based coroutines decorated with @coroutine."

It seems to be wrong, a method written as follow:

def test(): yield 1

will be evaluated as a coroutine by asyncio.iscoroutine(), even if not decorated. The old doc stated "Return True if obj is a coroutine object, which may be based on a generator or an async def coroutine.", which seems more correct.

----------
messages: 326404
nosy: Gefn
priority: normal
severity: normal
status: open
title: asyncio.iscoroutine() documentation is wrong
versions: Python 3.7

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

From report at bugs.python.org  Tue Sep 25 18:31:02 2018
From: report at bugs.python.org (Jesse Hostetler)
Date: Tue, 25 Sep 2018 22:31:02 +0000
Subject: [New-bugs-announce] [issue34803] argparse int type does not accept
 scientific notation
Message-ID: <1537914662.44.0.545547206417.issue34803@psf.upfronthosting.co.za>


New submission from Jesse Hostetler <jessehostetler at gmail.com>:

The 'argparse' module gives a parse error for integer arguments written in scientific notation. I would expect this to work, since integers can be constructed from literals in scientific notation.

Example (also attached):

import argparse
foo = int(1e3) # Works: foo = 1000
parser = argparse.ArgumentParser()
parser.add_argument( "--foo", type=int )
parser.parse_args( ["--foo=1e3"] )
# error: argument --foo: invalid int value: '1e3'

----------
components: Library (Lib)
files: argparse-int-scientific.py
messages: 326409
nosy: jessehostetler
priority: normal
severity: normal
status: open
title: argparse int type does not accept scientific notation
type: enhancement
versions: Python 3.7
Added file: https://bugs.python.org/file47824/argparse-int-scientific.py

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

From report at bugs.python.org  Wed Sep 26 01:23:08 2018
From: report at bugs.python.org (Aydin)
Date: Wed, 26 Sep 2018 05:23:08 +0000
Subject: [New-bugs-announce] [issue34804] Repetition of 'for example' in
 documentation
Message-ID: <1537939388.49.0.545547206417.issue34804@psf.upfronthosting.co.za>


New submission from Aydin <bagiyevaydin at gmail.com>:

In the documentation of Python 3.7.0 there is an error in the usage of the world 'for example'.

----------
assignee: docs at python
components: Documentation
files: Functional Programming HOWTO ? Python 3.7.0 documentation.png
messages: 326418
nosy: docs at python, rarblack
priority: normal
severity: normal
status: open
title: Repetition of 'for example' in documentation
versions: Python 3.7
Added file: https://bugs.python.org/file47825/Functional Programming HOWTO ? Python 3.7.0 documentation.png

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

From report at bugs.python.org  Wed Sep 26 02:18:03 2018
From: report at bugs.python.org (=?utf-8?q?Pekka_Kl=C3=A4rck?=)
Date: Wed, 26 Sep 2018 06:18:03 +0000
Subject: [New-bugs-announce] [issue34805] Explicitly specify
 `MyClass.__subclasses__()` returns classes in definition order
Message-ID: <1537942683.07.0.545547206417.issue34805@psf.upfronthosting.co.za>


New submission from Pekka Kl?rck <pekka.klarck at gmail.com>:

I had a use case where `MyClass.__subclasses__()` returning classes in the definition order would have made the code simpler. They seemed to be returned in that order, but because the docs didn't say anything about it [1] I did some searching to find out can I trust the order to stay the same also in the future.

Based on my searches it seems that prior to Python 3.5 the information was stored in a list and that preserved the order. In Python 3.5 the information was stored into a dict for performance reasons as part of issue 17936 [2]. Back then dicts weren't ordered, so the order is undefined in Python 3.5, but in Python 3.6+ the order is again preserved. In practice Python 3.5 is the only current version where the order of `__subclasses__()` is not defined.

My proposal is to make the current, and old, behavior of returning classes from `__subclassses__()` in definition order explicit. If nobody has anything against that, I'd be willing to provide a pull request updating docs and adding unit tests making sure the order is not messed up in the future. Let me also know if even this kind of simple changes would need to go through python-ideas or python-dev. The PEP process feels overkill when there are no code changes required.


PS: I know both Antoine and Guido commented issue 17936 [3] that they don't know any use cases for the order. I can explain my use case if someone is interested.

[1] https://docs.python.org/3/library/stdtypes.html?highlight=__subclasses__#class.__subclasses__
[2] https://bugs.python.org/issue17936
[3] https://bugs.python.org/issue17936#msg189959

----------
messages: 326420
nosy: pekka.klarck
priority: normal
severity: normal
status: open
title: Explicitly specify `MyClass.__subclasses__()` returns classes in definition order

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

From report at bugs.python.org  Wed Sep 26 04:06:20 2018
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 26 Sep 2018 08:06:20 +0000
Subject: [New-bugs-announce] [issue34806] distutils tests fail with recent
 3.7 branch
Message-ID: <1537949180.44.0.545547206417.issue34806@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

two distutils tests fail when running the tests from an installed location. 3.7 branch 20180925, succeeded with a 20180911 snapshot. Is there any locale setting required?

======================================================================
ERROR: test_non_ascii (distutils.tests.test_log.TestLog) (errors='surrogateescape')
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.7/distutils/tests/test_log.py", line 26, in test_non_ascii
    log.debug('D?bug\tM?ss?ge')
  File "/usr/lib/python3.7/distutils/log.py", line 41, in debug
    self._log(DEBUG, msg, args)
  File "/usr/lib/python3.7/distutils/log.py", line 34, in _log
    stream.write('%s\n' % msg)
  File "/usr/lib/python3.7/encodings/cp437.py", line 19, in encode
    return codecs.charmap_encode(input,self.errors,encoding_map)[0]
UnicodeEncodeError: 'charmap' codec can't encode character '\u0117' in position 7: character maps to <undefined>

======================================================================
ERROR: test_find_executable (distutils.tests.test_spawn.SpawnTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python3.7/distutils/tests/test_spawn.py", line 95, in test_find_executable
    rv = find_executable(program)
  File "/usr/lib/python3.7/distutils/spawn.py", line 176, in find_executable
    path = os.environ['PATH']
  File "/usr/lib/python3.7/os.py", line 678, in __getitem__
    raise KeyError(key) from None
KeyError: 'PATH'

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

----------
components: Distutils
keywords: 3.7regression
messages: 326428
nosy: doko, dstufft, eric.araujo, ncoghlan, vstinner
priority: normal
severity: normal
status: open
title: distutils tests fail with recent 3.7 branch
versions: Python 3.7

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

From report at bugs.python.org  Wed Sep 26 04:36:33 2018
From: report at bugs.python.org (Antony Lee)
Date: Wed, 26 Sep 2018 08:36:33 +0000
Subject: [New-bugs-announce] [issue34807] pathlib.[r]glob fails when the
 toplevel directory is not readable, whereas glob.glob "succeeds"
Message-ID: <1537950993.74.0.545547206417.issue34807@psf.upfronthosting.co.za>


New submission from Antony Lee <anntzer.lee at gmail.com>:

After

    $ mkdir -p foo/bar && chmod 000 foo

one gets

    In [1]: glob.glob("foo/bar")
    Out[1]: []

but

    In  [2]: list(Path("foo/bar").glob("*"))

gives a PermissionError.

I'm not arguing that pathlib should reproduce glob's behavior (in fact I think raising an exception is better in this case), but this could be better documented (os.walk does indicate that "By default, errors from the scandir() call are ignored." whereas I don't think either glob or pathlib docs mention this point at all).

Compare with https://bugs.python.org/issue24120, which relates to unreadable directories found *inside* the toplevel directory.

----------
components: Library (Lib)
messages: 326432
nosy: Antony.Lee
priority: normal
severity: normal
status: open
title: pathlib.[r]glob fails when the toplevel directory is not readable, whereas glob.glob "succeeds"
versions: Python 3.7

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

From report at bugs.python.org  Wed Sep 26 07:43:35 2018
From: report at bugs.python.org (ucyo)
Date: Wed, 26 Sep 2018 11:43:35 +0000
Subject: [New-bugs-announce] [issue34808] bytes[0] != bytes[0:1]
Message-ID: <1537962215.0.0.545547206417.issue34808@psf.upfronthosting.co.za>


New submission from ucyo <urcyglu at gmail.com>:

bytes('sdf', 'UTF8')[0] != bytes('sdf', 'UTF8')[0:1]  # FALSE
'sdf'[0] != 'sdf'[0:1]  # TRUE

Is this a feature or bug. I would have expected the same behaviour.

----------
components: Library (Lib)
messages: 326446
nosy: ucyo
priority: normal
severity: normal
status: open
title: bytes[0] != bytes[0:1]
type: behavior
versions: Python 3.6

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

From report at bugs.python.org  Wed Sep 26 08:02:56 2018
From: report at bugs.python.org (Ruslan Kharitonov)
Date: Wed, 26 Sep 2018 12:02:56 +0000
Subject: [New-bugs-announce] [issue34809] On MacOSX with 3.7 python getting
 "Symbol not found: _PyString_AsString"
Message-ID: <1537963376.97.0.545547206417.issue34809@psf.upfronthosting.co.za>


New submission from Ruslan Kharitonov <therk at me.com>:

Getting the following error on MacOSX after installing Python 3.7.0 from the Python download. Also, tried installing from brew.

?  ~ python3
Python 3.7.0 (v3.7.0:1bf9cc5093, Jun 26 2018, 23:26:24)
[Clang 6.0 (clang-600.0.57)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from bin.test import *
>>> help(fetch_words)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/_sitebuiltins.py", line 102, in __call__
    import pydoc
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/pydoc.py", line 66, in <module>
    import platform
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/platform.py", line 116, in <module>
    import sys, os, re, subprocess
  File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/subprocess.py", line 139, in <module>
    import _posixsubprocess
ImportError: dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/_posixsubprocess.so, 2): Symbol not found: _PyString_AsString
  Referenced from: /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/_posixsubprocess.so
  Expected in: flat namespace
 in /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/_posixsubprocess.so

----------
components: macOS
messages: 326451
nosy: ned.deily, ronaldoussoren, therk
priority: normal
severity: normal
status: open
title: On MacOSX with 3.7 python getting "Symbol not found: _PyString_AsString"
versions: Python 3.7

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

From report at bugs.python.org  Wed Sep 26 10:32:06 2018
From: report at bugs.python.org (=?utf-8?q?S=C3=A9bastien_Celles?=)
Date: Wed, 26 Sep 2018 14:32:06 +0000
Subject: [New-bugs-announce] [issue34810] Maximum and minimum value of C
 types integers from Python
Message-ID: <1537972326.01.0.545547206417.issue34810@psf.upfronthosting.co.za>


New submission from S?bastien Celles <s.celles at gmail.com>:

Hello,

I'm looking for a way to get (using Python) the maximum and minimum values of C types integers (ie  uint8, int8, uint16, int16, uint32, int32, uint64, int64...) from Python.

I asked this question on StackOverflow and get a nice answer https://stackoverflow.com/questions/52475749/maximum-and-minimum-value-of-c-types-integers-from-python

but I wonder if this kind of feature couldn't be add directly in `ctypes.c_` as property.

Maybe we could have the following properties:
- `issigned`
- `max`
- `min`

Moreover being able to convert a number into a C type integer raising exception when input data is out of range could also be considered
Maybe using code like https://pastebin.com/cvm95m1x
(instead of silently overflow)

Kind regards

----------
messages: 326467
nosy: scls
priority: normal
severity: normal
status: open
title: Maximum and minimum value of C types integers from Python

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

From report at bugs.python.org  Wed Sep 26 10:37:22 2018
From: report at bugs.python.org (Charalampos Stratakis)
Date: Wed, 26 Sep 2018 14:37:22 +0000
Subject: [New-bugs-announce] [issue34811] test_gdb fails with latest gdb
Message-ID: <1537972642.29.0.545547206417.issue34811@psf.upfronthosting.co.za>


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

In Fedora we got a new build of gdb which makes python's test_gdb fail on x86_64, i686 and aarch64(arm 64 bits) architectures.

gdb's commits between the passing and failing tests:
https://github.com/bminor/binutils-gdb/compare/ab080c102869dd3ad300a99d0c00b256404fd76b...e08ef628a7e3098699ec6939584e2c9f7a9e1952

This is too big of a list, so here is the commits from gdb's python folder:

https://github.com/bminor/binutils-gdb/commits/master/gdb/python

The offensive commits should be between 89fbedf3abc90b62fbb7f08782ed78d87b3fccaa on Aug 18, 2018 and
94c8b7253a5e165ee92f7302f3247764d69b55e5 on Sep 16, 2018

Traceback to follow.

----------
components: Tests
messages: 326469
nosy: cstratak
priority: normal
severity: normal
status: open
title: test_gdb fails with latest gdb

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

From report at bugs.python.org  Wed Sep 26 12:07:03 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 Sep 2018 16:07:03 +0000
Subject: [New-bugs-announce] [issue34812]
 support.args_from_interpreter_flags() doesn't inherit -I (isolated) flag
Message-ID: <1537978023.88.0.545547206417.issue34812@psf.upfronthosting.co.za>


New submission from STINNER Victor <vstinner at redhat.com>:

The support.args_from_interpreter_flags() function recreates Python command line arguments from sys.flags, but it omits -I (sys.flags.isolated).

Because of that, "./python -I -m test ..." behaves differently than "./python -I -m test -j0 ...":
https://bugs.python.org/issue28655#msg326477

----------
components: Library (Lib), Tests
messages: 326478
nosy: vstinner
priority: normal
severity: normal
status: open
title: support.args_from_interpreter_flags() doesn't inherit -I (isolated) flag
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Wed Sep 26 12:42:21 2018
From: report at bugs.python.org (calimeroteknik)
Date: Wed, 26 Sep 2018 16:42:21 +0000
Subject: [New-bugs-announce] [issue34813] child process disappears when
 removing a print statement after its creation
Message-ID: <1537980141.45.0.545547206417.issue34813@psf.upfronthosting.co.za>


New submission from calimeroteknik <calimeroteknik at free.fr>:

When two processes are created and killed, the behaviour is different if print or sleep statements are inserted.
It can also be random (different results executing the same program several times) on certain machines and versions of python.

Attached two versions, one where the child process mysteriously disappears in the cpython interpreter, and another other one that raises ChildProcessError: [Errno 10] No child processes.

This shows up with cpython, all versions I tested (3.7, 3.6, 3.5, 2.7). pypy is unaffected.

----------
files: hang.py
messages: 326485
nosy: calimeroteknik, davin, pitrou
priority: normal
severity: normal
status: open
title: child process disappears when removing a print statement after its creation
type: behavior
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7
Added file: https://bugs.python.org/file47829/hang.py

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

From report at bugs.python.org  Wed Sep 26 12:55:34 2018
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 26 Sep 2018 16:55:34 +0000
Subject: [New-bugs-announce] [issue34814] makesetup: must link C extensions
 to libpython when compiled in shared mode
Message-ID: <1537980934.49.0.545547206417.issue34814@psf.upfronthosting.co.za>


New submission from STINNER Victor <vstinner at redhat.com>:

Python can be compiled in "shared" mode: "./configure --enable-shared", Py_ENABLE_SHARED is defined in pyconfig.h. Most Linux distributions use this configuration.

By default, Python builds most C extensions using setup.py which is based on distutils. The get_libraries() method of Lib/distutils/command/build_ext.py explicity add a dependency to libpythonX.Y if Py_ENABLE_SHARED is defined.

But it is possible to use Modules/Setup to build some C extensions using Makefile rather than setup.py. If "*shared*" is in Modules/Setup, following modules will be compiled as libraries (".so" files on Linux). For example, RHEL and Fedora use this configuration for many C extensions. Problem: C extensions compiled like are not linked to libpython.


Example of the issue on Fedora 28 with Python 2.7:

$ ldd $(python2 -c 'import _struct; print(_struct.__file__)')
	linux-vdso.so.1 (0x00007ffeedf38000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fb4da876000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fb4da4b7000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fb4daca1000)

=> notice the lack of libpython

Python 3.6 is fine:

$ ldd $(python3 -c 'import _struct; print(_struct.__file__)')
	linux-vdso.so.1 (0x00007ffd493dd000)
	libpython3.6m.so.1.0 => /lib64/libpython3.6m.so.1.0 (0x00007f47b9160000)
	...


Patch used by Fedora to build _struct (and other modules) using Makefile:

https://src.fedoraproject.org/rpms/python2/blob/f27/f/python-2.7.1-config.patch



Another example of patch, to build _contextvars as a shared library:

diff --git a/Modules/Setup b/Modules/Setup
index a0622cc8c6..975aeff70d 100644
--- a/Modules/Setup
+++ b/Modules/Setup
@@ -148,7 +148,7 @@ _symtable symtablemodule.c
 # modules are to be built as shared libraries (see above for more
 # detail; also note that *static* or *disabled* cancels this effect):
 
-#*shared*
+*shared*
 
 # GNU readline.  Unlike previous Python incarnations, GNU readline is
 # now incorporated in an optional module, configured in the Setup file
@@ -166,7 +166,7 @@ _symtable symtablemodule.c
 #array arraymodule.c   # array objects
 #cmath cmathmodule.c _math.c # -lm # complex math library functions
 #math mathmodule.c _math.c # -lm # math library functions, e.g. sin()
-#_contextvars _contextvarsmodule.c  # Context Variables
+_contextvars _contextvarsmodule.c  # Context Variables
 #_struct _struct.c     # binary structure packing/unpacking
 #_weakref _weakref.c   # basic weak reference support
 #_testcapi _testcapimodule.c    # Python C API test module


Attached PR fixes Modules/makesetup to:

* (1) Add a dependency on the Makefile target to libpython: to make sure that the parallel compilation works as expected
* (2) Add a dependency to libpythonX.Y on the compiled shared library (".so" file on Linux)

----------
components: Build
messages: 326486
nosy: vstinner
priority: normal
severity: normal
status: open
title: makesetup: must link C extensions to libpython when compiled in shared mode
versions: Python 3.8

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

From report at bugs.python.org  Thu Sep 27 02:11:36 2018
From: report at bugs.python.org (tom.r)
Date: Thu, 27 Sep 2018 06:11:36 +0000
Subject: [New-bugs-announce] [issue34815] Change Py_Ellipse __str__ behavior.
Message-ID: <1538028696.7.0.545547206417.issue34815@psf.upfronthosting.co.za>


New submission from tom.r <tom.p.reichel at gmail.com>:

Added ellipsis_str function to Objects/sliceobject.c such that str(Ellipsis)=='...'.

----------
components: Interpreter Core
files: sliceobject.c
messages: 326522
nosy: photofone
priority: normal
severity: normal
status: open
title: Change Py_Ellipse __str__ behavior.
type: enhancement
versions: Python 3.8
Added file: https://bugs.python.org/file47833/sliceobject.c

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

From report at bugs.python.org  Thu Sep 27 03:14:17 2018
From: report at bugs.python.org (Lars Friedrich)
Date: Thu, 27 Sep 2018 07:14:17 +0000
Subject: [New-bugs-announce] [issue34816] ctypes + hasattr
Message-ID: <1538032457.9.0.545547206417.issue34816@psf.upfronthosting.co.za>


New submission from Lars Friedrich <lars.friedrich at leica-microsystems.com>:

The following creates an OSError:

import ctypes
hasattr(ctypes.windll, 'test')

The expected behavior would be to return "False"

----------
components: ctypes
messages: 326528
nosy: lfriedri
priority: normal
severity: normal
status: open
title: ctypes + hasattr
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Thu Sep 27 03:14:59 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 27 Sep 2018 07:14:59 +0000
Subject: [New-bugs-announce] [issue34817] Ellipsis docs has extra dot in the
 markdown that makes it look like .... (four dots)
Message-ID: <1538032499.31.0.545547206417.issue34817@psf.upfronthosting.co.za>


New submission from Karthikeyan Singaravelan <tir.karthi at gmail.com>:

I looked up the Ellipsis documentation at https://docs.python.org/dev/library/constants.html#Ellipsis which has the below text : 

> The same as .... Special value used mostly in conjunction with extended slicing syntax for user-defined container data types.

The three dots are marked with backtick and look like codeblock but on a light theme it looks like a CSS issue. The backtick contains the actual ellipsis value (...) but the . at the end makes it look like .... especially since I was also using custom dark theme for https://docs.python.org so I thought it was four dots instead of three dots.

Markdown text at https://github.com/python/cpython/blob/master/Doc/library/constants.rst

> The same as ``...``.  Special used mostly in conjunction with extended slicing syntax for user-defined container data types.

It's very trivial but I thought to add a report and I am fine with a won't fix for this. I thought to add a PR but English is not my first language and I don't know if it can worded better. I can change it to "The same as ... which is a special value used mostly in conjunction with extended slicing syntax for user-defined container data types." to avoid the misleading dot and feedback welcome.

Thanks

----------
assignee: docs at python
components: Documentation
messages: 326529
nosy: docs at python, xtreak
priority: normal
severity: normal
status: open
title: Ellipsis docs has extra dot in the markdown that makes it look like .... (four dots)
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Thu Sep 27 05:07:11 2018
From: report at bugs.python.org (Dimitri John Ledkov)
Date: Thu, 27 Sep 2018 09:07:11 +0000
Subject: [New-bugs-announce] [issue34818]
 test.test_ssl.ThreadedTests.test_tls1_3 fails in 2.7 with AttributeError:
 __exit__
Message-ID: <1538039231.16.0.545547206417.issue34818@psf.upfronthosting.co.za>


New submission from Dimitri John Ledkov <dimitri.j.ledkov at intel.com>:

test.test_ssl.ThreadedTests.test_tls1_3 fails in 2.7 with AttributeError: __exit__

When building python 2.7, update to 20180926 from the 2.7 branch, on Ubuntu 18.10 (cosmic) with OpenSSL 1.1.1 the test_ssl errors out like so:

======================================================================
ERROR: test_tls1_3 (test.test_ssl.ThreadedTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib/python2.7/test/test_ssl.py", line 2815, in test_tls1_3
    with context.wrap_socket(socket.socket()) as s:
AttributeError: __exit__

Distribution issue https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1759172

----------
assignee: christian.heimes
components: SSL
messages: 326534
nosy: christian.heimes, xnox
priority: normal
severity: normal
status: open
title: test.test_ssl.ThreadedTests.test_tls1_3 fails in 2.7 with AttributeError: __exit__
versions: Python 2.7

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

From report at bugs.python.org  Thu Sep 27 05:51:51 2018
From: report at bugs.python.org (orlnub123)
Date: Thu, 27 Sep 2018 09:51:51 +0000
Subject: [New-bugs-announce] [issue34819] Executor.map and as_completed
 timeouts are able to deviate
Message-ID: <1538041911.43.0.545547206417.issue34819@psf.upfronthosting.co.za>


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

The map and as_completed functions can randomly timeout earlier or later due to NTP stepping the clock or something changing the time and/or date.

Here's some code to reproduce the issue for map:

import concurrent.futures
import time

with concurrent.futures.ThreadPoolExecutor() as executor:
    list(executor.map(time.sleep, [29, 30], timeout=3000))

And similar code to reproduce it for as_completed:

import concurrent.futures
import time

with concurrent.futures.ThreadPoolExecutor() as executor:
    future1 = executor.submit(time.sleep, 29)
    future2 = executor.submit(time.sleep, 30)
    list(concurrent.futures.as_completed([future1, future2], timeout=3000))

It doesn't error normally, as it shouldn't, but if you move your clock an hour ahead within 30 seconds of running it you get this:

Traceback (most recent call last):
  File "<stdin>", line 2, in <module>
  File "C:\Python\Python37\lib\concurrent\futures\_base.py", line 588, in result_iterator
    yield fs.pop().result(end_time - time.time())
  File "C:\Python\Python37\lib\concurrent\futures\_base.py", line 434, in result
    raise TimeoutError()
concurrent.futures._base.TimeoutError

Or this if you used the as_completed example:

Traceback (most recent call last):
  File "<stdin>", line 4, in <module>
  File "C:\Python\Python37\lib\concurrent\futures\_base.py", line 238, in as_completed
    len(pending), total_futures))
concurrent.futures._base.TimeoutError: 1 (of 2) futures unfinished

The error stems from map and as_completed using time.time to calculate the duration for the timeout. The problem with time.time is that it's adjustable (i.e. it can skip around) which makes it unideal for comparing relative times. A solution would be to replace the time.time calls with either time.monotonic (preferable?) or time.perf_counter.

----------
components: Library (Lib)
messages: 326535
nosy: orlnub123
priority: normal
severity: normal
status: open
title: Executor.map and as_completed timeouts are able to deviate
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Thu Sep 27 09:58:02 2018
From: report at bugs.python.org (wencan)
Date: Thu, 27 Sep 2018 13:58:02 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue34820=5D_binascii=2Ec=3A15?=
 =?utf-8?q?78=3A1=3A_error=3A_the_control_flow_of_function_=E2=80=98binasc?=
 =?utf-8?q?ii=5Fcrc32=E2=80=99_does_not_match_its_profile_data_=28counter_?=
 =?utf-8?b?4oCYYXJjc+KAmSk=?=
Message-ID: <1538056682.62.0.545547206417.issue34820@psf.upfronthosting.co.za>


New submission from wencan <wencan at live.cn>:

git version: a94ee12c26aa8dd7dce01373779df8055aff765b

/home/wencan/Projects/github.com/python/cpython/Modules/binascii.c: In function ?binascii_crc32?:
/home/wencan/Projects/github.com/python/cpython/Modules/binascii.c:1578:1: error: the control flow of function ?binascii_crc32? does not match its profile data (counter ?arcs?) [-Werror=coverage-mismatch]
 }
 ^
/home/wencan/Projects/github.com/python/cpython/Modules/binascii.c:1578:1: error: the control flow of function ?binascii_crc32? does not match its profile data (counter ?time_profiler?) [-Werror=coverage-mismatch]

----------
components: Build
messages: 326563
nosy: wencan
priority: normal
severity: normal
status: open
title: binascii.c:1578:1: error: the control flow of function ?binascii_crc32? does not match its profile data (counter ?arcs?)
type: compile error
versions: Python 3.8

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

From report at bugs.python.org  Thu Sep 27 11:25:48 2018
From: report at bugs.python.org (=?utf-8?b?0JjQs9C+0YDRjCDQndC40LrQuNGC0LjQvQ==?=)
Date: Thu, 27 Sep 2018 15:25:48 +0000
Subject: [New-bugs-announce] [issue34821] Crash after run Python interpreter
 from removed directory
Message-ID: <1538061948.41.0.545547206417.issue34821@psf.upfronthosting.co.za>


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

How to repeat: see screen.

For example, command "lsb_release" is also not found removed directory, but there is no crash.

Python2, in this case, run without problem.

----------
files: python_bug.png
messages: 326567
nosy: ????? ???????
priority: normal
severity: normal
status: open
title: Crash after run Python interpreter from removed directory
type: crash
versions: Python 3.4
Added file: https://bugs.python.org/file47836/python_bug.png

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

From report at bugs.python.org  Thu Sep 27 12:17:40 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Thu, 27 Sep 2018 16:17:40 +0000
Subject: [New-bugs-announce] [issue34822] Simplify AST for slices
Message-ID: <1538065060.28.0.545547206417.issue34822@psf.upfronthosting.co.za>


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

Currently an AST for expressions can have non-terminal nodes of two types: expr and slice. Every of them can be a one of several kinds. A slice can be of kind Index (just an expression), Slice (optional expressions separated by ":") or ExtSlice (slices separated by ",").

For example, the expression "d[a, ..., b:c]" is represented as:

    Subscript(
        Name('d', Load()),
        ExtSlice(
            [
                Index(Name('a', Load())),
                Index(Constant(Ellipsis)),
                Slice(Name('b', Load()), Name('c', Load()), None)
            ]
        ),
        Load()
    )

and the expression "d[a, ..., b]" is represented as:

    Subscript(
        Name('d', Load()),
        Index(
            Tuple(
                [
                    Name('a', Load()),
                    Constant(Ellipsis),
                    Name('b', Load())
                ],
                Load()
            )
        ),
        Load()
    )

(note that ExtSlice is used only if there are slices in subexpressions).

I suggest to get rid of the separate slice type. The Slice kind will be a kind of the expr type instead of the slice type. The ExtSlice kind will be always replaced with a Tuple, even if subexpressions contain slices. Nodes of the Index kind will be replaced with expr nodes to which they are referred. For example, the expression "d[a, ..., b:c]" will be represented as:

    Subscript(
        Name('d', Load()),
        Tuple(
            [
                Name('a', Load()),
                Constant(Ellipsis),
                Slice(Name('b', Load()), Name('c', Load()), None)
            ],
            Load()
        ),
        Load()
    )

This will simplify the code for handling AST, especially the C code. The following PR removes around 400 lines of code (a half of them are generated, but others are handwritten). I hope that this regularization will help to write a general code for walking AST for expressions and remove more duplicated code in ast_opt.c, ast_unparse.c, and symtable.c. This even can help to solve a problem with crashes in handling too deep AST if implement the recursion without using the C stack (but this is dreams).

This change is more breaking than a change in issue32892. What will continue to work:

* The code for creating an AST when pass values as arguments: `Index(value)` will return just `value`, `ExtSlice(slices)` will return `Tuple(slices, Load())`.

* NodeVisitor based processing. Methods visit_Index() and visit_ExtSlice() will be never invoked. The semantic of visit_Slice() will be not changed. visit_Tuple() will be invoked instead of visit_ExtSlice() for extended slices.

* isinstance() and issubclass() checks for Slice. Subclassing of Slice.

What will no longer work (with the current implementation):

* The code that creates empty AST nodes and sets their attributes. `node = Index(); node.value = value` will no longer work.

* The code that reads attributes of just created Index and ExtSlice nodes. `Index(value)` will return just `value` instead of a new object whose attribute "value" is a specified value. A list of subexpressions of ExtSlice(slices) will be accessible as the "elts" attribute instead of "dims" (because it is a Tuple).

* isinstance() and issubclass() checks for Index and ExtSlice will always return False.

* Subclassing of Index and ExtSlice. Instantiating subclasses of Index and ExtSlice will return the same result as for Index and ExtSlice, i.e. not instance of these classes.

* The code that produces a Python code from AST will need to handle indexing with tuples specially (see Tools/parser/unparse.py) because d[(a, b)] is valid syntax (although parenthesis are redundant), but d[(a, b:c)] is not.

Some limitations are caused by the desire for simplicity and can be removed. For example it is possible to add the "dims" alias of "elts" to Tuple, and make subclasses working as before. It is more hard and inefficient to keep isinstance() checks and attribute access for Index. If some breakage for Index is not avoidable, I'm not sure that it is worth to spent efforts for imitating the old behavior for ExtSlice.

----------
components: Interpreter Core, Library (Lib)
messages: 326570
nosy: benjamin.peterson, brett.cannon, gvanrossum, nascheme, ncoghlan, serhiy.storchaka, thautwarm, vstinner, yselivanov
priority: normal
severity: normal
status: open
title: Simplify AST for slices
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Thu Sep 27 12:58:23 2018
From: report at bugs.python.org (Michael Stapelberg)
Date: Thu, 27 Sep 2018 16:58:23 +0000
Subject: [New-bugs-announce] =?utf-8?q?=5Bissue34823=5D_libffi_detection_?=
 =?utf-8?q?doesn=E2=80=99t_work_in_my_setup?=
Message-ID: <1538067503.8.0.545547206417.issue34823@psf.upfronthosting.co.za>


New submission from Michael Stapelberg <michael+python at stapelberg.ch>:

(Tested with Python 3.7, but AFAICT, the situation hasn?t changed in Python 3.8.)

Python?s configure tries to fill the LIBFFI_INCLUDEDIR system variable with the value of -I as returned by pkg-config libffi --cflags-only-I.

Python?s setup.py tries to determine whether libffi is present by searching a couple of well-known library directories.

Both of these checks fail in my environment (think Linux From Scratch). I?m setting the following environment variables:

CPATH=/home/michael/libffi-3.2.1/include
LIBRARY_PATH=/home/michael/libffi-3.2.1/lib64

gcc can build against libffi just fine:

% echo echo '#include <ffi.h>                  
> int main() {}' > foo.c
% gcc -o foo foo.c -lffi
% ldd foo
	linux-vdso.so.1 (0x00007ffe4450a000)
	libffi.so.6 => /home/michael/libffi-3.2.1/lib64/libffi.so.6 (0x00007f3935aba000)
	libc.so.6 => /home/michael/glibc-2.27/lib/libc.so.6 (0x00007f3935902000)
	/lib64/ld-linux-x86-64.so.2 => /home/michael/glibc-2.27/lib/ld-linux-x86-64.so.2 (0x00007f3935aca000)

However, when compiling Python, I?m getting the following error message, resulting in the _ctypes module not being built:

INFO: Could not locate ffi libs and/or headers

Now, one issue is that pkg-config understands CPATH, so calling pkg-config --cflags-only-I is not sufficient to obtain the include directory, one also needs to clear CPATH:

% pkg-config libffi --cflags-only-I      

% CPATH= pkg-config libffi --cflags-only-I
-I/home/michael/libffi-3.2.1/include

After patching this in configure, LIBFFI_INCLUDEDIR is set correctly, but the build still fails, as the libffi shared object is located in my non-standard path, which setup.py doesn?t check.

Without knowing much about the Python internals, it seems to me that both of these issues would be fixed if Python stopped trying to find the libffi include/lib locations and just used pkg-config to detect the required CFLAGS and LDFLAGS, just like Python currently does with openssl.

Is there any reason we can?t use pkg-config for libffi like that?

Thanks!

----------
components: Installation
messages: 326572
nosy: stapelberg
priority: normal
severity: normal
status: open
title: libffi detection doesn?t work in my setup
type: compile error
versions: Python 3.7

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

From report at bugs.python.org  Thu Sep 27 13:07:57 2018
From: report at bugs.python.org (Zackery Spytz)
Date: Thu, 27 Sep 2018 17:07:57 +0000
Subject: [New-bugs-announce] [issue34824] _ssl.c: Possible null pointer
 dereference
Message-ID: <1538068077.13.0.545547206417.issue34824@psf.upfronthosting.co.za>


New submission from Zackery Spytz <zspytz at gmail.com>:

If _PyBytes_Resize() fails in _ssl_MemoryBIO_read_impl(), Py_DECREF() will be called on a null pointer.

----------
assignee: christian.heimes
components: Extension Modules, SSL
messages: 326573
nosy: ZackerySpytz, christian.heimes
priority: normal
severity: normal
status: open
title: _ssl.c: Possible null pointer dereference
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Thu Sep 27 14:00:22 2018
From: report at bugs.python.org (Karthikeyan Singaravelan)
Date: Thu, 27 Sep 2018 18:00:22 +0000
Subject: [New-bugs-announce] [issue34825] Add more entries to os module to
 pathlib reference table
Message-ID: <1538071222.64.0.545547206417.issue34825@psf.upfronthosting.co.za>


New submission from Karthikeyan Singaravelan <tir.karthi at gmail.com>:

I found issue33194 where unlink from pathlib can be used to delete a file or symlink similar to os.unlink or os.remove but the visibility for the function was low. I found there is a reference table with os module functions and their equivalent pathlib methods. I think this can be improved by adding an entry for Path.unlink as an equivalent for os.remove and os.unlink. I would suggest adding some more functions to this table. The added functions are as below : 

:func:`os.chmod`                       :meth:`Path.chmod`
:func:`os.mkdir`                       :meth:`Path.mkdir`
:func:`os.rename`                      :meth:`Path.rename`
:func:`os.replace`                     :meth:`Path.replace`
:func:`os.rmdir`                       :meth:`Path.rmdir`
:func:`os.remove`, :func:`os.unlink`   :meth:`Path.unlink` 
:func:`os.path.samefile`               :meth:`Path.samefile`

The only issue is that some functions have a dir_fd=None in os module and I think this table is used for functions that do equivalent actions and not as drop-in replacements with equal type signatures. Feedback welcome. Since the table is present only on 3.7 and master I am leaving 3.6 for versions. I will push a PR shortly for this.

Thanks

----------
assignee: docs at python
components: Documentation
messages: 326577
nosy: docs at python, xtreak
priority: normal
severity: normal
status: open
title: Add more entries to os module to pathlib reference table
type: enhancement
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Thu Sep 27 18:58:54 2018
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 27 Sep 2018 22:58:54 +0000
Subject: [New-bugs-announce] [issue34826] io.BufferedReader crashes in 2.7
 on memoryview attribute access
Message-ID: <1538089134.67.0.545547206417.issue34826@psf.upfronthosting.co.za>


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

The following test code segfaults on Python 2.7:

```python
import io
class X(io.RawIOBase):
  def readable(self):
    return True
  def readinto(self, b):
    if isinstance(b, memoryview):
      print(b.format)  # XXX boom, crashes here.
    return 0

io.BufferedReader(X()).read(8)
```

The crash happens on the b.format attribute access.

This does not happen on 3.6.

----------
components: IO, Library (Lib)
messages: 326597
nosy: gregory.p.smith
priority: normal
severity: normal
stage: needs patch
status: open
title: io.BufferedReader crashes in 2.7 on memoryview attribute access
type: crash
versions: Python 2.7

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

From report at bugs.python.org  Fri Sep 28 01:44:33 2018
From: report at bugs.python.org (Micheal Taylor)
Date: Fri, 28 Sep 2018 05:44:33 +0000
Subject: [New-bugs-announce] [issue34827] Make argparse.NameSpace iterable
Message-ID: <1538113473.95.0.545547206417.issue34827@psf.upfronthosting.co.za>


New submission from Micheal Taylor <bubthegreat at gmail.com>:

There was an issue to make argparse.Namespace iterable with a specific intent on being able to convert it to a dictionary (https://bugs.python.org/issue8982).  Additionally there was another improvement request to make it accessible like a dictionary.  (https://bugs.python.org/issue8979)

While vars(args) and args.thing do accomplish the needs, I'm really lazy, and would like the object to be more accessible - for instance, if I will always need to access every attribute (because I make a small namespace that fits a simple script, making it iterable would be convenient.  It's also more convenient to use the typical **thing syntax for passing it into functions if all the attributes are required for different things.  This keeps code within the functions that would use it simpler, because we no longer need to reference args.thing, we can reference thing directly within the function it's been passed to.  vars(args) does accomplish this, but it is arguably not as familiar for folks as the more "familiar" syntax of **args.

----------
components: Library (Lib)
messages: 326605
nosy: bubthegreat
priority: normal
severity: normal
status: open
title: Make argparse.NameSpace iterable
versions: Python 3.6

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

From report at bugs.python.org  Fri Sep 28 02:51:55 2018
From: report at bugs.python.org (Joel Klimont)
Date: Fri, 28 Sep 2018 06:51:55 +0000
Subject: [New-bugs-announce] [issue34828] sqlite.iterdump does not work for
 (most) databases with autoincrement
Message-ID: <1538117515.33.0.545547206417.issue34828@psf.upfronthosting.co.za>


New submission from Joel Klimont <joel.klimont at gmail.com>:

There is a bug in sqlite3/dump.py when wanting to dump databases that use autoincrement in one or more tables.

The problem is that the iterdump command assumes that the table "sqlite_sequence" is present in the new database in which the old one is dumped into.

>From the sqlite3 documentation:
"SQLite keeps track of the largest ROWID using an internal table named "sqlite_sequence". The sqlite_sequence table is created and initialized automatically whenever a normal table that contains an AUTOINCREMENT column is created. The content of the sqlite_sequence table can be modified using ordinary UPDATE, INSERT, and DELETE statements."
Source: https://sqlite.org/autoinc.html#the_autoincrement_keyword

Example:
BEGIN TRANSACTION;
CREATE TABLE "posts" (
    id int primary key
);
INSERT INTO "posts" VALUES(0);
CREATE TABLE "tags" (
    id integer primary key autoincrement,
    tag varchar(256) unique,
    post int references posts
);
INSERT INTO "tags" VALUES(NULL, "test", 0);
COMMIT;

The following code should work but because of the assumption that "sqlite_sequence" exists it will fail:

>> import sqlite3
>> cx = sqlite3.connect("test.db")
>> for i in cx.iterdump():
>>    print i
>> cx2 = sqlite3.connect(":memory:")
>> query = "".join(line for line in cx.iterdump())
>> cx2.executescript(query)

Exception:
Traceback (most recent call last):
  File "/home/test.py", line 10, in <module>
    cx2.executescript(query)
sqlite3.OperationalError: no such table: sqlite_sequence

Here is the ouput of cx.iterdrump()
BEGIN TRANSACTION;
CREATE TABLE "posts" (
    id int primary key
);
INSERT INTO "posts" VALUES(0);
DELETE FROM "sqlite_sequence";
INSERT INTO "sqlite_sequence" VALUES('tags',1);
CREATE TABLE "tags" (
    id integer primary key autoincrement,
    tag varchar(256) unique,
    post int references posts
);
INSERT INTO "tags" VALUES(1,'test',0);
COMMIT;

As you can see the problem is that "DELETE FROM "sqlite_sequence";" and "INSERT INTO "sqlite_sequence" VALUES('tags',1);" are put into the dump before that table even exists. They should be put at the end of the transaction. (Like the sqlite3 command ".dump" does.)
Note that some databases that use autoincrement will work as it could be that a table with autoincrement is created before the sqlite_sequence commands are put into the dump.

File: https://github.com/python/cpython/blob/master/Lib/sqlite3/dump.py

I have already forked the repository, written tests etc. and if you want I will create a pull request.

----------
components: Library (Lib)
messages: 326610
nosy: itssme
priority: normal
severity: normal
status: open
title: sqlite.iterdump does not work for (most) databases with autoincrement
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/issue34828>
_______________________________________

From report at bugs.python.org  Fri Sep 28 04:37:55 2018
From: report at bugs.python.org (Juliette Monsel)
Date: Fri, 28 Sep 2018 08:37:55 +0000
Subject: [New-bugs-announce] [issue34829] Add missing selection_ methods to
 tkinter Spinbox
Message-ID: <1538123875.3.0.545547206417.issue34829@psf.upfronthosting.co.za>


New submission from Juliette Monsel <j_4321 at protonmail.com>:

Though the text area of the tkinter Spinbox behaves like an Entry, the methods selection_from, selection_range, selection_present and selection_to have not been implemented. So for consistency with the Entry widget, I suggest to add them.

----------
components: Tkinter
messages: 326614
nosy: j-4321-i
priority: normal
severity: normal
status: open
title: Add missing selection_ methods to tkinter Spinbox
type: enhancement

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

From report at bugs.python.org  Fri Sep 28 05:20:44 2018
From: report at bugs.python.org (Julien Palard)
Date: Fri, 28 Sep 2018 09:20:44 +0000
Subject: [New-bugs-announce] [issue34830] functools.partial is weak
 referncable
Message-ID: <1538126444.59.0.545547206417.issue34830@psf.upfronthosting.co.za>


New submission from Julien Palard <julien+python at palard.fr>:

According to the doc:

    :class:`partial` objects are like :class:`function` objects in that they are callable, weak referencable, and can have attributes.

I don't understand why "weak" here, and it's the only occurence of "weak referencable" in the documentation.

I don't see an object in Python being referencable but NOT weak referencable, do I miss something obvious here?

----------
assignee: docs at python
components: Documentation
messages: 326617
nosy: docs at python, mdk
priority: normal
severity: normal
status: open
title: functools.partial is weak referncable
type: enhancement
versions: Python 3.7

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

From report at bugs.python.org  Fri Sep 28 07:36:17 2018
From: report at bugs.python.org (Caleb Hattingh)
Date: Fri, 28 Sep 2018 11:36:17 +0000
Subject: [New-bugs-announce] [issue34831] Asyncio Tutorial
Message-ID: <1538134577.09.0.545547206417.issue34831@psf.upfronthosting.co.za>


New submission from Caleb Hattingh <caleb.hattingh at gmail.com>:

Hi Yury,

As discussed, below is a very rough outline of a proposed TOC for an asyncio tutorial. No content has been written yet (only what you see below). I think we should nail down the TOC first.

Asyncio Tutorial
================

Proposed Table of Contents:

- Why asyncio?
    - Reason #1: thread safety by not using threads at all.
    - Reason #2: very many concurrent socket connections, which threads
      make cumbersome.
    - Demo: concurrency without threads
        - (only goals here are to *briefly* introduce the syntax, and then
          demonstrate concurrency without threads)
        - show two tasks, one prints out integers 0-9, while the other
          prints out letters of the alphabet, A-I.
        - pose the question: "they're running concurrently but we're
          not using threads: how is that possible?"
        - explain that there is a thing called an "event loop" behind
          the scenes that allows execution to switch between the two
          every time one of them "waits".
        - emphasize that you can easily spot where the switch can happen,
          it is where you see the "await" keyword. Switches will occur
          nowhere else.

- The difference between functions and `async def` functions
    - async & await
        - show `async def` functions, compare to `def` functions.  
        - use inspect module to show what things actually are, e.g. function,
          coroutine function, coroutine, generator function, generator,
          asynchronous generator function, asynchronous generator.
        - point out you can only use "await" inside an async def fn
        - point out that `await <x>` is an expression, and you can
          use it in most places any other expression can be used.

- How to run `async def` functions
    - point out there are two different issues: (a) `async def` functions
      can call other functions, and other `async def` functions using
      `await`, but also, (b) how to "get started" with the first
      `async def` function? Answer: run the event loop.
    - show `asyncio.run()`, in particular running an `async def main()`
      function, which itself can call others.

- Dealing with concurrent functions
    - (This is maybe too similar to the new docs in the section
      https://docs.python.org/3/library/asyncio-task.html?highlight=asyncio%20run#coroutines-and-tasks)
    - What if you want to run an `async def` function, but you don't
      want to wait for it? Answer: create a "task" for it.
    - What if you want to run multiple functions concurrently, and you
      do want to wait for all of them to finish? Answer: use `gather`
      or `wait()`

- Case Study: chat server/client (my proposal)
    - (goal is to walk through building a realistic example of using 
      asyncio)
    - (This will be a lot more fun than a web-crawler. Web-crawlers are
      super boring!)
    - (I'm pretty confident the size of the code can be kept small. A 
      lot can be done in under 50 lines, as I showed in the case studies
      in my book)
    - server uses streams API
    - server receives many long-lived connections
    - user can create/join a "room", and then start typing messages.
      Other connected clients in the same room will see the messages.
    - client implementation has some options:
        - could use Tkinter gui, using streams API in an event loop 
          on a separate thread. (This would show how asyncio isn't some 
          alien thing, but is part of python. Would also show how to 
          set up asyncio to work in a separate thread. Finally, would not
          require any external dependencies, only the stdlib is needed
          for the entire case study.)
        - could use a browser client, connecting back to the server 
          over a websocket connection. (This might seem simpler, but 
          in fact introduces a lot more complexity than just using
          tkinter. We need to bring in html, css, probably some js and
          probably also a third-party websockets python library. I feel
          like it isn't a good fit for a stdlib python tutorial, but it 
          is a more modern approach.)
        - there are not a lot of other options. terminal-based client 
          might be possible, but probably hard, not cross-platform, and 
          will be unappealing to many people. 
    - When describing the code, point out:
        - you have to choose a "message protocol" (size-prefixed is fine)
        - you must put `send` and `recv` in separate tasks
        - server will "keep track" of connected clients and the room
          (or rooms?) they've joined
        - startup and shutdown, specific references to the new `run()`
          function
        - <others>?

----------
assignee: docs at python
components: Documentation, asyncio
messages: 326628
nosy: asvetlov, cjrh, docs at python, willingc, yselivanov
priority: normal
severity: normal
status: open
title: Asyncio Tutorial
type: enhancement
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Fri Sep 28 08:20:13 2018
From: report at bugs.python.org (Michael Harris)
Date: Fri, 28 Sep 2018 12:20:13 +0000
Subject: [New-bugs-announce] [issue34832] "Short circuiting" in base64's
 b64decode, decode, decodebytes
Message-ID: <1538137213.36.0.545547206417.issue34832@psf.upfronthosting.co.za>


New submission from Michael Harris <pw.michael.harris at gmail.com>:

When given an invalid base64 string that starts with a valid base64 substring, the functions will return the decoded bytes only up to the substring rather then ignoring the non-alphabet character.

Examples:
>>> base64.b64decode("AAAAAAAA")
b'\x00\x00\x00\x00\x00\x00'
>>> base64.b64decode("AA=AAAAAA")
b'\x00\x00\x00\x00\x00\x00'
>>> base64.b64decode("AAA=AAAAA")
b'\x00\x00'

----------
components: Library (Lib)
messages: 326630
nosy: pw.michael.harris
priority: normal
severity: normal
status: open
title: "Short circuiting" in base64's b64decode, decode, decodebytes
type: behavior
versions: Python 3.5

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

From report at bugs.python.org  Fri Sep 28 09:09:48 2018
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 28 Sep 2018 13:09:48 +0000
Subject: [New-bugs-announce] [issue34833] [CI] Azure Pipeline: Initialize
 Agent failed
Message-ID: <1538140188.61.0.545547206417.issue34833@psf.upfronthosting.co.za>


New submission from STINNER Victor <vstinner at redhat.com>:

Error: "Initialize Agent failed". Sorry... I don't see any additional information, only this error message...

Failed build:
https://python.visualstudio.com/cpython/_build/results?buildId=31597&view=logs

Source:
https://github.com/python/cpython/pull/9619

It's not the first time that I see this issue.

----------
components: Tests
messages: 326633
nosy: steve.dower, vstinner
priority: normal
severity: normal
status: open
title: [CI] Azure Pipeline: Initialize Agent failed
versions: Python 3.8

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

From report at bugs.python.org  Fri Sep 28 12:14:56 2018
From: report at bugs.python.org (Dimitri John Ledkov)
Date: Fri, 28 Sep 2018 16:14:56 +0000
Subject: [New-bugs-announce] [issue34834] test_ssl.test_options does not
 correctly account for built-in ctx defaults with openssl 1.1.1
Message-ID: <1538151296.99.0.545547206417.issue34834@psf.upfronthosting.co.za>


New submission from Dimitri John Ledkov <dimitri.j.ledkov at intel.com>:

self.assertEqual(default, ctx.options) in test_options fails with openssl 1.1.1 as it does not correctly account for OP_ENABLE_MIDDLEBOX_COMPAT. It is not defined by the python2.7 ssl module either.

either ssl.OP_ENABLE_MIDDLEBOX_COMPAT needs to be backported, or the test case should just add that constant in when openssl version is >= 1.1.1

----------
messages: 326642
nosy: xnox
priority: normal
severity: normal
status: open
title: test_ssl.test_options does not correctly account for built-in ctx defaults with openssl 1.1.1
versions: Python 2.7

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

From report at bugs.python.org  Fri Sep 28 12:26:40 2018
From: report at bugs.python.org (Dr_Zaszus)
Date: Fri, 28 Sep 2018 16:26:40 +0000
Subject: [New-bugs-announce] [issue34835] Multiprocessing module update
 fails with pip3
Message-ID: <1538152000.15.0.545547206417.issue34835@psf.upfronthosting.co.za>


New submission from Dr_Zaszus <asserov at gmail.com>:

pip3 install --upgrade multiprocessing 

fails with a python2 error in 'setup.py': 
       print 'Macros:'
                     ^
   SyntaxError: Missing parentheses in call to 'print'. Did you mean print('Macros:')?

----------
components: Installation
messages: 326643
nosy: Dr_Zaszus
priority: normal
severity: normal
status: open
title: Multiprocessing module update fails with pip3
versions: Python 3.7

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

From report at bugs.python.org  Fri Sep 28 12:32:44 2018
From: report at bugs.python.org (Dimitri John Ledkov)
Date: Fri, 28 Sep 2018 16:32:44 +0000
Subject: [New-bugs-announce] [issue34836] test_ssl.test_default_ecdh_curve
 needs no tls1.3 flag in 2.7, for now
Message-ID: <1538152364.12.0.545547206417.issue34836@psf.upfronthosting.co.za>


New submission from Dimitri John Ledkov <dimitri.j.ledkov at intel.com>:

test_default_ecdh_curve fails, as ssl.OP_NO_TLSv1_3 is not set on the context. and the test case can only work with non-tls1.3 connections.

this indicates that the pull request that sprinkled ssl.OP_NO_TLSv1_3 everywhere was not backported, taking into account all the other backports that did subsequently remove those flags in many test cases.

at the moment that test case is failing, but it would be nice if it didn't.

----------
messages: 326644
nosy: xnox
priority: normal
severity: normal
status: open
title: test_ssl.test_default_ecdh_curve needs no tls1.3 flag in 2.7, for now
versions: Python 2.7

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

From report at bugs.python.org  Fri Sep 28 16:04:13 2018
From: report at bugs.python.org (Sean Harrington)
Date: Fri, 28 Sep 2018 20:04:13 +0000
Subject: [New-bugs-announce] [issue34837] Multiprocessing.pool API Extension
 - Non-Global Initialization of Workers
Message-ID: <1538165053.48.0.545547206417.issue34837@psf.upfronthosting.co.za>


Change by Sean Harrington <seanharr11 at gmail.com>:


----------
components: Library (Lib)
nosy: seanharr11
priority: normal
severity: normal
status: open
title: Multiprocessing.pool API Extension - Non-Global Initialization of Workers
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Fri Sep 28 17:15:58 2018
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 28 Sep 2018 21:15:58 +0000
Subject: [New-bugs-announce] [issue34838] Improve arg clinic code generation
 for cases with type checking
Message-ID: <1538169358.96.0.545547206417.issue34838@psf.upfronthosting.co.za>


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

An arg clinic specification such as

    p: object(subclass_of='&PyTuple_Type')

generates slow code using _PyArg_ParseStack() that has to parse a format string like "O!" to decide to make a type check.  Instead, it should directly generate a branch-predictable test for the type check and then call the much quicker function _PyArg_UnpackStack().

See https://github.com/python/cpython/pull/9628 for an example of this change giving a 30% speedup.

----------
components: Argument Clinic
messages: 326659
nosy: larry, rhettinger, serhiy.storchaka, vstinner
priority: low
severity: normal
status: open
title: Improve arg clinic code generation for cases with type checking
type: performance
versions: Python 3.8

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

From report at bugs.python.org  Fri Sep 28 20:18:04 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 29 Sep 2018 00:18:04 +0000
Subject: [New-bugs-announce] [issue34839] doctest: Change example under
 warnings section
Message-ID: <1538180284.16.0.545547206417.issue34839@psf.upfronthosting.co.za>


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

The Warnings section of the doctest documentation (https://docs.python.org/3.8/library/doctest.html#warnings) contains an example that the printing order of a dictionary is not guaranteed.  Since it is now guaranteed to be insertion order, perhaps the example should be changed.

----------
assignee: docs at python
components: Documentation
messages: 326663
nosy: cheryl.sabella, docs at python
priority: normal
severity: normal
status: open
title: doctest: Change example under warnings section
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Sat Sep 29 02:38:06 2018
From: report at bugs.python.org (shuoz)
Date: Sat, 29 Sep 2018 06:38:06 +0000
Subject: [New-bugs-announce] [issue34840] dlopen() error with no error
 message from dlerror()
Message-ID: <1538203086.61.0.545547206417.issue34840@psf.upfronthosting.co.za>


New submission from shuoz <zzw20124321 at gmail.com>:

python _ctypes.dlclose(arg). 
Never check the arg  so we get a Segmentation fault (core dumped)

poc.py
```
import _ctypes
_ctypes.dlclose(3)  # 3-4294967296
```
python poc.py


gdb info

```
----------------------------------registers-----------------------------------]
RAX: 0x7ffff7ffcca0 --> 0x40d0d00000000 
RBX: 0x0 
RCX: 0x7ffff6a49fd0 (<dlclose_doit>:	mov    rax,QWORD PTR [rip+0x201fe1]        # 0x7ffff6c4bfb8)
RDX: 0x2e10a0bf96213a9d 
RSI: 0x0 
RDI: 0x3 
RBP: 0x7ffff6a49fd0 (<dlclose_doit>:	mov    rax,QWORD PTR [rip+0x201fe1]        # 0x7ffff6c4bfb8)
RSP: 0x7fffffffd280 --> 0x0 
RIP: 0x7ffff7dee161 (<_dl_close+1>:	test   BYTE PTR [rdi+0x3d4],0x8)
R8 : 0x3 
R9 : 0x7ffff6a49fd0 (<dlclose_doit>:	mov    rax,QWORD PTR [rip+0x201fe1]        # 0x7ffff6c4bfb8)
R10: 0xc55dc0 --> 0x31 ('1')
R11: 0x7ffff7eec3d8 --> 0x9 ('\t')
R12: 0x3 
R13: 0x7ffff7e952b0 --> 0x1 
R14: 0x7ffff2d12140 (<py_dl_close>:	push   r14)
R15: 0x7ffff7e17228 --> 0x16
EFLAGS: 0x10246 (carry PARITY adjust ZERO sign trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
   0x7ffff7dee152:	nop    DWORD PTR [rax+0x0]
   0x7ffff7dee156:	nop    WORD PTR cs:[rax+rax*1+0x0]
   0x7ffff7dee160 <_dl_close>:	push   rbx
=> 0x7ffff7dee161 <_dl_close+1>:	test   BYTE PTR [rdi+0x3d4],0x8
   0x7ffff7dee168 <_dl_close+8>:	mov    rbx,rdi
   0x7ffff7dee16b <_dl_close+11>:	jne    0x7ffff7dee210 <_dl_close+176>
   0x7ffff7dee171 <_dl_close+17>:	mov    edx,DWORD PTR [rdi+0x310]
   0x7ffff7dee177 <_dl_close+23>:	test   edx,edx
[------------------------------------stack-------------------------------------]
0000| 0x7fffffffd280 --> 0x0 
0008| 0x7fffffffd288 --> 0x7ffff7de7564 (<_dl_catch_error+116>:	mov    rax,QWORD PTR [rsp+0x8])
0016| 0x7fffffffd290 --> 0x0 
0024| 0x7fffffffd298 --> 0x7ffff7fd8720 --> 0x7fffffffd2e0 --> 0x7ffff737f690 --> 0x0 
0032| 0x7fffffffd2a0 --> 0x0 
0040| 0x7fffffffd2a8 --> 0x7ffff737f690 --> 0x0 
0048| 0x7fffffffd2b0 --> 0x7ffff737f698 --> 0x0 
0056| 0x7fffffffd2b8 --> 0x7ffff737f688 --> 0x0 
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
Stopped reason: SIGSEGV
_dl_close (_map=0x3) at dl-close.c:809
809	dl-close.c: No such file or directory.
gdb-peda$ bt
```

----------
components: ctypes
messages: 326668
nosy: shuoz
priority: normal
severity: normal
status: open
title: dlopen() error with no error message from dlerror()
type: crash
versions: Python 3.5

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

From report at bugs.python.org  Sat Sep 29 03:49:04 2018
From: report at bugs.python.org (Simon Sapin)
Date: Sat, 29 Sep 2018 07:49:04 +0000
Subject: [New-bugs-announce] =?utf-8?b?W2lzc3VlMzQ4NDFdIFNjcmlwdOKAmXMg?=
 =?utf-8?q?directory_not_in_sys=2Epath_with_embeddable_Windows_distributio?=
 =?utf-8?q?n?=
Message-ID: <1538207344.54.0.545547206417.issue34841@psf.upfronthosting.co.za>


New submission from Simon Sapin <simon.sapin at exyr.org>:

https://docs.python.org/3/library/sys.html#sys.path documents:

> As initialized upon program startup, the first item of this list, path[0], is the directory containing the script that was used to invoke the Python interpreter.

On Windows with an embeddable zip file distribution, this does not happen.

Steps to reproduce:

* Create a foo.py file that contains `import bar`
* Create an empty bar.py file
* With your usual Python installed from the "normal" executable installer, check that `python foo.py` runs without output or error
* Download and extract https://www.python.org/ftp/python/3.7.0/python-3.7.0-embed-amd64.zip
* Run `..\python-3.7.0-embed-amd64\python foo.py`

Expected result:

The script runs again without output or error.

Actual result:

Traceback (most recent call last):
  File "foo.py", line 1, in <module>
    import bar
ModuleNotFoundError: No module named 'bar'


This might be an occurrence of https://bugs.python.org/issue33698, since the embeddable distribution has a python37._pth file that contains "python37.zip" and "."

print(sys.path) shows [
  'C:\\Users\\example\\python-3.7.0-embed-amd64\\python37.zip',
  'C:\\Users\\example\\python-3.7.0-embed-amd64'
]

This StackOverflow question describes the same issue: https://stackoverflow.com/q/51403126/1162888

----------
messages: 326671
nosy: ssapin
priority: normal
severity: normal
status: open
title: Script?s directory not in sys.path with embeddable Windows distribution
type: behavior

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

From report at bugs.python.org  Sat Sep 29 05:29:49 2018
From: report at bugs.python.org (Dan Snider)
Date: Sat, 29 Sep 2018 09:29:49 +0000
Subject: [New-bugs-announce] [issue34842] Incorrect error messages in bisect
Message-ID: <1538213389.56.0.545547206417.issue34842@psf.upfronthosting.co.za>


New submission from Dan Snider <mr.assume.away at gmail.com>:

internal_bisect_left and internal_bisect_right use PySequence_Size when a "hi" argument wasn't provided, which causes this silly error message:

    >>> bisect.bisect_right(dict.fromkeys(range(10)), 5)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: object of type 'dict' has no len()

They could use PyObject_Size and let PySequence_GetItem in the loop catch the error:

    >>> bisect.bisect_right(dict.fromkeys(range(10)), 5, 0, 10)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: 'dict' object does not support indexing

Since that actually makes sense and is more efficient / less verbose than adding a PySequence_Check.

----------
components: Interpreter Core
messages: 326672
nosy: bup
priority: normal
severity: normal
status: open
title: Incorrect error messages in bisect
versions: Python 3.6, Python 3.7

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

From report at bugs.python.org  Sat Sep 29 09:28:22 2018
From: report at bugs.python.org (Cheryl Sabella)
Date: Sat, 29 Sep 2018 13:28:22 +0000
Subject: [New-bugs-announce] [issue34843] logging cookbook docs: remove
 'recent' when referring to multiprocessing
Message-ID: <1538227702.53.0.545547206417.issue34843@psf.upfronthosting.co.za>


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

In the logging cookbook docs, the word 'recent' is used to describe versions of Python containing the multiprocessing module.  Since multiprocessing is 10 years old, I think it may be safe to remove the word 'recent'.

----------
assignee: docs at python
components: Documentation
messages: 326676
nosy: cheryl.sabella, docs at python
priority: normal
severity: normal
status: open
title: logging cookbook docs: remove 'recent' when referring to multiprocessing
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Sat Sep 29 16:17:10 2018
From: report at bugs.python.org (Luna Chen)
Date: Sat, 29 Sep 2018 20:17:10 +0000
Subject: [New-bugs-announce] [issue34844] logging.Formatter enhancement -
 Checking on style and
Message-ID: <1538252230.83.0.545547206417.issue34844@psf.upfronthosting.co.za>


New submission from Luna Chen <luna at bnmetrics.com>:

Issue: Currently logging.Formatter does not check if the format passed in is valid style or if the field is valid when creating the logging.Formatter object. It would be nice to have such check in the constructor of the logging.Formatter.

Here are 2 scenarios:

Scenario 1: Passing in invalid `fmt` when creating the logging.Formatter.
Example:
    import logging
    logger = logging.getLogger('my_logger')
    handler = logging.StreamHandler()

    fmt = logging.Formatter("blah-blah", style="{")
    handler.setFormatter(fmt)

    logger.addHandler(handler)
    logger.setLevel(logging.DEBUG)

    logger.info('This is my logging message.')

The above example would output the fmt string("blah-blah") whenever a logging operation is performed, such as `logging.info`, `logging.warning`.
And this goes the same for mismatching style and fmt, like so:
    fmt = logging.Formatter("{asctime}-{message}", style="%")


Scenario 2: Passing in invalid fields to logging.Formatter

    import logging
    logger = logging.getLogger('my_logger')
    handler = logging.StreamHandler()

    fmt = logging.Formatter("%(FuncName)s-%(message)s")
    handler.setFormatter(fmt)

    logger.addHandler(handler)
    logger.setLevel(logging.DEBUG)

    logger.info('This is my logging message.'
)
As you can see from the above example, the "%(FuncName)s" field is misspelled with a capital "F", which should have been a lowercase "f". In this scenario, we would get an interesting stacktrace:

--- Logging error ---
Traceback (most recent call last):
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/logging/__init__.py", line 992, in emit
    msg = self.format(record)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/logging/__init__.py", line 838, in format
    return fmt.format(record)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/logging/__init__.py", line 578, in format
    s = self.formatMessage(record)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/logging/__init__.py", line 547, in formatMessage
    return self._style.format(record)
  File "/Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/logging/__init__.py", line 391, in format
    return self._fmt % record.__dict__
KeyError: 'FuncName'
Call stack:
  File "<stdin>", line 1, in <module>
Message: 'This is my logging message.'
Arguments: ()

Personally, I think the "KeyError" here can be misleading and confusing to some. 



Proposal:

I would like to make a PR with the following changes:
- Checking fmt to match the style in the constructor of logging.Formatting
- When calling log message functions such as "logger.info()", an "extra" key word arg can be passed for custom format fields, 
  for example:
  fmt = logging.Formatter("{cpuUsage} - {message}", style="{") # In this case, cpuUsage would be custom
  logger.info("my logging message", extra={"cpuUsage": "my_cpu_usage"})

  - I would like to have custom fields passed in as an additional (optional) argument into the constructor for logging.Formatter
  - Another option is to have an additional member method for adding additional fields
  - I think we could essentially have both options
  - With this, we can remove the "extra" argument in Logger.makeRecord()


Draw Backs:

- This change might essentially break some existing code where someone might use the "extra" argument in log message functions, as we would do the check on logging.Formatter level



Please let me know your thoughts, and I thought it would be nice to get some new ideas and areas I haven't thought about before I make this PR.


Best regards,
Luna Chen (BNMetrics)

----------
components: Library (Lib)
messages: 326690
nosy: BNMetrics, gvanrossum
priority: normal
severity: normal
status: open
title: logging.Formatter enhancement - Checking on style and
type: enhancement
versions: Python 3.6

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

From report at bugs.python.org  Sat Sep 29 18:05:23 2018
From: report at bugs.python.org (thautwarm)
Date: Sat, 29 Sep 2018 22:05:23 +0000
Subject: [New-bugs-announce] [issue34845] allow exprlist as the iterators of
 comprehensions to be consistent with for statements
Message-ID: <1538258723.92.0.545547206417.issue34845@psf.upfronthosting.co.za>


New submission from thautwarm <yaoxiansamma at gmail.com>:

Currently we can use `exprlist` as the iterator in a `for` 
statement:

  ```
  for i in 1, 2,:
     print(i)

  1
  2
  ```

  However, when it comes to comprehension expressions:

  ```
  [i for i in 1, 2]

  SyntaxError: invalid syntax
  ```

  I know there might be some reason that leads to the absence of the consistency between `for` expression and statement, but IMO until now it could be better to allow `exprlist` to be the iterator of comprehensions. I'm not sure whether our community has noticed this problem so I'm to propose it here.

  A crucial benefit from this change is that we can avoid the ambiguity when a comprehension is accepted as function parameter.

  ```
  f(for i in [1, 2, 3], 1, 2)
  ```
  We now get a SyntaxError when writing such codes, but people who know this syntax might think the parameters can be distinguished from each other, but it's still not allowed. 
  
  Allowing `exprlist` to be the iterator slot of a comprehension would be a rational solution. If `f(for i in [1, 2, 3], 1, 2)` is equivalent to `f(for i ([1, 2, 3], 1, 2))`, it will be natural to restrict the number of parameters to be just 1 when the parameter is a comprehension.

  You can slightly accept this workaround and try following examples:
  ```
  f(for i in 1,)
  f(for i in 1, for j in 2, 3,)
  f(for i in 1, 2 if cond(i) for j in 3, for k in 4,)
  ```
  Obviously, in each of above cases, the number of parameters is 1,
just because a `exprlist` could the iterator of a comprehension.

  The disadvantage of this change is, there is not too many related use cases, for any `[expr for target in iter_elem1, iter_elem2, ...]` could be altered as `[expr for target in (iter_elem1, iter_elem2, ...)]`. Meanwhile, that might not be true when it comes to someone works frequently with interactive python.
 
  
  Finally, I have finished this implementation at https://github.com/thautwarm/cpython/tree/exprlist-in-comprehensions, and I do want to make contributions to cpython projects. If most of you feel comfortable with this change, may I make a PR next?

----------
messages: 326692
nosy: gvanrossum, serhiy.storchaka, thautwarm, yselivanov
priority: normal
severity: normal
status: open
title: allow exprlist as the iterators of comprehensions to be consistent with for statements

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

From report at bugs.python.org  Sat Sep 29 22:15:16 2018
From: report at bugs.python.org (Satheesh Thomas)
Date: Sun, 30 Sep 2018 02:15:16 +0000
Subject: [New-bugs-announce] [issue34846] Runtime failure with Failed to
 import site module
Message-ID: <1538273716.55.0.545547206417.issue34846@psf.upfronthosting.co.za>


New submission from Satheesh Thomas <sat.tho at gmail.com>:

Run time failure to execute python scripts. It was running for long time without any issue . But sometimes get this error which stops the entire execution. Looks like some .pyc file got corrupted .

----------
components: Build
files: Python error1.png
messages: 326697
nosy: sat.tho at gmail.com
priority: normal
severity: normal
status: open
title: Runtime failure with Failed to import site module
type: crash
versions: Python 3.5
Added file: https://bugs.python.org/file47837/Python error1.png

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

From report at bugs.python.org  Sat Sep 29 23:52:14 2018
From: report at bugs.python.org (Fantix King)
Date: Sun, 30 Sep 2018 03:52:14 +0000
Subject: [New-bugs-announce] [issue34847] asyncio: Add PHA for TLS 1.3
Message-ID: <1538279534.68.0.545547206417.issue34847@psf.upfronthosting.co.za>


New submission from Fantix King <fantix.king at gmail.com>:

This was raised in GH-9460 where the same post handshake authentication (PHA) was added to the ssl module. It should be added to asyncio too. This issue is to discuss the design of PHA API in asyncio, and implement it in Python 3.8.

One approach is to add _SSLProtocolTransport.verify_client_post_handshake(), but an additional new transport mixin type to asyncio/transports.py would be needed (Yury).

Yury also proposed another option to use get_extra_info() API to get something like an "SSLExtra" object with additional APIs.

----------
components: asyncio
messages: 326700
nosy: asvetlov, fantix, yselivanov
priority: normal
severity: normal
status: open
title: asyncio: Add PHA for TLS 1.3
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Sat Sep 29 23:55:38 2018
From: report at bugs.python.org (Dan Snider)
Date: Sun, 30 Sep 2018 03:55:38 +0000
Subject: [New-bugs-announce] [issue34848] range.index only takes one
 argument when it's documented as taking the usual 3
Message-ID: <1538279738.27.0.545547206417.issue34848@psf.upfronthosting.co.za>


New submission from Dan Snider <mr.assume.away at gmail.com>:

Unfortunately, it looks like there's no requirement for an abc.Sequence to implement the 3 argument form of seq.index, so I suppose this is technically just a documentation bug...

>>> range(5).index(2, 1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: index() takes exactly one argument (2 given)

>>> help(range.index)
Help on method_descriptor:

index(...)
    rangeobject.index(value, [start, [stop]]) -> integer -- return index of value.
    Raise ValueError if the value is not present.

----------
assignee: docs at python
components: Argument Clinic, Documentation
messages: 326701
nosy: bup, docs at python, larry
priority: normal
severity: normal
status: open
title: range.index only takes one argument when it's documented as taking the usual 3
versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7

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

From report at bugs.python.org  Sun Sep 30 01:04:51 2018
From: report at bugs.python.org (Andrew Svetlov)
Date: Sun, 30 Sep 2018 05:04:51 +0000
Subject: [New-bugs-announce] [issue34849] Drop logging when asyncio waits in
 selector.select()
Message-ID: <1538283891.7.0.545547206417.issue34849@psf.upfronthosting.co.za>


New submission from Andrew Svetlov <andrew.svetlov at gmail.com>:

The waiting is the pretty normal case: no IO is performed and no immediate activities are scheduled.

Therefore logging such cases is just a noise.

----------
components: asyncio
messages: 326702
nosy: asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Drop logging when asyncio waits in selector.select()
type: behavior
versions: Python 3.8

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

From report at bugs.python.org  Sun Sep 30 04:15:19 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 30 Sep 2018 08:15:19 +0000
Subject: [New-bugs-announce] [issue34850] Emit a syntax warning for "is"
 with a literal
Message-ID: <1538295319.77.0.545547206417.issue34850@psf.upfronthosting.co.za>


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

Gregory have noticed that the "is" and "is not" operator sometimes is used with string and numerical literals. This code "works" on CPython by accident, because of caching on different levels (small integers and strings caches, interned strings, deduplicating constants at compile time). But it shouldn't work on other implementations, and can not work even on early or future CPython versions.

https://discuss.python.org/t/demoting-the-is-operator-to-avoid-an-identity-crisis/86

I think that the adequate solution of this issue is not demoting the "is" operator, but emitting a syntax warning. In general, this is a work for third-party checkers. But many people don't use checkers for their one-time scripts, using "is" with a literal is always a mistake, and it is easy to add a check for this in the compiler.

Currently the compiler emits SyntaxWarning only for parenthesis in assert: `assert(x, "msg")`. But in earlier versions there were more warnings (they are errors). In 3.8 yet one SyntaxWarning will be added instead of DeprecationWarning for unknown escape sequences in string literals.

The proposed PR makes the compiler emitting a SyntaxWarning when the "is" or "is not" operators are used with a constant (except singletons None, False, True and ...). A warning will be replaced with a SyntaxError if the warnings system is configured to raise errors. This is because SyntaxError contains more information and provides better traceback. The same change was made for "assert(...)". Added tests, including tests for "assert(...)".

Barry have noted that using the "==" operator with None can be also classified as an error. But I think that in this case there may be legal uses of this, and the compiler should not complain. It is a work for third-party checkers, which can provide configuration options for enabling and disabling particular kinds of checks.

----------
components: Interpreter Core
messages: 326714
nosy: barry, gregory.p.smith, gvanrossum, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Emit a syntax warning for "is" with a literal
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Sun Sep 30 04:37:44 2018
From: report at bugs.python.org (Bnaya)
Date: Sun, 30 Sep 2018 08:37:44 +0000
Subject: [New-bugs-announce] [issue34851] re.error - for the search function
 in the re module
Message-ID: <1538296664.11.0.545547206417.issue34851@psf.upfronthosting.co.za>


New submission from Bnaya <bnaya.honig at gmail.com>:

I was writing the following:
re.search('([+-*])', "54  *  83")

And I got the following runtime error:
Traceback (most recent call last):
  File "<input>", line 1, in <module>
  File "C:\Users\bnaya\AppData\Local\Programs\Python\Python37-32\lib\re.py", line 183, in search
    return _compile(pattern, flags).search(string)
  File "C:\Users\bnaya\AppData\Local\Programs\Python\Python37-32\lib\re.py", line 286, in _compile
    p = sre_compile.compile(pattern, flags)
  File "C:\Users\bnaya\AppData\Local\Programs\Python\Python37-32\lib\sre_compile.py", line 764, in compile
    p = sre_parse.parse(p, flags)
  File "C:\Users\bnaya\AppData\Local\Programs\Python\Python37-32\lib\sre_parse.py", line 930, in parse
    p = _parse_sub(source, pattern, flags & SRE_FLAG_VERBOSE, 0)
  File "C:\Users\bnaya\AppData\Local\Programs\Python\Python37-32\lib\sre_parse.py", line 426, in _parse_sub
    not nested and not items))
  File "C:\Users\bnaya\AppData\Local\Programs\Python\Python37-32\lib\sre_parse.py", line 816, in _parse
    p = _parse_sub(source, state, sub_verbose, nested + 1)
  File "C:\Users\bnaya\AppData\Local\Programs\Python\Python37-32\lib\sre_parse.py", line 426, in _parse_sub
    not nested and not items))
  File "C:\Users\bnaya\AppData\Local\Programs\Python\Python37-32\lib\sre_parse.py", line 580, in _parse
    raise source.error(msg, len(this) + 1 + len(that))
re.error: bad character range +-* at position 2

Note that for different operators order, such as:
re.search('([+*-])', "54  *  83")
or
re.search('([*+-])', "54  *  83")
the function worked just fine.

----------
components: Regular Expressions
messages: 326716
nosy: Bnaya, ezio.melotti, mrabarnett
priority: normal
severity: normal
status: open
title: re.error - for the search function in the re module
type: crash
versions: Python 3.7

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

From report at bugs.python.org  Sun Sep 30 10:16:34 2018
From: report at bugs.python.org (Aymeric Augustin)
Date: Sun, 30 Sep 2018 14:16:34 +0000
Subject: [New-bugs-announce] [issue34852] Counter-intuitive behavior of
 Server.close() / wait_closed()
Message-ID: <1538316994.45.0.545547206417.issue34852@psf.upfronthosting.co.za>


New submission from Aymeric Augustin <aymeric.augustin at m4x.org>:

**Summary**

1. Is it correct for `Server.wait_closed()` (as implemented in asyncio) to be a no-op after `Server.close()`?
2. How can I tell that all incoming connections have been received by `connection_made()` after `Server.close()`?

**Details**

After calling `Server.close()`, `_sockets is None`, which makes `Server.wait_closed()` a no-op: it returns immediately without doing anything (as mentioned in https://bugs.python.org/issue33727).

I'm not sure why the docs suggest to call `wait_closed()` after `close()` if it's a no-op. My best guess is: "this design supports third-party event loops that requires an asynchronous API for closing servers, but the built-in event loops don't need that". Does someone know?

I wrote a very simple server that merely accepts connections. I ran experiments where I saturate the server with incoming client connections and close it. I checked what happens around `close()` (and `wait_closed()` -- but as it doesn't do anything after `close()` I'll just say `close()` from now on.)

The current implementation appears to work as documented, assuming an rather low level interpretation of the docs of `Server.close()`.

> Stop serving: close listening sockets and set the sockets attribute to None.

Correct -- I'm not seeing any `accept` calls in `BaseSelectorEventLoop._accept_connection` after `close()`.

> The sockets that represent existing incoming client connections are left open.

Correct -- if "existing incoming client connections" is interpreted as "client connections that have gone through `accept`".

> The server is closed asynchronously, use the wait_closed() coroutine to wait until the server is closed.
 
I'm seeing calls to `connection_made()` _after_ `close()` because `BaseSelectorEventLoop._accept_connection2` triggers `connection_made()` asynchronously with `call_soon()`.

This is surprising for someone approaching asyncio from the public API rather than the internal implementation. `connection_made()` is the first contact with new connections. The concept of "an existing incoming client connection for which `connection_made()` wasn't called yet" is unexpected.

This has practical consequences.

Consider a server that keeps track of established connections via `connection_made` and `connection_lost`. If this server calls `Server.close()`, awaits `Server.wait_closed()`, makes a list of established connections and terminates them, there's no guarantee that all connections will be closed. Indeed, new connections may appear and call `connection_made()` after `close()` and `wait_closed()` returned!

`wait_closed()` seems ineffective for this use case.

----------
components: asyncio
messages: 326725
nosy: asvetlov, aymeric.augustin, yselivanov
priority: normal
severity: normal
status: open
title: Counter-intuitive behavior of Server.close() / wait_closed()
type: behavior
versions: Python 3.7

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

From report at bugs.python.org  Sun Sep 30 10:50:10 2018
From: report at bugs.python.org (Anel Hodzic)
Date: Sun, 30 Sep 2018 14:50:10 +0000
Subject: [New-bugs-announce] [issue34853] Python django cors
Message-ID: <1538319010.84.0.545547206417.issue34853@psf.upfronthosting.co.za>


New submission from Anel Hodzic <programeranel at gmail.com>:

API call gives the desired response when trying through browser or postman. 

from rest_framework import generics
from django.shortcuts import get_object_or_404
from .jsonserializer import GroupSerializer, SubgroupSerializer, ProductsSerializer
from .models import pGroups, pSubgroups, Products
from flask import Flask
from flask_cors import CORS

app = Flask(__name__)
CORS(app)

@app.route("/Group/")
# @cross_origin()

# Create your views here.

class GroupList(generics.ListCreateAPIView):
    queryset = pGroups.objects.all()
    serializer_class = GroupSerializer

But when i try to make that call using JQuery

let dropdown = $('#locality-dropdown');

dropdown.empty();

dropdown.append('<option selected="true" disabled>Choose product group</option>');
dropdown.prop('selectedIndex', 0);

const url = 'http://127.0.0.1:8000/Group/';

// Populate dropdown with list of provinces
$.getJSON(url, function (data) {
  $.each(data, function (key, entry) {
    console.log(entry.name);
    dropdown.append($('<option></option>').attr('value', entry.abbreviation).text(entry.name));
  })
});

I get the output :

Failed to load http://127.0.0.1:8000/Group/: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access.

Trying to set up the FLASK-CORS https://flask-cors.readthedocs.io/en/latest/

Im complete beginner in web programming

----------
messages: 326726
nosy: Anel Hodzic
priority: normal
severity: normal
status: open
title: Python django cors

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

From report at bugs.python.org  Sun Sep 30 12:25:00 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 30 Sep 2018 16:25:00 +0000
Subject: [New-bugs-announce] [issue34854] Crash in string annotations in
 lambda with keyword-only argument without default value
Message-ID: <1538324700.29.0.545547206417.issue34854@psf.upfronthosting.co.za>


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

Compiling a string annotation containing a lambda with keyword-only argument without default value causes a crash.

from __future__ import annotations
def f() -> (lambda *, x: x): pass

The following PR fixes this crash. It also fixes other errors:

* Removes a space between "lambda" and ":" in the representation of lambda without argument.

* Removes the final "*" (it is incorrect syntax) in the representation of lambda without *args and keyword-only arguments when compile from AST.

----------
components: Interpreter Core
messages: 326730
nosy: gvanrossum, lukasz.langa, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Crash in string annotations in lambda with keyword-only argument without default value
type: crash
versions: Python 3.7, Python 3.8

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

From report at bugs.python.org  Sun Sep 30 13:55:56 2018
From: report at bugs.python.org (Eric Lindblad)
Date: Sun, 30 Sep 2018 17:55:56 +0000
Subject: [New-bugs-announce] [issue34855] batch file variables
Message-ID: <1538330156.86.0.545547206417.issue34855@psf.upfronthosting.co.za>


New submission from Eric Lindblad <lindblad at gmx.com>:

The development version code can set the variable EXTERNALS_DIR in two .bat files, but nowhere in a .bat file is set the variable EXTERNAL_DIR, the latter appearing in find_python.bat. I am not a Powershell user and so cannot interpret the content of the file .azure-pipelines/windows-steps.yml, where the variable EXTERNAL_DIR likewise appears, but, being familiar solely with .bat files would question whether a misprint had occurred in the below commit, as "%EXTERNAL_DIR%" rather than "%EXTERNALS_DIR%"?

https://github.com/python/cpython/commit/68d663cf85d1ac5eaf83482eed39c0a6f8093601#diff-60f6a0e6e49e5990c3ad465771fff9cd

committed on GitHub Jul 17, 2017

----------
components: Build
messages: 326735
nosy: lindblad
priority: normal
severity: normal
status: open
title: batch file variables
versions: Python 3.8

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

From report at bugs.python.org  Sun Sep 30 14:14:23 2018
From: report at bugs.python.org (Serhiy Storchaka)
Date: Sun, 30 Sep 2018 18:14:23 +0000
Subject: [New-bugs-announce] [issue34856] Make the repr of lambda containing
 the signature and body expression.
Message-ID: <1538331263.14.0.545547206417.issue34856@psf.upfronthosting.co.za>


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

>>> f = lambda x, y=1: x+y
>>> f
<lambda x, y=1: x + y at 0x7f437cd27890>

Currently it is less informative: "<function <lambda> at 0x7f437cd27890>".

----------
components: Interpreter Core
messages: 326738
nosy: gvanrossum, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Make the repr of lambda containing the signature and body expression.
type: enhancement
versions: Python 3.8

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

From report at bugs.python.org  Sun Sep 30 16:10:30 2018
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 30 Sep 2018 20:10:30 +0000
Subject: [New-bugs-announce] [issue34857] IDLE: SyntaxWarning not handled
 properly
Message-ID: <1538338230.46.0.545547206417.issue34857@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

In 3.6.6, """compile("assert (0, 'bad')", '', 'single')""" in Python or IDLE emits "SyntaxWarning: assertion is always true, perhaps remove parentheses?".

In Python,
>>> assert (0, 'bad')
<stdin>:1: SyntaxWarning: assertion is always true, perhaps remove parentheses?

In IDLE's Shell, the same statement is effectively treated as incomplete in that newlines are echoed and IDLE waits for input until something is entered.  KeyboardInterrupt (^C) or any text terminate the loop.  In the latter case, "SyntaxError: multiple statements found while compiling a single statement" is printed.

In a file, the statement has no effect, but the warning should be printed in the shell.

----------
assignee: terry.reedy
components: IDLE
messages: 326745
nosy: terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: IDLE: SyntaxWarning not handled properly
type: behavior
versions: Python 3.6, Python 3.7, Python 3.8

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

From report at bugs.python.org  Sun Sep 30 21:56:32 2018
From: report at bugs.python.org (Michael Smith)
Date: Mon, 01 Oct 2018 01:56:32 +0000
Subject: [New-bugs-announce] [issue34858] MappingProxy objects should JSON
 serialize just like a dictionary
Message-ID: <1538358992.7.0.545547206417.issue34858@psf.upfronthosting.co.za>


New submission from Michael Smith <michael at smith-li.com>:

If a mappingproxy object is a read-only proxy to a mapping, would it make sense for them to JSON serialize just like the mapping they come from? Currently, json.dumps throws the "I don't know how to serialize this" error:

$ python -c 'import json
> import types
> json.dumps(types.MappingProxyType({}))'
Traceback (most recent call last):
  File "<string>", line 3, in <module>
  File "/usr/lib64/python3.6/json/__init__.py", line 231, in dumps
    return _default_encoder.encode(obj)
  File "/usr/lib64/python3.6/json/encoder.py", line 199, in encode
    chunks = self.iterencode(o, _one_shot=True)
  File "/usr/lib64/python3.6/json/encoder.py", line 257, in iterencode
    return _iterencode(o, 0)
  File "/usr/lib64/python3.6/json/encoder.py", line 180, in default
    o.__class__.__name__)
TypeError: Object of type 'mappingproxy' is not JSON serializable

----------
components: Library (Lib)
messages: 326756
nosy: Michael Smith2
priority: normal
severity: normal
status: open
title: MappingProxy objects should JSON serialize just like a dictionary
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/issue34858>
_______________________________________